Skip to main content

Author: Robert Galen

Sprint Planning or Estimates – Should Product Owners Care?

Written by Robert Galen on . Posted in Articles.

There seems always to be questions surrounding aspects of the Product Owner role. Folks are always looking for clarity around what the PO should and should not be doing.

The harsh reality is that the role isn’t that clear. Heck, I would argue that no Agile roles are crystal clear. But I do think there are some healthy boundaries and these are what I try to communicate wherever I go.

Two common questions involve the Product Owners role in sprint planning and work estimation. Both of these activities are not directly in the sweet spot of PO responsibility, so there are usually quite a few questions around what they do as the team plans or estimates their work.

My hope in tackling these two activities in this article is to shed some light on the healthy boundaries associated with solid Product Ownership, or to at the very least, give it a go.

Sprint Planning

If you read the Scrum Guide’s definition of Sprint Planning, it exposes two distinct parts to the meeting.

Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.

Topic Two: How will the chosen work get done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

Clearly the Product Owner is required for first part of the meeting. But after that part is completed, nearly every PO I’ve ever met wanted to leave the team to their own devices in planning the sprint. Their hearts are in the right place, but I believe they’re wrong in leaving. They’re missing an incredible opportunity to listen to their team and gain insights into what’s hard and what’s not.

You see second part of Sprint Planning is essentially focused on four things:

  1. The team plucks each story off of the Product Backlog in priority order;
  2. They decide, as a team, the strategy they will use to attack the story. Who will do what, where are the hard bits, are their collaborative opportunities for swarming on the story, what is the optimum workflow, what testing will occur and when, etc. The discussion unfolds around the plan of attack for each story;
  3. Then the team tasks out all of the work associated with delivering the story to meet their (and the organizations) Definition of Done;
  4. Usually, there is also discussion around the overall level of effort and risk. Sort of a retrospective of the actual work (hourly estimates) and how it stacked up against the original sizing in Backlog Refinement.

Sprint Planning stops when the team is full or at their capacity. I often see teams stop during sprint planning to reassess who is working on what and then reassign / better balance the work to better consider team skills and availability.

Related Article: Agile is a Team Sport

My point in asking that the Product Owner hang around for sprint planning is this – there is an incredible amount of information they can glean by simply listening to their team. For example, they can better understand:

  • What stories are inherently harder or more complex than others;
  • When teams need to spike stories and how to encourage that earlier in backlog refinement;
  • New found insights into testing complexity and effort for different types of stories;
  • The skills and capabilities of their team, so that they can better align the backlog with the real capacity of the team;
  • Of course velocity reality surfaces in sprint planning, so understanding the team’s true capacity is another benefit.

Product Owners can also simply listen to the strategies the team is discussing to attack the work. If they feel they are missing things, they can suggest alternatives. For example, if the Product Owner feels they’re biting off too much, they can say that. Or if the plan is too risky, they can challenge that as well.

I guess what I’m trying to say is that Product Owners are a member of the team. So they should participate in planning as much as possible to create a balanced and thoughtful plan that is achievable because it’s THEIR plan and THEIR commitment too.

Now let’s move onto the other topic, what part should the Product Owner play in estimation?

Estimation

Let’s first make it clear that there should be very little one-time estimation in Agile contexts. All of the Agile methods take a two-tiered approach to estimation.

Tier-1 is estimating Product Backlog elements. Quite often you hear of teams estimating in story points or t-shirt sizes. Most of the units have a relative nature to them – meaning that they’re not intended to be time-centric or laser accurate. They’re “in the ballpark” estimations that are relative to one another. For example, a 5-point user story should be roughly twice as large as a 2-point story. Or a medium story is roughly twice as big as a small story.

These estimates are focused on giving the Product Owner a relative view to the size (cost) for each element or user story in the Product Backlog. And remember that the team iterates on estimates as they break stories down in the backlog. So the Product Owner is continuously being exposed to size and cost information as they consider trade-offs and reprioritization (valuation) in their backlogs.

