Suppose, for example, you reach a point in your agile implementation where teams are delivering and executing in a much more productive and efficient way. That begs the question, are they delivering the right things? Now that teams can deliver faster with better quality, how does an organization leverage these newly acquired super-skills? 

The answer is clear: the business and product strategies have to change, too. If teams can deliver faster and more iteratively then we need a product or business strategy that can take advantage of these capabilities. It’s not enough to continuously improve how we deliver. It’s not enough to just keep scaling agile to encompass more and more teams. What we must do is improve our ability to figure out what to deliver next. We need to incorporate feedback, learning, experimentation, and rapid delivery into our business and product strategies—without these all we’ve figured out is a faster, better way to deliver the same old results.

What many organizations have discovered in their adoption of agile is that their organizations are rich in policies and controls that were installed to support a process they no longer use. In order to achieve their organizational agility goals, these organizational policies and processes need to be adapted to match the new agile execution, delivery, and strategy models. For example: If existing release management policies require a 3-month conveyor belt to deploy a completed product but the team can deliver completed product monthly (or even weekly), those release management processes and policies must change in order to take advantage of team’s abilities.

To truly pursue organizational agility, we must tackle and transform emerging constraints— things like signoffs, stage gates, metrics, performance plans, risk management, etc. This goes far beyond team-level problems (or even enterprise agile) to the systemic constraints that stand in the way of true agility.

