“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.

• What went well this year, or what did I do well this year that contributed to my personal, professional and company’s success in 2011?  Celebrate these successes and consider ways to leverage them in 2012.
• What wasn’t successful and I should try to stop doing or do differently?  Celebrate these attempts, laugh where possible and leverage what you learned in 2012.
• What changes am I going to make or try in 2012 to improve my results?  Focus on one or two things that you believe are important to try.

Now consider what you’ve done, learned and will try relative to the challenges you know are ahead in 2012.  Planning or strategizing for the nearest challenges in the New Year relative to what you accomplished and learned in 2011 will provide some guidance on the first steps you should take.  Additionally, here are three things for you to consider as you begin to think about the work ahead:

Alignment – Is there alignment between your customers needs and what you are delivering?  Is there alignment or agreement on goals?  Is there alignment between your personal and professional goals and what the company needs to be successful?

Transparency – Be open, honest and respectful in communicating and delivering what needs to be accomplished, why it is important to accomplish and how it will be accomplished.  Alignment is not possible without transparency.

Success – What does success look and feel like to you?  Create your vision of what success feels like and work with your team, your management and your peers to create a shared vision of success to help guide the organization.

I have often found that creating a shared vision of success for a team provides a compass for a team as well bringing the team together to work collaboratively towards a goal.  Understanding the organization and your client’s needs begins the necessary step of aligning priorities, and determining how best to meet the challenges.  Finally supporting and enabling transparency helps create an environment where the team can self-organize, where the learning process is valued in determining how best to solve a problem and collaboration can be improved, ultimately improving delivery.

I found that a large information radiator for displaying project risks and issues has been well received by clients. The version I use is a simple 2×2 matrix. The two columns are used to classify items as Business or Technology related; the two rows to show whether the items are Execution or Coordination related — teams that aren’t smitten by the categories are free to change the headings to whatever makes sense in their context. Concentric rectangles denote when the effect of a risk will be felt.

Sample Risk Radar Chart

Items in the inner-most rectangle (or square or circle) identify current issues (risks that have come to fruition) or risks that will become issues within the next two sprints if not handled. The next outer rectangle shows risks that the team foresees materializing within the next 4 sprints. Longer timeframe risk items go outside the 4 sprint rectangle.

Color coding helps denote the severity/impact of the risk. Reds and Oranges affect the project more negatively than the Yellows and Greens. The Sunburst item in this case was a showstopper that was going to bring the project to a complete halt. The areas on the extreme right were for items that weren’t deemed worthy of being tracked on the risk-radar board just yet or for risks that had been taken care of.

For teams the goal was to handle risks before they became issues. Ideally, the innermost rectangle should be empty — teams should be proactively mitigating risks and taking care of them before they get into the innermost “Next 2 Sprint” rectangle.

We used large foam boards and masking tape for creating these risk-radar charts. The chart was prominently displayed in the team room and could be referred to during meetings.  The light weight foamboards made it easy for one person to carry the chart from one room to another if a meeting was being held elsewhere. Pictures taken with a digital camera were emailed to off-site participants.

Once a week, the Product Owner and ScrumMaster would meet with the development and QA managers and with business and IT stakeholders to review progress and roadblocks. During this hour long session, the group would discuss the issues and risks starting from the innermost rectangle.

This meeting served four purposes: (1) as a risk escalation mechanism, (2) as a mechanism for managers and stakeholders to remove impediments that were too big for a team to resolve on it’s own, and (3) as a mechanism for moving away from the existing one-way status reporting culture — managers and stakeholders were expected to report on progress (or lack thereof) on items they had publicly taken ownership of during the previous meeting, and (4) as a way for keeping managers from harassing the teams to “go faster”.

The reason this chart worked surprisingly well was: (1) it was always in everyone’s face and was hard to ignore, (2) managers had insight into risks and impediments and could proactively smoothen the way for the teams, (3) managers realized that teams could not go faster until the issues were taken care of.