Tier-2 estimation is quite different. It’s directly an output of sprint planning and involves the team breaking the stories down into tasks and then estimating the amount of time and effort for each—usually in hours. So in this case, each sprint the team gets into the inner details of the work and determines their best guesses for tasks and hours. Traditional project managers and planners typically like sprint planning because it gets into the nitty-gritty details.

But only the details for the current sprint.

Product Owners and Estimation?

Back to the question, what role does the Product Owner play in estimation? They need to engage as a team member. They need to challenge the scope and details of estimates. They need to understand the Definition of Done and ensure that their team’s estimates fully support it.

They need to continuously consider their teams capabilities, risk, and complexity when it comes to committing to work. Helping their team negotiate the fine line between over and under commitment – delivering as much, high-value software that they can.

They also have to realize that they can positively (and negatively) influence the estimation process within their teams, not only with their words but with their inflection and body language. If they put incessant pressure on the team to cut their estimates, then they’ll get just that – poor quality, poor estimates, and demoralized team members.

If, on the other hand, they emphasize positive analysis and thinking for example:

  • In full support of done-ness
  • Supporting solid design and construction
  • Building in quality
  • Iterating on simple solutions
  • Continuously getting customer feedback
  • Giving the team space for innovation and creativity

Then their role compliments Agile estimation effectiveness incredibly well.

Wrapping Up

Let me start this section by saying that the Product Owner role should not have a direct role in planning or estimating.

Why you might ask – since that seems to be contrary to the theme of this article.

Well, because they’re not directly doing the work. The Product Owner is also heavily biased towards delivery, and there’s the potential of them negatively influencing the team.

But with that being said, I think there are important supporting roles the Product Owner can play in both activities, one where their experience and balance can help the team’s execution.

To answer my introductory question, should Product Owners care about planning and estimates? The answer is more than yes; it’s engaging as a responsible teammate, which helps the team deliver on the vision and goals.

Stay agile my friends,

Bob

The Collective Memory of the Team

Written by Robert Galen on . Posted in Articles.

If you’ve any experience in Agile approaches for software development, one of the common arguments surrounds documentation. Mostly it centers on software requirements, but it also extends to other forms of documentation, for example, design or user-centered documentation.

Many Agile teams struggle with documentation. My experience aligns with folks leaning one of two ways:

  1. Either they continue to write requirement documentation (and literally ALL documentation) as if they were still operating in a Waterfall environment, or
  2. They write user stories that are so terse as to be hardly useful in describing the customer’s expectations. And they often stop writing anything else.

In other words, they go to the extremes of documentation instead of finding a healthy, lean, and communicative balance. One of the reasons for this seems to be our view of documentation as being the sole repository for product and team knowledge. While that’s true, I also like to remind Agile teams that there is another viable form or place for that knowledge – which is the team’s memory. Since many of the Agile ceremonies are whole team events, I like to ask teams to use their collective memory as part of their product information and knowledge archive.

This article intends to explore that notion just a bit more deeply.

The Team’s Collective Memory

I think the intent of Agile documentation, in general, is only to write what has value for the team towards creating valuable software. There is the realization that all documentation has two purposes, either it:

1. Serves as a communication device as the team is building an architecture, feature, or capability; or
2. It serves to document something for future consideration.

If we’re worrying about our current sprint or the next few sprints, then conversations are equally important to writing things down. And by this I mean whole-team conversations.

In one recent article, I disagreed with a fellow coach who was leveraging a backlog refinement technique that only included Product Owners and a sub-set of their teams. The rationale was driven mostly from an at-scale, Enterprise level perspective. But my key argument against it was that the team would be missing the future context that ongoing discussion, engagement, and story distilling would give them.

Not only from the short-term point of view but more importantly from a longer-term perspective. It helps the team to think about, design for, and anticipate their future. It’s also quite motivating…to know where you’re going.

