Last fall I went on a 2-week vacation with my wife in France.  When I returned, of course, the gag was “Did you run your vacation agile style?”  ”Did you start every morning with a scrum?”   I love playing along, but as I thought about it, to my horror, there was a lot of “agility” to my vacation, and maybe their teasing wasn’t so far from the truth.

As an example…

We spent three days in Paris and the rest of our time roaming around the country in a car.  It was essentially a sightseeing vacation.  I maintained a big list of things that we intended to see.

A Backlog.

Much of the time, we woke up in one town and the only real objective for the day was making it by nightfall to a town where our next reservation was.

Sprint goal.

While we might have several things we wanted to see and do every day…

Sprint backlog.

…there were always things that got in the way of our plans, like unexpected traffic or bad weather.  Sometimes we simply left a little late having spent extra time savoring our croissants and café au lait.  As a result, we might have to drop the least important excursions.

Continuous prioritization.

We wouldn’t always have a clear idea of exactly what we wanted to do once we arrived at a new destination, but we usually had no problem coming up with a plan.

Grooming the Backlog.

At one point, we found ourselves in the Alps with inclement weather.  My plan to take the cable car up to the top of Mont Blanc fell apart because they were having snow and whiteout conditions at the top of the mountain and high winds closed the cable car.  So we changed plans and headed south to the Riviera one day early.

Sense and respond.

At the end of the trip, during the TGV ride back to Paris, we reflected on our trip.  I asked my wife if she were to plan the trip all over again, what would she do differently?

Retrospective.

I don’t know whether to be embarrassed or proud.

At least the inside of our car wasn’t covered with stickies.

“not after-the-fact rationalization or a good story designed to hide failure. It is a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty in which startups grow. Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects.”
Ries, Eric (2011-09-13). The Lean Startup (p. 38). Random House, Inc.. Kindle Edition.

At first blush it seems this concept is just made to be utilized by teams working in an iterative manner. They can define sprints, validate learning, and adjust course. The challenge is that validated learning is more than just conjecture or forecasts, this means we must align the product of sprints with empirical, measurable goals. Enter the sprint goal.

More Than Just a List of Stories

When I first started using Scrum, the team I was on had the concept of a sprint theme or goal. Unfortunately for me, at that time I didn’t really appreciate the power of this concept. In fact, we just used it as a summary or aggregation of what was being worked on for the upcoming sprint. “Hey it looks like we’re doing a lot on the search component this sprint, I guess the theme for this sprint is to enhance search”.

This is a common concept I still see many teams do, and it is not without merit. Product backlogs can quickly include hundreds of stories for a given release, and productive teams may complete so many even in an iteration it can be easy to lose the forest for the trees. The simple construct of themes or goals by iteration help people outside – as well as within – the team get a general idea of what’s going on and when. It is a useful tool of abstraction that can help us organize our work. However, if we simply use the theme or goal as a summary of what we already laid out, we’re massive amounts of value on the table. Let’s look at an example.

The product owner of a team I was working with was quite worried. They were building a new reporting system and progress was very slow. The technology they were using was incredibly old, and they were constrained to it for the time being. He wanted to make a release in about six months time, but was unsure if they could do it. After a couple sprints, he said he wanted a realistic approximation of the team’s ability to build one self-serve report from beginning to end. Earlier iterations had been less successful as the team was doing research for other capabilities within the system, there were some technical issues to work through, hardware to procure and some other distractions of that nature.

The product owner cut through this ambiguity by simply stating that for one 2-week sprint, he wanted the team entirely focused on one report. The goal was to see if the team could build one report from beginning to end in the sprint; everything else could wait. His motivation for doing this was to see if the plan of completing a series of reports within the timeframe outlined was even realistic. There were some 20 reports and if the team couldn’t get to a pace of nearly 2 reports an iteration, they had no hope of completing the project with this technology platform. The sprint commenced, the team worked heroically, but by the end, they were unable to complete the report to the product owner’s satisfaction. They had validated their fears that the old platform was too brittle, slow and encumbered by patches and technical debt to allow them to work at the pace desired to make the goal. Nobody could justify the failure or couch it by saying the were working on other things, they put all that to side for validate the fastest pace they could achieve. This is not to denigrate the team, or even the outcome. They learned a valuable lesson and abandoned the release, rather than throw good money after bad.

Now here’s where things get interesting. The product owner was a creative person, and money was already budgeted for this team to work on this project. While they couldn’t build the self-serve reporting system he wanted, their mandate was really one around cost savings. The company had presumed the self-serve system would deliver those cost savings, but now it had become clear that the cost of building such a system would not be justified by the value of the savings. Fortuitously, in an earlier sprint the lead architect had played around with a tool that automatically compiled reports form a series of spreadsheets. This may not sound like much, but the business unit the team was trying to support spent an inordinate amount of time compiling large reports for major customers. The process was tedious, error prone, and sufficiently expensive that they could only product regular reports for large clients. This tool the team had tinkered with briefly had the potential to automate that compilation process. I knew this team was destined for great things when the product owner asked me, “what’s to prevent me from pursing this other avenue?”. I replied that he had justified the investment and he was ultimately accountable, so if it delivered value, then nothing was standing in his way. He was quite excited and set a new goal for the next sprint.

The team believed the tool could be used to automate the compilation of reports that the business produced, but this was still conjecture. The goal for their next sprint was to validate that the tool they had used could indeed produce these reports. Based on what they learned, they would decide if this solution was worth pursuing or not. Based on this goal, you can imagine that sprint planning looked a little different. The product owner was less concerned with bugs and documentation. Several components from their “definition of done” were relaxed as the real goal was to see if the technology would work and perform in a reasonable time. With that in mind, the team chose the most important parts of the system to deliver in order to validate that learning. They constructed a proof of concept system that would be limited in configuration, error handling, and functionality, but it would consume actual spreadsheets from the business and produce a report in the same format as those used by the business. At the end of the two weeks, they were able to demonstrate that, while the system was a little cumbersome to use, it could produce a report from the data the business would use and it could do it quite quickly. The team pivoted to build a production ready version of this system.

They rebuilt their product backlog to deliver a system that would compile reports from spreadsheets and product high quality polished reports according to some predesigned formats. They were able to complete the project according the original timeline and the time savings it delivered met the initial goals of the project. To make matters even better, the cost of producing these expensive reports was lowered sufficiently that the business could offer them to all clients without changing their staffing model. The project was a great success, but I can’t help but wonder what would have happened if not for the critical activities of those two sprints.

Two Goals, Two Types of Learning

Looking at this example, we see two types of learning. In the first instance, they set a goal to test their pace. Based on their demonstrated pace, they made a decisions about their ability to deliver a project according to a projected schedule and budget. They effectively “failed fast” because certain assumptions were invalidated, namely that they could build self-service functionality at a rapid pace in the old technology platform. In the second case, we see learning about the product. They decided to try a new approach, for which limited business analysis or technical research had been done. Instead, they set a goal for their sprint of building enough to answer the necessary business – can they produce the same report? – and technical – will it be fast & automated? – challenges. In both cases, we see that the goal was instrumental in planning and scoping the sprint.

In the first case, the team decided intentionally to not work on anything other than the report. This was because they were still doing some general set up and other supporting activities. They presumed that eventually that work would go away, so if the goal was to see how fast they could build a report without distractions, they deferred those things to run a more realistic test. They even reduced due diligence and preparation of work for successive sprints so they could completely focus. They had strict guidelines about overtime; if their baseline incorporated people working extra hours, that would become expected going forward. In the case of the second sprint, the goal was focused on a specific deliverable to answer questions of fit for purpose. They were more interested in a technical proof of concept that addressed a couple key areas. The Scrum concept of “potentially shippable” code was discarded, they weren’t trying to get something to market yet, they were trying to get something to answer questions, and fast. If the technology worked, the product owner had a lot of selling and justification to do in order to make sure his own sponsors were comfortable with the change in course.

From this perspective, we see that a good iteration goal can help in a couple ways. If provides laser like focus on meeting real goals, this helps focus the team on what’s really important, and helps protect against the mindset that we need to build everything so it doesn’t really matter how we get there. Additionally, focused goals help a team confront risk, validate assumptions, and expedite learning. Properly used, a sprint goal is a very powerful tool.

The High Hurdle of Validated Learning

I must confess this entire experience occurred for me long before the concept of the Lean Startup was articulated as it has been today. I didn’t coach this team with the idea of validated learning up front, but let’s take a closer look to see how it holds up. Validated learning has some rigor behind it to protect a person, team, or company from simply justifying failures as important learnings. Rather, it requires validation that can be demonstrated empirically, which in the case of a start up means customers. Ries tells some very compelling stories of start ups testing assumptions with key metrics that can prove or disprove them. For example, in one case they were redesigning the website to try different marketing messages. They literally ran two simultaneous sites with different copy and messaging. Potential customers were randomly directed to one or the other. All the while, they were collecting conversion metrics for both sites to demonstrate empirically if one was working better than the other (Ries, p. 51). As a consultant who works mostly with large organizations in established markets, this introduces some challenges for this concept. We are still in an uncertain area, but many of these organizations sell to businesses are part of long term relationships producing far fewer data sets. Or in other cases, like some of the self serve tools we discussed, the capability is offered internally or to an existing customer. How do we validate our learning in these situations? Let’s take a look at some assumptions and key metrics.

In this example, there were two key assumptions that were tested:

1. The team can build at a rate to justify our current cost projections (6 months) – this was ultimately tested by looking at the team’s velocity, as well as a focused sprint to see if they could build one report. In both cases, the metrics showed this was an invalid assumption, which would call into question the ROI calculations for the project.
2. The team had a tool that could automate the compilation of reports that were currently put together manually – this was tested by a proof of concept version to create a PDF report in the same general format by pulling data from the spreadsheets and extracts the business already used. The team specifically measured the number of touches to run the process, the run time, and the ability to format the output. Ultimately, they were able to demonstrate a working version after their first sprint exploring this goal.

However, as I look at this situation, I see several leaps of faith and assumptions that were never validated in advance

• Providing a self-serve system to customers will reduce calls for ad-hoc reports: this was the overall business case for the original project. In the end, it was moot, as the team demonstrated they were not able to build the product at a rate to justify further investment. However, I can’t help but wonder what would have happened if they were able to go faster. Would customers have used these reports? Would we only have found out after the project was over?
• Providing an automated tool for compiling reports will save time for members of the business unit: the water is muddier on this one. While the team did work with business partners and talk about if this would be useful. They never produced a definitive measure to empirically demonstrate that it would be valuable. As it turns out, the team was able to finish this deliverable in under three months, so the risk was tacitly accepted. Looking back, I do wonder if there was a way we could have more deliberately validated this assumption.
• Smaller clients want these reports as well – this was an accidental discovery, and no one ever made an assumption about it until the functionality was available and some members of the business unit started offering it to small clients. In the case of this situation it was probably also moot, as the system only took 3 months to build. Had it been longer, the team would have had to devise a simple test, perhaps offering the report to any client who formally requests it. If nobody even asks for it, then they may not see value. Or, manually create the report for a couple test clients and see if they find is useful and want to continue to receive it.