Try it out on your next project and let me know what you think. Ideas for improvement will be highly appreciated.

New research leads me to believe that we may be collectively suffering from ego depletion.

Ego depletion is the idea that self-control or willpower is an exhaustible resource that can be used up. Interestingly enough, sugar (or glucose) intake helps us prolong our ability to make decision after decision throughout the day.

Initially it sounds far fetched, until you think about all of the decisions you make throughout a work day and how they correlate with your sugar intake.

Consider the number of decisions you had to make in order to get to work this morning. Now once you’ve sat down and booted up your machine, imagine how many decisions you make before you start to even code. After you’ve started coding (or writing your tests if practicing TDD) imagine how many decisions you continue make in the span of just 1 minute.

If you do the math you begin to realize that you make a staggering amount of decisions throughout the course of just one work day. Many of these decisions are under pressure with serious implications.

In addition to ego depletion, research has found that these decisions can be broken down into pre-decision and post-decision processes.

A prolonged period of pre-decision is not ideal for a team that thrives on quick feedback loops.

I believe we can use this new found research to help our teams be in situations where they can make the best decision possible.

Daily Standups - Urge agile teams to have the daily standup in the morning if possible. It is our daily plan and we need our team focused as we make decisions on what we are about to do.

Retrospectives - Bring candy or snacks into the retrospective. Team members are more likely to forget their manners when suffering from ego depletion. It isn’t just people, it even happens with man’s best friend too.

Iteration Demos - Schedule these early and bring muffins, donuts or pastries along with some form of juice. If the Product Owner is accepting the work, he or she needs to have the mental fuel to make the tough decisions.

Feedback Loops - How long does it take to compile and run tests locally? How long does it take to deploy a build to test or production? How long does it take to get an answer from the business on feature question? All of these affect pre-decision time spans and deplete willpower.

I believe if we can align our agile and scrum coaching techniques with these findings, the result will be a team that is in an environment where they can repeatedly make good decisions.

“Hey, man! One week down, two weeks behind…” -Kirk Lazarous, Tropic Thunder (2008)

While not a terribly serious movie, I have always enjoyed this quote from the comedy movie about the ill fated making of a war movie. The concept of being only one week into a project, and yet somehow already two weeks behind seems so absurd as to be impossible, and yet it has been the reality for a lot of projects encountered. Invariably, ambitions around projects can get so high, with so many stakeholders that our definition of success rapidly becomes so great we watch the possibility of completing our project recede into the horizon. Properly defining and then managing project success is a critical activity in any project. There are a number of excellent resources I’ve drawn upon over the years to do this. This blog post is more a compilation of my thinking on this topic threading through some of these techniques.

The Iron Triangle of Project Management

Fig 1 - The Triple Constraint

The first concept I encountered on this topic was introduced to me as a project manager. I was told to manage the triple constraint of scope, schedule, and budget. The concept is simple and quite effective. On any given project, there are fundamentally three constraints, the amount of work you’re going to deliver, the amount of money you’re willing to spend, and how long the project can run. As the name implies, these are constraints imposed upon a project, “you must finish by 12/31/12″ that will be used to determine if a project was successful or not. As the triangle image demonstrates, you can constrain on up to two dimensions, but not all three. Thus, you could engage with a project sponsor in an earnest discussion about where you would put the prioritizing focus for a given project. Let’s look at some examples to better illustrate this point.

Fig 2 - Triple Constraint Examples