Why Collective Memory Matters 

An important part of the collective memory is learning from our history. In Extreme Programming, there is a term called Yesterday’s Weather. Initially, yesterday’s weather reflected estimates and actual, so the point was to consider past work (estimates, actuals, interruptions, complexity, etc.) when estimating future work.

But I believe the concept is broader than that. Everything an Agile team does in its journey is fodder for yesterday’s weather. For example:

  • Similar stories – we’ve done something like this before. In fact, there are 8 stories in the backlog that look very similar to that historical story and this one. Should we handle them the same? What about at the same time?
  • Gotchas – last time we did something like that, it really didn’t work out very well. In fact, it literally “blew up” in our faces. Let’s not do that again…or let’s approach it a different way.
  • Knowing over doing – you know, you were right the last time when you said we needed to spike that story. Is this one similar? And would a little prototyping increase our knowledge over simply guessing?
  • Help with just enough – we encountered a story very similar to this a few sprints ago. It helped us a lot to define business rules for the discounts. Is this similar to that? Do we need that information before we can accurately estimate it?
  • Similar, but – oh, this is like that other story BUT only 50% of the testing effort and the development is about 2x more work. How many points did we assign to it before? And how long did it actually take?

I find that the more we bring our ever-increasing collective memory to bear in our user story conversations, 3-Amigo discussions, and backlog refinement, the better the results. Not only results from a delivery point of view, but also from a solution integrity and impact perspective.

Collective Memories Help Form Reference Stories

Another part of your collective memory is forming what I usually call reference stories. These are user stories that you use as examples to help your estimation. Whether you’re using Fibonacci-style, T-shirt style, or no estimate style estimation or something else, having a historical view to stories of different sizes (examples) can really help your estimation and planning.

In this case, reference stories can be:

  • Actual stories where the estimate turned out to align well with the actual (results).
  • Sometimes it’s helpful to have reference stories for the “types” of work you do: front-end, back-end, DevOps, UX, whatever.
  • You’ll need reference stories that align with your estimation values. For example, find a nice “medium” front-end story and use that as a comparison for other mediums

I also talk about the recalibration of your reference stories. If, for example, you find that your size Fibonacci-8 stories typically turn out to be Fibonacci-13’s or 3’s, then you may want to recalibrate your Fibonacci-8 story in some way. But be careful not to recalibrate too often – as it impacts the validity of your teams’ velocity going forward.

The Power of Personas

I’ve found that the more we can describe the role, the better the implementations become. But not only the implementation details but the entire process we use for developing the story. In particular, the questions and the conversations amongst the team members become much richer.

Because of this, I often try to strongly influence Agile teams to develop client or customer personas as a means of supplementing their collective memory. In simple terms, I want to teams to from “As a User” thinking to “As a Persona” thinking. This related article speaks of making that transition.

The final point is to view your personas as emergent and active understandings of your users. That is, you should be actively modifying, extending, and embellishing your personas as you gain ongoing insights. In this way, they augment your collective memory.

How to Establish Collective Memory

And one final point in establishing your collective memory is something that pre-dates Agile. What, you might ask? Note-taking. I find that many Agile teams forget to take notes as part of their work. For example, backlog refinement meetings are a wonderful place to jot down critical notes that capture the discussions, options, agreements, and flow of work.

As a ScrumMaster, I usually ask for a team member to volunteer to be the “scribe” in each meeting – usually rotating the role. The scribe tries to capture the discussions in whatever tool the team is using to maintain their stories and backlog.

Before the team moves on from the story, the scribe reviews what they heard and the notes they’ve captured. Of particular interest to me is “next steps” in the maturation of the story. If they’ve missed something important, they’ll add it to the stories context before moving on.

Often when I discuss this approach, someone accuses me of “not being Agile”; that I’m forcing the team to write too much documentation. My usual reply is that this is FOR the team and intended to supplement their collective memory as an aspect of their Agile documentation efforts.