It may be find that we didn’t validate those last set of assumptions. In one case, it was rendered moot by the invalidation of another assumption, and in the other two, the exposure was only 3 months, which the team deemed to be a manageable risk. The concept here would be to identify the assumptions and then methodically figure out ways to validate the most important, riskiest ones as quickly as possible. Considered another way, we could consider this approach to be the scientific method applied to projects. We make a hypothesis, figure out how we can test it, and then we test it. Thus, our confidence in validated learning would be related to our ability to identify valid measures that would prove or invalid the assumptions we have made in our project. While the lean start up model is focused largely on using this approach for product discovery, it could apply equally well to questions and assumptions around execution like the test the team ran to test their rate of delivery.

Getting Back to Sprint Goals

It’s probably worth reflecting on the idea that, while user stories have become the medium of work in most agile projects, they are not intrinsic to Scrum. I have not posed these questions to the creators of Scrum, but I would suspect when they first thought about planning sprints, they imagined something more like the model of validated learning than the model of taking a bunch of user stories or use cases and seeing how many would fit into the next cycle. So, with this in mind, how would we apply this concept of validated learning to agile projects and sprint goals?

Validated learning requires methodically and empirically testing each assumption underlying your project as quickly as possible. The thinking going that the sooner you can validate your assumptions, the sooner you know you are doing the right thing. Any work beyond the bare minimum needed to validate an assumption is potentially waste, because if the assumption is invalidated, then chances are that other piece of work won’t be needed either. If we look at the example of the team building the self-service reporting application, once they realized their pace was so slow they would not make the time and ROI expectations, all the work done to build out that system was discarded, thus any more than the minimum to realize it wasn’t viable was excessive effort. In the traditional agile project, we see a product owner prioritizing based on their perspective of business value. In this model, we see the product owner identifying the key assumptions and then prioritizing which ones should be answered first. Then, the team would set goals for sprints based on the bare minimum to validate a given assumption. The act of defining a sprint would be driven based on the question, “what’s the fastest way we can validate this assumption?”

Let’s take an example. Imagine we’re building an online financial research website to take on Yahoo finance. Our website is going to be better, because we’re going to incorporate the ability to relate the research to your stock portfolio. The traditional agile approach would build a thin line through the system and figure out our bare minimum to launch. We would need quoting, charts, historical information, you name it. We could outline and prioritize the stories to build our vanilla financial service website as the “bare minimum” is more important. In this model of validated learning we would want to home in on that key assumption, that people will use the new website based on the integration of stock information compared to your portfolio. That is a huge assumption and its not clear our bare minimum to launch system will even test that. Perhaps the better way would be to start conjecturing some ways to test that hypothesis with empirical data. Perhaps a widget that would be embedded in a financial broker’s webpage. Perhaps we just build functionality around a watch list, because we presume that a watch list would be used the same way someone’s portfolio would, although that in itself is another assumption we’ll have to test later. Thus, the identification and resolution of assumptions becomes the prioritizing and organizing vehicle behind the entire backlog and each individual sprint. In fact, in cases where a company may exist in an established market, preventing them from launching the full system until it meets a certain threshold of capability, may make the case for validated learning even more. Teams may start by prioritizing based on assumptions, and then at some point pivot and then focus on prioritizing for delivery on a validated strategy. Indeed, if we look at some of the ideas from other thought leaders in the agile field, several people seem to be converging on this:

• Alistair Cockburn discusses prioritizing a project first on learning, and then on business value
• Mike Cohn discusses measuring and burning down a project’s risk profile

The Art of Assumptions

Unfortunately it seems we have opened one door only to find more. Looking back at some of the projects I’ve worked on, I can see huge merit in this approach of building a backlog and iterations around validating assumptions. However, now it begs the question how do you identify and prioritize assumptions. If we identify assumptions, what happens if we can’t come up with a plan to test one of them within the time box of our iteration? Much like good teams need to learn how to slice stories and functionality, good teams will need to learn how to slice assumptions in to progressively smaller and smaller tests so that they can maximize learning. The fact that a team can’t demonstrably test and validate an assumption may also cause some question about the overall capabilities of the team. One of my favorite non-technical examples is the Kiwi boat “Black Magic”, which won two Americas Cups based on a model of two boat design. The ship builders and designers used two identical boats, one as a control and one as a variable. They would make a single change to one ship and then race the boats. If the boat with the change won, it was incorporated into the control design and they repeated the task. This went on for six months, and the team achieved a velocity of validating over a six physical design changes on a fair weather day (Michael Schrage, Serious Play, p. 182). In order to achieve that turn around they had to change the way they built boats. They brought the ship designers into the shipyard to streamline communication and also had to bear the up front cost of building two identical boats. Likewise, you may find that your team requires investments and changes to the way it operates in order to rapidly validate learning.

These questions will have to wait until another day. For now, even if we are not yet able to articulate all of our assumptions with ways that they can be tested, we can begin down that road by identifying clear business or execution goals for a sprint. Just this simple step would give us a clear validation, where we could ask, “are the stories we’ve identified the bare minimum to achieve that goal?”. It may also increase our feedback, as soon someone will start asking how you’ll even know that goal has been met. At that point, you’ll be well on your way to getting validated learning.

Everyone Wants to be “Agile”

First, let’s agree on a definition. When talking about an agile enterprise or organization, we mean an entity that is capable of quickly sensing changes in an environment and responding to them so that it may continue to thrive. Agility, in this sense, isn’t so much the use of specific practices like Scrum, kanban, or XP, but rather the properties that they – hopefully – create for an organization. Let’s further consider Agile practices to be  our organization’s ability to respond to change. As a measure of an organizations capabilities, we can refute the claim that some industries can’t be Agile. While an online retailer can be faster than a bank, they are not in direct competition. The goal is simply to be more agile than your competition rather than achieving some absolute measure of agility. From this perspective, all organizations want to be agile. They want to be able to respond to stimuli telling them to exploit new opportunities or respond to new threats. The question really is: how agile is your organization and how does that impact your organization’s ability to execute?

How Do You Measure Agility?

If we remain focused on Agility as being manifest in the capabilities of an organization, we can consider the Agile spectrum based on the level that an organization’s ability to respond impacts its overall execution. In this model, there is a simple spectrum with three distinct points worth considering.

Capabilities as a Liability

Beginning on the left are organizations that suffer from poor capabilities being a liability towards their execution. Fundamentally, this is when an organization must change it’s approach, compromise what it wants to do, or in other ways pursue sub-optimal strategies due to serious limitations in its ability to be responsively execute. This could be the organization trying for the “single, perfect” implementation of a project, because they lack the ability to do multiple releases or work iteratively. The situation that always comes to mind for me is the stakeholder that rarely gets the opportunity to be a part of a development project, and they see this next project as their only hope to get everything they ever want, thus they begin to ask for an inordinate number of features as they never know when they will get another chance. In an idea world, would they ask for stuff they think they may possibly need two year from now? No, but considering the apparent limitations of their current delivery model, they are asking now, because they have no faith that, should they actually need those features two years from now, the organization would be able to deliver them at that point in a timely manner. Organizations in this area frequently suffer from a lack of trust. Another common example would be business units expressing their requirements as solutions – ones they believe will make the delivery easier – without actually engaging with technology about the real problem they want to solve. Ironically, this anti-pattern frequently undermines the project. The technology team doesn’t see the real objectives and is simply trying to build a solution as conceived by the business, however impractical that solution may be.

Balanced Capabilities

In the second position along the spectrum, the organization has achieved a level of agility in its delivery such that it can consistently deliver what the business requests as they request it. While this position is in the middle of our spectrum, it is a major achievement and represents one of the major benefits of an agile transformation: namely the ability to align an organization’s operational capabilities with the goals and strategy of the organization. When talking about the value proposition of Agile, most people point to tactical improvements such as improved quality or time to market. These tactical improvements are not useful unless they are in the service of a business strategy. So if the first position represents an organization whose capabilities are so lacking that they undermine an organization’s strategy, the second position represents one of balance where the organization is capable of consistently delivering the tactical objectives of the organization. In our last example, we talked about the business conceiving of their own solutions that they believed would make delivery easy. In this case, business and technology would have a healthy enough relationship to discuss real objectives and jointly figure out the best solution.

Capabilities as an Asset

While the balanced position may seem to be an ideal, it still suffers from the systems anti-pattern known as “Garbage In, Garbage Out“. Namely, if an organization is able to deliver upon tactical objectives, but those objectives are poorly conceived, the organization will still fail. In good organizations, fast enough feedback may offer businesses with the opportunity to learn from their failures. In great organizations, the very operational capabilities are such that the organization learns by doing. Their ability to get rapid and constant feedback on many levels allows the organization to learn, improve, and ultimately produce a better strategy than what they originally conceived. If the balanced position is where the organization has sufficient capability to implement its desired work, this position represents an operational capability such that the delivery part of the organization is not only able to deliver the work, but learn and implement solutions that better serve the higher purposes and long term goals of the organization than what people initially imagined.

Agile projects are fundamentally learning endeavors, and this position represents the ideal point where empirical feedback is used to improve not only operational capabilities, but also the strategic plans of the organization. A truly agile organization is not only able to build things right, but capable to learn and adapt in order to build the right thing. Going back to our earlier example of business sharing requirements with technology, in this domain, not only would the business share their objectives with technology to figure out the best solution, but the technology group may implement incremental solutions and other demonstrations to help validate assumptions and improve everyone’s understanding of how best to solve the problem so that the final solution they implement is significantly better than either group could have conceived at the beginning of the project.

Beyond A Spectrum and Towards a Map

Before going further, I must confess an apprehension. Until sitting down to think about this blog I would have described agility as a spectrum implying a single dimension as the last diagram outlined. The more I think about this, the more I can’t help but see that successfully responding to changes in an environment actual requires two distinct capabilities: the ability to detect that change and the ability for the organization to respond.  Considering that my last blog post just looked at the role of a product owner along two dimensions and mapped out different points, I’m feeling like I have only one trick that I am continuing to use, but I can’t help but escape that these two dimensions must be looked at individually. I promise to my readers that my next few posts will steer clear of charting a problem along two dimensions and thank you for your patience. With that out of the way, let’s dig a little deeper into this and turn our spectrum into a map. At first we said that organizations have this simple measure of agility, but let’s tease apart ability to change from ability to sense.

Ability to Change

This is probably the more obvious of the two capabilities, and it really is a measure of how quickly, once we have decided to do something, can we go about executing it. Lean processes offer the powerful measure “concept to cash“, which represents how long it takes an organization to get from the point it has an idea to the point it can be capitalized. It implies not only overall speed for delivering large things, but also an ability to change directions mid course in case circumstances change. This measure is more rooted in the operations of an organization as it really looks at the entity’s capacity for accelerating and overcoming its own inertia once a new direction is set. The most common model I see is for organizations to implement some level of work in process limits – either by establishing Scrum-like time boxes for delivery or using a lean-centric general WIP limit – to provide better visibility into the delivery process, force prioritization, and increase cycle time of delivery. By focusing on minimizing inventory – generally in the form of work in process – and focusing on high technical quality , we retain the ability to change and take advantage of new learning.

Ability to Sense

If the ability to change measures an organization’s capability for adjusting what it is working on quickly based on feedback, then the ability to sense is the organizations capability to rapidly get that feedback. It represents an organization’s capacity for identifying new trends, getting feedback on what it’s doing and in general sensing changes within its overall domain. This feedback can be gained from a number of agile practices including going to market rapidly, extensive customer engagement in the development process, and front-loading risk early in an iterative development process.

