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:
- When torn between industry pressure of using Agile and beating the age-old conditioning of using waterfall execution, many projects fall prey to the worst mid-way, that is – mini waterfall execution.
- Also, the fact that we have more people ‘interested in’ Agile than ‘knowing’ what Agile is. Rarely there is apprehension in starting the project in Agile because ‘Agile’ sells. Although, having people who really know or use Agile in purist way, is where the struggle lies.
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 –
- Some documents even when created prior to the development has to be retouched post development (Case in point, technical design documents and Unit test plans). It is often the designer or the architect who creates the technical design document in the design phase. But updating the documents post development is generally done by developers. With people changing, the context changes.
- The team shrinks post development (because a project manager has to reduce the team after development phase) and there is a sudden rush of closing the documents that are agreed in SOW (Statement of Work). Result- the quality of the documents is being compromised.
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.
Why Agile (Scrum) is an answer
[Note: Assuming here that the readers have basic understanding of what Agile and Scrum is.]
- Scrum welcomes change. “Responding to change over following a plan” is one of the Agile manifestos. One scrum team focuses on one sprint at a time, so there is always a scope to fit in the change requests as a part of the later sprints. However, the decision of when to incorporate the change, will lie with the product owner. When CRs make an entry in the program, Product owner will decide when and how to include that in the product backlog as a user story. These user stories will later be a part of the sprints backlog in agreement with the Scrum team.
- A scrum team is a set of self-organized cross-functional people. Thus individuals are not expected to be tied to one skill. In absence of a person with a specific skill, the cross functional team is equipped to move ahead. And this scrum team works as a unit. Absence of one team member might impact the velocity of the team but not the quality.
- Scrum as a framework doesn’t specify what and how many documents to be created apart from the artifacts (Product Backlog, Sprint backlog, Product Increment and Definition of Done). Documentations in a scrum project is derived by the need of the program, not by the need of the client or organization. So, client and vendor together come up with a list of bare essential documents that are needed for the program.
- Defect testing is not on hold till the end in an Agile Scrum world. The end of each sprint is a potentially shippable unit. In Sprint review, the scrum team shows the coded, tested and usable unit of work. JUnit, automated test cases, auto deployment etc are the preferred processes to fasten the testing and deployment process.
End Note:
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.