Wrapping Up

I guess it all boils down to my expectation that each mature Agile or Scrum team continuously develops their collective memory surrounding documentation, agreements, experiments, user stories, plans, virtually everything – that it’s a viable approach to augment how much “writing” they do day-to-day.

It’s also a compelling argument for keeping your teams together as long as possible. Clearly your collective memory is also related to the team’s cohesion and longevity.
I hope this article has piqued your thinking about Agile documentation – both the written and the remembered kind. Now if I could just remember how I wanted to end this…

Stay Agile my friends,

Bob.

Why the Scrum Product Owner IS a Project Manager, part-2

Written by Robert Galen on . Posted in Articles.

In the first part of this post we began to explore the Project Management quadrant of my 4-Quadrants of Product Ownership model. When I introduced the 4-Quadrants in this post or blog post, I introduced four areas where I thought a skilled and well-balanced Scrum Product Owner had to have skill and focus:

1. Product Management
2. Project Management
3. Leadership
4. Business Analysis

The one that seemed to get the most pushback from folks was the Project Manager area. I think because many had a view to traditional project managers they’d worked with in the past, and they were having trouble mapping these skills into the role of Product Owner.

Next I’ll continue the deep- dive exploration of aspects of that quadrant, with three more areas:

5) End-to-End Project Release Planning

One of the central activities of SAFe is conducting a 2-day PSI (Potentially Shippable Increment or Release Train) planning session as a team. The event is focused on mapping work (Epics & Themes) or the “ask” from a business perspective to each teams’ ability to commit to User Stories that meet the ask.

The planning takes an end-to-end view, so from:

  • Requirements and visualization
  • Architecture – system, UX, DevOps
  • Through construction
  • Testing (functional, non-functional, automation development)
  • Covering operational readiness (DevOps deployment, documentation, training, customer readiness, etc.)
  • Deployment to Production

In other words, it takes a “Concept-to-Cash” view to ALL of the work required to deliver on the goals, themes, and features for the release. And keep in mind that the PSI is planned in a series of sprint-level increments, so it is an iterative plan.

In SAFe, there is a role entitled Release Train Engineer or RTE. They are largely responsible for facilitating and orchestrating an effective PSI-planning event.

Even if you’re not implementing the SAFe framework, many Agile organizations and teams leverage some sort of release-level planning activity—particularly in at-scale Agile. It just makes sense to have a view to a larger picture before letting loose multiple Agile teams towards an unplanned goal.

I would argue that the individual Product Owners and the Chief Product Owner are incredibly important to effective release planning. Not only to “set the stage” with the “ask”, but to be there during the planning to answer questions and to help the teams make appropriate scope tradeoffs as they try and deliver on your goals.

I would even say that Product Owners should become “students of” release planning techniques, approaches, and models. Even with an RTE or similar role, you’ll want to partner with them to ensure you and your teams have a solid plan. Here’s a link to a PDF article that explore various forms of release planning in much more detail.

6) Stakeholder Management

I remember distinctly in traditional projects where our C-level team would “call in” the project managers for portfolio level tracking. Often they would never see or interact with the individual teams. Instead, the project managers were the sole lenses for each project.

This placed a tremendous burden on the project managers to effectively “manage” stakeholder information sharing, expectations, and their reactions. Some were good at it and others were not. Some had more trust with stakeholders, which mattered a great deal too.

Often you could draw a direct correlation between projects that were going well versus not, by the maturity and skill of their project managers stakeholder management.

As we move to Agile contexts, this sort of stakeholder management is still largely relevant, but now it falls to Product Ownership to handle expectations management. Often it focuses on reinforcing the importance of your Stakeholders and Senior Leadership to “fully engage” with your/their Agile practices.

