A Practical Approach to Agility and Product Management

Tag: health

Pressure Filters in Agile Organizations

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.


Continue reading

From ALM to GLM

The Evolution of ALM Applications

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:

  1. 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..
  2. 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.
  3. 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:

  1. Growth items get identified through Agile ceremonies such as sprint retrospectives or strategic retrospectives as suggested by AgilityHealth.
  2. Growth items get collected in a growth backlog and prioritized.
  3. 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.
  4. 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.
  5. 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.
  6. Out of all items on the growth backlog, the most pressing items will hopefully see resolution by teams and leadership.
  7. The immediate impact of resolved growth items is improved team health, which has various components including morale/happiness, effectiveness, level of collaboration, and skills.
  8. 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.

Agile is Everything – Everything is Agile

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:

  • arrows with AgileOrganizational 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.
  • Architecture (think emergent architecture, loosely-coupled components, micro services, etc.)
  • Relentless (self-) improvement at all levels. Kaizen.
  • Team and interpersonal dynamics.
  • Team and organizational health.
  • Product innovation.

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

  • Engineering, technology, architecture, quality (obviously)
  • IT infrastructure
  • Product management
  • Project management
  • Finance & accounting
  • Human resources

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.

Common Team Patterns

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?

Closing the Impediment Gap

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?

Internal Impediments

As long as it’s within the team’s or Scrum Master’s control to successfully deal with an impediment, this is a viable approach and
hopefully most impediments fall into this category. (Let’s call these “internal impediments”.)

External Impediments

The problem is, there are these other impediments that are outside the team’s or Scrum Master’s control (let’s call these “external dependencies” because their root cause lies outside the team). What happens to those? Scrum doesn’t really say and is missing explicit mechanisms and ceremonies to deal with them, so it’s often left to the Scrum Master to figure this out.
During an Agile transformation, when a lot attention is paid to the maturing Agile teams and the overall progress, there is – in most cases – a person or a group of people in place who “own” the transformation. This group is a good audience for helping the teams resolve external impediments because it is motivated and empowered to keep the transformation on track.
 Photo Aug 07, 12 49 57 PM
In organizations which have been Agile for some time (maybe several years), often there is no clear ownership of “Agility” any more and it’s (hopefully) just part of an organization’s DNA and status quo. In these cases, the Agile steering committee has often-times already been disbanded and with that, there’s now a void in that a Scrum Master with external dependencies has no clear audience to get resolution. He may improvise, try to track down various involved stakeholders and affect organizational change himself, but, due to his lack of organizational influence, may not get very far. In those cases, these external dependencies often remain unsolved and the teams tend to get frustrated and numb to the impediments that never get taken care of. They feel the lack of organizational support, give up and often just “deal with it”.
 Photo Aug 07, 1 00 26 PM

What to do?

So what is the solution? During an Agile transformation and beyond, an organization should have a clearly identified group of Agile stakeholders, people who feel responsible for the success of Agile in the organization. Then there should be an explicit process for dealing with external dependencies that involves those stakeholders who will hopefully take ownership of these hairier organizational impediments.
That said, organizations aren’t always great at putting these mechanisms in place and might require to be given more specific guidance and tools. That’s where AgilityHealth (an Agile assessment and growth tool) can provide the necessary structure:
  • Resulting from regular strategic retrospectives, external impediments are identified and clearly flagged as “organizational growth items”
  • Those impediments are reviewed quarterly with an explicitly defined leadership group
  • That group pulls a number of these impediments from the growth backlog and commits to resolving them
  • Impediments are dealt with and resolved (likely in collaboration with the team)
  • After 3 months, the leadership group is asked to review with the teams the progress that has been made (this doesn’t imply that impediments shouldn’t be resolved faster if possible).
  • The cycle starts over.
Photo Aug 07, 12 59 20 PM
In essence, this process & tool create a new macro feedback loop as well as a quarterly “impediment sprint” with leadership. (In larger organizations, there could be several concentric layers of impediment sprints, e.g. involving portfolios first and then the overall organization.) Since this approach makes explicit the process, its cadence, the process participants and roles, it helps fill the gap that Scrum and other team-based Agile frameworks leave unfilled. Institutionalizing the process will provide accountability and heart beat that ensure these external impediments aren’t left unresolved.


I’m hoping this blog post has helped identify different types of impediments that need to be treated differently and will encourage organizations to be more deliberate with regards to how to deal with external impediments.