Category: Agile
Challenges in Agile Project Management
Gayathri Ramamoorthy

Gayathri is a proven Project Manager with experience spanning over a decade in the IT industry in all areas of the SDLC. A strong end to end technical and functional background has enabled Gayathri to perform multiple roles such as Delivery Lead, Project Manager, Solution designer and Technical Consultant over the span of her career.

In last few years, we have been hearing the word ‘Agile’ frequently in the project delivery workspace. Quite often, we had constructive debates and interesting discussions among colleagues on challenges in Agile projects. Common concerns were – lack of ownership from team, mixed signals from senior management and ineffective cost management. I would like to share my experience where we applied agile methodology to a project aiming to deliver the functionalities/features quicker for the business to use and the challenges we encountered.

The project was initiated to develop new reports for a business unit to measure their sales performance. The data required to build the report was sourced from a datawarehouse which hosted the consolidated transactional data from various source systems. The project scope was to develop reports and to implement the required business rules and data transformation. The project applied agile techniques to deliver the reports in an iterative deployment schedule. The features required in the reports were listed and prioritised by the business sponsor and the sprint period was 4 weeks. In Agile methodology, sprint is the time period within which a selected list of feature is completed and made ready for business use.

In an agile project environment where the team is set of highly skilled developers, a sponsor who was supporting the team to follow agile framework, a management team who applied the agile techniques appropriately, what could go wrong in such agile project? In spite of an optimistic agile environment, there were still challenges.

Design changes during the iterative sprints – Are you thinking of doing design, development and testing in an agile way? I would recommend to read ahead and validate if that approach would help your project to achieve the desired outcome on time.

The project started with minimal business requirements from the business and the list of features required were identified. The project included redesigning the underlying data model of an existing application and adding the new features identified to the application. The project did not have the detailed requirements at the start of the project and the design, data model, build and testing started simultaneously following agile approach. As we progressed through sprints, any design or data model changes, while developing the features down the line, eventually resulted in rework on the features completed in earlier sprints. The finished products were revisited every time there was a change in design which increased overall cost and caused delay in progressing with the remaining open activities.

From my experience in this agile project, it would be challenge to complete the sprints on time if design is evolving across sprints. If the project involves major redesign or new application development, it is worth investing initial few days in preparing high-level design with the available requirements. This would avoid rework on the features while we get into the development sprints. Development and testing goes well within a sprint timebox.

Team member sharing while sprint is in progress – The projects had a dedicated skilled team which was a key strength to get the development on time and of high quality. The project deployment was planned into multiple deployment phases so that the finished products can be released earlier. There were cross impacts due to other inflight project and the part of the development team was deviated to focus on sharing the knowledge of the project and its impact on other projects so as to enable first deploy release to go ahead as planned. As per Agile guidelines, the core sprint development team is expected not to be deviated from the locked down list of features. But in the real world, the knowledge of the skilled team is required to mitigate any risks related to that project. We had delays on the sprint that was in progress in order to accommodate risk mitigation activities. A dedicated and committed team is a key for a successful Agile project. The agile project manager should implement the two key techniques that the Scrum methodology emphasises strongly.

  1. The Scrum Master should ensure that the team is not impacted by any changes or other external influences that could potentially deviate the team from the current sprint. The Scrum master should ensure that the team remain focussed on the current sprint until the end of sprint
  2. Any changes in resource plan should be restricted while the sprint is in progress.

Requirements unclear even while sprint is in progress – Agile framework facilitates the business SMEs to change or finalise requirements while the feature is being developed. But in order for the development team to complete the development within the sprint time, the business should be clear on the requirements for the features in the current sprint to enable on time completion. Ambiguous requirements, while sprint is in progress, lead to delays in completing the feature within the sprint and may result in increased backlog.

The business subject matter experts have to have the requirements clear to enable the team to complete the project on time. Any requirement changes from the business SME impacting the sprint has to be considered as a new item in the backlog list. Requirement changes during the sprint has to be recorded and tracked to effectively manage the sprint timelines and overall project cost.

While Agile framework accepts less documentation, we need to understand the main objective of agile framework is quick delivery. Documents that enable quick delivery and better control on time and cost are still required in agile project management. As much as projects are unique, challenges within the projects are also unique. Lessons learnt from past experience always helps in the handling these challenges effectively in the future. Agile methodology also gives the opportunity to identify any challenges at the end of each sprint which will enable to apply corrective measures throughout the journey of the project. Go Agile, enjoy the continuous learning and eventually master the skill of Agile project management.

Think before you Agile..

 