For example, getting them to regularly attend sprint demo’s, release planning, Scrum of Scrums meetings, and even circulating around daily Scrums will give them a strong sense for progress, challenges, and where they might help.

But you’ll still need to provide a “buffer” between your teams and your stakeholders, so that they effectively understand and react well to the transparency and the adjustments being made.

Note: this crosses into the Leadership Quadrant of the 4-Quadrants to some degree. This is one of those nuanced areas that really make a difference in your overall success. I often challenge the Chief Product Owner (or other Product leaders) to think about who and how they’ll be thoughtfully and actively managing their stakeholders.

7) Project Retrospective

Clearly you’re involved in each sprint retrospective that your teams conduct. And I want to encourage you to fully engage in each one of them. But that being said, I also think you need to take your feedback acquisition “up a level”.

Your Sprint Reviews are a wonderful ceremony to gather feedback from your Stakeholders and Leaders. Please don’t miss that opportunity to gather their feedback as you deliver each increment. And don’t always assume that you’re getting it either. I’ll share a story to make that point.

I was talkin Software Devg to the EVP ofelopment at a conference not that long ago. He was describing the interaction in a recent Sprint Review or Demo. He said:

Bob, I threw a 5 to represent my reaction to the demo, but I wanted to throw a 2. In truth, the demo was terrible and I believe the team failed to meet customer needs in their development efforts. I just felt very uncomfortable giving that sort of negative feedback in front of a large audience. I pulled aside the Director of that team later, and I gave her my feedback.

I actually challenged him to speak the truth” in future reviews. I tried to make the point that it was important to be transparent with feedback as well. Sure, craft it carefully, but if a demo sucked and you said it was great, that is setting a very bad precedent. He responded:

You’re right Bob, but we are located in the South and have a culture of thoughtfulness and care when giving bad news. It will take me (and us) time to get over this cultural barrier. But I can’t imagine “telling truth” for quite some time.

Clearly you need to work incredibly hard to get all forms and types of feedback out from your stakeholders. Be aware of your cultural norms and figure out creative ways to get the truth on the table so you and your teams can address any deficiencies or misses.

SAFe has a release-level retrospective at the end of each PSI. It’s a cross-team, ALL stakeholder meeting where issues are discussed and improvement action-plans are formed. So there are multiple “layers” to the feedback and reflection opportunities.

I’ve written several other posts that explore the power of Sprint Reviews beyond simply showing software:

• http://www.projecttimes.com/robert-galen/the-agile-project-manager%E2%80%94voila-the-great-reveal.html
• http://www.batimes.com/robert-galen/sprint-reviews-learnings-from-the-movies.html

I wanted to remind you of one of the reasons I developed the 4-Quadrants in the first place. It’s because of how hard the Product Owner role is to perform well. It’s an incredibly deep and broad role that requires tremendous effort and skill. It also requires quite a bit of time.

I often joke, and it’s not really a joke, that I’ve only met 4-5 Product Owners who could perform all aspects of the 4-Quadrants by themselves. Ever! What this implies is that it’s OK to ask for help. In fact, you’ll most probably need to get help in your role.

If you have Project Management strengths and skills, then take some of this on yourself. If you don’t, then look for someone else in the organization with these skills and strengths to help you out. For example, in SAFe environments, you might want to make the RTE a partner or best friend.

But the KEY is to find or ask for help if you need it in the quadrants where you are weakest.

Wrapping Up

I know, I’ve just added a tremendous amount of additional work to every Product Owner reading this article. I’m sorry. But whether you like the 4-Quadrants model or not, this work is there for you regardless. The key is to be aware of it, get someone covering it, and to do it very well.

All of the 4-Quadrants are important to the role of Product Ownership, but I hope I’ve shown you how crucial the Project Management quadrant is to you, your team, and your organization.

Stay agile my friends,
Bob.

Why the Scrum Product Owner IS a Project Manager, part-1

