Indeed, the challenges that agile organizations have been facing as they embrace team centric work have actually been confronted by numerous organizations prior to Agile. Automobile companies, professional consultancies, oil companies, and even the world bank have encountered this challenge where their technical experts have become ensconced in cross-functional project silos. Looking at how these organizations have addressed this challenge offers us some interesting insights. The successful organizations didn’t try to bolster their functional silos or build standards groups, but rather they embraced a more informal and organic model for sharing knowledge, solving problems and even making strategic investments: communities of practice.

What Makes a Community of Practice?

It can be easy to misconstrue a community of practice with other similar constructs such as functional silos or centers of excellence. When well implemented, communities of practice are meant to be distinct from these other entities, offering them certain advantages. Etienne Wenger identifies communities of practice based on three primary attributes.

Domain

Communities are defined by a common interest that defines the boundaries and interests of community members. The domain indicates precisely what that shared interest is. It may be functional in nature, such as a development or QA community, but it could also be based on other shared interests such as a market, geography or even a specific technology or skill. The domain represents that shared interest in which community members are looking to support each other, build more knowledge and capacity.

Community

Unlike functional silos, communities are informal and social in nature. They are based on the connections that are built and cultivated between community members. As such, membership is optional and people’s level of involvement will vary by person and over time. Within a community, some people may serve as outspoken experts, others may be involved and make regular contributions, and still others may simply quietly consume information. All of these roles are acceptable and individuals may even more from one to another over time. This dynamic nature means that membership is fluid and dynamic. The social structure means that involvement in a community is defined by people’s interest, rather than explicit role or function. This offers a dynamism absent in formal structures as new members can join bringing new energy and people who are less interested can disengage easily.

Practice

Communities of practice differentiate themselves from centers of excellence by being focused on practice. Namely, community members participate in a community as a means of furthering their skills and solving problems. Good communities produce interest and engage people by solving problems. This also provides an elegant way to prioritize and focus the energy of a community, as it is organized around the problems that community members bring to it. This is a critical distinction and success criteria for communities. I have seen numerous communities form based on a top down directive and then try to organize around establishing a body of knowledge or standards that appeared to be valuable to the organization, but were distant from the day to day demands facing community members. Unfortunately, working groups like this frequently run out of energy and disband. In order to be vibrant, community members need to see immediate value from participation in communities.

Why Use Communities of Practice?

So what are the benefits that we get from communities of practice? For people who have existed within cross matrixes organizations, excessive formal hierarchies can become very cumbersome and take time to adjust. A given individual may have interest among more domains than an organization can provide formal structures for. In any organization using cross-functional project teams, each person has at least two: a functional specialty and a project team. Thus, communities of practice allow for informal structures to interweave people into multiple domains without carrying the burden of additional structures. This is not at all unlike the concepts of “meta-scrums” described described in several agile scaling approaches. The focus on practice is also a key advantage, as it balances interest in a domain with practical and tactical benefit. If a community can not deliver value, then members will stop showing up and the community will end. This provides an elegant model for the creation and destruction of communities over time based on where the interest and energy is within an organization and it requires no formal organizational intervention.

I must confess that I didn’t first appreciate the value communities of practice could play in an agile organizational transformation. This was a fortuitous discovery for me when I began working with the PMI Agile Community of Practice and began to learn more about communities of practice in general. Let’s take a quick look at some of the value communities offer and how it aligns with agile organizational transformations.

Functional Specialization vs. Team Focus

Invariably, every organization I have worked with encounters this problem when they charter cross-functional, dedicated project teams. Communities of practice allow for functional specialists to remain in contact with one another, share experiences, coordinate effort, and maintain their own sense of identity. In the case of Chrysler and several other organizations, as project teams reduced the need for functional managers, many of them become more involved as community coordinators, playing a more facilitative role to cultivate and develop vibrant communities of practice around their specialties (Wenger et al, Cultivating Communities of Practice 81).

Building Expertise & Standards

Another chronic challenge that faces agile organizations is how to help grow functional expertise across teams and agree on standards. Communities of practice provide a powerful engine for sharing experiences and learning. The social structure of a community plays a key role in allowing information to spread quickly. The most formal example of this being in Xerox, where repair technicians created habits of socializing with other technicians in order to share stories and experiences. This provided a rich body of informal knowledge that made the technicians significantly more effective at their jobs (Brown & Gray, 1995). In fact, Xerox has since gone on to implement online tools to allow technicians to communicate and share expertise from any geography.

Impediment Resolution

