We Lost to Agile

26 November 2013

Rohit Ratan Mani
Diebold Systems Pvt. Ltd.


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:

Senior management
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.

Product management
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!



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (3 ratings)

Comments

Glen Wang, CSM, 11/26/2013 3:34:41 AM
identifying "selling points" of agile to people in different positions is good.
Gurpreet Singh, CSP,CSM, 11/26/2013 11:55:35 AM
awesome piece!
David Lowe, CSP,CSM, 11/28/2013 7:39:02 AM
We've got quite a few publishing firms using agile in the UK now (and no doubt others too).

My answer to "who should implement agile" in a company is that everyone has a part to play:
(1) the team needs to perform and act in the gist of the values & principles (otherwise the business won't see the benefits)
(2) the business needs to support it AND feed through work in an agile way. It shouldn't be thinking of projects as just going from A (now/nothing) to B (full solution), but should be thinking of when it can go to market at the earliest opportunity and what the milestones are (i.e. when they'd want to go to market with a revised version). This latter point is often missed out when firms (esp. non-tech) think about agile.
Amit Sawhney, CSPO, 12/20/2013 12:05:52 AM
On the question regarding "Who should drive Agile implementation" -In my opinion, the drive and support will come both from the senior management and the teams that build, design and deliver if they understand the benfits of going agile and undertsand the principles of agile. One benefits that Agile may provide over the traditional methods is that each requirement/story has an associated benefit, they are in an order of priority and the acceptance crieria is well articulated. So you just don't go and building something but everyone knows what they are building and what for. On the flexibility of adding/changing requirements is something that may not apply to other industries as it applies to IT. However, the sense of collective ownership and retrospectices can help all organisations.

It would have been useful if you could mention the industry your friend is associated with,it may help envisage the challenges that other industries face.
Amit Sawhney, CSPO, 12/20/2013 2:58:00 AM
On the question regarding "Who should drive Agile implementation" -In my opinion, the drive and support will come both from the senior management and the teams that build, design and deliver if they understand the benfits of going agile and undertsand the principles of agile. One benefits that Agile may provide over the traditional methods is that each requirement/story has an associated benefit, they are in an order of priority and the acceptance crieria is well articulated. So you just don't go and building something but everyone knows what they are building and what for. On the flexibility of adding/changing requirements is something that may not apply to other industries as it applies to IT. However, the sense of collective ownership and retrospectices can help all organisations.

It would have been useful if you could mention the industry your friend is associated with,it may help envisage the challenges that other industries face.

You must Login or Signup to comment.