Mapping Along Both Dimensions

Using these two dimensions, we find five areas that represent different sets of emergent behavior for an organization based on how well it can respond to change and how well it can sense what’s going on. This diagram over simplifies as it visually seems to indicate that there are only five points where a given organization can exist. My experience certainly indicates that this is still on a scale, where an organization may have caring degrees of capacity in sensing and responding and that it is not a binary switch. However, for our purposes, these areas offer a way to look at distinct characteristics of each area.

In this model we see the original three points we’ve already discussed: capabilities as an asset, balanced capabilities, and capabilities as a liability. The characteristics of these points would remain the same, but by extending into two dimensions we see that an organization must balance both abilities or fall into a place of imbalance where they may have capacity in one dimension but lack it in the other. These imbalances can lead to common anti-patterns.

Chaotic

A common challenge we see with many organizations is that they first perceive agile as being exclusively in the domain of operations, or even just development. This may be because agile was sold as a silver bullet, it may be because change is threatening so many people are quick to try and label it merely as tactical improvements in the delivery of software. They present agile as merely working in small cycles and improving through put. Organizations with this mindset very well may experience some success, improving their ability to deliver. However, if they don’t grow their definition of agile, engage their business and other organizational leaders, they risk moving into the top left area, which I’ve simply dubbed “chaos”. In this realm, the organization is able to move swiftly, but it does not have high quality channels for feedback to direct that activity. Teams may find themselves jumping from item to item based on whims or other apparently arbitrary reasons. In such an environment, an organization’s ability to deliver is undermined by the fact that they are unable to get feedback and validate assumptions quickly. Thus, even if they can rapidly iterate, they may find that the iterative nature of their work is entirely encapsulated in a more traditional release process. Some organizations may invest in their technical development to the point where they can build new features every two weeks, but this benefit is seriously limited by the fact that they are unable to get meaningful feedback on these features prior to being launched, and launches are quite infrequent. Thus, the organization may tactically operate in an Agile way, but they are unable to really take advantage of those abilities. If they are adapting and moving quickly it is merely to the whims of powerful stakeholders or to address fire drills that are most likely not truly valuable. Hopefully, champions of this process will then advocate and educate their business partners about the benefit of agile projects so that they can jointly invest in increased ability to sense and get feedback.

Confined

The confined organization faces a similar challenge to the chaotic one, but from a different direction. Rather than being unable to get feedback quickly, this organization can not reduce the cost of change to the point where they can implement changes at the rate that they are learning. They find themselves in this area when they start in the lower left area lacking both an ability to get feedback and an ability to change. They invest in a practice like Scrum and begin to put working product in front of internal users, stakeholders and maybe even customers. Ideas begin to flow incredibly fast and the team becomes lost in a never ending backlog that overwhelms their ability to deliver work. Or they learn important things about the system, but lack the technical capability to do anything about it. In either case, they now face a situation where they are able to get new ideas and better understanding of the problem domain, but unable to properly exploit it. Frequently this happens if organizations begin to embrace agile practices, but are not quite so aggressive in removing impediments and improving engineering practices. As the old saying goes, knowing but not doing is no better than not knowing. In this situation, hopefully organizations see the case for investing in their ability to change such that they have the technical capability to match their every changing list of requirements.

Implications of this Model

The single most important implication of this model – for better and worse – is the very transitional nature of an organization’s position on the map. The chaotic and confined positions offer prime examples of an inherently unstable position. They expose a major gap in an organizations capabilities and cause problems. In the optimistic situation, this apparent gap is correct and the organization continues to move to the top right part of the map. However, it’s quite possible that the organization decides the best way to deal with the uncomfortable exposure of their shortcomings is to simply stop doing whatever it is that’s exposing those shortcomings.

Additionally, if we consider this map a broad landscape upon which organizations may spend years moving, than we appreciate that the journey is profoundly important and it is not simply defining an ideal state to achieve. In fact, the changing nature of the marketplace as well as most companies indicates that even if you occupied the top right position a decade ago, the standard has changed. That which was once state of the art very well may no longer be so. Thus, the most important thing is continuing to move in the direction of increased capability to sense and respond. Right now several luminaries within the agile software development field are having a big discussion about two lean concepts: kanban and one-piece flow. The discussion brings up many good points in arguing the superiority of one-piece flow over kaban – indeed, the Toyota philosophy is to flow if possible, then pull (kanban) and only push as a last resort. However, the more important thing is the continued path towards improvement. A team embracing Kanban practices very well may be improving from their current state without getting into a discussion of whether or not this is the ideal longer term end state. Indeed most of the research on change management and learning shows that moving too quickly towards some perfect goal may very well undermine the change if it is too ambitious in the short term. Going back to the beginning of this article, the goal isn’t some absolute measure of agility, but rather one’s organization’s ability to continue to improve those capabilities such that it can out maneuver its competition.

I hope you find this model useful in conceptualizing that task and communicating it to others, and would welcome other’s perspectives.

Archetypes of Product Owners

I don’t mean to imply that every product owner I’ve worked with could fall into one of a series of buckets, nor that alignment with a single archetype would imply someone can not behave according to another. In fact, as I look at the people I have had the privilege to coach and work with, I see the archetypes representing a couple progressions individuals move through towards becoming truly effective agile product owners. These categories capture the essence of different roles I have seen people play. Some are good, some are bad, and some are somewhere in between. The most hopeful thing is that I have seen people successfully progress from one to another and to another as they learned and grew in their role. Thus, these don’t imply a fixed classification, but rather a step in a journey.

The Stenographer

This is a place where many people find themselves – including yours truly – at some point early in their career as analysts. Whether they are an analyst or a product owner, they are simply expected to ask the customer what they want, and to write it down. Unfortunately, my experience was that my customers were notorious for asking for a solution they thought would solve their problems without actually articulating what they were really trying to do. Indeed, my own journey beyond this archetype really began when I was able to eliminate a six month development project by talking through with our business partner in response to a request they submitted for some new functionality. Low and behold, we were able to offer that capability to them with the current system by using a few tricks!

As a product owner, the stenographer finds themselves – by choice or organizational imposition – in a role where they are unable to influence and not expected to add much expertise or knowledge to the problem domain. Product owners in this role may feel more like order takers from higher up executives who are looking to use them as interlocutors to relay requirements to the development team. Unfortunately, this is a self-defeating position for a product owner. They are unable to articulate a clear direction for the team to execute against, because they must continually go back to get questions answered.

Ultimately, product owners must outgrow this limited model and become masters of their own destiny if they are to help guide their teams in a coherent direction. In fact, many organizations embarking on an Agile transformation are open enough to change that this provide an opportunity for an un-empowered analyst to grab the opportunity and find a voice nobody knew they had. They begin to show leadership and vision, at least enough for the team they work with to execute effectively.

The Decider

Offering confident message and vision forward, we see product owners in the decider archetype offering a clarion call to their team about what must be done, what order and to what end. The key benefit they offer the team is decisiveness and a vision to execute against. No longer must the team troll through enormous document to glean a possible answer to a question. No more must they wait weeks to float questions in order to get simple answers. The decider short circuits these anti-patterns and provides consistent and timely information to the team so that it can continue to do what it does best: deliver software.

This is not to say that the decider has no product expertise, as some are quite experienced in their domains, but rather that their primary locus of control is in the stated role of product owner being the “single wring-able neck” who owns the product backlog for a team. They cut through the ambiguity and uncertainty so that the team doesn’t have to. At their best, they are able to set both “big hairy goals” for the project and tactical goals for the team. One precocious product owner I worked with really took to this concept. I recall working through a story map with her when we were identifying their first release. Working with some key people on her team, they decided that the priority for the first release was to confront product and technical risk. Once she clarified that goal, she quickly move through the backlog and de-prioritized anything not meeting that criteria. I recall her looking at each piece of work and simply stating things like, “well that doesn’t move us any closer to our goal, so let’s put it off until later”.

She provided a consistency that allowed the team to focus on a goal and not get bogged down in changing scope or a morass of requirements for the project that were not terribly important but threatened to distract the team.

Unfortunately, this archetype is not without it’s downside, and I would describe this as a transitionary place for product owners. While they cut through ambiguity and provide clarity of purpose, this is not always informed by deep product knowledge. Product owners working in this model run the risk of sending their teams off a cliff. Fortunately, the nature of Agile projects is designed to accommodate this, by allowing for false starts and early failure. The impact of a lost two week iteration is usually not profound for a large project that is being properly managed. This is also the opportunity facing these product owners, namely to learn more about the domain. The iterative nature of Agile projects provides ample opportunity for individuals to test a hypothesis, experiment, and learn. This opportunity is not lost on good product owners, and we frequently see them become veritable authorities within their product domains moving them into the next archetype, the genius.

The Genius

Product owners in this archetype are generally coming from one of two paths. Either they have been playing the role of product owner for some time and have used that opportunity to accumulate experience, or they are credible subject matter experts within their domain already and have now been put into the role of product owner to lead an Agile team. These individuals frequently retain the confidence and decisiveness of the decider archetype, but they can back up that clarity of purpose with a significant amount of expertise. A general difference I see between geniuses and deciders is that deciders are generally more focused on the tactical decisions. They lay out the next release or prioritize the next set of features. Geniuses will focus more energy and time articulating the big picture and crafting a bold and ambitious vision for the product overall.

This depth of personal knowledge about a product domain can be incredibly valuable to a team. It allows the product owner to better educate the team about the nature of the domain, answer difficult questions, and in general set context very well. This in turn allows the team to be more responsive and creative in their own solutions. Unfortunately, this expertise comes with a couple of risks. While a product owner with this level of expertise can be quite effective, if they do not share their understanding and help to explain their vision clearly to those around them, their expertise can effectively be wasted. Indeed, it may be quite a difficult situation for a product owner in this position, as the “curse of expertise” can even undermine their ability to communicate effectively. A critical success factor for product owners in this model is to be able to clearly articulate complex ideas. Even if they do share their expertise, they are still prone to the risks that face any expert in that their own past experiences may actually become liabilities. As the economist Kenneth Boulding once famously said, “Nothing Fails Like Success.”

Namely, patterns and approaches that have served us well in the past will invariably be used again in the future, until they fail. If an expert has used a limited set of techniques or perspectives to great success, they may be unable to let them go and move on to new ideas and concepts. Similarly, the genius archetype must avoid leaning on their own expertise too much and not exploiting the empirical feedback loop available to them inherent in any iterative and incremental project.

The other major trap that I have seen product owners in this role fall into is what Fred Brooks dubbed the “second system effect“, where they have the opportunity to build a newer version of a system they are already familiar with and become seduced by progressively more and more advanced capabilities until they have conceived of a system that is unnecessarily complex and expensive. This risk can even be amplified within an Agile project, as there are less constraints upon the scope that a product owner can request. The best way I have seen to guard against this type of dynamic is by laser like focus on tactical goals when prioritizing work for each iteration. Ironically, these are the skills that the decider archetype most embodies. Thus, some people may begin their journey as a budding product owner who is able to cut through the fog of complexity, but then later succumb to it as they learn more and more about the very system or product they are guiding.

