Scrum Team has stabilized- what next?

Mar 31, 2014 | | 1 comments |
Most transformations start with the basic idea of either getting teams to start working in Agile or streamlining their existence process.

At a certain point, teams stabilize, velocity improves, quality soars and things look up.

Is the goal to repeat the same cycle day after day or is there more to work through once the team stabilizes? I have always though that the trying to get teams working in Agile is more like a bicycle- if you stop pedaling, it stops.

Here are 5 things to consider as next steps to keep the team going:
  • Baseline velocity- Always know your baseline velocity, when you started and ways you can work on it.
  • Focus factor- when the team stabilizes, it’s a good idea to know if the team has the right focus. Its velocity/work capacity. For more info read Jeff Sutherlands article here .  
  • Failure trends and patterns- The commitment made by the team always doesn't match the outcome. Looking into why stories fail and trying to identify a pattern might lead the team to understand the underlying problem. It could be user stories that require infrastructure, it can be kind of stories that haven’t been worked on, it can be a story requiring a new technology.  Once you have identified the pattern, it becomes quite easy to find a resolution.
  • Estimations- If in every sprint more than 20 percent of stories remain not done, along with other factors you might want to have a look at the way estimation is being done by the team. Some teams commit more by underestimating stories in trying to please the management and keeping to the team’s velocity. Of course by the end of the sprint teams fail to deliver. There are more managers and Product Owners who always push the team to commit more, so they have enough work on hand ever sprint fearing lesser work meaning team members might be free most of the time. Bottom-line, under estimating doesn’t help as much as over estimating doesn't.
  • Linking and tracking the layers- Stop looking only at team levels and start looking at the bigger picture, look into the your program and portfolio management and how it  is coming down to the team. Look into the quality of the user stories and how everything is affecting the team.
(Pic Courtesy: Google Images)

To learn about how to get into project management read my book Stepping into Project Management (Welcome to the #PMOT World). To connect with experienced Project Manager's from all over the world, get mentored or shadow for a day see the SIPM Community.

Interview with Siddharta Govindaraj

Today we interview Siddhartha Govindraj, who specializes in Lean/Agile processes for software development. He has also contributed in the book "Beyond Agile: Tales of Continuous Improvement" published by Modus Cooperandi Press, Feb 2013 and Published in the March 2011 issue of the Cutter IT Journal on "Use of Kanban in Distributed Offshore Environments". An occasional organizer of events as a part of Chennai Agile User Group and speaks in conferences in India and abroad.

He was nominated for the Brickell Key award in 2011, an award given by the Lean Software & Systems Consortium for recognizing achievements in the lean-agile industry and is also a Fellow of the Lean Systems Society.

He is very interested in the behavior of decentralized and distributed systems.

Agile becoming mainstream now, how do you think the world of project management has changed?

In one way, yes….. definitely more and more organizations are seeing the value of agile in terms of incremental development and faster time to market. However, there are a few aspects where agile is still to make a significant mark. First, the people aspect of agile has still not fully permeated into the culture of many organizations. The idea that motivated, self-organized teams can deliver better software is not yet in the mainstream. I also think that many companies need to invest in the technical environment. The third aspect that companies often neglect is looking at delivery as an end to end system in the organization. Agile is often applied at the team level, and systemic impediments are not fixed. So there is still a long way to go. 

While older companies have a tough time with transformation, the good news is that newer companies like Facebook have been agile right from the start. Over the next decade, success of these newer companies will establish the culture for the whole industry.

As someone who creates tools for Agile and Lean project environments, please tell us what according to you is the most important: the tool or the expertise of the project manager?

Of course the expertise of the people in the project is the primary criteria for success. Where tools will help is in aiding decision making so that people (both within the team, and management) have better insights to take better decisions. 

This questions also leads to an interesting difference between agile project management tools and traditional project management tools. In agile, a lot of decisions are taken by the self-organized teams. Hence the tools need to be able to support the needs of the team. If the team decides that the tool is an overhead or is not adding value to them, then it becomes worthless. By contrast, the primary need of traditional tools is targeted towards managers, who are the decision makers to micromanage the team. 

A big problem is when an agile tool is used in a traditional way – i.e. the team does not feel the value, but is forced to use it so that the managers can micromanage them. My personal opinion is that tools that encourage this behavior rarely lead to truly agile culture. 

Tell us why you decided to create your software and did you use agile way of managing it while n development?

The previous answer has some insight into why we launched our tool. We saw that many organizations implemented tools which support agile mechanics, but not the agile mindset. Such tools get deployed, teams hate to use them but are forced to do so because the management doesn't trust the team and wants to control exactly what is going on in the team. Well, guess what? The team only updates the tool rarely and the data is unreliable so it helps nobody. This does not help build an agile culture. 

What we wanted to do was to build a tool that a team will find easy to use and useful for their own self organization. Basically, we took traditional, proven methods that teams use in a physical space -- card walls, task boards, story maps and so on, and made them available in an electronic format. This gives the benefit of electronic tools, while still being in a format that teams find useful for themselves. 

What according to you are the 3 qualities that every Agile Project Manager should have?

First, curiosity to keep learning. Secondly, soft skills to connect with people (within the team and outside) and build relationships. Finally, the ability to influence people and drive change and improvement. 

I haven't said anything about knowledge of agile. This is easy to learn, and anyone can learn what a product backlog is and how a particular process works. But the qualities above are difficult to train, and very crucial for agile success.

If someone new, stepping into Agile Project Management asked you about the 3 books to read, what would you recommend?
My favourite three books are:

1. Agile Software Development -- Alistair Cockburn (Quick note: This book isn’t about agile, but methodologies in general. It’s a great background about how and why agile works, but perhaps not what you are looking for if you want to know specific mechanics like how to story point a story)
2. The principles of product development flow -- Donald Reinertsen 
3. Kanban -- David Anderson

Where can someone find the link to your software and your books?
I've also been a contributor to this book - http://amzn.to/beyond_agile


Thank you very much for your time.

Does Agile mean NO Managers?

Mar 6, 2014 | | 1 comments |
In trying to move in the right direction Agile-wise too soon, there are organizations who will consider removing managers or team leads completely from the equation.

However, removing the title doesn't mean, the role or the job has been removed and these management positions are simply disguised via different names. There are scrum masters sometimes who are actually functional managers for the team.


I think the reason these roles overlap is because sometimes organizations don’t realizes the role of a scum master.

A scrum master is the facilitator for the team and does not make decisions for the team. I think this is the trickiest factor that no management realizes. Scrum master isn’t the decision maker or someone who will appoint stories or tasks to the team. So a manager cannot disguise himself into this role.

So, one way to resolve this problem is to never merge both of these roles. Scrum master and the functional manager shouldn't be the same person. Even by overlapping roles for one team, you send out the wrong message to the other teams.  

The managers can happily co-exist with the agile teams and they can be great blocker resolvers. They should be the one helping teams deliver more by removing all impediments, looking into the patterns and trend of all teams and see what can be done to minimize the recurring causes of the issues.  


If management interferes and spoon feeds teams in every chance they get, teams never come close enough to becoming self-organizing teams and making their own decisions. Management can choose to either make teams adopt Agile better or make decisions that messes it u for the organization. 

(pic courtesy: google images)