Written by Robert Galen on . Posted in Articles. 1 Comment on Why the Scrum Product Owner IS a Project Manager, part-1

On the surface, this statement appears as if I’ve lost my mind. For one thing, a traditional view of Product Owners is as a Product Manager or a customer/business stakeholder-facing role, and the traditional Project Manager is more a planning and execution focused role. The two are quite far apart and seem to have little synergy.

The other factor is traditional versus Agile contexts.

There are no “traditional” Product Owners. Usually, a Product Manager is in the role but it’s very outwardly and upwardly facing. Once the requirements are “signed off”, they’re not that interested in collaborating with the team until the end of the project.

And traditional versus Agile project managers can be quite different. For one, the acts of estimating, planning, and tracking are the prime directive. For the other, these are important, but team collaboration, exploration, customer feedback, quality, and value-based delivery are even more important.

The 4 Quadrants of Product Ownership

When I introduced the 4-Quadrants in this series of blog posts [part1] [part2], I introduced four areas where I thought a well-balanced Scrum Product Owner had to have skill and focus:

  1. Product Management
  2. Project Management
  3. Leadership
  4. Business Analysis

The one that seemed to get the most pushback from folks was the Project Management area. I think because many had a view to traditional project managers they’d worked with in the past and they were having trouble mapping these skills into the role of Product Owner.

I actually struggle with the mapping aspect myself – so I get the need for the activity. I just worry about more traditional project managers (or the tactics) having a negative effect on their agile teams performance. Nonetheless, let’s explore it.

A Deep Dive into the Product Ownership – Project Management Quadrant

Next I want to explore seven specific project management-oriented activities that should help you visualize the responsibilities of this quadrant. The list isn’t exhaustive. For example, I could have added some sort of budget level and ROI responsibilities to the list. And there are probably others. But it should give you sufficient flavor to help you understand the quadrant more and to effectively describe Product Owner responsibilities within it.

1) Project Chartering

It often starts with a project vision or base need on the part of the business. This then drives a project chartering activities such as:

  • Vision & Mission
  • Goals
  • Functional and non-functional requirements
  • Constraints
  • Success criteria
  • Budget and ROI
  • Establishment of teams
  • High-level plans
  • All leading towards some sort of commitment

Within an Agile context, teams need to be pulled together, jump-started, and product backlogs (high level to low level) need to be constructed. Terminology like Sprint #0 can often be heard or used as part of these efforts.

In this blog post, I explore some of the dynamics of creating a proper beginning for Agile projects. Agile project chartering is this activity and I believe the Product Owner should be in the middle of helping craft an effective launching pad for their agile projects.

2) Project Risk Management

A few years ago I shared a blog post about Agile risk management. Essentially I implied that it wasn’t done the same as in traditional projects; that there was very little specific risk planning in Agile projects. Instead, the entire team was responsible for surfacing risks as early as possible and for mitigating and reacting to those risks.

Now I still largely hold to that advice, but I think it changes a bit in many projects. I do think that having the team sit down for a bit and brainstorm their project risk landscape as a good idea. As is factoring these discussions into the team’s planning efforts and strategies.

For example, in the Scaled Agile Framework (SAFe) there is a specific Potentially Shippable Increment (PSI) planning event and risk planning is an important and distinct part of it. These plans either surface in a succinct risk plan, or better yet, in the PSI plans and strategies to deliver the committed features.

3) Project Communication

When I was studying for my PMP, one of the key areas that they discussed as part of “good project management” was pulling together a Communications Plan. I used to think that it wasn’t needed for Agile contexts. I thought that the principles of software demonstration, transparency, information radiators, and cross-team communication naturally took care of all the necessary information sharing.

And that’s true in smaller contexts. But I’ve changed my mind for other contexts.

In larger, Enterprise-level contexts, I now think a concise look at the needs for organizational communication as being incredibly important for a successful, large-scale Agile effort:

  • Who
  • How often (frequency)
  • What to communicate
  • And gaining their buy-in that they’ll be listening