Ultimately, the genius archetype faces the challenge of growing by increasing feedback channels available to them. The specifics for these sources are numerous and vary based on the context of the project.  It may be reaching out to less vocal stakeholders, like support or operations, in order to broaden perspectives available to the team. It could be building stronger relationships  with product development and finance in order to keep things like scope and budget within agreed upon constraints. It may also take the form of continuing to exploit iterative work in order to get empirical feedback and conduct testing and validation of concepts with the project team. Regardless of the details, experts need to ensure that they never allow their perspective become hermetically sealed within the world of their own personal experience. Having learned a significant amount about their problem domain, their journey is to continue deepening that knowledge as well as expanding the horizons into adjacent areas.

The Diplomat

The first two archetypes discussed rest upon one major assertion: that the product owner truly has the authority to articulate and prioritize work. If you read the Scrum Guide or just about any text book on Agile Software development, you will see that this is a requirement for an effective product owner. Unfortunately, I have seen too many projects where this is simply not the reality. In some cases, organizational policy, where the development team and their customer proxy are simply not empowered to make product decisions. More than anything else, this explains how people find themselves within the role of stenographer.

We explored the concept of product owners being given the authority to make decisions, as well as in some cases them simply grabbing it. But there is another path forward where product owners exert influence over their product with limited authority. This is the archetype I call the diplomat, where savvy product owners without formal authority are able to clearly and strategically work in environments to establish clarity of purpose and get questions answered so that the team can work effectively.

While the diplomat’s ownership of the product backlog may be limited, when played effectively, they can confront problems by bringing the various stakeholders together and getting them to work through their own differences. In fact, establishing a consistent vision across numerous project stakeholders is probably one of the most effective things that a product owner can do in many organizations. I have seen numerous companies where their software development process has become so fragmented and slow that no clear vision or priority exists between the business and technology partners; in some cases a consistent vision doesn’t even exist within the technical or business silos! In these situations, a thoughtful product owner can deliver immense value to their organization by bringing the different stakeholders to a table and helping them see how their inability to resolve differing priorities undermines the success of the very projects that they all depend upon.

At their best, diplomats are able to use organizational jujitsu so that people with various conflicting priorities are able to come fact to face with each other, discuss their interests, and make a decision in the best interest of the project, program and company. This is obviously much easier said than done, and I could probably write a series of blog posts discussing different techniques available to product owners in this archetype. I have seen product owners use very simple techniques to great effect, like insisting that all stakeholders agree on what to work on next, anything the group can’t agree on, doesn’t get done. This can provide powerful motivation for people to interact and work together.

While the diplomat can be quite effective and valuable in organizations where there are numerous stakeholders who wield immense influence and aren’t always in alignment, there are some limits to what someone operating in this model can achieve. Their contribution is basically limited by the ideas brought into the common pool of discussion between stakeholders. Much like the decider, they are not so much adding expertise, rather than simply cutting through conflict and indecision. In order to grow, diplomats must grow their own expertise and offer more value than simply bringing parties to the table and helping mediate differences.

The Catalyst

Moving beyond simple positional negotiations, experienced diplomat product owners move into another category I call the catalyst. In this archetype, they have accumulated considerable experience in their own right both in the problem domain, as well as in negotiation, communication and collaboration. Superficially, it may appear that they are operating in a similar model to the diplomat, but there are two key differences. They are strategic in who they engage and they are able to engage people in a way that allows new solutions to emerge.

As the name implies, catalysts play a critical role in helping get elements already within the system to react in ways that release energy or cause other valuable changes. In the case of Agile software development, this may be bringing to seemingly irreconcilable groups together to craft a shared vision allowing them to see how their interests can positively intersect. It may be pursuing other stakeholders in order to better balance the vision for a product. For example, one product owner I worked with brought several of the people from the business unit he represented to meet with the team periodically. They would show the team the type of work they did and how the project was going to benefit them. Incidentally, in one of these discussions, the lead architect happened to key into one pain point they mentioned about compiling reports – the point of this entire project was to streamline operations for this group – and he began to explore an entirely different solution to help solve that problem. In the end, his side investigation identified a novel way to use some of the systems they were developing to deliver automation to this business unit significantly faster, also meeting the ROI target of the project before they had completed the primary deliverable.

The catalyst is comfortable with problems with no apparent solution and invites as many perspectives as possible when confronting the problem, even if they have amassed sufficient authority that a decision rests solely within their domain. They understand that a shared vision not only fosters more solutions, but increases follow through on the actual execution. The challenge facing the catalyst is that regardless of the number of feedback loops they develop and their ability to engage different stakeholders, sometimes product require breakthrough innovation and different thinking. Apple offers a striking example of apparently counter-intuitive thinking including intentionally designing products they think are cool rather than doing market research. In the end, we see the catalyst growing by building up product expertise from unique sources of feedback and eventually converging towards the path of the genius.

Two Different Paths

These archetypes present more like a series of logical stepping stones for someone to make as they progress towards being an increasingly capable product owner. Some product owners focusing on exerting authority in the decider archetype. From there they build expertise and eventually move into a genius role. Others do not have the opportunity up front to be authoritative and must opt for a diplomat archetype. The growth opportunity for them is to build authority and decision making capabilities through their growing ability to influence without explicit power, allowing them to grow into the catalyst change. When first laying this out, I didn’t mean to show a progression, nor did mean to have the two paths diverge and then converge. Is there a sixth archetype that sits between the genius and the catalyst? Is there some ideal mastery of both influence and expertise that all product owners are striving to achieve? While I certainly agree that there are always further opportunities for growth, I’m not sure I can identify an idealized end state for this journey, so for the time being I have left this spot open. It seems identifying a terminus for some perfect product owner would undermine the concept of continual learning and growth that is one of the most important things I see in successful product owners. So let me just conclude on a note that there is no one pre-ordained journey. By enumerating these archetypes I hope others in those situations can help identify their circumstances and use that awareness to their advantage.

The Agile Super Coach

Of all the abused words in the Agile domain, none seems to be more abused than the simple word “coaching”. There are numerous people out there professing to be “agile coaches”, and while I don’t mean to denigrate what any of these people do, there is a very broad latitude in the types of things that they do. This can further confound our ability to work with organizations as there may be a disconnect between coaches and clients about what exactly they are doing.

Unfortunately, in the absence of a clear understanding, I have seen people begin to expect that the “Agile Coach” is nothing short of a super human being. The can swoop into any project, turn around the results, and simultaneously coach that group into effectively preventing all those problems from ever occurring again. Or they may have an unnecessarily narrow view of the role and try to put an Agile Coach in a box by insisting they only do training, for example. To be fair, when I encounter these missed expectations, they are usually my own fault. I did not do a good enough job of articulating what the role is I, or anyone else, would potentially be playing in that organization as an Agile Coach.

I can’t profess to be the keeper of truth on this topic, but here’s a model I’ve used to help organize my own activities and to make sure I’m articulating clearly what role I see myself playing.

The Agile Coach

Before moving on, let me venture my best attempt at a definition of an Agile Coach, which I am conspicuously labeling with capitalized letters to indicate that it is something very specific to the field of Agile software development and project management, and not to be confused with a professional coach, which we’ll discuss more in a little bit. An Agile Coach is a professional, working internally as a full time employee or externally as a hired consultant, who is working to help realize a profound organizational change to better embrace the values and principles espoused in the Agile Manifesto. Specifically, this is a person who is doing a blend of a number of activities based on the situation to help that organization overcome barriers to change – be they technical, organizational, or skills based. One of the key values of such a person is their ability to play different roles based on the context, and a high level of awareness of these different potential roles can be a critical factor in their effectiveness.

The Pillars of an Agile Coach

The Pillars of an Agile Coach

When I think about all the things that an Agile Coach must do, I visualize a massive structure that is the change we are trying to realize, something like a building with Roman columns supporting a massive roof. The roof represents the weight of an organizational change, and it is held up by numerous pillars. Each pillar increases the strength of these structure, as well as adding more stability. With more points of contact, the better balanced the roof is. With that visual in mind, I see four primary pillars that make up Agile Coaching: training, mentoring, coaching, and consulting.

Training – Conveying Knowledge and Skills

At this point, I would suspect everyone familiar with Agile Software Development is familiar with the Certified ScrumMaster (CSM) program where people attend a 2-3 day training class to learn the basic mechanics of Scrum and talk about their application at work. This is training in it’s purest form. People are attending a class to learn new skills, usually in an abstract sense. Training is a critical piece in any organizational transformation, as people generally do need to learn new ideas. However, implemented alone, people will fail to adopt these new skills into their regular behaviors and there are numerous studies which show that nearly 90% of everything people learn in a training class is lost shortly thereafter.

Mentoring – Putting New Skills into Practice

Mentoring occurs when people are back in their day to day routine and they work with an Agile Coach to learn and apply new skills in that environment. Mentoring frequently occurs in addition to training and after a training class introduced new concepts. Mentoring is similar to training in that there is a very explicit learner and teacher relationship. The mentor has the answers to the technical challenges at hand and will work with the mentee to put those practices into play. Mentoring may be an Agile Coach working with a Product Owner to help them lay out a story map, introducing the concept, guiding them through it, and assisting them along the way. Mentoring is a very useful technique and is necessary when launching new Agile initiatives to help people put new skills into practice. However it still implies that there is a correct answer or practice, which the instructor is communicating to others.

Coaching – Helping People Find Their Own Answers

If mentoring is helping to teach people the answer, coaching is helping people learn new answers on their own. Coaching as a profession predates Agile Software Development, and there are numerous organizations and techniques such as Co-active Coaching. The key difference here from the two earlier pillars is the nature of the relationship. In this case, the coach is much more of an equal to the person being coached. When coaching, an Agile Coach will serve more as a sounding board and guide through a reflective conversation of observation, reflection, change, and action.

Consulting – Getting Your Hands Dirty

The fourth pillar is the least like the earlier ones, but can be a critical success factor if used correctly. Consulting is when an Agile Coach actually takes on work items for an organization, team, or individual. It may be doing an assessment to better understand what’s going on in the organization and make recommendations. It may be to actually embed with the team and serve as ScrumMaster – or even a developer – for some time. Consulting is powerful for a couple reasons. It can help create early momentum in an organization when there is insufficient energy to get going. It can also establish rapport with a team or organization, as it shows the Agile Coach’s technical capabilities. It also is an excellent opportunity to model good behavior, and we see some coaches move between mentoring and consulting where at times they are teaching, and at other points they are actually doing work to help meet the objectives of that team or project. Consulting is also dangerous for an Agile Coach. As a change agent, they are inherently not quite part of the system as they are trying to help change it to become something else. If they immerse themselves too much they risk losing their perspective in the tactical demands of that work, or that they may come to be seen merely as a “pair of hands” who are useful to keep around but are no longer leading change.

Moving Between Roles

As you can see, it is very hard to realize profound organizational change leaning on only one pillar. In fact, the most successful Agile Coaches I have seen move back and forth between the roles as appropriate. My experience has been that I am most successful when I am aware of the different roles and how they may play out in a given context. For example, when engaging with a new team, they may not be open to a coaching relationship, or they may be overwhelmed and this is just the last thing they want think about. Or conversely, I may be dealing with an executive who is much more experienced than me, and I really am not in a position to approach as a teacher. In this case, a coaching approach may be much more productive. There are probably too many different situations to talk through, but I hope this communicates the key point: that these different roles are situational, all of them are useful at different times and we should be aware of what they are and how we are – or aren’t – using them.

