Very often, Agile is presented as the panacea for delayed releases, disconnect between the business and technology teams and the slow pace and long release cycle of the waterfall method. Well, Agile is simply a process to develop software, with its own positives and negatives. A process by itself can never be perfect, and with human involvement, there is a high likelihood that the new method will also fail, although in different ways from the old software development methods.
In this post, I would like to describe the key challenges that a product manager must watch out for, when he
- Joins a team following the Agile methodology and Scrums for software releases
- Joins a team that is transitioning from Waterfall to Agile
The information here is useful for both offshore enterprise and consumer product managers.
1. The very first thing he must ensure is that all requirements are clearly defined and documented. When something goes wrong, or the engineering output is not satisfactory, the first thing to do is blame the quality of requirements. My advice would be to never change requirements even if a customer demands a feature enhancement. You can always add it to the backlog, instead of disrupting the existing backlog.
2. The next important thing is to make sure that all processes are clearly defined and documented. If the team is transitioning from Waterfall to Agile, the program manager must remain available until at least 2-3 sprints are completed. It is also vital to make sure that a Scrum Master is designated to track the team progress. The Scrum Master must not report to the engineering manager. Weekly sprints must reach their sprint goals.
3. Make sure that QA is independently accountable, and is testing the weekly output both for new use cases as well as regression testing for existing features. One team I came across had QA also reporting to the same engineering manager. Needless to say, either bugs were not reported or were immediately reduced in priority.
4. Make sure that the non-functional requirements are adhered too. A common excuse I have heard is that since this is the first version of the use case implementation, we will improve performance later. Well, no client is going to wait for a half-baked feature, and releasing that feature will only cause high priority customer escalations, reducing sprint velocity and causing a cascading effect on other features.
5. At least 20-25% of the development time of the engineering team should be spent on defect resolution. In fact, one sprint out of 4 or 5 can be an exclusive bug-fixing one. This will ensure a reasonable product quality after a while.
6. Make sure that the effort estimations do not vary from week to week. This is the most common trick employed by engineering managers to prioritize features that they want to build, and change the product backlog priorities. There is no easy solution for this, but if you closely track the past performance of each engineer (yes, YOU have to do it, with the help of the scrum master) you can get a good idea of the real vs. claimed effort estimates.
7. Finally, do not hesitate to call out the engineering manager if you see the product drifting, the quality being lowered, or the performance not up to the mark. He will blame someone from his team, perhaps even fire someone to make an example of him, but ultimately, each engineer is accountable for his output. And he is accountable for managing them. If required, escalate to the engineering leadership and make them aware of the release delays. In addition, if you keep your own leadership informed too, then client escalations will not cause too many disruptions.
One final thing, there are never as many engineers of sufficient quality as desired. And recruitment remains a constant struggle in the product development world. It is not your job to manage this constraint. And yeah, the old story of tripling the engineering estimates to plan a future release date makes a lot of sense in India.
There are dozens of tricks and pitfalls to watch out for, when Agile is proposed as a software release process. This post mentions a few, but the key to on-time, in-quality releases remains close tracking of the progress made by the team against the defined requirements.