When I talk about Agile, it is mostly in the context of my experience in the IT industry. Many times my friends, working in different sectors, ask me why I support Agile in general when it is primarily focused to work wonders for my industry. When I really think back, I have not heard people from different industries speaking proudly of implementing Agile within their organizations. I tell my friends, "Agile gives you direction; it is you who pave the way toward the goal."
I told one of my friends to try out some Agile principles and share with me his experiences. Why should I not be enlightened about obstacles that await in other industries? And to my surprise, my friend did come back to me -- with a question that made me really think. I had faced this situation but never really thought about it, as I was in an environment that was conducive to implementing Agile.
My friend asked me, "Who should drive Agile implementation? Is it management's decision, or the team who would be following Agile principles?" There were many other questions that he kept shooting at me after his long meeting with his own management team. I had not expected him to come back to me so quickly -- and with so many questions.
I had to prepare a reply that could make a good business case for supporting Agile implementation in his organization. In hindsight, I was thinking of suggesting getting a consultant who could guide him as well his company's management. My friend agreed, but he pointed out that to get to that stage he first needed to prepare a business case citing advantages of even getting a consultant on board. (That was a month ago; now he's on his way to hiring such a consultant.)
In this article I thought I'd try to capture the discussion about one of the biggest questions that my friend faced, and that he asked me: "Who should drive the implementation and why?" We did some role-playing, wearing the hats of senior management, product management, the sales team, developers, testers, development and testing managers, project managers, the quality/process/audit team, and the accounting team. This was a lot of hats. (The last two teams, according to my friend, were the most difficult to get agreement from. My thoughts were in line with his, as it has always been, in my experience, their way or a noncompliant escalation. No offense to anyone meant by that; it's just been our experience.)
We had a task on our hands, and we started documenting our responses for each stakeholder, keeping in mind we were not going to restructure but might rename some existing roles. We had set up the objective of nailing down role, pain areas, impact, and benefits of implementing Agile for each stakeholder. We started from the top of the list, and here is what we documented:
This layer is responsible for providing guidance and approval, conducting review, playing devil's advocate, responding to the board with updates about progress, and so on. Just to summarize, this person is responsible for all the work happening under his or her purview. From this person's perspective, he or she is at the center of the whole action (isn't that everybody's perspective!). We needed to get blessings from this person to even think about implementing a new method.
The current process gives a good pictographical representation of the project's progress and has been long followed, so analyzing these sets of reports is easier. The process, though, gives output with a longer time frame. The pain point really is the high churn-out time.
The impact of moving to Agile would be:
Reduction in churn-out time
Change in reporting of project's progress
New ideologies to follow
One-time cost of training the team (budget sanction)
The selling point to this person was the reduced churn-out time, which would reduce the release-to-market time. We had to put up an analysis chart comparing charts for tracking projects for different methods. We also needed a detailed explanation of burn-down, burn-up, release plan, and so on that could give a real presentation of the project's progress.
This layer is responsible for envisioning product growth and tapping customer needs. For this layer, time is of the essence and they are the ones eager to see things churning out to customers. But, as of today, the product manager's main role is to document the product requirement and, if possible, prioritize the requirement. The issue comes when the team has started work on one requirement and the product manager changes the priority and demands to roll out the highest priority. In the current environment, this layer works in a more reactive way.
The impact of moving to Agile would be:
More involvement in release planning
More proactive participation
More involved detailing of the user story and defining the acceptance criteria
Better control/knowledge of the shippable product
Releases to the customer in smaller time frames
The selling point could be quicker release cycles and better control over and knowledge about the shippable product. The idea of getting more involved with the planning, getting into multiple discussions, documenting acceptance criteria, managing the product backlog, etc., is going to be a pain point.
A reduced release timeline should be what drives this layer toward Agile. Increase in workload through more involvement (though it is for betterment of both product manager and development/BA/testing team) has to be shown as a benefit in terms of improved visibility of deliverables and a better development-testing lifecycle.
I will continue documenting my discussion for other stakeholders in the next part of this article. Meanwhile I share these sections now, for your comments. We might have missed out on points that we would never have chosen to overlook. I'm looking forward to comments to get those points added to the list. Happy reading!