There is a classic business problem regaled in business school where the management company of a large tower is struggling to deal with complaints about wait times for their elevators. The company brought in consultants to investigate adding additional elevators and other expensive solutions. Then, brilliantly, someone re-frames the problem from an engineering one to a psychological one. It’s not that the elevators were slow, but rather people perceived they were waiting too long. If you solve the perception problem, then people won’t complain. What did they do? They put up mirrors in the elevator lobbies so that people would be distracted when waiting for the elevator. This novel approach effectively resolved the problem for a fraction of the cost that would have been required had this been viewed purely through the lens of an engineering problem. This is a perfect example of an Agile project leveraging learning in the middle of the project to fundamentally change directions to deliver a better result.

Within software development, we see the same challenge: depending on how we frame a requirement or user need, we may end up with a very different project. Herein lies a key challenge when running an Agile project, if your requirements are not captured in a flexible manner, you will sacrifice a significant amount of value. Had a project been chartered to increase the elevator capacity, as opposed to fix the complaints about wait time, the team would have been unable solve the problem simply by putting in mirrors. Indeed, they may have become contractually obligated to deliver more elevator capacity, locking the customer into a costly solution they did not need.

It’s not that the traditional Work Breakdown Structure is incompatible with Agile projects, but rather that the way we organize our work and use such a structure is crucial to how successful our project is. Let’s take a closer look at how we manage requirements within an Agile project. There are three key concepts we will walk through in detail: requirements should be small enough to fit into a short period of time, they should be prioritized, and they should be based on the user’s perspective.

Align your Work with the Business

By definition, an Agile project is meant to be executed in close alignment with the customer’s needs. Not only should it begin with this alignment, but it should be managed in an adaptive manner such that the project can adjust based on insights gained and changing circumstances. How exactly do we communicate the scope of work and requirements in a fashion complimentary to our goal of being adaptive? Enter the product backlog!

Originating from Scrum, the product backlog is a prioritized list of things needed for the product being built. In its simplest form, this could simply be a force ranked list of features or capabilities. Here is my simple list of features needed for my online book store. You will see that I have identified 6 features and placed them in a forced rank order.

A sample prioritized backlog for an online book store

I need to reiterate that when we say prioritized, we don’t mean “high”, “medium”, and “low”. Rather, our goal is an actual ranking, where item one is the single most important thing, item two is the next most important thing, and so on. Prioritizing into buckets leads to games. Have you ever had a project where 90% of the features were “must have”? Me too. If everything is a high priority, then nothing truly is. In fact, it is irresponsible project management. If I can’t tell what features are truly mission critical, I can’t make sure they are properly completed above other features that may not be as important. If you take nothing else from this article, get your customer to force rank their requirements, the clarity you get from this exercise will be invaluable.

The priority of the backlog is critical, as it drives the order in which features are delivered. Those on the top will be undertaken first, and those on the bottom will be deferred until all higher priority items are completed. Some people will refer to these items as “sushi slices” of functionality, where we define a piece of work that consists of a little bite of each type of task, as opposed to defining work items that are large and homogeneous. The image below should help you see what we mean when we say a feature that requires a little bit of each type of task.

Cycles of work in a waterfall and Agile project

This backlog is generally managed by the product owner or whoever is representing the business, and may be changed at any time. The general rule is that the business may change the priority of any piece of work that has not yet been started. Agile projects can benefit immediately from this type of prioritized list by using the progressive elaboration. This allows the team to focus energy on those items that are highest priority and will be done next. Those items that are of much lower priority can remain ambiguous. Simply stated, we don’t need to come up with the requirements or design for the entire system before we can proceed. This allows us to begin building and validating small pieces of functionality rapidly.

Define Work Items Small Enough to Complete in Under Two Weeks

Most Agile projects use some sort of time boxed iteration, where a team will take on work that it can to complete within a time horizon of about two weeks. Teams need to be proficient breaking up large requirements into progressively smaller capabilities to deliver. Smaller pieces of work improve testability and flexibility when prioritizing features. The Standish Group’s 2002 CHAOS report observed that users reported rarely or never using nearly 2/3rd of all features delivered in their systems. Breaking apart requirements into smaller pieces allows us to deliver the 1/3rd that are truly important without being tied to those that are less important.

Building on my earlier example, we may see that something like searching for a book is quite large once you begin to think about all the different dimensions upon which you may run a search. Here I have shown it being broken into four distinct features. What you will also notice is that they are not all of the same priority. Searching by ISBN was actually put on the very bottom of the list and represents one of those features that probably shouldn’t be built, but if we took on all of search as a single work item, very well may have bloated our product.

Sample book store backlog with search capabilities split into smaller features

Frame Work Items on Value for the Business

So now we have an ordered list of things to build for our product that are small enough we could fit them within an iteration of two weeks. That’s great, but it’s not enough. Simply having a list isn’t enough, think back to our elevator problem. They could have easily put together a list that included things like, “run elevators more efficiently” and “add more elevators”. While they could work through those items individually, we’re still focused on a single perspective. Teams frequently fall into this trap, they focus their backlog either on tasks to do or on technical components. Considering that many IT teams are led by project managers or tech leads, its natural they would bring their own bias towards how they look at a project. The challenge being, this is not how the customer thinks about the problem. Rather, we want our work to be focused on the experience of a user, because those are the outcomes we’re trying to influence. Focus on the user also gives us maximum flexibility to plan our work around what the customer really cares about, the experience and outcomes.

There are several different techniques you could use to capture requirements from a user perspective. For purposes of this discussion, let’s talk about User Stories, a practice from eXtreme Programming which is probably also the most commonly used within Agile software development. User Stories are a mechanism for framing requirements from the point of view of a specific user. They contain two parts, a narrative and acceptance criteria. The narrative contains an actor, an action and a justification and the acceptance criteria contains the criteria the business will test to approve a given story. While this structure is pretty useful, the important concept is that we’ve framed each feature as an experience, they are technically agnostic and they each have a business justification, what I would call the “so that” of the story.

For co-located teams, User Stories are designed to be lightweight enough that each one is put on a note card and stuck to a wall. In fact, User Stories are meant to be a placeholder for a conversation,  thus they give enough information for us to get the general idea, but encourage us to go speak to the business to make sure we completely understand. The acceptance criteria helps us nail down very specific criteria we will use for saying a piece of work is complete. Building upon our earlier example, here are the first two features written as user stories

Sample User Stories from book store backlog

Reconciling the Product Backlog with the Work Breakdown Structure

None of what we have walked through so far is in conflict with what the PMBOK® guide says about work breakdown structures. In fact, a review of the guide will show the following definition:

“The work breakdown structure (WBS) is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.” (PMI Project Body of Knowledge® 4th Edition, . 146)

The only difference is that with an Agile project, we expand our horizon of project goals and try to align them directly with the outcomes of the business. Thus, the goal of an Agile project won’t be to implement the XYZ system, but should rather be based on a specific outcome or experience. Beyond that, the same concepts apply. WBS can be progressively decomposed to smaller and smaller deliverables, much like we broke apart the book search feature. The PMBOK® supports the idea of progressive elaboration, so that we have invested a lot of time and detail into those items coming up next, and not a lot on those that won’t be addressed for a long time.

Empowering the Business

So those are the mechanics we use to manage scope and requirements. The real power comes in the way that a business partner can use them to maximize their own success. This article doesn’t have sufficient space to fully explore this topic, but let me offer you a few strategies used by effective product owners and project managers to get the most value out of their agile teams.

• Prioritize on business value – the team can simply start on the most valuable item and keep working until the law of diminishing returns kicks in and it is not worth working on anything else. This strategy will help a business build a lean product without extraneous features.
• Prioritize to maximize learning – in some situations where the solution is not fully understood, teams will pursue a strategy of prioritizing work in order to maximize their learning within the domain. You could almost think of this as the scientific method, where a product owner may establish a hypothesis about how to solve a problem, test it and then adjust the theory.
• Prioritize to minimize risk – good project managers know that if you’re going to fail, fail early. Working with the business, some teams will adjust the order of work in order to deliver those features that are highest risk first. The strategy being that if the project is to fail or encounter severe problems, these are the things that will cause problems. By doing them first, the team has the most amount of time to respond and risks can be confronted and removed earlier from the project.

These strategies aren’t mutually exclusive; teams frequently start with one and transition to another. Many teams will begin by prioritizing to reduce risk and maximize learning, and then as the domain is better known and less uncertain, adjust to a priority based on business value.

Conclusion

A product backlog doesn’t make you Agile, but a poorly designed and managed one will sacrifice a significant amount of potential value from an Agile team. Thus we see that a well used product backlog allows the team to properly align their work around the goals and objectives of the business. It brings that business into a closer partnership by giving them unprecedented transparency into what is being done and in what order. Lastly, it encourages collaboration. Each piece of work the team undertakes is tied to business outcomes and justification, inviting the business to partner much closer with the team working to deliver the project. Ultimately our goal is to deliver value for our customer, the more we can empower them to make decisions best representing their interests, the more value we can deliver.

Dr. Rao begins with an exploration of the various fundamental elements of the organism’s experience of tempo. It’s felt emotion is an essential sensor for cultivating situation awareness — you can get a feel for what’s going on in a situation by connecting to the feeling tone. The organism interacts with his environment in a set of key relationship modes: merging, going with the flow, pace-setting, and disruption — knowing which mode you are in can inform your decision of what to do next.

In this exploration he develops a Vocabulary of Thought, sketching a glossary of mental models of the self, others, and situations. He helps us make sense of how these mental models interact in the mind and how they externalize into the outside world, manifesting through Enactments.

All of these ideas build toward the intentional key insight of the book: by developing the awareness of and leveraging the structure of the Deep Stories in an otherwise seemingly amorphous flow, one can more creatively and skillfully navigate the experience. You can make better decisions if you look at life through the lens of a story. Rao calls this approach Narrative Rationality.

The book provides a patchwork of loosely anchored frozen steps across the stream of sense-making. It is a survey, not an exhaustive treatment. It is a heavy lift: a consilience of military thought, culinary arts, software development, the creative process, organization theory, psychology, systems and control theory, metaphysics, economics, improvisation and poetry.

Tempo is more than theory. Rao sprinkles exercises throughout the book inviting the reader to not just contemplate but engage. Use Tempo Doodling to explore a sense of rhythm in a conversation. Help reinforce the more positive behavior patterns in others through skillful mimicry. Cultivate an awareness of the ebb and flood of energy throughout your day by seeing your calendar as an artful map, not a sequence of meetings. Pull these skills and the theory together in order to wield the central power tool of the book: the Deep Story — a richly annotated narrative structure that can be used to orient one’s self in non-trivial situations. For example, in a given circumstance, do you sense confusion and/or volatility? You might be experiencing the “Exploration” epoch of a Deep Story. In this part of the story, a good move might be encouraging creativity (through play or “random exploration”)… fertilizing the field toward finding what Dr. Rao calls a “cheap trick” — an organizing insight that provides (hopefully) significant leverage…

This is theory begging to be applied.