This communication plan, or the responsibility for creating and reinforcing it, falls to the Product Owner and the PO Organization.

4) Project Tracking and Adjustments

I’m using the term tracking lightly here, but someone needs to be aware of the big picture commitments that the project has made and then map the team’s progress back to those plans and commitments.

In traditional environments, that’s either the project managers and/or functional managers. In Agile contexts, I contend it’s the role of the Product Owner.

Now the job isn’t too difficult because of the level of real-time transparency that should be occurring within and across your Agile teams. Often there is a cross-team authority, for example, a Scrum of Scrums meeting, that consolidates this information into a single meeting and set of tracking artifacts.

The real value of the tracking is what you DO with the information – i.e., the adjustments you make within your plans. This is distinctly different from the traditional responses, where projects were either on or off track. And if they were off track, often overtime and quality compromises were the only way to get them back on track.

In Agile contexts, we want to “flex on SCOPE” as our leverage for adjustment. These options largely fall to the Product Owner to make. With the team’s input and help of course, but scope tradeoffs are how you adjust towards your goals.

Wrapping Up

I know, I’ve just added a tremendous amount of additional work to every Product Owner reading this article. I’m sorry. And the bad news is that it’s not over. I will continue the role discussion in the next post. I hope you take the time to read it as well and connect-the-dots between the two.

All of the 4-Quadrants are important to the role of Product Ownership, but I hope I’ve begun to show you how crucial the Project Management quadrant is to you, your team, and your organization.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Agile is focused on… Capacity Equalization!

Written by Robert Galen on . Posted in Articles.

Not that long ago, I received an email from someone in the Northwestern part of the US. They were thinking of moving to agile approaches and they wanted to pick my brain surrounding the logistics of “going Agile”. It was an introduction of sorts, but it was also an assessment.

They were assessing whether I knew what I was talking about and whether they’d allow me to help them. They were also assessing cultural fit. But I was also assessing. Were they “ready” to try agile, were they serious about it, were they self-aware, and would I like to work with them.

It was a great round of email exchanges and it led to some interesting follow-up activity. But I remember a conversation distinctly to this day that I wanted to share with you.

Background

But first, we need to set a bit of context. This was an IT group within a division of a very large manufacturing organization. There were about 25 folks on the team organized into 4 groups that aligned with the applications or functions they were supporting. There was a Director and each group had a manager/technical lead.

This was a start-up division, so the IT group had only been in existence for approximately 3 years. They were static in size – so not growing in the foreseeable future.

They supported 100+ applications; many of them driven by corporate apps that this organization was leveraging, so there was a legacy component to their work. They were also building new set of applications for a new product line being developed.

When I asked the Director why he was thinking of engaging agile practices, he said:

Bob, we’re really struggling to keep up with external demand. There is a perception that “it takes forever for us to update or release anything”. We also have a fairly significant quality problem and our rework is high. I’m also having an incredibly tough time planning our work, as things change or come up all of the time.
I’m hoping “Agile” will help with or solve most of these challenges.

The Work

Once we progressed a bit in our assessment, I asked a series of questions around the project work they were doing:

  • How many projects are in your “portfolio” right now? ~125
  • How many of them are you committed to progressing based on stakeholder requests? ~80
  • How many are you actually working on right now? ~45
  • What do you (and your teams) think their capacity is – I.e. parallel projects that 25 folks can make reasonable progress on? Oh maybe 20-25

My reaction to this line of questions was dumbfounded shock. When I used my personal experience, I could see loading each team with 1 primary and 1 backup project, so that would equate to 8 parallel running projects. Perhaps round that up to ~12 if you wanted to stretch things a bit.

So wrapping that discovery up:

  • I think the organizational capacity is no more than 12 projects
  • They think there capacity is roughly twice that, ~25 projects
  • They’re actually working on nearly twice that, ~45 projects
  • They’ve got active stakeholder commitments for nearly twice that, ~80 projects
  • And the project portfolio tracking system is “keeping track of” ~ 125 projects

