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:
The market and customers require services and features faster, cheaper and at higher quality.
Leadership (management, sales, customer success, marketing, finance, etc.) respond by putting pressure on the Product organization, which is – at the end of the day – represented by Product Managers and Product Owners.
Product Owners ask for the Agile team(s) to delivery stories and features at high speed, but with good quality.
The Scrum Master acts as protector of the team and helps negotiate a feasible commitment (related to scope and time).
The Agile team attempts to deliver against their forecast/commitment.
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:
PPM – project portfolio management: Higher level roll-ups, reporting, forecasting and even budget tracking were introduced in the attempt to meet the needs of leaders and manage portfolios of work..
Product planning and roadmapping – This area, which is still in the early stages of being conquered by ALMs, involves product strategy, ideation & planning, roadmapping, story mapping, etc., i.e. The part of the product life cycle before items are defined enough to be worked by Agile teams.
DevOps – The realization that fully tested software coming out of Agile teams by itself adds no value until it is deployed and running in production was catalyst for forays into DevOps and automation to accelerate and automate the “last mile” of the development process with the goal of increased visibility and ultimately continuous deployment.
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.
The Next Frontier: GLM
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.
The Growth Item Value Loop
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:
Growth items get identified through Agile ceremonies such as sprint retrospectives or strategic retrospectives as suggested by AgilityHealth.
Growth items get collected in a growth backlog and prioritized.
Items that teams have the ability to address get worked on by Agile teams. Due to teams’ limited capacity only the highest value items may get worked on. Experimentation and inspect & adapt results in feedback loops and iteration over time.
Organizational growth items that teams themselves cannot resolve themselves require leadership to get involved. Leadership teams have to be formed consisting of at those leaders that have a stake in and ability to resolve those items.
Once formed, growth leadership teams work on addressing the highest value items since these teams too are often constraint in their capacity. When they are able to resolve items, feedback should be provided to the teams that identified the growth items, so that teams see that their voices are heard and that leadership takes them seriously and is interested in enabling them go get better and healthier. This type of feedback will reinforce the value of this process.
Out of all items on the growth backlog, the most pressing items will hopefully see resolution by teams and leadership.
The immediate impact of resolved growth items is improved team health, which has various components including morale/happiness, effectiveness, level of collaboration, and skills.
Improved team health will result in improved team performance which manifests itself in higher quality, throughput, value delivered or customer satisfaction which should tangibly benefit the organization and its financial performance.
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:
Organizational agility: enabling the organization to act and react quickly to environmental and market conditions.
Portfolio management, i.e. understanding size and benefit of high-level initiatives and making optimal decisions for the business. Working on the right things (in the right order).
Systems thinking (vs. local optimizations), aimed at optimizing the whole process of value delivery, not just software development.
Removal of waste in processes and shortening cycle times of value delivery (not just creating shippable code).
Making decisions based on economical and empirical considerations.
The Lean Agile mindset which influences leadership style and organizational decision making.
Organizational culture, including, but not limited to trust, respect, empowerment, etc.
Organizational design and structure as well as performance management and recognition approaches.
Product development approaches, e.g. the Lean Startup.
Drive away from industrial era management beliefs and styles.
Accounting practices impacting if and how capitalization is practiced, budgeting and planning.
Appropriate metrics and KPIs.
Technical practices (CI, CD, DevOps) and quality practices (test automation etc.) and technical craftsmanship.
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.
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:
What common challenges do you see across your teams?
What are things that can be done to help the teams improve in these areas?
As people reported on what they had observed, the common patterns that kept repeating were:
The further out into the future teams looked, the less clarity they had.
In other words: while most teams were pretty clear on what they were building an iteration or two out, they had much less clarity around the longer-term product roadmap. (Think of driving in the fog.) The backlog gets filled “just-in-time” for the next sprint.
Root cause could just be simply omission by the product owner to communicate the roadmap or actual challenges planning further ahead.
One of the impacts of the lack of a product roadmap is that design and architecture decisions are challenging because the teams won’t know what future capabilities their applications will need to support, which may result in suboptimal design, i.e. architecture that won’t easily support future features.
Teams aren’t clear on the value they’re delivering sprint over sprint to the business.
While they produce working software on a regular basis and release it to production, they’re not clear on how these features support business objectives and what results they produce, e.g. incremental revenue, customer sign-up/retention, etc.
In the process of brainstorming solutions, the following ideas came to the surface:
If longer-term roadmaps do exist and the product owner simply doesn’t make the effort to communicate them the team, it’s an easy fix to make the time to review and walk the team through them on a regular basis. Frequent communication between product owner and team are key.
In the case where these roadmaps actually don’t exist, this becomes more of an organizational growth item and needs to be addressed by working with the organization to drive towards developing longer-term roadmaps, e.g. quarterly or longer.
It was also suggested to publish a regular newsletter which could describe to the organization what the longer-term plans are and what business results recent features have achieved.
Establishing certain metrics may also be useful, such as using business value points at the feature level.
The organization may also want to make a concerted effort to capture customer reactions post deployment, e.g. customer sign-up or conversion (as suggested by the Lean Startup), user behavior through site instrumentation, etc.
Even capturing anecdotal customer feedback, customer success stories or app reviews with comments and communicating those back to the team could be useful.
It was also suggested to internally showcase the product features and capture survey responses.
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?