This book has been simultaneously disruptive and a normalizing experience for me. Venkat pulls together a set of ideas that were either vague and, at best, loosely connected in my own mind. He affirms many of the ways I already approach situations, firming up that understanding with intellectual rigor. He also has introduced me to a fresh set of perspectives. The material becomes quite dense as it climaxes and in parts of those sections, I simply had to allow the words to wash over me during this first reading. Even still, enough stuck that I can start using it. For example, I am addressing the question of “I want to be a catalytic leader, how do I encourage the self-organization of my team?” by recasting it in the form of a deep story: “What is the journey of a team learning to self-organize? … and how can I help catalyze that experience?” Even if this one is not a nail, I’m at least getting some feel for the heft of the hammer. It’s better-informed play.

I love this book. The author has struck a beautiful balance of science and art. He explores the very personal and pulls it back to the universal. As I finished reading the book, I felt sated, energized to put these concepts to use and yearning to learn more.

If you resonate with the notion of more fully connecting with the vibe of life especially to be more effective in your participation in it, you owe it to yourself to pick this book up. Price for pound, it’s an embarrassment of riches.

If we accept this truth, then does that mean the goal should be to eliminate all bureaucracy? The process rigor seen in most organizations is excessive, but many view it as a necessary evil. Necessary in order to maintain the scale, performance, or consistency required for there particular organization. With this in mind, managers may agree that organizational structure and rules can become stifling, and yet continue to implement it as a necessity for their organization. Quite possibly, they are right. What if the question isn’t about whether or not we have process, but rather what that bureaucracy should look like? Not all processes and organizational structures are created equally.

Organizational experts looking at the nature of organizational bureaucracy have sought to identify different dimensions for characterizing the nature of a given organization’s bureaucracy. The first dimension is one familiar to us, namely the level of formalized policies and structure within the company. This is a familiar dimension to anyone who’s worked in a couple companies of different sizes and seen how some organizations can have very rigid policies, while others are much more ad hoc and informal. Unfortunately, many people perceive this as the single dimension for managing organizational structure. They incorrectly believe we must choose between limited formal processes or implement a stifling bureaucracy. This is a particular challenge for Agile organizations as they try and figure out how to integrate numerous Agile teams, how to leverage the expertise developed across them, and what to do with the various organizational rules that have accumulated over the years.

That’s where the second critical dimension comes in: the type of formalization. Paul Adler and Bryan Borys have hypothesized that organizational bureaucracy can be characterized along a spectrum between coercive and enabling. Enabling bureaucracy encompasses rules built in an flexible and dynamic manner to help amplify the effectiveness of people. Coercive rules are created to mandate compliance, punish violation, and enforce adherence to certain standards. As these two simple descriptions imply, the type of rules and polices adopted and profoundly impact that impact they have on the organization and those working within the constraints of the system. Let’s take a closer look at the four proposed quadrants (Adler & Borys, 1996)

Organic

This is the familiar state of many Agile projects, where there is a low level of formalized processes and procedures, and a focus on personal interactions, collaboration, and commitment. When done well, this quadrant is exemplified by individual Scrum teams. They have minimal hierarchy, but they are potentially limited in their ability to scale. As there is little formal structure, it becomes difficult to foster organizational learning or help ensure adherence to agreed upon standards. This is the sweet spot where many organizations start, but feel they must eventually leave as they grow and mature.

Autocratic

A simple organization structure does not guarantee enablement of individuals within a system. Some organizations may have few explicit polices and rules, but be run by the dictates of a small group of individuals mandating what people should do. There is no constraining policy handbook, but people are far from free to do what they think is best. This quadrant serves as a powerful reminder that lack of structure is neither inherently good or bad.

Mechanistic

Moving into the dimension of highly formalized processes, let’s first look at mechanistic bureaucracy. This is where an organization has a high level of process maturity, and that maturity has been implemented in a way to control, limit, and restrain the behavior of individuals towards agreed upon norms. This domain is exemplified by the stereotypical experience people may expect from the Department of Motor Vehicles or the infamous “TPS Reports” from the movie “Office Space”. It is typified by excessive written policies and massive hierarchies of managers, directors, and supervisors.

Enabling Bureaucracy

Last we come to an enabling bureaucracy where rules are established as a means to empower individuals, foster organizational learning and help improve the performance of everyone. Whereas coercive processes are designed to limit behaviors to a small subset of allowed activities, enabling processes are designed to encourage autonomous behavior, reflection, and improvement by everyone within the organization.

The Difference Between Coercive and Enabling Design

Words like enabling and empowering have become such corporate fads that we need to clearly articulate what we mean when we differentiate between a coercive and an enabling process. A coercive process is designed based on the limitations of a person, it is meant to control key decisions and activities in order to ensure consistent results according to standards. When I began my career as a project manager, I was working in an organization that had a large planning spreadsheet. All of the cells were locked except for a handful of inputs where I entered the number of requirements elaborated, the number of pages in the requirements document, – I’m not joking, the number of pages was actually an input – and a number of other similar measures. Based on these inputs, I received a projected budget, risk factor, and timeline for my project. No thinking was required and no discretion was allowed. The formulas rated my project and provided the direct inputs into a go / no go decision. This process required minimal understanding of the domain, no investigative work to learn more about the real customer needs, it simply needed some basic clerical work in order to decide how large and risky a given project would be. It could be run by just about anyone in the organization, and that was the point.

Contrast this planning spreadsheet with the behaviors of a team using lean principles and something like a Kanban system to execute their work. Each step has an agreed upon standard of done, but doesn’t explicitly elaborate practices. People are free to innovate in their delivery methods provided they adhere to the agreed upon definition of done. Work is not assigned to individuals, but rather pulled when people are free. The primary constraint is an agreed upon work in process limit that means people may only work on a finite number of things. While the team follows a defined process, they own this process and can modify it over time based on what they learn. In this example, team members are indeed operating with a significant amount of structure. There are key standards and constraints, however they are defined and managed by the team. Thus, the process moves from a stifling imposition to a collaborative means for a team to experiment and improve. Whereas the coercive process limits individuals to a very finite set of actions and outcomes, an enabling process seeks to help people find new, and better behaviors to be incorporated into the way the organization works.

Characteristics of an Enabling Process

Enabling processes can be defined by four specific attributes in how they operate and are conceived.

1. Repair: all systems break down or experience exceptions. The question really is if the system is designed to offer individuals within it the ability to respond to those changes. In the case of software development, this characteristic is inversely related to the granularity of task steps and hand offs. Developers solely focused on building to a spec will be unable to recover from a missing piece of information in a document. They will need to escalate the gap, bring it to another group, have them update the document and then move through another review and sign off. On the other hand, an enabling process might allow for that same developer to begin building while working directly with the analyst who would have created the requirements document so that the two can jointly update the requirements based on any gaps or inconsistencies revealed by the development process. A lack of repair capability leads to another problem. Take the example of my old project planning spreadsheet. One of the data inputs was the number of requirements. Let’s say the business got really ambitious in the way they laid out their requirements. They are asking for a simple data feed, but listed every single field as a specific requirement. Now I obligingly enter that data into the spreadsheet and find this project everyone  expected to be a small endeavor will take three years to complete. I am unable to change the formulas, so I am faced with escalating and waiting for a specialist who helped create the spreadsheet to come help me, or I undermine the system by taking liberties with the data inputs until I get the answer I was looking for in the first place. One option introduces massive delays, and the other quietly undermines the purpose of the policy to add consistency and historical trends to our estimation and planning process. Enabling processes allow for these inevitability and have capacity for those people using them to make judgements and adjust to the reality unfolding around them.
2. Internal Transparency: in situations where we have defined processes to prevent people from thinking, they don’t need to understand how the system is working. Individual actors don’t need to understand, because their behaviors are completely mandated by a defined process. When implementing an enabling process, individuals now have a much broader range of activities, decisions and options available to them. In order to make correct decisions, they must be aware of what’s going on. I have spoken to several colleagues who have worked at  an organization so strongly functionally silo-ed that a group of specialists would come in to estimate a project as part of a toll-gate phase. They would look at preliminary requirements and offer an estimate just in time to move on to the next project. They never got to see how those estimates were used, what other projects they might be interacting with, or what the final result was. Thus, individuals were unable to learn and improve. Those producing the estimates did so in a vacuum. An opposite example would be the daily stand up or Scrum in an Agile team where the point is internal transparency. In fact, this is an excellent test of a team. Team members that are not really enabled will give their updates focused on activity (“I worked on this, this and this”) and most likely offer it to someone in a position of authority, as if they are justifying the time they worked. Enabled team members will talk to one another and their dialog will be much more focused upon when a deliverable may be finished and available to others or problems they are facing that they could use help to resolve. The point of this type of meeting is to offer everyone transparency into what is going on within the team so that people can make informed decisions.
3. Global Transparency: fish in a school swim with no singular source of coordination, nor do they have a consistent set of rules for moving as a group such as “everyone passes on the left”. Fish have lateral strips of highly sensitive acoustic nerve cells allowing them to sense the fish swimming around them. This is how hundreds and thousands of individual fish can swim in perfect concert together. In organizations, we would call this global transparency – the ability of people outside of a team, project or system to understand what’s going on inside it in order to properly align and coordinate their own activities. This may be something like a “Scrum of Scrums” used by Scrum teams to coordinate activity across teams, or even an effective use of information radiators and big visible charts for people passing by a team room to see what they are working on and what’s going on.
4. Flexibility: as I type this blog, I mis-spelled a word several sentences ago. The computer I use features basic spell checking functionality. It knows that I messed up, but rather than simply make the correction automatically, or prevent me from moving on to another word, it shows the word with a red underline. This is a powerful visual indicator allowing me to see that something appears amiss. In this case, I see the clearly incorrectly spelled word, click on it to see a couple suggestions and pick the right option. This is an excellent case where a system helped improve my capabilities without becoming an imposition or causing me to completely give up on trying to spell. In fact, the typo may have been correct. Perhaps it was an acronym for a new project I was working on, and while the word looks like a typo, it actually is something very meaningful to me. In that case, I could have selected and option to add this word to my own dictionary and never have the the application tell me it was a typo again. Or perhaps it’s only clear that the word is not spelled properly, but there are several options that would make fine semantical sense in that case. We can see a similar dynamic in the set up of Agile teams, where they are free to choose from a broad array of tools and techniques. In their better incarnations, this tailoring approach allows a team to adjust a fairly standard approach or method based on circumstances. Flexibility within a process allows for individuals and teams to be steered in the direction of good practices, but offers them the ability to adjust based on their specific circumstances.

Applying Enabling Bureaucracy to Organizational Processes

Large organizations can not function without bureaucracy, and Agile software development and project management do not change that fact. There is a grain of truth to the reluctant manager who views processes and policies as a necessary evil. However, carefully crafting policies to help empower people allows organizations to get the necessary scale and organizational learning without undermining the agility and opportunities for improvement we see in Agile organizations. Let’s take the example of a standardized work and look at how it would be implemented within an enabling and coercive manner. Standard work was first implemented by Frederick Taylor’s scientific management in an incredibly coercive manner. Efficiency experts would come in, measure the time it took people to do different pieces of work, mandate the best practice and then measure against the expectation for that specific practice. Employees had no discretion about how to do the work, they had minimal input to the standard and they were in no way able to offer feedback. They were simply measured by whether or not they were doing work according to the standard for their specific step. Chances are, they also worked in massive batch size, so they only saw the production of their piece of work in large orders.