The first example is a pretty straightforward single constraint where the delivery of a set number of features is most important, while schedule & budget being less important. My favorite example of this would be Blizzard entertainment, who explicitly refuses to announce release dates in advance for their games, rather insisting they build them properly and that it’s “done when it’s done“. The next example we see is a double constraint. In this case, we are prioritizing one of the two constraints over the other. A colleague working with an entertainment company offered a great example for a project like this. He had a specific team (fixed budget) and was building a new application for an upcoming sporting event. Thus, if they didn’t release by a given date, the application was worthless. In this case, the scope of what they release was actually the least important thing. Lastly we come to one of the failure models for this approach, which I would call the cop out. In this case, the sponsor basically puts the focus exactly in the middle, saying that everything is important. As you can imagine, this does not set up a project for success, as we have no flexibility along any dimensions.

From a project management point of view, I can see the value of this tool. However it leaves many questions unanswered. How important is it that we build something which is reusable and can be built upon in the future? How important is it that we invest in the team? Are there specific ROI figures that are required for this project to be viable? These are all left unanswered by such a tool. These limitations were clearly articulated when I managed to deliver a project on time, on budget, and to scope but it delivered zero business value.

Success Sliders

Rob Thomsett introduced the concept of Success Sliders as a means of exploring more than just three dimensions when considering the success of a project. This technique offer the ability to break apart that ambiguous concept called “scope”, or prioritize other dimensions like quality and team experience. Indeed, you can use this type of model to prioritize along a virtually infinite number of criteria.

Fig 3 - Success Sliders with a force ranking

Figure 4 - Score based Success Sliders

There are two common implementations I’ve seen of this technique. The first, demonstrated in Figure 3, is a force ranking. In this example, a number of stakeholders each individually had to force rank the priority of a number of different criteria such as “realize ROI”, “High Quality”, and “Deliver Project on Time”. Each individual stakeholder’s values are represented with a different color. The precise list may vary from project to project. In fact, eliciting and elaborating specific criteria can be an art in its own right. This example shows how different stakeholders show their perspective of priorities so that discrepancies can be discussed and reconciled before a project falls into duress. The ultimate goal is a single prioritization, as demonstrated in Figure 4. This is a screen shot from a tool made available by Mike Cohn on his website. This example is different in two counts. First, it represents a single set of agreed upon values. Second, it is not force ranked, but rather a budget. You can only increase the priority of one dimension by lowering the priority of another. This sort of tool, especially when used with a number of stakeholders, can be an excellent way to work through different expectations and amongst different stakeholders. However, this technique also introduces some limitations. While it does allow us to prioritize, it can’t quite distinguish what the absolute criteria is. We can focus on dimensions, but are the top 3 deal breakers? What about the top 4? There still is some ambiguity we need to cut through.

Project Constraints

Jim Highsmith proposed the use of identifying project constraints to as a way of reinventing the triple constraint. His argument is that those dimensions can be prioritized into “Fixed”, “Flexible”, and “Accept”, but those can additionally be illustrated with threshold criteria. Let’s illustrate that tool with the case of the sports application.

In this example we see that the primary constraint is schedule. The application must launch by 3/1/11. The flexible constraint is budget. In this case there is an existing team, so while there is a little bit of flexibility with the budget, this dimension shouldn’t move too much. The final constraint is that they can generally accept an application that can provide scores and game highlights. Thus we see the project team must deliver the application by the specified date while adhering to the general burn rate it currently has in order to opportunistically deliver whatever functionality it can within those constraints. As you can see with this model, whave a more precise conversation around the precise criteria.

The concept of a fixed constraint compared to a flexible constraint can be applied to the broader set of criteria identified in our earlier exercise. Let’s take a look at the situation illustrated in figure 4 using a constraint table.

What Do You Mean, “All Scope”?

Regardless of which of these more detailed techniques you may use, clearly breaking apart the “scope” dimension is critical. I have participated on too many projects that have blindly said something like, “our new system should deliver all the scope of the old system”, without really doing any analysis of exactly what that is. Indeed, I find that the question of scope can usually be broken into smaller pieces. Let’s look at some examples.

