What does success mean to you? One gets different answers depending on who the question is being asked. When talking about agile teams, the primary measurement of success is measured by how often teams deliver incremental business value driven product, directly resulting in more revenue to business or enhanced customer satisfaction or both.
As teams undergo training on agile values and principles, they get particularly excited with the idea of self organization and empowerment. Once trained, it is time to put the values and principles to practice. However the realities of management and control become a common cause of conflict resulting in the teams having to make a choice between agile behavior and management impression. The choice is quite obvious.
While a lot is done to encourage teams to become agile, management continues to be resistant. A big part of this resistance to change has to do with the perception management has about teams. Teams are constantly stereotyped as individual performers who cannot be trusted to deliver a defined scope of work in a defined time frame unless micromanaged. The result, teams are constantly given dates by which they need to deliver. To add to this, management continues to measure teams by data that does not encourage agile behaviors.
Tell me how you measure me and I will tell you how I behave Eliyahu Goldratt
Here are some key measurements that when looked in the right way will help get a true sense of what is being delivered and how successful the initiative is:
- Alignment (Alignment is a practice, not a state) – Once a vision has been established, a conscious effort to ensure alignment with the vision becomes critical. An great analogy of alignment was the recent mars mission by the India Space Research Organization (ISRO). The mission took almost a year to reach Mars from Earth but the biggest success factor is how it goes through coarse correction each second. There are systems built to just manage this aspect of the mission and the failure of the same can result in waste of immense magnitude.
- Incremental Value – Every bit of effort spent should translate into incremental value. Value can be something small that the business is able to see and provide feedback on to something equivalent of a business increment that increases revenues. In a lot of cases, teams have been seen spending effort on something that has nothing to do with the intent behind all the effort. For example; teams are often see spending time on making their velocity or their sprint burn down look good which provides no value. It is absolutely critical that everyone involved has a consistent definition of success.
- Fail fast – I was watching a video of the CEO of Google recently in which he talks about failure and why failure needs to be worn as a badge of honor. Most organizations have not been able to create an environment where individuals and teams feel safe to fail. The most obvious impact of which is elongated time spent on presenting inaccurate data pushing projects to fail late in the game hence resulting in huge waste.
Failure needs to be assessed all along the way and all involved parties should challenge each potential failure point to ensure failure can happen early and learning can be put in practice.
None of the above mentioned parameters can be quantitatively measured which is where the standard metrics based on the methodology only work as facilitators to the mentioned parameters. A conversation around methodology specific metrics only results in the core benefits of visibility, transparency being lost. Standard metrics should be assessed with an intent to gauge the health of an initiative driven by a well defined and consistently understood vision, ongoing alignment to the vision, delivery of incremental value and opportunity to fail fast.
I recently had this opportunity to talk at the Agile City Limits conference at the Dell headquarters in Round Round, Texas. There were a lot of awesome things about the conference. Awesome crowd, awesome energy and from the audience an awesome urge to ask some really great questions. Not to mention that the topic itself “Distributed Teams and Dependencies” was one that is the biggest concern with any large organization trying to adopt agile.
The primary intention behind this presentation was to decouple challenges with a distributed setup and agile. The problems teams and individuals face with a distributed team are resolvable through the use of right tools and techniques. With large and distributed teams, there is so much focus put on process that most teams gradually move away from individuals and iterations and drag themselves back to be driven by using more processes and tools.
The key to overcoming challenges with distributed teams is through using the right balance of agile teams with focus on product/project vision, cross team collaboration, building the right level of trust and understanding cultural sensitivity. Additionally, communication and collaboration tools along with required development tools become great facilitators for collaboration between teams. Teams using agile methods have had great success with tools like story mapping, backlog grooming, scrum of scrums.
I also took the opportunity to talk about what makes a good distributed setup and how organizations should focus on running Scrum successfully before scaling. At the end of the day, it is all about managing the distance.
The audience was particularly interested in understanding the opportunities around team dependencies. My focus in this part was to share my experience in how I and the teams I have coached addressed the challenges with team interlocks. After talking about why dependencies exist and the kind of problems dependencies bring, I walked through some tried and tested approaches which included:
- Approach to plan to keep dependencies to minimum as you form new teams
- Creating an open source model
- Planning for dependencies ahead of time
- Creating communities of practice for better collaboration
All in all, it was a great discussion and I hope the audience enjoyed attending my talk as much as I enjoyed presenting it.
Here’s my presentation.
Wanted to share my experience facilitating a retrospective for my team using the “Action for retrospectives” from innovation games. This is a excellent technique/game that allows the team to think about a retrospectives from multiple angles.
The “appreciation” angle came as a big surprise. Appreciations came in from everyone, both at personal and team level and setup the right environment for the more difficult discussions to follow. It was a very clear indicator of the fact that the team members appreciate each other but never had an opportunity to bring that in the open. In fact the appreciations clearly out numbered the other angles mentioned below.
The “puzzle” angle was about raising issues that existed without any member of the team having any knowledge about any possible resolutions. However; it turned out to be slightly different. A key finding being that a puzzle for one team member was not necessarily a puzzle for others. It remained a puzzle for one due to lack of conversation and collaboration between team members. As soon as it was bought out, potential solutions were discussed and actions items identified.
The “risk” angle highlighted issues that team members were experiencing as individuals but rarely had an opportunity to bring it in front of the whole team. There were issues that belonged to more than one buckets, in which case we allowed the team to have duplicates across multiple angles.
The “wish” angle was all about inviting innovative ideas from the team to focus towards continuous improvement. The team thought outside the box and came up with great ideas.
What makes this tool effective is that it brings out the high priority issues that might have not have been noticed by the team. If the same issues exists multiple time as a problem under puzzle or risk and there are ideas to address it under the wish angle, the issue just emerges as the highest priority. The team can then choose to identify the top issues and define action items to address those issues.
Click here to see a detailed description of the technique and access the online version to use this tool with distributed teams.