Now let’s fast forward to modern manufacturing practices exemplified by Toyota Production Systems and lean thinking. In these environments, teams and individuals continue to use standard work. However, the employees doing the work are the ones who own and maintain the standard, and they change it a lot. At Toyota, for example, they average 1 recommendation per employee per week (Liker, 2004). They go to great lengths to visualize the process using things like kanban systems, and employees have access to an andon-line allowing them to stop the production line and make a correction if they see a defect enter the system. The system is setup for improvement and optimization, and is not unlike the scientific method, where we must control for almost all variables in order to test individual ones. In both examples, we have strict rules and discipline. In the first, employees are treated as potential liabilities who must be managed to ensure they don’t work improperly. In the second, employees are treated as capable experts and the process is there to help them maintain institutional knowledge and build upon it. The difference in outcomes is profound.

Recommendations for Building Enabling Processes

Adler and Borys, whose research seems to be entirely independent from the Agile community, end up making recommendations that seem to fit very closely with how Agile practitioners would recommend running a project. When implementing a process, system or policies they recommend four guiding principles:

1. Keep a continual focus on the users of the process
2. Maintain an integrated view of the usability of the process and how it will interact with other systems
3. Engage users for early and continual testing
4. Implement a policy using iterative design while striving for continual improvement.

I find it incredibly validating the convergent nature of this research with the principles espoused in Agile software development. As Agile has grown throughout organizations, it only succeeds when groups are able to internalize the principles and figure out how to authentically implement them within their own domain. I hope concepts like these will help managers and bureaucrats within large organizations see how they should be playing a role in an Agile transformation. It is not that the goal is to eliminate all process and overhead, but rather restructure it to enable employees instead of coerce them.

Old Models Don’t Hold Up

When looking at organizations trying to manage a portfolio of work with Agile teams, we frequently find one of two common patterns that no longer supports the organization

• Each item run as a project: I’ve written before about the pull some organizations feel to solve all their projects with individual projects. Indeed the very success of prior projects can become their undoing as everything becomes a project, and stakeholders then expect to see all projects start so they can see progress towards their goals. This ends up leading to a mental model where executives may love Agile teams, but they feel that they couldn’t run their entire portfolio using it, because they don’t have 20-30 teams to manage the 20-30 projects they are running at any given time
• Large Project Broken into Silos: some organization undertake the exact opposite approach. Rather than having numerous tiny projects, they run large, monolithic ones that encompass more work than a small group of individuals could ever achieve. In these cases, we frequently see smaller build teams within the overall program, and they are frequently crudely cleaved around a functionality, application, or technology stack. This can introduce many problems, as teams may not be able to individually deliver much work, small sizes of each can introduce lots of variability and the cleaving of work across teams may also mean that the most valuable stuff is not confronted first (sure, we don’t need to build the more for the XYZ component right now, but that’s what the XYZ team is tasked with doing!)

Building Blocks within a Pipeline

Thus the challenge becomes managing a pipeline whereby work can be fed to teams in digestible sizes that are properly prioritized and elaborated. There are a number of different approaches and workflows that follow an idea from conception to prioritization and delivery by a team. Looking at these different flows it occurred to me that this is really just workflow encompassing some combination of a series of transformation steps. At the risk of being accused by my coworkers of “going meta” too much, I figured it would be worth looking each of these steps individually.

A good program manager can use these steps like building blocks to assemble a pipeline process to offer the necessary transformations to keep their project teams happily working on the most important work at a sustainable pace. Indeed my experience has shown that many of the lean concepts like managing work in process, cycle time and value stream apply quite nicely.

Prioritized List

Prioritization Step

Purpose: The prioritized list ranks work according to some measure such as value, time needed, or even a weighted importance across several dimensions.

Where is it used: within Agile teams, prioritized lists are probably one of the most commonly used portfolio management tools. Teams have a backlog of prioritized work to be taken on over time. When looking at a large portfolio, the same concept applies, by prioritizing work, we can figure out what should be sent through the pipe first. This tool should be at the very beginning of a product pipeline.

Common Applications: business value or expected order of delivery are probably the two most common lenses used for prioritizing work, but there are a number of other techniques ranging from the wisdom to of a product owner to dynamic group decision models such as multi-voting or even Innovation Games® such as Buy a Feature.

Filter

Filter Step

Purpose: Removes items from the backlog that do not meet a certain criteria (strategic alignment, value / cost, etc.)

Where is it used: frequently used at the beginning of a pipeline to prevent clearly extraneous things from entering. Also used after work is further elaborated or decomposed to remove things that, upon further elaboration, don’t meet a certain criteria or to eliminate parts of a larger item that was just decomposed

Common Applications: The most common applications of a filter would be some sort of ROI or strategic alignment tool where projects or their components must be justified by in some way aligning with goals or meeting an expected ROI threshold. As such, we frequently would see a filter after some sort of elaboration step.

Decomposition

Decomposition Step

Purpose: Breaks apart large deliverables into smaller ones that are more likely to fit within a team’s backlog or iteration

Where is it used: decompositions are generally used once a piece of work has made it through some level of due diligence and prioritization. The point is that this work is most likely to be undertaken, at least in part. While breaking deliverables into smaller pieces requires analysis work and carrying costs, it helps make estimating more accurate, provides smaller pieces of work that can be fed into teams and allows a better prioritization of features so that some sub-components can be delivered faster and wasteful gold plating can be removed.

Common Applications: Story slicing or the functional decomposition of large epics into user stories are common approaches for breaking apart stories. Story mapping is another incredibly powerful technique here for breaking apart what, at first blush, appeared to be an atomic component.

Elaboration & Sizing

Elaboration Step

Purpose: I am including these two steps together because my experience has been that they are invariably tied together. Elaborating deliverables is required to estimate how big they are, and the act of estimating invariably ferrets out numerous details of what would need to be delivered.

Where is it used: this is a fundamental step of any pipeline taking advantage of progressive elaboration, where we add more detail as time goes on. Indeed, this concept is even used in most traditional projects where we move from high level business requirements, to functional requirements, to system requirements and finally a design. Likewise, elaboration and sizing may happen several times within a portfolio process where we add “just enough” detail to determine a high level size in order to know if a feature could fit in a 3 month release or not. As it gets closer to delivery within a release, it may need to be further elaborated so that a team can take it or some piece of it into a specific sprint.

Common Applications: There are numerous forms of parametric sizing ranging from planning poker to more abstract ones like t-shirt sizes or, one of my personal favorites, dog sizes – really, you haven’t led a planning session until you hear people argue about whether or not a piece of work is a “standard poodle” or a “great dane”. Regardless, most techniques revolve around a similar concept, discuss the details of a piece of work enough compare it to other similarly sized pieces of work.

Allocation Grid

Allocation Step

Purpose: Many pipelines need a level of evenness of flow. The idea of a grid is to allocate a certain percentage of the pipe to different types of work in order to ensure that one things doesn’t overwhelm the others. This could be allocations of the pipe to different initiatives based on funding, thereby ensuring that each funding sponsor gets “their share” of the development output. It could also be used to implement the lean concept of leveling the work in order to ensure that work flows consistently. Lastly, it may be used to ensure we don’t accumulate technical debt or neglect important parts of our portfolio such as maintaining current systems or technical infrastructure.

Where is it used: Grids are frequently used once work has been broken into smaller pieces and has been prioritized.

Common Applications: It effectively can split one backlog into multiple. For example, if a program allocates 20% of its through put to maintenance work, then the top maintenance items will be pulled from the backlog to fill the 20% allocation, even if they are not top on the list. It can also be used to level work in the case where a team or teams must manage multiple types of work such as stories that involve only UI or stories entirely focused on business logic. Teams may even have specific allocations for technical improvements or refactoring in order to ensure they have some protected allocation of time to eliminate technical debt and run at a sustainable pace.

Putting it Together

I’m finding that most portfolio management processes can be found using combinations of these different building blocks, with each step a transformation along a value stream. Just like when using a task board, I would expect to see the precise flow over time as people mature, but let’s take a look at a couple example to demonstrate the point.

Prototypical Path

Let’s start with our challenge of too many requests. Traditionally, each request may very well become it’s own project requiring overhead and all the accompanying costs. This model below demonstrates how we would put request through a methodical process to elaborate, prioritize and limit the work that gets to the team. At the end of the process, we have a single consolidated backlog from which an individual team could pull work. The net effect is that the team would have the highest importance work across the entire portfolio, allowing the organization to reconcile the work of a program with a single team.

So here we see a development pipe walking through the following steps

1. Requests come in through multiple sources
2. Immediately apply a strategic filter and try to remove any requests that are not important
3. For those requests with merit, break them down into smaller stories
4. Prioritize all the decomposed stories, so that you have an individualized list of priority stories / features across all requests
5. Filter out those low value features or stories
6. Add detail and estimate the size of the higher priority decomposed stories
7. Prioritize those stories based on their net value (benefit – cost)
8. Allocate 25% of the pipe’s through put to each of the four initiatives

The key step I’m missing here is feedback, and as my coworker Mike would remind me, we should have feedback along every single step of the way to ensure that what we’re doing is indeed valuable and moving us towards our strategic goals. I’m not sure I’ve figure out how to fit that into a diagram like this, but I’m still working on it. At this point, I’m just trying to articulate a common set of components I may use when helping a client define and manage their program process for managing multiple requests. Like a Kanban system, right now I’m just trying to offer a tool for visualizing the flow, if we can’t see it, we can’t do anything.

What’s Next?

I would still consider this a work in process, but I would welcome feedback from others. Are there other critical transformation steps you see missing? Does a diagram like the one I laid out at clarity or make such a process more confusing? I suspect I’ll be writing a bit more about this soon, but I hope you enjoy the idea as I mature it further and thanks again to my colleagues for helping me to develop some of these ideas.

Indeed, this binary obsession – that you must pick one specific approach and apply it to all dimensions of a project – is entirely unproductive. In fact, it is usually not the reality in an Agile or traditional project, but rather a limit of our own thought process. The challenge being that if we find merit in one approach, the mind can take an absolutist value. Agile is useful for dealing with product visions, therefore we should apply Agile principles to every aspect of our project.

The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.
F. Scott Fitzgerald, “The Crack-Up” (1936)

Fitzgerald accurately describes the challenge facing us when organizing and executing projects; we must hold two opposing ideas within our head and continue to function. These two opposing ideas well well described by Kevin Kelly when he coined the terms clockware and swarmware as the two different approaches to managing work. They have since been embraced by many complexity theorists and I present them here as my own attempt to hold two opposing ideas and continue to function and show how one builds upon the other, and to argue that a project requires one or the other will inevitably lead to failure.

Clockware

This is the perspective best described as deterministic or Newtonian in nature. Alluding the the mechanics of a clock, situations within this domain may be very complicated, but they are ultimately predictable and manageable with sufficient analysis and calculation. This perspective is widespread throughout western thought from the view of factory work expounded by Frederick Taylor’s Scientific Management to the modern educational models which lean heavily upon standardized testing and closed problem solving. When applied to modern management and project work, we see deep analysis, detailed plans and an overall effort to control the unfolding process. This is where most Scrum practitioners and Agilists become critical of this mindset, showing how a heavy analysis on planning leads to brittle projects that spend more time trying to adhere to a plan than ensuring they are getting the best outcomes possible.

Swarmware