• Break by users: some applications have either a wide array of user times or clients who use an application differently. In this case, you may want to identify different dimensions to prioritize. For example, you could take an online book store and break it apart by the different roles and say something like the functionality for an online book shopper is the highest priority, as they are the ones actually buying the books. Support for wholesalers providing the books and your administrative support staff may be lower priorities for your first release.
• Break by business objectives: many projects have hard interdependencies or down stream processes that require time in order to deliver their own functionality. For example, imagine you have a web service that a customer must interface with. You may have priorities by date, based on the delivery schedule of your partner. Let’s say that you and your hypothetical partner plan to launch a new service for the holiday season, which must be live by 12/1/12 in order to take advantage of the holiday season. However, your project is not responsible for integration with the vendor. Rather you, must simply provide them with a usable web messaging interface by 11/1/12 so that they have 1 month to tie it together an test. That delivery of a usable service may be a more important criteria for the team than the actual 12/1/12 implementation date.

Let’s take one last look at a hypothetical project book store project and see how this whole thing plays out

This is More That Just Mechanics

While these exercises might seem pretty straightforward and simple, sometimes they can be quite contentious. I have encountered a number of anti-patterns when trying to use these types of techniques

• “We already know what the priority is” - frequently a project manager or sponsor may state quite simply that this level of detail is not important, because they already agree on it. In these cases, sometimes the easiest thing is to ask them simply to write it down and compare it to what some other major stakeholders think. Frequently, this will reveal enough inconsistency that they realize they need to entertain a more detailed discussion about criteria
• “But I’m the sponsor, Isn’t this simply my decision?” – sometimes project sponsors may feel offended that you are trying to democratize what they see as their decision to make. It’s very important to be clear about the point of this type of exercise and how you will use it to make decisions. Chances are, a project sponsor funding the project will ultimately make the prioritization decisions and define the final criteria. The point of an exercise like success sliders or constraints isn’t to do that for them, but rather to surface the expectations and perspectives of other stakeholders so that the sponsor can make the best informed decision. If the dev manager says that reusability is very important for the success of this project, that very well may at least be worth entertaining the discussion to understand why. There’s a chance they may know something the sponsor doesn’t and the discussion will help lead the group to a better decision.
• “This is ALL important” – some groups of stakeholders may be unable to parse more detailed criteria like in some of our later examples in this article. Rather, they may have a very hard time saying precisely what is or isn’t critical for success. This is usually where a force ranking, like in FIgure 3, can be most valuable. Before even engaging in a discussion about which dimensions are truly must have, or even the precise dimensions, stakeholders must simply prioritize in a force ranked order.
• “We don’t want to preemptively surrender scope” – when engaging in this exercise with groups that have little trust, its quite possible the business may reject this type of exercise feeling like the development team is simply trying to get them to give up scope or lower expectations. The point of this exercise isn’t so much to surround things; ideally, we’d like all dimensions. The point of the prioritization is to do responsible project management. We want to know what’s truly important before we start the project so that people can make informed decisions along the way ad new can manage risk so that if things do go wrong, we are able to maximize the chance it won’t impact our primary success criteria.

Visualizing Your Process with a Kanban System

• Project Manager as a Change Agent
• Visualizing Your Process with a Kanban System

In addition, we played several games:

• 60 Steps
• The Marshmallow Challenge
• The Bottleneck Game
• The Coin Flip Game

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.

“All Models are Wrong, Some Models are Useful”

- George Box

I’m just coming back from vacation and will be resuming my personal goal of one meaningful post per week, but I came across this quote and thought it was incredibly relevant. With the continued discussion about Scrum vs. Kanban vs. RUP vs. whatever comes next, as well as some of the concerns raised about the PMI now getting into the Agile certification business, I think it’s important for us to remember that all these models, frameworks, sets of practices, and other simplifications of the complex craft of software development are wrong. It just so happens that some of them may be useful. Our goal isn’t so much to find a perfect model, or to obsess over the warts on someone else’s, but rather to put to use the ones we find useful so that we can help organizations improve.

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.