Have you ever wondered how import leaders (Product Owners, Scrum Masters, Tech Leads, and stakeholders) are when it comes to the health and productivity of Agile teams? Well, I looked at the data and here is what it says: Continue Reading
Nowadays, everyone feels pressure in an organization. Traditionally pressure has been viewed as starting at the top of the org chart and permeating and cascading down in the organization. For this discussion, let’s assume the pressure originates outside an organization as market or customer pressures. Those are often to deliver features and services and to do so faster and more cheaply. Patience is not a key virtue of today’s economy.
In an organization that subscribes to Agile values and processes, the pressure takes the following path:
ALM (Agile Lifecycle Management) solutions, i.e. applications that help Agile teams deliver software solutions, have come a long way. They started out as tools to manage a backlog and assist teams with working on stories and defects in sprints. Then came collaboration features, reporting and the ability to work in Kanban. As the number of teams grew and more complicated work had to be organized and managed, portfolio items/epics appeared which helped group related stories into higher level aggregates.
In recent years, the ALMs (such as VersionOne) increased their functional footprint into other adjacent areas:
While the ALMs aim to cover core functionality in these different areas and continue to push their boundaries, it is also common to offer integrations for more sophisticated solutions in these areas in case the ALM customers demand highly specialized functionality.
While ALMs do a good job of ushering work items through the Agile process and even carry it all the way to becoming deployed software in production, there is a different class of items that – often invisibly – work their way through Agile teams and organizations: growth and learning. As Agilists we know that our teams, programs and portfolios should constantly evolve and improve. We are inspecting and adapting and applying Kaizen on an ongoing basis to improve.
The “items” in this case are not stories, defects or even epics/portfolio items; they are improvements and learning objectives (I’ll refer to these as growth items). At the team level, growth items may result from retrospective meetings and sometimes manifest themselves as improvement stories (or issues) in the ALM’s sprint backlogs or on the wall in the team room. While growth items are fundamentally different than stories and defects, making them visible as part of the backlog ensures the team remains focused on dealing with them.
This approach at the team level works reasonably well, although growth items are a different class of items and often don’t follow the same rules and flow of regular backlog items. Example: these improvements are often not part of the sprint commitment because they may require more time to resolve. Including them as part of tasking and burn down may also not work overly well. Frequently, growth items also require experimentation and several rounds of inspection and adaption spanning multiple sprints before they can be considered resolved.
Today’s ALMs may offer some solutions for team-level growth items but often that functionality is more of an afterthought. Where the approach breaks down even more is when those growth items that are outside the teams’ control and need attention and resolution by higher level entities, which could be programs, portfolios, functional leaders and senior management (example: a company’s facilities do not provide sufficient space for teams to collocate and effective collaborate). (See also: Closing the Impediment Gap.)
The ALMs don’t currently provide functionality to effectively deal with organizational growth items and I would argue that similar to specialized solutions for other adjacent areas there is room here for a new class of solutions I’d like to call Growth Lifecycle Management (GLM) applications. With learning and improvements being at the core of healthy Agile/Lean enterprises, GLMs should provide the mechanisms to capture, communicate, aggregate, analyze growth items, manage their resolution and analyze their impact on an organization. The latter will ultimately require integration and sharing of data with traditional ALMs in order to facilitate the correlation of growth item resolution and team and organizational performance.
In the Agile world, many of us are familiar with the concept of value stream: items of value (stories, features, etc.) flow through a series of steps after which value is delivered to the organization, e.g. by users being able to utilize new functionality in production. The flow in this case is unidirectional (often depicted left to right) and in most cases all items make it through the stream beginning to end.
Growth items tend to behave differently: First of all, not all items make it through the various steps. More like a sales funnel, at each step items may be dropped or dismissed, which reduces to potential output of value and limits the number of items exiting the process compared to the number of items entering the process. Examples: teams end up not implementing improvements they identified or leaders only select 4 out 10 identified organizational growth items based on capacity or expected ROI.
Secondly, the process isn’t strictly unidirectional with a single entry and exit point. Growth and incremental improvements are based on feedback loops. At the team level, members experiment with things that may resolve impediments and inspect & adapt. At the leadership level, leaders resolving organization growth item provide feedback to the teams which positively affects the health and motivates the teams and creates a self-reinforcing loop.
Due to these differences compared to the commonly used concept of value stream, I propose the term “value loop”. Let’s look at the steps in detail:
I used the term “value loop” since the overall process is iterative and continuous as opposed to linear in nature. Improvements never stop and feed on each other as also suggested by “Kaizen”.
What’s the relationship between the Growth Item Value Loop and the regular value streams? The Growth Item Value Loop lives inside the value stream. As it spins and picks up speed, it can act as an accelerator to the overall value stream as the improvements in health and performance positively affects the overall value stream performance. This dynamic also makes a compelling business case for focusing energy on the Growth Item Value Loop.
In Summary: The growth item lifecycle is very different than the lifecycle of traditional work items going through their value stream. Despite various vectors of functional growth, current ALM solutions do not effectively encapsulate the Growth Item Value Loop. Since this loop is at the core of Lean/Agile and valuable accelerant with tangible business impacts, there is room for application providers to cover this still relatively uncharted territory of GLM.
As agilists, we are all fighting – to various extents – the perception that Agile is a set of processes, techniques, and (if we’re lucky enough that people understand this) mindsets to optimize software development teams. To some degree I can’t blame people for thinking that because that’s kinda how Agile got started. But nowadays Agile is taking a very holistic approach, a perspective that goes far beyond helping a team of developers function better. By the way, when I say “Agile”, I’m including Agile scaling frameworks as well as Lean and related product development approaches (so yes, I’m casting a pretty wide net, which is reflective of the close relationships between these different knowledge areas).
Here are additional angles Agile is looking at the world from and tries to impact:
I probably forgot a few elements, but you get the gist. This is why agilists want to engage with and influence various levels in the organization, including senior management, and individuals in
Hopefully over time the limited perception of Agile will be corrected by people and organizations understanding the holistic nature of Agile. With that approach, we can really unlock and enable the potential of an organization and its products.
See the details here:
During our company’s last internal Agile Open conference (see InfoQ), we had a session that brought together Agilists using AgilityHealth (an organizational assessment and growth tool). The questions we tried to answer were:
As people reported on what they had observed, the common patterns that kept repeating were:
In the process of brainstorming solutions, the following ideas came to the surface:
On the positive side of common patterns, it was noted that a lot of teams rated themselves highly in the culture dimensions, which includes overall happiness and is the sign of good employee morale.
If you’re users of AgilityHealth, which common patterns have you observed and which actions have you seen as successful?
In theory, it sounds pretty straightforward: an Agile team identifies an impediment and either solves for it or the Scrum Master takes it upon himself to remove it. Easy, right?