If clockware assumes a static, closed system, then swarmware is focused on solving problems in a diametrically opposite environment. Swarmware frames problems as infinitely complex and changing in response to numerous factors including the actions one undertakes to manage the system. Based on this perspective, swarmware mandates a highly adaptive approach focused on experimentation, feedback and adaptation. Scrum would be an excellent example of a management approach that embraces this mindset. Frameworks like this are focused on emergent patterns and self organization over centralized planning.

One Building Upon the Other

The challenge in elaborating these two options as distinct choices is that it implies you must use one or the other, that there is some sort of active decision about which approach you think is better. Interestingly, some of the most powerful demonstrations of swarmware are conducted by organisms completely incapable of the simplest decision making, even if it appears they contain a significant level of intelligence. I recall at my old apartment a six month battle I waged against a colony of ants. Had I not known otherwise, I would have sworn there was a plotting queen ant somewhere telling her minions to avoid the places I put poison and to continue searching other cabinets as I tried numerous attempts to move food around and set traps to counter their offensive campaign into my kitchen. [Note of personal disclosure, I am an avid fan of National Geographic and museums of science. If you didn't know this about me already, you will by the end of this post]

If we consider the ants who plagued my apartment kitchen and terrorized my cat, they were clearly demonstrating complex, adaptive behavior, or as we’re calling it: swarmware. They first found a small spill of olive oil on the floor, and that got them excited. We cleaned up the spill, but it was too late. They found access to a few other spare scraps low to the ground and before long they were climbing up on counter tops and getting in cabinets. For creatures with a brain about 1/40,000th the size of a human, they were displaying some pretty creative solutions to find my food and overcome my attempts eliminate them. However, if you look closer at the behavior they were using, it was incredibly simple. We can clearly define the rules that would drive a foraging ant. In fact, we could almost write it as a series of strict rules. Let’s take a look at foraging behavior where ants use pheromones – scents they emit to lay navigation trails, communicate with other ants, and do a number of other activities – to enlist more ants in the efficient collection of newly discovered food sources.

1. Follow the strongest pheromone trail you can find until it comes to food.
2. If you can’t find a pheromone trail, begin to explore randomly until you find food
3. When you find food, follow the pheromone trail back to the nest
4. Repeat

My apologies to any biologists who may stumble upon this post – I’m sure I am simplifying a bit – but that is basically how it works. The ants follow a series of prescriptive rules without any judgement. The ants don’t look around, see that it is raining and adjust their strategy. Simply by blindly these 4 rules, they can get quite effective behavior. Here is a demonstration of how diligent application of a deterministic model – let’s call it clockware going forward – can lead to some highly complex and adaptive behaviors.

Figure 1 - Ants begin foraging

Our thought experiment follows the adventures of three ants. Assume it’s the beginning of the day, so no ants have laid down pheromone trails. Thus, they all pass through step #1 and move to step #2, begin foraging looking for food. Each ant heads out in a random direction. Two ants, after searching for some time, manage to find left over pizza. This triggers step #3, they collect food and follow the pheromone path they laid back to the hive. Our poor third ant doesn’t find food, so step #3 doesn’t get triggered for her – worker ants are all females, infact the only males in an ant colony are used for mating and they only live a few weeks, infer from that whatever you would like.

After one hour of foraging, two of the ants have made multiple round trips to the food, strengthening the scent of their trails. Now, four more ants come along to help forage. They start with step #1, look for a strong scent and follow the trail. The ant who wandered off an hour ago and hasn’t returned left the weakest trail – it was only laid by one single way trip – so the ants ignore it. The other two trails are 4x and 6x stronger as they have had multiple round trips laid by a single ant. Let us assume 3 ants follow the middle trail and 1 follows the trail to the right (nobody said ants were terribly smart).

Figure 3 - Ants after 2 hours of foraging

After a second hour, it has become very clear that one pheromone path is significantly stronger than the others. The trail on the left has never been walked by another ant – her fellow ants are  probably fearing that she may never be coming back at this point in time. The other two trails have been reinforced by ants traveling back and forth on them, but the middle one is 33% shorter than the far right trail, thus the same number of ants on that trail still make more round trips, thereby making the scent strong, thereby attracting more ants. This feedback loop continues and as more ants show up, by following the 4 rules they would self direct to shortest route leading to the food. I will offer my disclaimer again that I am oversimplifying; ants have demonstrated incredibly complex behavior including visual navigation, training younger ants, and understanding events tied to the time of day. However, the point remains that such a simple set of rules, strictly enforced, can lead to surprisingly complex and dynamic behavior. In the proper context, clockware can be used to empower adaptive swarmware behavior (Weston, 2001). (In case you are more interested in Ant behavior, I would refer you to http://blog.wildaboutants.com/)

Thus we see an elegant demonstration where the ants operate using simple, clockware-like, rules and the absence of a central planning authority allows these simple rules, when combined with feedback, to lead to some pretty adaptive behaviors. I should reinforce that the important characteristic of this sophisticated model is that the clockware was very simple in nature, the ants don’t apply rules about where to go searching for food, nor do they follow some centralized authority or plan. The clockware they use is a simple set of rules for responding to stimuli. The complexity comes in the number of ants applying these rules, the small randomization inherent in their activity, and the feedback where ants attract more when they find food that can be effectively retrieved. Of course, in modern projects, we are dealing with significantly more sophisticated actors and problems, so I would not venture to argue that team members on a software development team could operate with such a simple set of rules. However, the concept still applies: simple rules for small behaviors undertook by a number of people can enable highly complex and adaptive systems. Let me offer some examples.

Standardization and Innovation in Manufacturing

This concept has been realized and exploited by many companies under different names. Toyota offers a powerful example. Most people are very familiar with the innovative concepts Toyota has developed allowing them to implement what they call “operational excellence as a strategic weapon” (Liker, 2003). The company averages over 50 suggestions per employee per year, and implements well over 90% of the suggestions. This level of innovation and adaptive change can only be effective when coupled with a high level of disciplined clockware. Toyota is methodical about defining units of standard work and ensuring that people then work according to those standards. This may sounds like some traditional, heavily bureacratic organizations, but there are a couple key distinctions. Standards are created for the purpose of improving them, they are created by the people who do the work, and those people are empowered to change the process over time as they find ways to improve it. Thus they implement a system not unlike the scientific method with a number of variables under control in order to experiment different options and see their impact. Only with this level of discipline, measurement, and control, can the organization be free to try so many innovations and see if they make a positive performance. Much like the ants, disciplined simple behavior allows for feedback to foster more complex behavior within the system.

Applications within Agile Projects

Within an adaptive framework like Scrum, certain rules are meant to be clockware. With this perspective, the sanctity of what people call canonical Scrum begins to make sense.  This is the same paradox illustrated with Toyota, in order to be Agile we execute certain simple behaviors in a deterministic way. The mechanics of something like the daily stand up are strict and limiting, but adherence to them helps people gain better understanding of what’s going on and then leads to more self organization, because everyone has heard what everyone else is doing. Teams hold their stand ups the same time every day so that people are more likely to remember and be able to attend, even if this can be inconvenient from time to time. Participants self-censor their commentary to answer the three questions (what did you do yesterday, what are you doing today, what are your impediments) in order to focus discussion and keep the meeting short, otherwise people won’t be able to get all the information they need in a timely basis.

The counter example to this is the Agile team that, in the spirit of Agile, tries to adapt on everything all the time. People feel conversation is important, so they abuse the rules of a stand up and it ends up taking an hour a day (this could cause this single meeting to consume over 10% of the project time). Teams want to be able to finish a feature in an iteration, so they extend the date a couple days in order to finish, leading to inconsistent measurements of throughput and a false sense of progress. Scrum Masters allow product owners to accept work that is not really done, leading to an accumulation of technical or other forms of debt that will extract a serious toll from the project later. These are all examples where the swarmware concept was applied incorrectly, we tried to be dynamic and flexible on the wrong dimensions, which undermined actual feedback or execution. Generally speaking, you can tell your are experiencing this challenge when you hear people around you state some egregiously awful behavior they are about do to and then say, “it’s okay, we’re AGILE!”

When dealing with how a team will operate, Agile Coaches and ScrumMasters need to ask themselves if something is Swarmware or Clockware. For those things that we agree are in the domain of complex adaptive systems, we will want to leverage things like emergent design, experimentation, and adaptation. This is the swarmware of your project and it probably involves things like the overall technical design, the product backlog and the overall release plan. We expect these to change and will be very careful to not add too much forward looking detail so as to make them brittle or extend our assumptions too far past reality.

On the other hand, there are things that we don’t want to keep spinning on. This would include things like the application of something like test driven development, coding standards, or even the basic rules of a framework like Scrum or Kanban. Iteration dates and agreed upon standards like a definition of done should be set and not changed on the fly.

Evolve Swarmware, Increment Clockware

In any adaptive project, we will most likely change both clockware and swarmware, but we go about changing it in different ways. When dealing with swarmware, we embrace uncertainty and may allow new versions to emerge. Developers will begin with a simple system and take advantage of emergent design to slowly grow a more sophisticated system. In the case of clockware, we don’t evolve so much as increment. When a team sets a definition of done to state that done work must be tested in their QA environment, they shouldn’t adjust that definition on the fly from iteration to iteration if the QA environment is unreliable. By definition that is not a standard. However, the team may decide that they need a new environment for the PO to accept work, and change the definition going forward. This is exactly like the Toyota works setting standards and then methodically improving upon them. In these cases those, certainty is important and the standard should be followed until it is changed.

Figure 4 - Clockware progressing to Swarmware

In the end, the situation is akin the one explored with ants, most of what we do should consist of complex swarmware built on top of a series of simple pieces of clockware. Let me offer an example of a team I worked with recently. The teams developers had to build a new application upon a specific platform with certain agreed upon coding standards. Code was built based on automated unit tests and subject to code scans for things like cyclomatic complexity and other best practices. They delivered work every two weeks with agreed upon review dates for stakeholders and work was only called done when it adhered to an agreed upon list of conditions. This is all clockware. These rules were clear, detailed, and unchanging within the iteration. Between iterations they may adjust their definitions, implement new policies and make other changes, but once established, the rules must be followed. On top of this the developer maintained a dynamic design document they updated as they completed each feature. The product owner had a list of features that were not yet started and she was free to change the order and add new things at any point in time. The team would change task assignments as work progressed along their board. Thus, these more high level activities evolved over time and allowed a greater level of fluidity than the more concrete standards, they were treated as swarmware.

So as you look at your project and get into discussions about how flexible you should be about something, or what level of discipline is needed, ask yourself if you think this is clockware or swarmware. Is it a simple fundamental activity which can probably be clearly defined? Is it fundamental to the value proposition of your product? Using a model like this, hopefully you can maintain within your mind that we must hold two concepts within our mind. Our projects ultimately decompose to a lot of clockware, relatively predictable work that can be standardized, measured and managed. However, these small pieces quickly add up to highly complex things that operate in a qualitatively different way. This is what we would call swarmware, and it requires an adaptive approach leveraging feedback and adaptation. If you neglect the clockware, you won’t have the foundation to get consistent feedback or execute consistently. If you neglect the swarmware, you won’t be able to deal with the essential complexity of your problem domain. Thus in the end, both are important, the challenge is in identifying where one ends and the other begins.