In his 2009 Blog Post (http://bigv.is/xBNZEe) George Schlitz talks about the need to change these rules.  He states:

“Organizations make rules to operate in the presence of limitations…the rules that were made to operate in the presence of the old limitations must be eliminated or changed, and new rules created to deal with new limitations.”

As organizations improve how they operate they must change their organizational policies to deal with new constraints – not treat the existing policies as constraints themselves.

2012 will be the year that organizations start to turn the corner in their agile adoptions. They will recognize that team- or project-level adoption of Scrum, XP, Kanban, Lean (or some combination of agile processes) is only the first step towards achieving organizational goals. They will realize that organizational policies, process, and often, structures, need to change as well. Some will find the challenge too daunting—But those who figure out how to evolve their organizations; those that make it a priority to effect organizational change in order to meet ever-changing markets; and those that realize a sense of urgency and respond to it will find themselves on the path to true organizational agility.

Works Cited:

1. Schlitz, George. “Agile Removes Limitations…You Must Now Change The Rules.” Web log post. BigVisible Blog. BigVisible Solutions Inc., 10 Nov. 2009. Web. <http://www.bigvisible.com/2009/11/change-the-rules>.

This way of thinking and approach to change may drastically limit the success of your journey to becoming an agile organization.

Some indications that your organization treats change as a temporary state to be controlled, and may need help moving to a more appropriate theory of change for today’s complex environment:

• Establishing a standards board to cull “best practices” from a cherry-picked pilot team and/or from research to then “roll out” a new ["standard" agile] process to other teams (“surely only the pilot team was able to do something effective without a standard!”)
• Preventing teams from improving until someone has determined the “best practices” that they can then implement (e.g. “you can’t introduce that practice until the centralized group has determined the best process™ and best tool™ for everyone to use!”)
• Taking experiences of success from implementing a practice or improvement in one context (organization, project, situation) and dictating their use as standards in others contexts (“<practice x> worked with <SuperPilotTeam>, other teams must use <practice x> too!”)
• Measures of transition success based on “adoption percentages”

A Reality Check for Most Organizations Considering (or in the middle of ) Transitions to Agile, Lean, etc.

If you can relate to this, the ship that is your agile initiative may be sinking.  Over time, the initial excitement generated by the introduction of agile principles may be crushed by your management and organization as they ignore the learning process your teams have gone through, and carve out standards to be applied to everyone.

Basically, you may have the appearance of agile, minus the agile part – the practices without the principle; the motions without the capability.

This is one of several causes of the phenomenon known as CrAgile (“Crappy Agile,” a.k.a. “Scrummerfall,” “Scrum-But,” etc.) – wherein an initial exciting introduction of new ways gradually reverts to old ways.

The Learning Journey

Standards, when used as described above, don’t result in success of complex endeavors like product development efforts.  They result in begrudging compliance and, if you are lucky, successful following of steps as opposed to achievement of outcomes.  From years of coaching, consulting, and being a member of many successful and unsuccessful product development and change efforts, I have realized a few things about learning new ways, such as:

• Each person and team proceeds on its own “learning journey” when trying new things (see diagram). The real learning is in understanding what things work (and don’t) in different situations, reflecting on these experiences to understand why they did or didn’t work, modifying and improving them to work, and continuing to expand their awareness to continuously determine better ways.
• Standards and best practices, used wrongly, are an attempt to short cut this learning process.  Ironically, the short cut only cuts out the “learning” part, and results in blind adherence to practice, and rarely greater capability.

This diagram shows the learning journey of a team.  Over time, the team tries new practices and techniques.  They learn how things work, and how to customize practices and interactions in ways that work for them – in their environment, for their challenges.  The practices alone were not the reason for growing in capability, but rather trying the practices and learning about when and how to apply them.  The common management mistake is to assume that taking the practices that a high-performing team is using, and copying them to other teams, will result in the same improvement.

The Only “Best” Practice – Continuous Learning and Improvement

“There are no best practices, only better practices”

I don’t know where I first heard/read this quote, or who it came from (let me know and I’ll update this page- my searches yield many writings). What I do know is that the pursuit of “best practice” has a number of subtle problems:

1. It implies that once these practices are found, improvement is done. This is consistent with the “unfreeze-change-refreeze” model of change associated with Kurt Lewin in the early 1900′s. This older model of change is often criticized for being too inflexible to deal with the overwhelming amount of change and disruption we face today.
2. It mistakenly assumes that effectiveness of practices is context-independent (i.e. what works well in/for one situation, person, team, group, environment will work as well in other situations, persons, teams, groups, environments). Consider how much can be different about situations, people, teams, groups, and environments and it becomes easy to imagine how a “best” practice in one place may not even be a useful practice in another.
3. It assumes that change is not constant.  More and more articles, books, and experience show that change is constant, and that organizations that will survive in the future must develop the capacity for continuous adaptation.

A Better Use of Standards and Best Practices

Reconsider how best practices are used in your organization.  Learn from lean thinking a different approach to improvement and standards.  

1. Change your focus on standards from that of arriving at “best practice” to constantly finding “better practice”.
2. Shift the purpose of centralized groups from centers of governance to centers of enablement – helping to encourage teams to visit each other to learn about successful approaches
3. Encourage the building of communities of practice wherein people from different teams and group can share experiences and learning.

Lean “Yokotenkai”

In the lean world, the concept of yoko tenkai (which I’ve read is poorly translated as something like “beside/to the side, expansion” – shortened to “yokoten”) is a process of sharing best practices from one part of the organization to others, and (as importantly) improving or expanding them constantly to meet the needs of the new context. There are two aspects of yokoten- both are necessary, and neither is sufficient on its own.

1. The first is the “copying” of best practice to the side. This involves learning about discovered “best practices” from other parts of the organization.  A subtle (but critical) nuance is that these practices are not designed and dictated by some governing body- instead, the process of “copying” involves people sharing learning and observing practices in other groups as they are being used, in context.  It is a sideways proliferation of learned practices across the organization, fueled by observation of these practices where they are working.
2. The second part is “expansion.” Practices are not to be blindly and arbitrarily applied to other parts of the organization.  Instead, the practices are modified and improved to suit the needs of each group and context.  The result is continuous improvement, fueling more sharing.  This results in continuous “better” practices.

When people from one team observe practices in use in another team, they are taking these practices, bringing them to their team, and will more likely customize these to work best on their team and “make it theirs,” with the goal of improvement.  Alternatively, when an authority tells a team to implement a practice, will do what they are told, with the goal of following the practice.

What can you do?

Here are some ways you can get started, today:

• Discuss the role of standards in your organization.  Discuss yokoten and what it means to your group.  Research the Toyota Production System and other lean implementations.
• If you are on a team, try to embody yokoten yourself!
  • reach out to other teams to learn how they’ve been successful
  • bring back learnings to your team and improve/modify them to suit your context
  • share any improvements you make with those who helped you
• If your organization is embarking on a large transformation in pursuit of organizational agility, and seems to be run in a manner similar to that discussed in the beginning of this article, seek expert guidance.

The following things may take a long time to instill in your organization – as they may need cultural change to be truly accepted:

Start shifting the role of centralized groups from designers and declarers of standards to enablers of yokoten

• Ensure teams get the help they need to be successful
• Be aware of learnings in various teams
• Encourage teams to visit other teams that have been successful, and bring back learnings to their teams to improve

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.

Three Faces of Power

1. Decision Making – The power to make and implement decisions

2. Non-Decision Making – The power to set agendas and therefore limit what is even being discussed

3. Shaping Desires – The power to manipulate what people think they want

Lukes’ work is an extension of Max Weber’s Three Types of Authority, in which Lukes argues that Weber only focused on the first face of power, Decision Making.

Others such as Kenneth Boulding have described these power dynamics as the carrot, the stick and the hug.

Regardless of the names used, by simply being informed about these types of power you can become more aware of your surroundings.

The Engineering Manager ordered the Developer to change his task estimate.

An order from a Manager to a Developer is the most public form of power and is an example of how the Manger wants to be perceived. This first face of power is rather easy to spot and diagnose.

This meeting lead by the Director of Engineering only had task estimation standards on the agenda.

A Director who is controlling the meeting agenda is a bit more subtle and requires a level of awareness to see. What is it that they hope to accomplish by limiting the agenda in such a fashion? Limiting the agenda is a technique used to prevent issues that could cause opposition. Do they address issues if they arise in the meeting or do they misdirect? The second face of power tends to leverage delay, inconclusive questions and bureaucracy to avoid the needs of the weaker team members. Sound familiar?

The CTO convinced his team that accurate task estimates are the key to hitting quarterly goals.

A CTO who has convinced his management team that his interests are in their best interests is far more difficult to identify and diagnose. It isn’t always obvious that the actions of the team are a result of coercion from their boss. They can convince people that their wants and needs are actually harmful to them. This third face of power is often aligned with ideological institutions.

These are just a few examples of the faces of power you may experience every day in a large organization.

I believe that being aware of these faces of power help me become oriented during an organizational transformation. Perhaps you’ll find value in them as well.

We then got talking about Peter Weir’s 1989 movie, Dead Poets Society, starring Robin Williams and Ethan Hawke. In the movie, Robin Williams plays an English teacher who fosters a love of poetry in his students and encourages them to demonstrate freedom of expression and a willingness to go against expected norms. The movie takes an unexpected turn when one of the students commits suicide. The kid wasn’t free to live his own life but was being forced to live up to his father’s expectations and dreams. The father wanted his son to become a doctor and viewed poetry and drama as frivolous activities keeping his son from the real matter at hand — preparing for a future in medicine at Harvard. The son, in frustration shoots himself with his father’s gun.

So, the question is, whose fault was it — the dads for forcing his expectations on and disregarding his son’s feelings, or the teacher’s for introducing the concept that when faced with conformity, it is your responsibility to stand up for what you believe is right and to not blindly do what others tell you is just.

Recently I ran into Joe, a tech lead on a big Agile project I had coached. Joe is easily one of the best senior developers at the company, is enormously respected by the other developers and by the business stakeholders he interacts with. Joe has also done a stellar job on the Agile project and has been crucial in keeping multiple project teams functioning smoothly.  However, Joe got dinged on his just concluded annual review. IT management expressed dismay at Joe’s “lack of communication” and “poor planning.” What was actually meant was that IT management was not happy with Agile, was not happy with the business being part of the team, and was not happy with their inability to get ahead of any bad news and spin the message to the business — Joe’s superiors considered transparency to be a very very bad thing.

In this company, the C-level folks have utterly failed in convincing their subordinates that they truly believe in what they are espousing and have failed to create an environment that values and rewards openness. Thus far, senior IT managers have only paid lip service to changing the existing assessments, metrics, and reward systems that encourage lying and hiding material information. Employees believe that to be successful in this organization you need to keep a low profile, not stick your neck out, and to lie and shift the blame to someone else anytime something goes wrong. Senior IT managers have also failed to create any new experiences that would cause people to question and challenge their existing beliefs. Senior managers take their cue from C-level managers and try to do what they think their bosses actually want. I don’t blame them for simply going through the motions; after all, past experience has taught them that there is no benefit in doing something counter to what your boss expects (irrespective of what he/she says).

So, once again, the question facing me is: is it right for us to coach teams and get them dreaming about possibilities knowing fully well that they are not going to get real support and encouragement from their bosses, who say one thing to their business counterparts but do the exact opposite and have no interest in changing their modus operandi? Is it ethical for us to show people the great things that are possible and then have them penalized for their good work?

Have you faced a similar situation before? What did you do? What do you think is the right thing to do — call people out on their hypocrisy? Part ways with the client because long-lasting meaningful change is not a possibility at this time? Spend even more time on educating management and executives?

Let’s bust those myths!

Myth: Agile Doesn’t Work for Projects in the Highly Regulated Medical Environment.  (The reason usually given is that FDA regulations require detailed requirements prior to project approval; hence, waterfall.  However, in reality, you can develop in phases, with small incremental sets of requirements and the FDA requires only enough documentation to demonstrate your process.)

Truth: Abbott Labs overcame medical device regulation and stringent Class 3 certification and developed the m2000 Real-time PCR Diagnostics System, a human blood analysis tool, with four agile teams.  Compared to the prior methodology in use, this project resulted in a less cumbersome process, fewer defects, a reduction in costs of 43%, and a reduction in cycle time of 25%.

(Rasmussen, R., Hughes, T., Jenks, J. R., & Skach, J. (2009). Adopting agile in an FDA regulated environment. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 151-155)

Myth: Agile Doesn’t Work in Government

Truth: The FBI overcame a CMMI level 3, ISO 9001, government-mandated document-driven waterfall life cycle and developed the Domestic Terrorist Database & Data Warehouse with three agile teams.  Compared to the prior methodology in use, this project resulted in significant improvements in release planning, developer satisfaction, and a focus on the true goal: “to catch bad guys.”

(Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 96-100.)

For another example, the U.S. Department of Defense developed the Strategic Knowledge Integration Website utilizing three agile teams.  Compared to the prior methodology in use, this project resulted in improved quality, fewer defects, better teamwork, and a 200% productivity increase.

(Fruhling, A., McDonald, P, & Dunbar, C. (2008). A case study: Introducing extreme programming in a U.S. government system development project. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), Waikaloa, Big Island, Hawaii,USA, 464-473.))

