The original agile manifesto has been around for nearly two decades now and at a fundamental level, proclaims the core values that Agile stands for. The values of individual interactions, customer collaboration and responsiveness to customer requirements and changes – all coming together to produce working software incrementally and at a consistent pace – have been, and will remain the core theme for a long time to come. Having said that, when it comes to an organization, how these values manifest and are implemented to ensure agility at an enterprise level, has been an issue that many organizations have grappled with, and rather unsuccessfully.
During the last 12 years, PM Power has worked with many organizations in their journey towards an effective Agile way of working and in sustaining it over time. This blog presents a “manifesto” that, from our experience, summarizes key challenges, as well as, what organizations need to do to deal with them.
Here it goes:
“PM Power helps IT organizations with Enterprise level Agile Transformation and in sustaining it over time. Through our collective experience in this process, we have discovered significant value in
- Focus on Customer outcomes Over Backlog burnup
- Self-organizing teams Over Supervised teams
- Transformational Leadership Over Directive Leadership
- Experimentation and Learning Over Planned improvements
- Lean thinking Over Productivity Focus
That is, while there is some value with using items on the right, we have found true organizational agile transformation happens through focusing on items on the left.”
The rest of the blog focuses on explaining these values with some examples.
Values elaborated
1.Focus on customer outcomes over backlog burnup
Most organizations focus primarily on activities and outputs (essentially burning up from a backlog of items to do on an on-going basis) without a focus on how such activities or outputs impact outcomes for their business / customers. Typical outcomes from a business perspective for an enterprise may include increasing customer retention, improving customer experience, reducing cycle time in how the organization responds to customer requirements or requests, improved market share / profitability and so on. What delivery teams or support organizations do through their defined backlog is expected to clearly and visibly map to these outcomes. However, more often than not, teams in organizations are caught up in just tracking these activities / outputs (through backlog burnup), that they invariably lose sight of what they are working towards. If you take an example of a HR team in an enterprise, they are more often concerned about meeting recruitment or training targets rather than outcomes such as employee engagement or satisfaction that have a direct bearing on the organization’s business outcomes such as customer retention or experience.
If you take delivery teams, they tend to focus too much on stories completed in an iteration and the effort spent, and the speed with which the product backlog is burned up every iteration. While backlog burnup is important, teams need to relate to how this and/or other measures that need to be tracked impact business outcomes and own and deliver on those outcomes. For example, for a set of teams working to deliver a major release of a product, the expected outcome may be predictability of release commitment made by the team with the required quality. The company may miss a key market window / opportunity if the release date commitment is not met, with the most critical features committed working, as per user expectations. Measures defined should take care of both these outcomes and teams need to be aligned to them and tracking performance against these outcomes. For example, how does one ensure user experience is understood and planned for and tracked on an on-going basis? What other factors (other than backlog burnup) contribute to predictability of delivery? Are teams staffed right and stable? How good, ready and visible is the product backlog? Unless all teams understand expected outcomes and align measures they track against these outcomes, they will end up with missing out on committed outcomes. For success with Agile, teams need to be owning and delivering on outcomes.
2. Self-organizing teams over Supervised teams
Self-organization was a principle that the original agile manifesto talked about, mostly at a team level. However, most organizations have ended up paying lip service to that principle. They have managers running delivery and releases, yet claiming their teams are empowered and self-organized.
Self-organization is a powerful value and a need at an enterprise level. Given the need for flexibility and responsiveness to dynamic market needs and the high degree of technology complexity involved, organizations cannot afford to work in functional silos to deliver value. Functions including pre-sales/sales, development, quality assurance, user experience and product design, product management, release engineering, and operations have to come together and operate without boundaries to deliver customer and business value. Day to day directions from managers/supervisors to such cross-functional teams will stifle them and slow them down in meeting commitments. The enterprise culture should promote ownership for outcomes in every individual and this needs to be combined with effective cross-functional collaboration and self-organization of teams for success.
Self-organization requires that teams that deliver and support customer requirements and product releases, find their own ways of how they will plan and organize themselves. They need to estimate and plan commitments they make, and make decisions on how they will re-organize to meet commitments when issues crop up, or new requirements come in or when things don’t go according to plans made. There should be no functional boundaries across the organization to deliver on customer and business commitments. When this happens, you can sense that the ownership is with the teams involved and they feel empowered to give their best to meet commitments. The role of managers and supervisors in this process is to ensure that teams have the required competence and infrastructure / environment support to get things done.
3. Transformational Leadership over Directive leadership
One of the issues most organizations faced with moving to agile in the early days was the belief that agile behavior and implementation have to do only with delivery teams and not with senior management and leadership. The fact that agility is a mindset and culture issue that needs to be pervasive across the organization was lost on them and even the consultants who helped them in their agile journey did not realize the importance of leadership transformation required for success with Agile. Only during the last two to three years has there been an attempt to look at Agile transformation as an enterprise level initiative.
What this has meant for organizations that moved to Agile several years ago has been unmet expectations and hard learning along the way, and even worse, a difficult mindset change for leaders used to operating in a directive mode all along. When a leader is directive with his/her own reportees (who are often managers themselves), they tend to carry the same style with the teams they work with making it impossible to have self-organizing teams as we discussed before. Directive style of leadership may be needed in some specific situations – for example when the team is facing a short-term crisis where the team needs direction and close monitoring to overcome the crisis – but managers need to quickly revert to a facilitative mode once the crisis is overcome.
What is needed for success with Agile is Transformational leadership. With such leadership, leaders communicate the vision for the organizational transformation, provide the big picture and set direction and once this is done, they provide the required space for organizational units and teams to determine how they will execute on that vision and enable and support them in delivering on it.
4. Experimentation and Learning over Planned improvements
Most organizations rely on processes for planning and driving improvements. For example, annual strategy reviews, quarterly operational reviews and product release / team retrospectives are some means by which organizations take stock of what they are doing, how it impacts outcomes and results and use that to identify and drive needed process or policy changes.
The trouble with planned improvements is that more often than not, the focus is on compliance and less on effectiveness. I have often seen product release level retrospectives done as a ritual when teams are tired and exhausted at the end of a release, with the result you rarely get quality improvement inputs. Planned improvements work to an extent but organizations become creative and achieve breakthroughs when individuals, teams and organizational units are allowed to experiment and learn from their failures.
For example, teams can be allowed to experiment with their engineering processes, use of tools or the way they plan, estimate and track commitments as long as the leadership knows that they understand their responsibility and ownership for outcomes. Teams need to know that they will not be micro-managed and will be given space to experiment and learn from both their successes and failures. In fact, there should not only be encouragement and support but reward for teams and units that are role-models in experimentation and innovation. This is clearly a function of the organization and leadership culture and takes time to evolve and nurture.
5. Lean thinking over Productivity Focus
It is impossible to find one organization that is not concerned with team productivity and consequently its contribution to organizational productivity. While, by itself it is not as big an issue, it becomes a concern when leaders are obsessed with productivity and measurements for productivity and worse still, setting organizational standards and using comparison of such standards and measurements across teams to determine which teams are doing well.
One of the most often used productivity measurements in an agile environment is velocity. The trouble with velocity as a productivity measurement is that velocity doesn’t always give a true picture of how a team is doing. When teams are measured on velocity there is a tendency for them to somehow meet this objective, which may indirectly affect the way they size stories to meet expectations of velocity. Velocity was always intended as a measure to forecast and predict what teams can accomplish in a given time frame (such as for a product release) and for teams to use it to understand their process and drive improvements in their ability to deliver over time.
Organizations need to focus on the entire cycle from market demand / requirement through to delivery, support and feedback to identify and reduce non-value adding activities. This is essentially what lean thinking is all about and needs to be an obsession with all teams involved in the entire process flow. This is a substantially better way to drive waste reduction and increase efficiency.
Organizational units should be supported in measuring waste and cycle time, and in understanding and addressing factors that contribute to higher waste and cycle time. The intent is to ensure a smooth flow of process that delivers significantly better business outcomes than a focus on productivity and output driven measurements that oftentimes does not deliver the required outcomes.
