Originally published on ScrumAllicance.org in Jan-2015.
Nowadays, everyone uses the word “Agile” to mean different things and to their advantage. I’ve seen that this confuses people as they hear multiple things from various perspectives and don’t really know what to do. That is where you’ll see that there are all sorts of feelings from Enthusiasm, Commitment to Anger, Fear and Frustration associated with Agile, based on who you talk to and what their experiences has been or what they’ve heard about it.
So I wanted to share my experience on Agile Journey in the last 6 years from the Development Manager as well as from the Program Management side. One thing that I would like to high-light are the wrong behavior patterns and how to correct them.
First of all some people think of Agile as another Project Management methodology where
- Project Manager is called Scrum Master
- MS Project is replaced with Jira-Agile, Rally, Version One or Spread-sheets
- Instead of half-Yearly delivery of software now there is monthly or bi-weekly software delivery
- Instead of weekly status meetings there are daily status meetings called as Daily Scrums
When this is the case it makes feel Management more in Control as they can see Burn down charts online as well as think they’ve the visibility of what each engineer is doing. On the flip-side, it makes engineers feel under pressure and fearful. So the immediate response from the engineers will be resistance.
Is this the correct understanding? Absolutely NOT
Now let’s look at the correct understanding by examining some parts of the Agile Manifesto and the principles behind the manifesto. This will make it clear that this is not another Project Management methodology but it is a Culture which promotes the Environment of Trust, Collaboration and Cooperation for achieving business objectives.
Agile Manifesto makes it very clear that the focus should be on “Individuals and Interactions” to deliver “Working Software” while “Collaborating with the Customers” as well as “Responding to Change”. Now, when we look at the processes in Scrum methodology from this angle, it makes it very clear that how the processes are catered to enable this.
To share my experience, in one group the Agile process was being rolled-out and I attended that presentation. To my surprise there was no mention of Agile Manifesto or Agile Principles. The presentation was mainly catered towards the Sprint tracking and Feature tracking. When I asked few engineers what they thought about it, one said, just another way of tracking!!
Here is the process high-lighting the Principles behind the Agile the Manifesto, which needs to be emphasized.
Sprint Planning
- Product Owner and team collaborates to ensure that User stories are well-understood and the highest priority items for the Sprint
- Team Commits what can they deliver in the Sprint and Management Trusts them to be able to Deliver
One critical feature was lagging behind and team was working very hard to deliver. During the Sprint planning meeting it was very clear that only half of the target of last Sprint was met and it will take whole of the current Sprint to deliver. Sensing the situation, felt that the reality is; the whole feature is grossly underestimated and the Scrum Master was afraid to speak. As a result team motivation was going down as management tension kept increasing.
I discussed with the Scrum Master frankly, showing him the current velocity and discussing the open issues which pointed to the unaccounted work. He told the truth and then we worked together coming up with the various options for the delivery and the final proposal required all the most common 3-things. 1. Additional Time, 2. Additional Resources and 3. Reduced Scope. However when presented this to the upper management they were quite cooperative in agreeing to it as well as making sure that the committed resources are assigned. This got the team commitment back as well as the focus on the quality of the feature was maintained.
Daily Scrum
- Team updates each other and Commits to each-other as well as team collaborates and adapts to situations to meet the Sprint goals
When one of the group had just started with Agile implementation and I was helping out Scrum Masters, who didn’t had any formal training earlier. In the Daily Scrum, I observed that whenever any issue was raised Scrum Master will give the decision immediately. Quick decision making!!
I discussed with the Scrum Master separately afterwards, and then the Team started taking up the responsibility of resolving the issues. How? Advised him to ask 3 questions when any issue is raised,
- “So what should we do about it?” Engineers started opening up and giving solutions
- “What does everyone think about this?” The people who didn’t give solution, at least started nodding their head and slowly started to speak up when they didn’t agree with it.
- “So what is the decision?” This made team feel more empowered and started taking the decisions.
Sprint Review
- Working Valuable Software is demo’d to the Product Owner and stakeholders to ensure Customer Satisfaction
In one of the UI intensive Agile project I was involved with, initially the Team used to Demo the software at the end of every Sprint, and every time there is a demo, PO will come up with more modifications to the UI to the same functionality. So Management was feeling that the Team is slow and the Team feel pressured and frustrated.
After observing the situation, had a meeting with PO (PM in this case) and Management. We called the PO over here to work with the team for 1-week and he understood the feelings of the Team and where the communication gap was. PO was committed and he extended the stay for another week and made sure that Team understood what was required and more importantly why. From that point onwards, it was smooth sailing of the Team with PO.
Sprint Retrospective
- Team reflects on how to become more effective and tunes and adjusts the behavior accordingly
- Management provides support and removes the barriers/impediments to teams productivity
In one of the initial retrospective with a feature team, I found strong sense of Dev and QA as different teams and blaming each other in the retrospective comments and discussions. Slowly I jumped in and diverted the discussion para-phrasing the problem removing all the personal references and asking the question, “So what’s the solution?” As it was reaching the conclusion, asking again “Does the team think this is the right thing to do?”
The good part of the discussion was that the Team was open as well as committed.
As the Coach my role was just to guide it in the proper direction towards the resolution of the issue, which increased the team commitment and next retrospectives were focused more on the problem solving and not people.
So now you can see the Focus on the Culture and how the process enables the culture and the focus on the culture helps team to follow the process in spirit.
So I would request everyone to look back and see which of the Agile Principles are being followed and which ones need to be followed. Bring them to notice in the retrospectives and to the management to come up with the plan of action together so as to make it successful and Keep the spirit behind it Alive.
Finally, Doing Agile is easy but Becoming Agile is a behavior change, which takes time and requires patience and perseverance.
Wishing you all the best in your Agile endeavor.
Leave a Reply