Predictability Doesn’t Involve Predictions

When I say the word “predictability,” I think people assume that I expect them to be able to predict what they’re going to be doing 3-6 months from now.  They think I’m asking them to make predictions based on estimates.

 

In reality, I’m asking them to behave predictably so we can have some empirical evidence to combine with estimates as a way of making forecasts.  There are a couple things that are required for teams to behave predictably.

  1. There needs to be a backlog of work that is broken down into small chunks.
  2. The team needs to complete the small chunks of work in a disciplined manner, limiting the work in process and producing working, tested code on a regular, frequent cadence.

Breaking work down into small chunks is a skill that is developed with practice.  It’s not easy to begin with and many people get frustrated to the point that they say it can’t be done.  My experience has shown that there is no work that can’t be decomposed without some effort.  Sometimes that effort even involves doing a little piece of the work, especially if it’s a type of work we haven’t done before, but once the means to the end is roughly understood, the work can be decomposed.

If the work is relatively large (the definition of “relatively” varies by domain and level of experience), we don’t need to decompose all the work to the finest level.  We need to break all the work down into intermediate chunks and then we need to continuously decompose the intermediate chunks so we maintain a rolling backlog of finely-decomposed work.

Even the method of estimating I prefer doesn’t call for predictions.  I prefer relative sizing over time-based estimates.  The only “prediction” I’m asking for is how much larger or smaller one piece of work is over another piece of work.  I don’t want you to predict how long it’s going to take to do each piece of work.

I’m really trying to give teams a large degree of control over how they will accomplish an objective, but I’m asking them to be transparent about the backlog of work items required.  I’m also asking them to give me an idea of the size of the items so I can make continuous forecast adjustments of my own based on the pace at which they are progressing through the backlog.

 

Interesting Aside

It’s interesting to watch the evolution of work decomposition and estimating in a stable team.  When a team works together over a period of time, they unconsciously develop an idea of the preferred size of a work item.  This is the size that a work item needs to be before team members feel comfortable that they have a clear understanding of it.  As teams develop this norm, the size of all their work items in the near-term backlog converges on this size.

Possible, Valuable, Viable




my office wall

 

The wall above my desk is plastered with artifacts that help keep me grounded in product development principles, including the Scaled Agile Framework (SAFe) Big Picture, the Agile Manifesto (including the principles), and a to-do list from the inception of our Agile adoption.  I’m going to use those three particular artifacts to explain how we arrived at the practice of “possible/valuable/viable” being critical to our success.

The To-Do List

Agile Adoption To Do

In early 2011 we adopted Agile methods and practices.  We organized all of our business analysts, QA analysts, and engineers into six cross-functional teams and aligned them with product families.  The membership of these teams is stable and work is funneled to them instead of forming new teams around new projects.  With six stable teams, we had a clear view of our capacity that forced us to stop trying to work on too many concurrent projects.

We had great internal support and it didn’t take long for the teams to stabilize and consistently deliver working, tested software.  We learned early that the teams could hum along when they had a well-groomed backlog, but really struggled when the backlog of work was vague.

As a means to force the creation of well-groomed backlogs across the teams, I scheduled our first quarterly release planning meeting to occur about three months after we began our adoption — nicely aligned with a vacation I already had planned.  Seriously, I went on vacation and left one of our scrum masters to facilitate our company’s very first attempt at synchronized release planning.

The key learning from the first release-planning session was that planning can’t be accomplished in a two-day period.  Planning needs to be continuous with a short burst of what people have termed “pre-planning” right before the two-day planning event.

The SAFe Big Picture

SAFe Big PictureThe quarterly two-day planning event  continued to be valuable as a way to achieve synchronization across businesses and teams.  It was a great way to meet the tactical needs of our teams to understand what they need to build and think about how they’re going to build it.

However, the methods used to conduct continuous planning and prepare for the planning event were a bit of a dark art.  Some product groups did it well while others really struggled.

Additionally, the growth in people and products across the company made it impossible for any one person to have awareness of what’s going on at any level of depth.  We’re now up to 13 teams serving seven product lines across two business units.

As we grew, we started to look at Agile scaling models that would give us a framework to enable distributed decision making within certain guardrails.  We wanted people to understand how they would consistently contribute to the process of turning an idea into a product feature.

At the time we began to adopt Agile methods and practices, I was reading Leffingwell’s Agile Software Requirements book, a precursor to the SAFe.  I adapted concepts from the book into our existing stage-gate product development process.  At a very high level, our process looks like this:

Simple Process

Obviously, I’m not much of a graphic artist so I’ve kept the SAFe Big Picture on my wall to give me something to point at when I’m explaining the principles and concepts of scaled Agile.

The Agile Manifesto

Agile ManifestoThat was all well and good, but I felt like we were losing something in the process.  I started to hear phrases like “sign-off” and “hand-off”, phrases that reminded me of the days of waterfall software development and a lack of cross-functional collaboration.

When looking at Agile scaling frameworks, it can be easy to get lost in the “governance” aspects required to effectively implement and leverage a multi-tiered model.  It is tempting to get caught up in all the nicely structured functional-decomposition tokens (epics, features, stories) and the logical lifecycle flows of these tokens.  It all looks so neat and orderly — how could anything go wrong?

Some things that started to go wrong were long lead times in the fuzzy front end, creation of lengthy Business Requirements Documents (BRDs) by Business Analaysts, sign offs on BRDs, and narrowing in on a solution very early with late engagement of technologists to validate potential solutions.  Man, we were back to waterfall!

As I looked at the copy of the Agile Manifesto taped above of my desk, it bugged the hell out of me that we were losing sight of the first value,individuals and interactions over processes and tools, as we scaled Agile to earlier phases of product development.

Possible/Valuable/Viable

possible valuable viableAlthough I was frustrated that we were sliding into waterfall practices in the early phases of product development, I struggled to figure out what action to take.  That changed one day when I was talking to my friend Dennis Stevens.  Imagine that — an interaction with another individual helped me move forward.

When we got through with our conversation, we had come up with a simple model called “possible/valuable/viable”.  We wanted to make sure conversations were happening at all phases of product development between people who could evaluate whether something was possible, valuable, and viable.

  • Possible: we have the organizational capability and capacity to undertake it.
  • Valuable: it provides value to us and our customers.
  • Viable: there is an achievable technical solution for it.

When we applied Possible/Valuable/Viable to our development process, you can see the roles involved at the various stages of development.

Simple process with PVV

Early in the process, the Executive Committee and GMs are determining if we’ve got the high-level strategic capability and capacity to undertake a new idea.  They’re having conversations with business managers who understand the marketplace value and architects who can help assess build/buy choices.

In the middle where we we’re decomposing the idea into versions and features, the PMO is making sure the right people in the organization are available.  They’re having conversations with business analysts who help determine what features are most valuable, and architects or tech leads who are coming up with the specific solution architecture.

When we get down to building and releasing software, scrum masters, product owners, and teams are having the possible/valuable/viable conversations.

Results

As with all things Agile, the journey continues.  We don’t get the right people involved every time, but we’ve seen significant progress.

The simplicity of possible/valuable/viable has also proven to be helpful.  When someone says a decision was made and I ask, “Who was there to assess the viable aspect?” no more needs to be said.  The person I’m asking has a clear understanding what I’m talking about.

A Paper Tiger Manifesto

Someone recently brought the Manifesto for Async Software Development to my attention.  I was intrigued and curious because I believe there is a role for some async aspect to development in our hyper connected world.

Alas, this manifesto is completely empty because it isn’t rebelling against anything real.  If it’s satire, bravo — you sucked me into your illusion.

The “this over that” format is the only similarity I see between this and the Agile Manifesto.  The historical context of the Agile Manifesto is important to better understanding it.  The “over that” clauses in the Agile Manifesto represent real things that occurred in software development of the 1980’s and 1990’s (I was there).  People really were writing comprehensive documentation and advocating for it before creating any software.  People really were selling tools and monolithic processes as the saviors of software development instead of having people actually talk to each other.

I don’t get the Async Software Development Manifesto because I don’t see Agile or Scrum arguing in favor of useless meetings and office hours, detailed planning, or tribal knowledge.  If people think Agile and Scrum are in favor of those things, that’s because of a mis-adoption of the principles or just bad management.  Bad management is still bad management, regardless of the approach used to developing software.

A manifesto needs something legitimate to rebel against in order to have meaning. I just don’t see it in this case.  It feels like the Async Manifesto created a mirage against which to argue.

I’m not sure whether to read the set of “Meetings only as a last resort” principles as satire or seriousness.

  • Product owners can replace planning meetings by simply filing issues in the issue tracker”?  Really?  Nearly every developer I know would have a stroke if they weren’t involved in the creation of the backlog.
  • “Product owners can ascertain status by reading the comment threads of issues currently being worked on and posting questions as needed.”?  Really?  Someone actually thinks a potential multi-day back-and-forth in comment threads is better than a five-minute conversation?
  • “Call a meeting only when all other channels of communication aren’t suitable for a specific issue.”  Well, duh.  But it’s a lot easier to have a planning meeting on a regular cadence than it is to try to schedule an ad-hoc meeting.  See principle F9 in Reinertsen’s seminal “Principles of Product Development Flow” for the statistic and economic proof of this.