Good agile teams need to be aggressive and methodical about solving problems, and communities provide additional resources to help people do just that. In fact, if you look at the informal nature of communities of practice, and the shared domains they use, this model is ideally suited for creating a sense of ownership of these problems and their solutions by the people doing the work. As removing impediments is a critical role of Scrum Masters and agile coaches, I frequently set up a such a community at clients to help give these people within an organization a common forum to support one another and bring more force to bear in removing obstacles for their teams.

Self Organization

Following concepts from complexity theory, many agile organizations look to move decision making to the lowest responsible level, as those who are closest to the domain are frequently in an excellent place to make informed decisions. But how exactly can you build constructs that allow individual contributes to make strategic decisions like where the organization should invest its finite resources for future products or services? McKinsey offers a powerful example where they actually built service offerings and pursued business based on consultants working within informal communities of practice to build knowledge and capabilities around new services and markets (Wenger et al, Cultivating Communities of Practice 17).

As you can see, the informal, member driven nature of these communities of practice aligns very much with the challenges that organizations embracing agile practices must confront. I hope to write much more about this later, as I’ve already seen some interesting patterns using communities of practice at clients as well as quite a bit of impressive activity with the PMI Agile Community of practice. For now I’ll just have to leave this as an introduction to the concepts. I would love to hear what types of experiences you have had with your own communities and informal structures, whether called communities of practice or not, at organizations using agile practices.

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

“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

An Impediment to Agile

Later, when I embarked on my career as an Agile coach, I ran into this issue again. If you think about it, pay for performance or management by objective runs in the face of two of the very values of the Agile Manifesto.

• Working Product over Documentation – if people have very localized objectives, which indeed they would need in order to be “properly” evaluated, then chances are analysts are rewarded for documentation, project managers for plans, and testers for executing test cases
• Responding to Change over Following a Plan – here we see a challenge of delivery cadence. If we assume that most pay for performance goals are set at the beginning of the year, then basically that person is financially locked into the view of the organization at that point in time. If I am the PM working on a project that is competing with another project for resources, and that project is more important, the best thing for the company very well may be for me to sacrifice my project for the sake of the other one. However, if I have a pay for performance plan rewarding me for completing that project, then my organization is basically paying me to undermine its best interests.

Corraborating Research

This belief has always been a gut feel for me, more a hunch based on my experience then something I was able to scientifically prove. Thankfully, several other people have done much more research on this topic, and their results reinforce what many people already believed.

Variable pay-for-performance is a folly

Bruno Frey and Margit Osterloh survey some of the recent scientific literate and come to the conclusion that variable pay for performance is fundamentally flawed. Specifically, they identified four major problems

• It is impossible to set goals that are precise enough to be relevant over even a one year horizon
• Those being given the pay for performance objectives know the nature of their work better than managers and can potentially manipulate their evaluation criteria to their advantage
• Pay for performance reduces people working on anything not explicitly identified, even if it may be valuable
• Pay for performance undermines forms of intrinsic motivation, which have been shown to be significantly more powerful

The Limits of Extrinsic Motivation

In his groundbreaking book, “Drive“, Daniel Pink explored the concept of extrinsic verse intrinsic motivation. One of the most interesting conclusions he found was that the research consistently showed extrinsic rewards – money and similar compensation – not only failed to improve performance in most situations, but in those that specifically required thought or creativity, people generally performed worse as financial compensation increased (Pink, 2009).

How Should We Compensate in an Agile Organization?

I’m sure I don’t have the complete answer here, but I see several key guidelines

• Pay Enough to Take Money off of People’s Minds: most of the research indicates that a good salary is important, but once you pay someone so much that they aren’t worried they are under paid, you can’t do much more with direct financial incentives.
• Play to Intrinsic Motivation: this probably merits its own series of blog posts to further explore, but research indicates people respond much stronger to internally focused forms of motivation such as belonging, autonomy, personal mastery, and purpose. Following this logic, you may reward top performances with more freedom to choose side projects (autonomy) or perhaps opportunities to build their skills further (personal mastery).
• Accountability to the Team: in traditional organizations, managers have huge discretion over promotions and bonuses for their direct reports. As organizations embrace Agile practices and move to flatter, team based structures, individual accountability is harder to discern by a functional manager outside of a team. As the team is making commitments and organizing itself, it follows that the teams ultimately need control over who is allowed on their teams and who is rewarded. This even plays towards the intrinsic motivation of belonging, as people gain control over their team composition, membership within that team becomes more valuable.

I highlight these issues not to say that I have an answer, but rather to direct attention to some of the larger organizational fixtures that may seem innocuous or unrelated to implementing Agile, but which can become major impediments to profound change and improvement. As organizations move to adopt Agile values and practices, they will need to look far beyond just software development and project management to make the necessary changes.

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.

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