Myth: Agile Doesn’t Work for Large Products

Myth: Agile Doesn’t Work with Distributed Teams

Truth: Google’s AdWords product busts both of these myths.  With 20 teams and 140 people across 5 different countries, this large agile program was a groundbreaking success at Google and resulted in more predictable releases, higher quality, and an improved ability to accommodate changes, as compared to the prior methodology in use.

(Striebeck, M. (2006). Ssh: We are adding a process. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 193-201)

Myth: Agile Doesn’t Work in the Regulated Telecom environment

Truth: British Telecom moved their entire IT department to agile, starting with 2000 people from 2004-2007.  This large transformation resulted in an improvement from 10% value stream effectiveness to 55%, created an attitude of delivering real value to the business through IT, and shifted the company’s perception of IT from a service provider to an integral part of the business solutions.

(http://www.agilistapm.com/casestudy-british-telecom/. http://scalingsoftwareagility.files.wordpress.com/2008/06/scrumbt-v14.pdf)

Myth: Agile Doesn’t Work for Client-based projects

Myth: Agile Doesn’t Work for Fixed Price projects

Myth: Agile Doesn’t Work well when integrating a Third Party Product

Truth: I coached an agile team at a prominent consulting company through a project with a client who was a well known record label.  They built a new, fully rebranded, eCommerce website using open source CMS and Search engine, and a third party eCommerce provider.  The site included product bundling, integrated music player, and social networking integration.  It was implemented using Scrum/XP with a single team of about 12 people over 5 months.  The result was an award-nominated site that improved conversion rates dramatically, ultimately profitable for and considered a strong success for both the agency and the client.

Myth: Agile Doesn’t Work for Manufacturing Vehicles

Truth: Wikispeed developed a 4 passenger, 100 mpg, street-legal road car in 3 months using modular, off-the-shelf, carbon-fiber body construction, with no capital investment, and no paid employees.  Agile processes were utilized with a single international team.  The project went beyond the prototype phase and cars are available online.

(http://www.solutionsiq.com/the-agile-ceo/bid/51480/Agile-Innovation-or-How-to-Design-and-Build-a-100-MPG-Road-Car-in-3-Months)

What else ya got?

(note: leads for some of these case studies came from David Rico’s presentation on Lean & Agile Project Management for Large Programs & Projects)

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

Step 1. Lead from the front using the leader part of servant leader. Use this when the team is lost, going off the rails or about to run back into the burning barn of traditional project management.  As soon as the team gets their bearings, starts being honest with themselves, or chooses not to get burned again, move immediately one step back and to the side.

Step 2. Coach from the side. Be there on the sideline giving support, offering suggestions and providing guidance. Shift to Socratic method.  Once the team gets their confidence back, take another step back, moving behind the team.

Step 3.  Mentor from the rear.  look for patterns, learn how the team(s) are moving ahead through their challenges so you can lead them when they ask for help.  Remember you are now a firemen always ready to go when the team rings the bell.  When you get to the fire you’ll know which steps to take.

Brian Bozzuto, principal Agile Coach at BigVisible

The session will cover:

• The critical role project managers can play in helping agile projects succeed
• Growing popularity of agile within the PMI including agile certifications such as the Agile Certified Practitioner (ACP) and the Agile Community of Practice
• The impact of agility on organizations as they embrace agile practices across the enterprise

Bob Fischer, Agile trainer, coach, facilitator, and change agent at BigVisible

This presentation will cover:

• The role of a manager in an agile organization
• The role of a transition team supporting the transition to agile
• Bring your questions. This will be an interactive session where you’ll get the chance to address your specific concerns.

The PMI Mass Bay Chapter is one of the largest in the United States, and in the top 6% of all chapters worldwide by size with over 2,300 members, including over 1,500 certified Project Management Professionals (PMP®).

Find out even more information about BigVisible at the PMI Mass Bay Chapter Meeting.

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

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

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

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

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

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

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

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

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

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

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

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

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