Most of the “Flexible Work Environments” principles contradict the first stated principle of “creative professionals need long stretches of uninterrupted time to get meaningful work done.”

The “Document everything” principle is too absolute.  It takes us back to the 1990’s.  We don’t need to document everything and we don’t need to document nothing.

I understand that there’s a role for async work in today’s distributed, hyper-connected world, but it’s not the end all and be all solution.  It’s also not completely contradictory to Agile methods, including Scrum.

Phrases that Raise My Eyebrows

There are certain phrases that I hear in the course of product development conversations that cause me to raise my eyebrows.  Frankly, some of them are like fingernails on a chalkboard (for those of you old enough to remember chalk boards) to me.  Some of these phrases are so ingrained in our corporate lingo that most people don’t realize they’re using them.  They are uttered by everyone from software engineers to product managers.

Here are a couple I’ve heard recently.  I’ll update this post or write more posts as more of them hit my ears.

  • “I could work on task xyz.”  The objective is never to work on something.  The objective is to get something done.  If you start something, have an idea for how you’re going to get it to done, not just work on it.
  • “I’ll be ready to push that to QA tomorrow.”  There are two things that bug me about this one:
    1. In our software development teams, nothing gets pushed to QA.  It gets to a state that it is ready to be tested.  Getting it from that state to done is a team responsibility, not a QA responsibility.  Ideally, a QA analyst or test engineer will be available to test it, but if not, the team needs to figure out how they’re going to get it to done.
    2. We want our development process to operate as a “pull” system.  When a work product is done being transformed from one state to another, it enters a buffer queue (e.g. the Resolved state in most teams’ scrum boards).  It doesn’t get pushed to QA.  The work product only gets pulled from the buffer queue when the team has capacity to perform the next transformation on it (e.g. testing).
  • “We need to move this forward.”  This is stated by someone who wants to demonstrate progress on something to a stakeholder.  It seems rather innocent, but like the first item in the list, our objective should never be to start something or do some work on something, it should be to finish the most important thing we have.  The problem with moving things forward is that it is usually at the expense of getting something else done.  Too many things are worked on at once; they all move forward, but the most important of them never actually gets done.  This means we don’t actually deliver any value.

Customer delight in a cost-of-delay model?

Two authors who have had recent away over me are Steve Denning and Don Reinertsen.

Denning’s focus on the changes needed in management in order for business to thrive much less survive are interesting. Given that I’ve spent the past seven years in a variety of IT leadership positions that have all involved agile methods, perhaps my admiration of Denning is too easy; he looks at managers with Agile experience as the potential next leaders of business as a whole.

Reinertsen’s statistical and mathematical focus on product development flow have given me a vocabulary to express many things I previously only had understood intuitively.

One of the key tenets of Denning is to focus on customer delight. Effectively, this is a rebellion against the popular management theory of recent time that all focus should be on shareholder value.

Then we have Reinertsen’s number one principle of using an economic model to make all product development decisions. One of the primary methods he supports is cost of delay.

Although I’ve recently seen Denning’s key tenet rephrased something to the effect of “focus on customer delight in an economically responsible way“, I still struggle trying to rationalize focusing on customer delight while utilizing an economic model for decision making.  Is it possible to come up with economic variables to represent projected customer delight in a cost-of-delay model?

Scaling Agility – Collaborative Scheduling

I spent today at the first day of a two-day course at DevJam titled Scaling Agility.  The main focus of today was working within teams and we started to get into working across teams in the last hour.

One of the exercises I could see using made scheduling tactile.  The prerequisites are a set of prioritized and sized backlog items (e.g. stories).  You also need to know the capacity of a time box.

Each backlog item is listed on a card that corresponds to its size.  These cards are then placed into time boxes.  The cards can’t overlap and no more cards can be placed in the box than there is capacity.

Another key aspect of this exercise is that it needs to be done collaboratively with a group of people who can represent the feasibility, value, and usability of each backlog item.

You can see an example we worked on in class below.  There is one large item, one medium item, and two small items in the first time box (left side of the left piece of paper).

Collaborative scheduling example.
Collaborative scheduling example.