What follows are my personal experiences and thoughts based on a recent contract role that I did as a Project Manager of an Agile project.

Agile has been a buzz word for quite some time now and I think it’s safe to say that it’s caught on as a fashion statement as far as project methodologies go. Nowadays most of the job adverts ask for agile experience, which I assume is a direct indicator of most projects wanting to go the agile way. I have attended an interview where the hiring manager, looking at my profile said something like ‘I feel outdated and have been thinking of going agile with my project’ which in fact was a multi-year network upgrade project, one of the last projects in the world I would think of making Agile.

My project was a long term (2 years) development project and the project team involved 7 squads working on a fortnightly sprint based development model. We followed Agile ritualistically. We breathed agile so to speak. Where I stand now, I believe that agile, in its purest form, may not be appropriate for most of the long running (multi-year) projects around.

Here are some tips I’ve picked up in my experience to-date.

Agile Must Haves:

Documentation:

However you try to coat it, Agile depends heavily on making documentation lean and on demand. This has some detrimental impacts in the long run. If you have a project running for a long duration, or a project which is done and dusted but the go live is delayed and the team had to be dismembered and re-convened (with different set of contractors) later . Nobody would have a clear end to end view of the architecture, requirements, design implemented, standards used etc. Thus the need to focus on the long term, even when the sprints are of 2 weekly duration. Figure out what are the documents that an operation team would require to maintain the application, or a new set of contractors would need if they were to re-engineer the solution for whatever reason. System appreciation document, Requirements document, Requirements Traceability documents to list a few. Effort needs to be set apart and planned for documentation during each iteration or at regular intervals say every 4th iteration.

User Stories:

There is an argument that user stories provide traceability in agile projects. But I haven’t found that effective. User stories would be sliced pieces of bits and pieces of functionality which are created to fit into the effort available in a sprint doable by a developer, testable by a tester. But no group of user stories would clearly depict the requirements in a clear and understandable manner in the long run. Hence go for a tool like JAMA for putting in requirements. You need to establish a clear heirarchy of functional requirements and a process as to how and under what sub requirement would a user story of a particular type and function be added. Establish the skeletal process upfront before you write your first user story. We got into a mess as the skeletal structure and the processes were not set upfront and each Scrum Master who came on board went their own way in documenting requirements.

Refactoring:

Refactoring is the next topic that needs attention. The need to get going with the next set of requirements, along with the need to be agile and deliver at very short intervals leads to a lot of disjointed coding practices and deviations from the initial design architecture standards. More often than not you would tend to cut corners to ensure we deliver the requirements on time for the iteration. There is an unavoidable need to have a refactoring sprint planned regularly. If it could be afforded, you could have a separate squad consisting of the architect and a developer working together who pick up what has gone into the previous iteration. This squad then reviews, corrects and refactors code where required regularly. Another idea is that it can be a sprint planned for all/some of the squads every 2 months or so where they spend (say) 1 week of their time in refactoring and tidying up what has already gone in. In the second model it is imperative that some watchdog like the architect or a senior developer keep a note of what are the corners that were cut, deviations that were done, either in consultation with or whatever is found through reviews.

Work/life Balance

Agile gives a real good work life balance for employees. It’s perfect from a developer or a tester’s perspective. You commit to what you can do and go ahead do that.

It’s perfect in all the other ways that we all know about like, being able to cater to the customers immediate needs, providing a working software at regular intervals which the customer can look and feel and modify his requirements accordingly to.

Agile keeps the enthusiasm level up there or thereabouts always. It is great to have frequent sense of achievement, release of pressure, re planning and re estimation, recharging of batteries.

A Physical Agile Board:

Always have a physical agile board unless you have a big and wide screen monitor/smart board which is life like. The sense of physically moving tasks from one stage to another cannot be replaced.

Have a ‘graveyard’ where you would move the completed tasks and stories. If possible get different squads to use different colours or may be different colours for different types of tasks (one for dev and one for Test maybe) this would help to create some nice and creative patterns on the graveyard which through a time-lapse video would make us all proud as a work of art and provide an ongoing sense of achievement.

 

 

Agile Pitfalls:

Churn:

Agile is for teams involving good to expert level developers and testers. New members must be drafted in gradually, and drafted in only when then they are very close to 100% ramped up. New team members or those who are not well versed with the technology in-use, liquidate the effectiveness of agile methodology. When such a member joins, for quite a few iterations at least the team’s velocity estimates go low and so does the productivity. Agile teams are like bullet trains. You can’t attach a cargo van at the end of it and expect it to run at the same pace. It can be very detrimental. This is one of the reasons I feel, why agile is not good for a long running project where you, more often than not, would have churn and developers and testers move in and out frequently or in organizations where resources are pulled into different projects or operational activities at various times.