And no, I’m not making this up. Back to their challenges, I’ll boil them down to the following:

  1. We’re not meeting our project commitments, and
  2. We have a quality problem

What would you say IS the problem?

Put on your “consulting hat” for a moment, and no, you can’t reply with “It depends”. What would you recommend this company do to turn the ship around and start delivering better quality software more reliably?

My advice surrounded the insanity of them trying to do too much with too little. And by doing too much, or working beyond the reasonable capacity of their teams, they were churning themselves. Or multi-tasking so much that it was reducing their already limited capacity and productivity.

Essentially, to them, it felt like they were working on a lot of things, working hard, even frenetically. And they were.

But the reality was, they weren’t getting things done. And when they did manage to deliver something, they were exhausted, which impacted the quality.

Multi-tasking IS The Enemy AND Agile is a Capacity Equalization Play

I tried to walk them though the idea that they had too many things “in play”. That by significantly reducing the number of parallel projects, focusing on fewer, and then trying to get them done, they might get better results.

I say this in my agile classes all of the time. That:

  • Multi-tasking is not an effective strategy, you actually lose time in task switching for knowledge work;
  • That busyness or sheer effort is not necessarily correlated with results;
  • That’s its always better to work on a small set (batch) of things (tasks, User Stories, Projects) and get them DONE;
  • Finally that focus produces higher quality products.

It’s also important to align your work and your commitments to your reasonable capacity. Clearly in this case, having THREE COMMITTED PROJECTS PER PERSON was probably not a good idea. Independent of the size of those things, and in this case, they were quite large.

In their case, it gave the appearance that more was being done, but they weren’t delivering. Sooner or later, this promise, but don’t deliver strategy will become obvious to all and utterly fail.

But They’re Making Me Do It

The biggest pushback I heard from this group, and it wasn’t simply from the Director, was that they couldn’t “slow down” or “do less”. They blamed their senior leadership for the problem. That senior leaderships expectation of the organizations capacity was way beyond the reality of their capacity, but that they couldn’t say no. They couldn’t pushback or ask leadership to more thoughtfully prioritize their portfolio.

They bought into the insanity of their infinite capacity and were afraid to TELL TRUTH to their leadership team. Instead, they ignored the root problem, continued to churn, and to disappoint.

My return argument was that they were part of the problem. In fact, because they were allowing everyone to expect increased capacity, they were inspiring the increased expectations. I also explained that their leadership team was probably very aware of their not having the perceived capacity. I.e. in slipped dates, slipped scope, and poor product quality.

It’s a “game” of sorts that many traditional software and IT organizations play:

Leaders keep asking for more until you say ‘No’
And Teams won’t say ‘No’ or “We’re FULL” and keep committing to more.

It’s insidious though because of the negative impact it has on already limited capacity. And it often creates a downward spiral until someone has the courage to tell the truth and to align the organizations capacity to project requests.

So while the senior leadership in the organization was a party in the madness, I put the root cause squarely on the leadership of the IT organization. Somehow they had to stop agreeing to more, more, more and immediately scale back on their “commitments”.

At this point, and I’m sort of joking, they thanked me for my time and virtually kicked me out of the door (we stopped exchanging email). My guess is that they’re still churning to this day.

Wrapping Up

I’ve recommended this before in other articles, but I think it’s relevant here. I want you to review a video by Henrik Kniberg on the role of the Scrum Product Owner. It’s a 15-minute video and quite nicely done.

About 5-7 minutes into the video, Henrik makes the point of the most important word for the Product Owner. I want you to watch the video and catch that moment. I think it is not only relevant for the Product Owner, but for my potential client and many other organizations. Heck, it’s relevant for all of us.

So as he says, you must practice it every day!

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.