There is no second guess that Agile methodology and its various frameworks like Scrum, Kanban have managed to generate everything from successful products to vast curiosity in the last couple of decades. And we have enough case studies of Agile implementation in both products based as well as service-based organisations.
With this post though, I am focusing on the current project management challenges more from a service-based organization perspective.
So, a follow-up question could be if Agile is the answer to most of these challenges, why the challenges are still there? The answer to that is:
The challenges highlighted below are the outcome of both waterfall execution as well as semi Agile execution. Answer to both is, implementing Agile the right way.
Challenge 1- Frequent Requirement Changes: Even when the scope of the project has been talked at length, estimated and SOW (statement of work) has been signed, there are things that are not factored or thought of. Or quite often, in the middle of project execution, client has new ideas or needs. This results in – Change Requests, the (in)famous latecomers to the party. They appear when the team is towards the end of the development phase, or in middle (if the team is lucky). The project manager though has made a project plan for the entire duration of the execution. Accommodating these change requests is like having guests over at the end of a tiring day. They are never welcome. Even when, these change requests come with billing (or extending the analogy, these guests come with gifts).
Moreover, estimating these CRs are a challenge in itself. For example, a particular CR may be estimated for 15 days FTE, because that is the time needed to implement this change by developers. But the cascading impact generally is much more than 15 days because of the additional efforts to fit in that CR. So even though billing to the client is for 15 days, the cost to the company is more. And thus the resistance in accepting CRs.
Challenge 2- People Dependency: The project plan charts work versus people. And changing any of these dimensions, upsets the plan. While change requests ruffle the work dimension or sudden absence of people jeopardize the people dimension. People leave organization, they fall ill, they go on long vacation and a very detailed project plan has to undergo multiple changes, especially in a big team. I had seen projects where the effort invested in updating project plan was same as the overall development effort. Unlike real Agile teams, people often are not cross-functional. So, one person filling in for the other person is not easy. These challenges often resulted in the resistance to approving leaves. Eventually, the teams burnout.
Challenge 3- Vast Documentation: The scope and variety of documentation is a project-specific thing. These are driven by what has been agreed upon with the client in SOW. But generally, there is no getting away with a few standard documents like Function specifications, technical design documents, Unit test plans, release notes, User guides etc.
Moreover, in a CMML5 service-based organization, there are many process-level documents to be created.
There are two prime challenges in creating these documents –
Challenge 4- Defect Density: This challenge is not very different from the basic problem statement that gave birth to Agile. In waterfall model of execution, there is no intermediate demo to the client, so all the defects are being accumulated from design and development phase, await to be detected during user acceptance testing phase. Even in many semi Agile implementation, not always the end product of a 15days sprint is a potentially shippable unit. More often than not, these sprints are mini waterfalls. Thus the stitching of individual sprint outcome, happens no sooner than in integration testing or system testing phase. The more the delay in identifying a defect, the more the risk.
[Note: Assuming here that the readers have basic understanding of what Agile and Scrum is.]
When a service-based organisation will embrace Agile ways of implementing the projects, it might encounter new challenges as well. For example, it will have to answer - What role a project manager is going to play now? How can a scrum master ensures that (s)he has to play a prominent yet invisible role? Will the product manager have the real authority on the product backlog? Can we afford to have team of only smart, self-organised and cross functional people?
Saving a follow-up blog post to answer these challenges. But the good news is- there is answer to all these questions.
Your email address will not be published. Required fields are marked *