In an agile project the timeline OR the scope can remain constant. Both cannot. Due to the inherent nature of agile, scope gets swapped in and out, functionality requirements keep changing everything moves around between iterations.

Stakeholder Management:

Ensure that you engage and educate the stakeholders on what they are getting into. It so happened in one of my projects that towards the end of the project, (mainly due to some internal politics between the concerned departments within the company) the agility and its rules were forgotten and the business put a wooden foot forward saying the scope is non-negotiable and so is the time-to-market. Hence all the remaining scope in the backlog became indispensable. This same backlog was always thought of as a priority list (as it should be) which would be tackled in the right order and it would be the product owners responsibility too to ensure that he gets the most important features in the time remaining till the project go live. So now we had a situation where the product owner who was all agile and happy to add in and chop off requirements as he wished suddenly went backstage and there we had the business director standing on top of us with a ‘my way or highway’ attitude.

Agile Non-Negotiables:

What the above scenario teaches me is that even though we run an agile project, do 2 things. Educate / coach your stakeholders on how agile works and what it means, with respect to overall scope and timelines. Secondly, keep yourselves covered by always probing and getting as much requirements (even at a high level) listed upfront, high level planning poker done for all the requirements , add your buffers and keep the forecast with respect to scope also highlighted in your weekly reports. What I mean is, if there was a new chunk of work that came in to the backlog which suddenly became priority for the product owner, show clearly by means of trend graphs how the overall scope has increased and how that impacts timelines if all the requirements were to be completed.

You might say “we all do that!” Yes but still ensure that every week the view of how the overall picture looks with regards to scope is provided to all stakeholders. The product owner shouldn’t be able to shrug off the accountability of getting what is required in the time that is allocated.

Particular mention needs to be made of some product owners who, on seeing that the velocity of the squad is really good, tries to get it in more thrills and frills wherein that high velocity should be used to tackle the important features first and then return to the thrills if time permits. Keep a tab on the prioritization thought process of your product owner at all times.

Squad Management:

When you have multiple agile squads, each runs with a different velocity of course as each squad has a different way of story pointing and different levels of productivity too. Thus, when preparing project plans you need to ensure that you take a reasonable and probable average velocity into account. If you are starting a new project with new squads who haven’t been together before then all you can do is a reasonable guess I believe. But ensure that you do a most likely, worst case, best case analysis and provide forecasts accordingly.

Agile Pitfalls: The next bit, though a bit sensitive to talk about is worth the mention. Agile teams can grow to be very sentimental and moody. They need to be nurtured with care and love. At times all that care and love can create a monster. They become a collective unit and conspire to put blockers where there are workarounds, give out considerably higher story points than is appropriate, can decide to delay a few activities so that the stretch goal needn’t be brought in to the current iteration even though there is spare time available, give out higher story points and ensure that there is enough buffer to compensate for less than 100% effort. All this can happen even when teams aren’t facing new challenges regularly. So one way of tackling this is to do a close monitoring of the work that each member is doing, even at the risk of going against one of the concepts of Agile which is to have full belief in the team and its capabilities. You could do this being less conspicuous by catching up with team members offline and not in a formal team meeting environment or at her or his desk. You might even want to swap team members without affecting the structure too much at the same time. This reduces chances of such behavioural patterns developing.

 

Other things to consider.

 

Games:

We once had a security hackathon which was basically a 2 hour period wherein all the developers and testers attached the application and tried to crack into secure data. It did bring out quite a few security vulnerabilities, which are part of the often forgotten and often non-written non-functional requirements. This is a highly recommended practice.

Getting the squads together to engage in some agile games is another way of making it fun at work while indulging in some team building activities. You’ll get a truckload of games online which you could try out for your squads. Most of my team really liked whenever we had them.

 

Reporting:

Backlog is very volatile bucket so how do you actually depict anything meaningful to the stakeholders on how and when would something be done. A visual representation of what feature was developed when we had what we called a Sprint pipeline plot. Which was an excel sheet which showed blocks of work that would be covered by each squad and around when.

Also consider how useful this would be in a situation where you have 5+ squads (like we had 7) and you have a year-long project to run. Scope might keep getting added to a particular module and might get culled in some others, but with this sort of visibility you can easily look at options on how you could rejig and make everything fit more like a jigsaw puzzle. It would be much easier discussion with senior stakeholders too, in order to explain how agile you are and how confident you still are in meeting the project goals.

 

Screen Shot 2016-08-11 at 11.41.50 AM
We did an EVM (Earned Value Management) plot. Keeping in mind various aspects like the most likely, worst case and best case average velocity of the sum of all squads.Financial management

The total scope that we had to cover in terms of story points. This was based on the initial very high level planning poker where we got the total number of story points that needed to be covered. Here again we did a best and worst case. It’s imperative that we do a reality check a few times through the project to revalidate the total number of story points that forms the scope. Please ensure that when you do this exercise you do take into account time that needs to be spent on stuff other than development, testing and deployment, I can think of research work, tech spikes, maybe a cloud deployment etc. which may not be part of a module you work in, may not be part of the discussions and work that you do with the product owner but are necessary for the software to be released. I could write a separate blog on how to prepare EVM graphs for an agile project. That’s an elaborate topic in itself. May be I will do it one of these days and provide some examples on how to go about it.

 

By: Nikhil Prabhakar 

Nikhil is a project manager who has recently joined IMA who comes with a management background in Applications development, Service Delivery, Transformations and Transitions and has worked with a diverse set of customers across the globe.
He has just been promoted from ‘forever wanting to write about his experiences’ to ‘having his first blog published’. Nikhil is an avid soccer fan and is’nt shy in proclaiming his support for Arsenal FC


Project Documentation – Striking a balance
Aneesh web pic for blog

Aneesh started his career in 2007 as a Business Analyst and joined IMA in 2013. He brings tremendous energy, focus and initiative to his job as a Business Analyst. When not solving client’s problems, he spends his time driving around the suburbs occasionally taking out his camera for a snap or two .

Documentation has always been a part of formal project management practices. There are many layers of documentation that get created. The three types that are normally done are:

(a) what is to be built
(b) how is it to be built and
(c) how the project is to be managed.

But often, documentation ends up being a task that is to be completed before ‘actual’ project execution begins.

Many IT projects involve multiple stakeholders and draw upon diverse skill sets of many project team members. The team may include project managers, technical and business architects, business analysts, developers, testers and change managers. The project is often governed by committees whose members may be involved in many projects.

Team Members

The members of the team then interact as required with the client who itself might have a hierarchical set up for approvals for requirements, testing and deployment. The role of each member of the project team and the client varies at each stage of the development life cycle and the stakeholders must make necessary adjustments as their roles changes.

Project Management Office

PMOs usually ensure that projects are well managed by implementing project management standards and procedures and often mandate various project management documentation in the belief that all well managed projects need them. The detailed documentation of the schedule of activities and expected outcomes/deliverables with timelines provide immense value from a management perspective. Mandated documents and their structures enable anyone familiar with them to quickly find information relevant to them on any of their projects. It provides an easy frame of reference for any project team member to assess his own role in light of a plan and prepare for the road ahead. Such documentation is especially relevant in projects requiring services of specialised consultants who are called upon in the project at appropriate stages and their roles could be limited to that particular stage. The project and programme management is also clear on the artefacts that are to be expected at any point in the project life cycle which results in efficient deployment and utilisation of project resources.

Other

However, there are cases where projects with comparatively smaller budgets generate these documents for the main reason of complying with the PMO and in the process spending scarce time and budget in documentation. There have been instances where it consumes a significant percent of the project duration and cost. It may also delay the project implementation in some cases.

So the moot point here is what level of project related documentation is optimal. The most logical answer seems to be “It depends”. The value of such documentation needs to outweigh its cost.

Agile?

At this point I am sure that many of you will think of Agile methodology as a possible alternative because of the preference given to deliverables over documentation. However not all business domains and industries have adopted agile as a preferred model and agile does not suit many projects and businesses.

Consider Parameters

Various parameters of a project like complexity of implementation, budget, duration, headcount etc. could be considered as inputs to derive a subset of the exhaustive list of project related artefacts. This sounds sensible as there seems to be no point in developing a whole gamut of project management documents to develop a website with just a handful of pages whereas it might make perfect sense to have all of the artefacts in a project aimed at developing an online student enrolment system for a big university.

In case of significant overlap of information in multiple documents it would be a good measure to amalgamate one or more of the documents into a single document. If there are various small projects which are executed under an umbrella programme, it might be possible to have documentation at the programme level. This will reduce the number of documents considerably. Projects in an organization could be categorized based on some of the parameters mentioned above and the artefact requirements could be defined for these categories.

To conclude, it is important to strike a balance on the level of documentation is required. For each project, what is appropriate might be different. Each document that is prepared must have a clear answer to the question ‘what is the value it adds’. This paper is only a flagging of the issue and suggesting some directions for change in broad brush strokes. Greater analysis of project management practices and methodologies is required in this area.

 

5 tips for embracing the benefits of Agile Development

As a seasoned Prince2 Project Manager, I was very comfortable in managing projects in stages. The scope was defined and locked in.  The sponsor and project board had a clear understanding and agreement of what would be delivered in the stage. Any deviations to the project delivery were managed through exception reports……Life was good.

Pablo is a seasoned professional who is focused on delivering high quality outcomes for his clients. His strength is his ability to quickly develop relationships with stakeholders at all levels to find a way through complex issues. Highly qualified with an MBA and over 14 years’ experience in consulting and project management, Pablo has helped his clients in numerous industries including Education, Health, Defence, Telecomms and Finance achieve their business and project objectives. When he is not immersed in solving his client’s most pressing challenges, Pablo enjoys spending time with his children and cooking a variety of delicious cakes and desserts which makes him valued team member for morning tea. He also doesn't mind a long drive along the coast every now and again.

Pablo is a seasoned professional who is focused on delivering high quality outcomes for his clients. His strength is his ability to quickly develop relationships with stakeholders at all levels to find a way through complex issues. Highly qualified with an MBA and over 14 years’ experience in consulting and project management, Pablo has helped his clients in numerous industries including Education, Health, Defence, Telecomms and Finance achieve their business and project objectives. When he is not immersed in solving his client’s most pressing challenges, Pablo enjoys spending time with his children and cooking a variety of delicious cakes and desserts which makes him valued team member for morning tea. He also doesn’t mind a long drive along the coast every now and again.

Then – along came Agile and to be brutally honest, the prospect struck me with fear….

WHAT ?? the client can change their requirements on a whim ? My mind screams ‘that’s not in scope!!’

A Sprint is only 2 weeks long?? My mind exclaims – ‘what can these developers build in 2 weeks??’

There’s 100 stories in the Product backlog ?   How can these not be in a Project schedule…. I NEED to build a detailed schedule….

A requirement is a User Story ?  and I’m thinking – a User Story is what I read to my daughter every night…

There was a lot to learn in this new Agile world…. and yet I do enjoy a challenge….. so the lessons began.

I was the new PM on the Block…. (is that a song?)…and I needed to show my team some confidence that I (somehow) knew a bit about Agile.

So we had daily stand-ups – this was a great idea!  I could now grill….no not grill…..I could request a daily update from each team member and find out if there were any issues that I needed to resolve. This would definitely assist me in tracking project progress.

We held Sprint Planning sessions, bought some Scrum Poker cards and had great debates about business value and story points…. I enjoyed negotiating with developers on the effort to complete a user story, but it was also difficult to assign business value to a story without the Product owner present.

We conducted Sprint Retrospectives – these were difficult to begin with but the team soon learned the benefits of having regular reviews and getting feedback from all team members.

We appointed a Scrum Master to help the team manage their sprint products and keep the team on track.

I was beginning to enjoy this new approach in managing a software development project…. and I quickly began to understand how Agile can be used to deliver products to our customers in a faster way.

Not everything went to plan though so I would like to share my own lessons learnt –

  1. Get a Scrum Master on board at the START of the Agile Project.  I see the Scrum Master as the lead who will provide the guidance and direction to the development team on a daily basis.  They are also great for managing the product backlog and keeping the team on track.
  2. Like the first point – Get the Product Owner on board and keep them on board through the entire sprint. The ideal scenario is where the Product Owner is embedded in the Project team.  They can make business decisions on the spot and this is what makes the project delivery truly Agile!
  3. Develop and deploy a product version in every sprint – this can be difficult with a lengthy and complex project but there is a definite advantage in conducting regular testing and reviews with the Product owner.  We held product refinement sessions to demonstrate our product and seek immediate customer feedback that we can quickly build into the next release.
  4. Don’t underestimate the testing effort or timeframes. This includes integration, user acceptance, performance and regression testing.  Of course – I think this applies to both Agile and Non-Agile projects but it must be factored into Sprint planning sessions.  You may be tempted to squeeze testing effort – my advice – don’t!
  5. Business engagement and communication is still a key requirement – although you may have a Product Owner working in your Agile team, you still need to maintain regular contact with all your client stakeholders to ensure they are aware of current project status, issues and risks.

Overall – I can now begin to appreciate the benefits and techniques in Agile Development and I am more confident in applying these in new Projects.

I would be keen to hear your thoughts and experiences in adopting the Agile approach in your projects.