Clash of Cultures

     I’ve had the opportunity to work in some interesting business environments in the last couple of years. What made them interesting was the partnerships of multiple organizations with different cultures striving towards common goals.  As an Enterprise Coach, it is part of my role to help these organizations navigate these cultural differences. These differences often exhibit themselves in obvious and sometimes mundane ways.

     In one instance, where Company A had hired Contractor B to deliver a program of projects, Company A was interested in transparency and the use of Big Visible Charts.  They believed that broadcasting the true state of affairs was a valuable communication mechanism and helped everyone understand not only our successes but where problems existed and thus where priorities could be found.  Management of Contractor B on the other hand was very concerned about displaying any information that could be construed as negative.  They were only interested in broadcasting positive news.  They feared that the broadcast of problems or perceived failures would be a drag on morale.

     Interestingly (and possibly related), these same organizations also had vastly different meeting cultures.  Company A was protective of their peoples’ time.  Meetings were scheduled only when required participants were available and there was rigour around responding to meeting invites in order to make the best use of everyone’s time.  Company B had a culture where meetings were scheduled regardless of whether required participants were already booked.  Further, people who were double or triple booked then selected the meeting they would attend in real-time.  This resulted in the meeting organizer never really knowing who would show up for the meeting until it occurred.

     These cultural difference have a marked effect on the ability of the companies to work together effectively.  So what to do?  Well, the first step is to identify the differences; accept that these differences are likely ingrained.  The second step is to refrain from trying to shift one company to the other’s culture; instead start the process of creating a new culture for the combined team.  The third step is to engage the team in a discussion of how best to address these differences for the good of the projects.  The fourth step is to establish working agreements in these areas, explicitly agreeing to review and adjust those working agreements as the team discovers new situations.  As with every working agreement, it’s important that everyone model the agreed upon behaviors and be willing to hold each other accountable to these agreements.

     While these kinds of cultural differences often occur between organizations, they also occur between different departments, groups, and teams within a single organization.  Can you recognize those differences within your organization?

Don't Underestimate the Power of the Backlog

While there is no doubt that agility, at its core, requires a shift in mindset, one of the key tools used alongside that mindset (and apart from the retrospective) is the ‘Product Backlog’.  In software development this backlog is supposed to represent all of the business problems that a product is designed to solve.  By prioritizing and sizing the items in the backlog, agile teams always have an idea of what the next most valuable item is to work on.  This practice helps the team accrue value in the product as quickly as is practical.  Teams using Scrum select some highest priority subset of the remaining product backlog to work on in a given sprint.  The result of the sprint is ideally a product increment which solves the problems described by the backlog items.  The team then selects the next highest priorities and continues sprint by sprint until enough value has been accrued to warrant releasing a version of the product.

When applying the values and principles of Scrum outside the domain of software development, this backlog remains an important companion tool.  Depending on the domain, it may or may not be called a Product Backlog, but it remains a list of problems that represent a body of work (with an overall goal) and those problems are prioritized by value.  There may or may not be a need to size them, again depending on the domain and how the work is being managed.

Some examples of using this technique outside of software follow.

Goal: Create the organizational infrastructure for the management of a construction project.

When a team was tasked with setting up the organizational infrastructure necessary to manage the engineering, procurement and construction of a natural gas plant, they used a Mind Mapping technique to articulate the problems that needed to be solved (nodes) by the infrastructure and their root causes (sub-nodes).  Subsequently the team created a backlog of those problems and their common solutions.  The priorities were estimated simply by using the frequency by which the same root causes appeared as sub-nodes throughout the Mind Map.

The ‘Backlog’ in this case consisted of the problems to be solved. During each successive sprint, the problems were solved by a multidisciplinary team working on tasks related to creating, reviewing and approving the required artefacts to address the problems.

The ‘Product Increment’  in this case was an increment of functioning organizational infrastructure.

Goal: Help a team meet milestones required to meet a construction schedule.

When a multi-discipline team was tasked with meeting a series of milestones in a traditional project schedule, they identified which milestones they believed would be most difficult to meet based on empirical evidence.  The priorities were estimated based on the overall impact of missing those milestones.

Here, the ‘Backlog’ consisted of the problematic milestones to be reached and during each successive sprint the problems were solved by a multidisciplinary team working on tasks related to finding new solutions to those problems.  The team used a Breakdown/Breakthrough process  for each of those problems, therefore sprint tasks were related to discussing the problem, arriving at a novel solution, and implementing process or artefact changes to complete the deliverables on time.

The ‘Product Increment’  in this case was the successful completion of the deliverables according to the project schedule.

Even in the world of traditional project management, the power of the backlog is strong.  Can you see where you could define a ‘product backlog’ and a ‘product increment’ that fits your situation?

Scrum Alliance - Progress on Transforming the World of Work

I’m a Scrum coach.  I like to think that I help people, teams, and organizations change the way they connect with their work, think about their work, and function.  I have chosen to do this under the auspices of the Scrum Alliance as a Certified Enterprise Coach.  One of the things that drove me to do this was the mission of the Scrum Alliance - Transforming the World of Work.  I am passionate about this mission and have dedicated my career to this endeavour.  I believe that many people toil in disengagement and dissatisfaction within their work environment.  I believe this harms both the individuals and the organizations for whom they work.  I believe there is a better way.  I believe we are uncovering better ways of working.  I believe Scrum is a framework that fosters that discovery. 

I assume that in order to really transform the world of work on a significant scale, we will need a critical mass of people with enough understanding and experience demonstrating and living the values of Scrum  The relatively low number of Certified Scrum Professionals and Certified Team Coaches could indicate that we are failing to reach this critical mass.  Anecdotally we see and hear that there are not nearly enough people in the world who understand and execute the values and principles within the Scrum framework.  So our anecdotal evidence appears to match the data.

I suspect that not enough people are interested in CSP certification and beyond because they don’t see a compelling reason for it.  If there was value, people would seek it out.  So how could it be more valuable? 

One approach might be to think about certifying organizations in Scrum.  That organizational certification might include some critical mass of CSP’s and/or CTC’s.  Customers of those organizations would have some assurances that their vendors were actually proficient in the use of Scrum.  The organizations themselves would then need to have CSPs and beyond as part of their organization which would lead to individuals seeking out CSP certification.  This would provide some impetus for individuals to continue their learning and it could provide some organizations with a competitive advantage.

I believe we are missing something in not helping address the needs of these organizations’ customers.  Isn’t this all supposed to be about delighting the customer?   I believe we should direct our Scrum awareness marketing activities in a much broader context.  We need the customers of the organizations that use Scrum to see the value of Scrum and WANT their products developed using Scrum because they value their involvement and the inherent innovation.  It is through the awareness of the customers that we’ll see acceleration in the adoption of Scrum.

Catalytic Poisoning; Coaches and Chemicals

As an agile coach, my purpose is to help people, teams, and organizations transform the way they think about their work and how they function as an organization. My role serves as a catalyst in these transformations, asking questions and inspiring clients to create their own new thinking. As with any change involving people, this does not happen overnight. These transitions can take several months to several years, and I’ve been considering how my coaching perspective is affected in these long term engagements. 

In considering this, I was reminded of another type of “catalyst” I learned about in school. In the world of chemical transformations, tiny amounts of a substance can be introduced to a reaction to increase the speed of a transformation and decrease the amount of energy required for the transformation to take place. These substances are called catalysts and they are usually unaffected by the chemical reaction taking place around them.

If you are a regular reader, you know I am a big fan of analogies from other aspects of life. This one was pretty clear to me when I happened upon it. When added to a new or already existing agile transformation, a coach’s mission is to increase the speed of a transformation and decrease the amount of overall energy required for the transformation.

However, catalysts (whether chemicals or coaches) can occasionally be inhibited, deactivated, or destroyed by secondary reactions.  Some secondary processes cover a catalyst in bi-products (see my previous post on Scaling) and inhibit the effect of the catalyst.  If that inhibiting effect is permanent, it is known as ‘poisoning’. It is important that coaches remain vigilant to recognize the risk of this, and prevent it.

During a long term engagement with a client, it is inevitable that relationships form, biases shift, and as a result, dysfunctional patterns can emerge.  As coaches we are trained to avoid these pitfalls, yet we are human. While my objectivity is often desired, it is my subjectivity that is often required in order to be an effective coach. I need to connect with people.  I need to understand them--- their fears, their motivations, their relationships with their teammates.  As time marches on, making these connections can occasionally draw me into situations where I risk losing my coaching stance and perspective.  Occasionally, my investment in the outcome of the work can become more important to me than the means to accomplish it.

In a recent example involving multiple teams, multiple companies, and multiple cultures over an 18 month period, my catalytic effect had deteriorated immensely to the risk of being poisoned.  My ability to affect the teams and organization through coaching was handicapped.  After recognizing this, I introduced a person to the transformation with different experience, different perspective, different history, and different relationships.  This had the two-fold effect of re-energizing the transformation---and opening space for another catalyst leader.  People and teams were able to better learn for themselves by being involved in new and meaningful conversations, and I too was encouraged by this new energy.  I’ve had some limited experience with paired coaching and this example has led me to believe there is likely tremendous value in utilizing that concept in large transformations.

Knowing when you, as a catalyst, have been inhibited is one of the many coaching skills necessary to ensure that your clients’ transformations continue to evolve.  I suspect the risks increase more for in-house coaches rather than consultants, but I'd like to hear what you think.

An-Isotropic Scaling

In the vernacular of my former career as a metallurgist, 'scaling' is defined as 'the accumulation of unwanted material on solid surfaces to the detriment of function'.  Over the last year or two, I've been amused by the discussions around scaling in agile environments and the applicability of that definition.  There are many, although not all,  in the agile community who might define scaling as 'the accumulation of unwanted process and overhead on solid teams to the detriment of their function'.

In metallurgy, there is the notion of isotropic vs an-isotropic scaling.  That is, the difference between uniform scaling and non-uniform scaling.  It is natural to visualize scaling anything uniformly along all axes.  When we look at a picture, we think in terms of increasing or decreasing it uniformly in all directions, resulting in a larger (or smaller) version of itself.  Sometimes we use uniform scaling and fix the ratio of expansion or contraction along the axes to match the original and maintain a shape.  However, there are situations where the reason for scaling actually dictate non-uniform scaling; the bigger picture isn't the goal, rather increased utility or performance at a different size is the goal.  I believe that to be the case with scaling an agile organization.

Isotropic scaling of an existing system can very often lead to expansion (or contraction) in unnecessary areas and not enough expansion (or contraction) in others for the desired effect. 

Very often, expansion within an organization requires growth at different rates-- and in different directions.  This is precisely the definition of an-isotropic scaling. Further, it’s quite possible that the expansion in one area actually requires a contraction in others for the system to be effective.  Rather than focusing on keeping the shape of the organization intact through uniform scaling, it might be helpful to recognize that  non-uniform scaling, by definition, changes the shape of an organization.

Too often, expansion is seen as the solution to problems- problems that would actually benefit from contraction. A classic example is the notion that we need to increase the number of support teams to handle increasing numbers of customer support issues.  Using a systems thinking approach, the real solution to this problem is to uncover the cause of growth in customer support issues and address that, rather than expanding to handle the symptoms.

When we are scaling an organization, we need to identify what problem we are trying to solve.  Are we trying to coordinate existing and additional teams for some form of consistency (perhaps architectural or technological)?  Are we trying to increase the throughput of the organization in terms of different products/services delivered?  The specific solutions to those scaling issues may depend on the maturity of leadership, teams, products or portfolio management, and will likely require growth at different rates in each of those.  With mature products and teams, perhaps it is simply the portfolio management system that needs to scale up.  With mature leadership and products and services, perhaps it is only the teams that need to multiply.  Without taking into consideration the people and their relationships, it is very possible that process and overhead will be added to the detriment of an already well functioning part of the whole.  As many organizations consider people simply ‘human resources’ within a process, it is too easy for those organizations to ignore the human part of growth or contraction.

There are, of course, instances where isotopic growth is required.  When we are considering the increase in capacity for software delivery, there is often a desire to ‘hire developers’ to accomplish this.  In this case, the increase in capacity usually needs to be isotropic (perhaps with fixed axes); adding developers, testers, Scrum Master, Product Owner. Adding developers alone doesn’t increase capacity, adding multi-discipline teams increases capacity.

An agile mindset keeps us focused on inspecting and adapting based on a clear understanding of what problem we are trying to solve.  Scaling an agile organization is no different; we need to keep focused on the problem we are trying to solve, rather than simply uniformly scaling a system that works in its current situation.


Coaching Symbiosis

I had a conversation with a colleague the other day about coaching.  She'd asked what I got out of coaching; what was fulfilling about it.  Perhaps I hadn’t seriously pondered this question before.  More likely it was that I hadn’t ever been asked to speak the answer.  It took longer than I was comfortable with to be able to respond to this question.  How could I have devoted my career to this vocation and not be able to quickly explain why?  Eventually a stream of thoughts came to mind in a burst.

It's about experiencing unique people.

It's about experiencing a myriad of situations.

It's about learning what is important to people.

It's about watching ordinary people do great things.

It's about watching great people do great things in their own way.

It's about listening to someone respond in a way you hadn't thought of before.

It's about listening to how people respond to you and learning where that comes from.

It really felt like a dam had burst.  I had lost touch with these reasons and suddenly they had come bubbling to the surface again for me to hear and feel.  It felt urgent to say these things.  Urgent, because perhaps if i didn’t say them quickly enough they might be lost again.  Hearing myself say these things reminded me viscerally of why coaching matters to me.  Getting lost in the quest for results and the ‘end from the means’ had dulled my senses to why I chose this path.  There are many reasons to choose a career and ideally those reasons converge on what fulfills you.  Over the past several years, perhaps I have let them diverge.

Coaching is the art of guiding people to discover for themselves what’s getting in their way and how to overcome that interference.  That is an unending journey for both parties, and if you're not learning from the people you work with, you're probably not coaching.

Musical Scales

Having spent years playing in musical ensembles, I’ve recently considered the similarities between 'scaling' musical groups and other types of teams.  For the listener (the customer), the value in scaling musical groups is in the increased variety of instruments and their associated interactions and dynamics. But what is the experience of scaling like for the musicians?

The most personally rewarding musical ensembles I've played in were small groups of 2-4 people, where the interaction with each other was constant and immediate. We would sit together in a configuration that allowed us all to see each other without anyone having their back to the audience. It was important that we could make eye contact with each other, breathe together, and take cues from one another. The notation on the page is only the framework to create music.  The nuances within that framework and the interpretation of that framework are where the music lives.   It was a joyful experience to anticipate each other's timing and intonation based on our history and immediate body language. We respected each other's abilities, and reveled in our mates' individual contributions to an overall musical experience. All of this took practice, time, and passion.

As a member of a symphony orchestra (50-70 people), the situation changed significantly.  Once again we all played from the same score, had similar (but not identical) aural interactions, and our visual interactions were still limited by proximity to others.  We took cues from other players in our section and from the conductor. The orchestra's seating arrangement involved 'sections' of like instruments arranged in a semi-circle around the conductor.  If you were at the front of your section, you could take cues from people at the front of other sections.  If you were at the back of your section, you took cues from the people in front of and beside you.  The quality of the music produced was defined not only by the underlying score-- but the ability of the large group of musicians to be collectively in time, dynamically aligned, and in tune with that score.   The conductor was responsible for interpreting the score emotionally and showing the orchestra the timing/dynamics necessary to express that emotion.  A significant amount of time was spent keeping an eye on the conductor, especially when there were complex musical interactions.  The conductor faced the orchestra, back to the audience, and was the unifying force behind the music.  

I love watching and listening to people who are exceptional at their craft. The highlight of orchestral work for me was experiencing soloist performances against the backdrop of the rest of the orchestra. The soloist was the star of a moment, with the orchestra playing a supporting role. If we were in perfect unison  (intonation, timing, dynamics) the resulting effect was magnificent.

While the powerful music created by orchestras can be divine, I’m still drawn to creating music in duets, trios, and quartets.  Why?  I can only surmise that for me, it’s about the symbiotic and continuous exchange with people I trust and admire. The arrangement of a symphony  orchestra is strikingly similar to many traditional organizational structures.  Can you see how and why?  Do you see similarities to the way your department, division, or company functions?  What could you and those around you do differently to shift the experience closer to that of a quartet?  Let me know -  @snowdolphin



Mindset over Mechanics

Recently I had the good fortune to attend the Global Scrum Gathering in Orlando, Florida (#SGFLA).  The stated theme of the gathering was "Transforming the World of Work".  A strong undercurrent amongst participants was that while Scrum has helped incrementally improve many teams and organizations, so much more could be achieved. 

What's missing? 

As a community we've been all too focused on the mechanics of Scrum.  Despite subscribing to the Agile Manifesto's primary value of "Individuals and Interactions", we've somehow placed more focus on the other 3 values; maybe because they're easier.  At the gathering, I participated in many conversations centred on the need for being agile (rather than doing agile) and being agile hinges on having an agile mindset.  Helping individuals, teams, and organizations achieve an agile mindset should be our FIRST priority. 

Without that shift in mindset realized, I've witnessed and willfully participated in the decay of many agile transitions based in mechanics. To be clear, mechanics ARE important, but in the spirit of the Agile manifesto we value agile mindset more.  As Steve Denning stated in his recent review of HBR's 'Embracing Agile':

"Agile isn’t just a methodology to be implemented within the existing management framework. Agile is a dramatically different framework for management itself."

"If managers themselves see Agile as “methodologies for their employees” to be deployed like any other management methodology, the chance of strong sustainable Agile implementation with full benefits is remote. Getting the full value of Agile depends on managers themselves consistently embodying the Agile mindset in all their own words and actions."

A significant part of the role of any coach is to focus on mindset.  By focusing first on mindset, the mechanics are much more likely to come naturally and continue to evolve.  Agile is, after all, a journey not a destination.  During the gathering, at Michael Sahota's workshop on Reinventing Organizations, he said: "The consciousness of the change approach limits the outcome."  Effectively, without helping change the mindset and consciousness (=culture!) of the people and organizations we work with, our efforts to transform the world of work will never achieve their potential. The engineer in me is reminded of a quote often attributed to Albert Einstein "Problems cannot be solved with the same mind set that created them."  Quantum mechanics may be much more complex than Scrum mechanics, but the need for a different mindset to see their true value remains the same.

What's the mindset of the people in your organization?

The E-Mail Iron Triangle

In traditional project management the axes of success are usually denoted as cost, scope, and schedule.  This is often known as the 'iron triangle' as it was once believed that if one thought about it long enough (and estimated accordingly), each of these 3 axes could be fixed.  These days most sane projects are executed with an understanding that, at most, 2 axes can be fixed. 

The farther that communication is removed from face-to-face interaction the less effective that communication is.  For numerous reasons, face-to-face is better than telephone; telephone is better than texting; texting is better than email.  Co-locate where possible!  Yet, due to geographical distribution of companies, their teams, and their customers the need for this type of communication is unavoidable.  The cost of that decrease in effectiveness is rarely taken into account at the project level.  Let's consider the concept of the 'iron triangle' in the context of the use and proliferation of email communication on projects:


As projects progress, people are involved in communicating via email at different frequencies and urgencies and for different purposes.  These email volumes (some portion of the scope of our work) are always underestimated and perhaps most puzzlingly, are not considered by some to be actual 'work'; they're considered something separate.  In the Creative Economy of knowledge work,  email is unfortunately a huge part of the work.  Solving problems requires collaboration and the exchange of ideas and if we choose to have these conversations asyncronously (for whatever reason) through email then we must accept that we are working at an often reduced velocity.  In order to maintain a level of thoughtfulness in engaging in these asyncronous conversations, we each have a volume threshold beyond which the quality and timeliness of our responses will suffer.


The cost of 'keeping up' with the ever increasing volumes of email usually results in:

  • a decline in the quality / timeliness of the work,
  • an increase in the stress of the people involved,
  • the realization that the work needs to be subdivided and additional people involved, or
  • the realization that less people need to be involved in the work

As email volumes increase unhindered, the cost can only increase.


As email volume increases, the ability to respond meaningfully in a timely manner decreases.  This leads to people trying to multi-task by responding to emails amidst other communication mechanisms like meetings/ teleconferences. This in turn reduces the quality of at least one and likely all of those communication mechanisms.  Often an illusion of responding in a timely manner only creates churn due to incomplete answers or incompletely thought through responses.  People need time to communicate effectively.


So if scope increases beyond a threshold, cost and/or schedule will increase.  Most people have exceeded their threshold. That threshold can only be avoided by taking a hard loo at working communication agreements, communication conventions, and individual systems tailored to each person's working style.  Until these true costs are effectively considered on projects, the E-Mail Iron Triangle will remain fixed along all three axes and people, teams and organizations will continue to suffer the consequences.

How can you tell if your threshold for email has been exceeded?  Some symptoms are:

  • feeling the need to respond to email while doing something else
  • having to respond to an email multiple times because you didn't give it the time it deserved initially
  • hearing yourself say on any given day "I haven't caught up to my emails from yesterday yet"
  • feeling like you may have missed an email, but you're not sure because you have so many (unread or read) cluttering your inbox.

If you've experienced these symptoms,  you, your team, and your organization probably need to examine which two axes of the email iron triangle you want to anchor and which you're prepared to let float.

To the Moon!

Iterative / Incremental delivery to get to the Moon.

During a recent trip to Houston, Texas I was fortunate enough to visit the NASA Johnson Space Centre. The Apollo program was designed to land humans on the Moon and bring them safely back to Earth.  I believe this achievement to be one of the greatest engineering feats in history but it had never dawned on me to think about how it was achieved.  It was while I was visiting NASA that I realized that Apollo Missions 7,8,9,10 and 11 were used iteratively and incrementally to achieve this goal.  The list of problems necessary to be solved to achieve the ultimate goal might have looked (simplistically) something like this:

  • Leave the Earth’s atmosphere
  • Enter Earth orbit
  • Orbit the Earth
  • Travel to the Moon
  • Enter Moon orbit
  • Orbit the Moon
  • Land on the Moon
  • Re-enter an orbit of the Moon
  • Travel to the Earth
  • Orbit the Earth
  • Land on the Earth

 Each of these problems had sub-problems associated with them and in software development we might associate these with Epics and their composite Stories.  Also note that extensive future mission improvements were made by using retrospectives after each mission.  I’ve highlighted the Epic/Stories addressed during each mission and I have extracted the descriptions of each mission from:

As you’ll see the problems were solved iteratively and incrementally until the only problem left to solve was the actual landing on the lunar surface.

Apollo 7

  • Leave the Earth’s atmosphere
  • Orbit the Earth
  • Travel to the Moon
    • Mid-course corrections
  • Orbit the Moon
    • Communications on the far side of the moon
    • Undock LM from CSM (simulation)
  • Land on the Moon
    • LM descent
    • LM land
  • Re-enter an orbit of the Moon
    • LM ascent
    • Dock LM to CSM (simulation)
  • Travel to the Earth
  • Orbit the Earth
  • Land on the Earth

The primary objectives for the Apollo 7 engineering test flight were simple: Demonstrate command and service module (or CSM) and crew performance; demonstrate crew, space vehicle and mission support facilities performance during a crewed CSM mission; and demonstrate CSM rendezvous capability.

The S-IVB stayed with the CSM for about 1 1/2 orbits, then separated. Schirra fired the CSM's small rockets to pull 50 feet ahead of the S-IVB, then turned the spacecraft around to simulate docking, as would be necessary to extract an LM for a moon landing. The next day, when the CSM and the S-IVB were about 80 miles apart, Schirra and his crewmates sought out the lifeless, tumbling 59-foot craft in a rendezvous simulation and approached within 70 feet.

Cunningham reported the spacecraft lunar module adapter panels had not fully deployed, which naturally reminded Thomas Stafford, the mission's capsule communicator, or capcom, of the "angry alligator" target vehicle he had encountered on his Gemini IX mission. This mishap would have been embarrassing on a mission that carried a lunar module, but the panels would be jettisoned explosively on future flights.
The Apollo vehicle and the CSM performed superbly. Durability was shown for 10.8 days -- longer than a journey to the moon and back.

Three of the five spacecraft windows fogged because of improperly cured sealant compound, a condition that could not be fixed until Apollo 9. Visibility from the spacecraft windows ranged from poor to good during the mission.

The CSM's service propulsion system, which had to fire the CSM into and out of the moon's orbit, worked perfectly during eight burns lasting from half a second to 67.6 seconds. Apollo's flotation bags had their first try out when the spacecraft, considered a "lousy boat," splashed down in the Atlantic southeast of Bermuda, less than 2 kilometers from the planned impact point. Landing location was 27 degrees, 32 minutes north, and 64 degrees, four minutes west. The module turned upside down, but when inflated, the brightly colored bags flipped it upright.

Apollo 7's achievement led to a rapid review of Apollo 8's options. The Apollo 7 astronauts went through six days of debriefing for the benefit of Apollo 8, and on Oct. 28, 1968, the Manned Space Flight Management Council chaired by George Mueller met at the Manned Spacecraft Center, investigating every phase of the forthcoming missionThe tired, but happy, voyagers were picked up by helicopter and deposited on the deck of the USS Essex by 8:20 a.m. EDT. Spacecraft was aboard the ship at 9:03 a.m. EDT.

Apollo 8

  • Leave the Earth’s atmosphere
  • Orbit the Earth
  • Travel to the Moon
    • Mid-course corrections
  • Orbit the Moon
    • Communications on the far side of the moon
    • Undock LM from CSM
  • Land on the Moon
    • LM descent
    • LM land
  • Re-enter an orbit of the Moon
    • LM ascent
    • Dock LM to CSM
  • Travel to the Earth
  • Orbit the Earth
  • Land on the Earth


The mission objectives for Apollo 8 included a coordinated performance of the crew, CSM, and the support facilities. The mission also was to demonstrate translunar injection; CSM navigation, communications and midcourse corrections; consumable assessment; and passive thermal control. The detailed test objectives were to refine the systems and procedures relating to future lunar operations.

The first midcourse correction occurred at about 10 hours, 55 minutes into the mission and provided a first check on the service propulsion system, or SPS, engine prior to committing spacecraft to lunar orbit insertion. The second and final midcourse correction prior to lunar orbit insertion occurred at 61 hours, 8 minutes, 54 seconds.

Loss of signal occurred at 68 hours, 58 minutes, 45 seconds when Apollo 8 passed behind the moon. At that moment, NASA's three astronauts became the first humans to see the moon's far side.

During the 20-hour period in lunar orbit, the crew conducted a full, sleepless schedule of tasks including landmark and landing site tracking, vertical stereo photography, stereo navigation photography and sextant navigation. At the end of the 10th lunar orbit, at 89 hours, 19 minutes, and 16 seconds, a three-minute, 23-second trans-Earth injection burn was conducted, adding 3,522 feet per second. Only one midcourse correction, a burn of five feet per second conducted at 104 hours, was required instead of the three scheduled.

Apollo 9

  • Leave the Earth’s atmosphere
  • Orbit the Earth
  • Travel to the Moon
    • Mid-course corrections
  • Orbit the Moon
    • Communications on the far side of the moon
    • Undock LM from CSM
  • Land on the Moon
    • LM descent (simulated)
    • LM land
  • Re-enter an orbit of the Moon
    • LM ascent (simulated)
    • Dock LM to CSM
  • Travel to the Earth
  • Orbit the Earth
  • Land on the Earth

The primary objective of Apollo 9 was an Earth-orbital engineering test of the first crewed lunar module, or LM. Concurrent prime objectives included an overall checkout of launch vehicle and spacecraft systems, the crew, and procedures. This was done by performing an integrated series of flight tasks with the command module, or CM, the service module, or SM, the joined command and service module, or CSM, the LM and S-IVB stage while they were linked in launch or various docked configurations, and while they were flying separate orbital patterns. The LM was to be tested as a self-sufficient spacecraft, and was also to perform active rendezvous and docking maneuvers paralleling those scheduled for the following Apollo 10 lunar-orbit mission.

The flight plan's top priority was the CSM and LM rendezvous and docking. This was performed twice - once while the LM was still attached to the S-IVB, and again when the LM was active. Further goals included internal crew transfer from the docked CSM to the LM; special tests of the LM's support systems; crew procedures; and tests of flight equipment and the extravehicular activity, or EVA, mobility unit. The crew also configured the LM to support a two-hour EVA, and simulated an LM crew rescue, which was the only planned EVA from the LM before an actual lunar landing.

The LM descent and ascent engines fired on orbital change patterns to simulate a lunar-orbit rendezvous and backup abort procedures. The CSM service propulsion system, or SPS, fired five times, including a simulation of an active rendezvous to rescue an LM that had become inactivate.

After separation of the CSM from the SLA in Earth orbit and jettison of the SLA's LM protective panels, the CSM was to transpose position and dock with the exposed LM. The docked modules were to separate and the spacecraft was to adjust its orbit 2,000 feet away from the S-IVB stage. The S-IVB engine was then to restart twice, placing the stage in an Earth-escape trajectory and into solar orbit. This would simulate a translunar injection of the stage for Apollo 10 and subsequent lunar missions. Other objectives included the multi-spectral photographic experiment for subsequent crewed spacecraft.

Apollo 10

  • Leave the Earth’s atmosphere
  • Orbit the Earth
  • Travel to the Moon
    • Mid-course corrections
  • Orbit the Moon
    • Communications on the far side of the moon
    • Undock LM from CSM
  • Land on the Moon
    • LM descent
    • LM land
  • Re-enter an orbit of the Moon
    • LM ascent
    • Dock LM to CSM
  • Travel to the Earth
  • Orbit the Earth
  • Land on the Earth

The Apollo 10 mission encompassed all aspects of an actual crewed lunar landing, except the landing. It was the first flight of a complete, crewed Apollo spacecraft to operate around the moon. Objectives included a scheduled eight-hour lunar orbit of the separated lunar module, or LM, and descent to about nine miles off the moon's surface before ascending for rendezvous and docking with the command and service module, or CSM, in about a 70-mile circular lunar orbit. Pertinent data to be gathered in this landing rehearsal dealt with the lunar potential, or gravitational effect, to refine the Earth-based crewed spaceflight network tracking techniques, and to check out LM programmed trajectories and radar, and lunar flight control systems. Twelve television transmissions to Earth were planned. All mission objectives were achieved.

Apollo 11

  • Leave the Earth’s atmosphere
  • Orbit the Earth
  • Travel to the Moon
    • Mid-course corrections
  • Orbit the Moon
    • Communications on the far side of the moon
    • Undock LM from CSM
  • Land on the Moon
    • LM descent
    • LM land
  • Re-enter an orbit of the Moon
    • LM ascent
    • Dock LM to CSM
  • Travel to the Earth
  • Orbit the Earth
  • Land on the Earth

The primary objective of Apollo 11 was to complete a national goal set by President John F. Kennedy on May 25, 1961: perform a crewed lunar landing and return to Earth.

The last problem to be solved was the actual landing on the moon.  In the series of Apollo missions, all other problems had incrementally been shown to be solved.

What's in a Title?

Much is made about the title of 'Project Manager' and the need (or not) for that position in agile software projects.  I've always felt that the role of Project Manager is different than the role of a Scrum Master even though the roles are often attempted to be filled by the same person.  While there may be some overlap in the roles, the Scrum Master is generally focused internally toward the team and the Project Manager is often focused on activities that affect the team but are external to the team.  A Scrum Master would be focused on guiding the team through the Scrum framework, helping the team improve their effectiveness, and removing impediments for the team.  A Project Manager is often tasked with ensuring that regardless of what is transpiring within the team, the team is aligned with current corporate protocols and constraints.  Ideally, of course, the entire organization is using an agile mindset and the role of Project Manager is subsumed by that of Scrum Master. In reality, at least as a transitional move, the two roles are still required during the early stages of an agile transformation.

The role of Product Owner and/or Manager on a sofware project should have the responsibility for making all the business decisions related to scope, budget and schedule because they are supposed to have the most understanding of the value created and the business priorities for the marketplace.  Other members of the team (and indeed of the organization) may have different opinions but it is the role of the Product Management discipline to make product business decisions.

In Oil and Gas Facilities construction, the Project Manager is the arbiter of ALL of those same business decisions.  It is from the roots of construction/manufacturing that software development took its first organizational steps and so it is not surprising that the title of Project Manager has been confused.

The Satir Interaction Model and Hand Reading in Poker.

Essentially the Satir model involves processing of communication via several steps: Intake, Meaning, Significance and Response. Teaching yourself to be disciplined about progressing through these steps helps greatly with minimizing miscommunication. The idea is that whenever you receive information (e.g. someone engages you in conversation) that you ask yourself the following questions before responding:

  • What did I just see and/or hear (sometimes, smell, taste, touch)?
    • The facts.
  • What does it mean?
    • Possible interpretations based on context.
  • How did it make me feel?
    • Significance based on my mindset
  • How should I respond?

Poker is a game of communication; telling a story based on the movement of chips in relation to the exposure of community cards.  Perhaps the Satir model is useful in reading opponents' hands in a NLHE tournament, street by street. Here's a pre-flop example:

  • What did I just see (action)?
    • A player with the table chip lead opened to 2.5x from middle position and there is a short-stacked player in the big blind with 8 big blinds remaining.  The action folds to me in the small blind.
  • What could it mean (ranges)?
    • What ranges of hands could these facts represent? Based on previous hands shown down and activity, the raiser is likely to have any: suited connector 89+, pair 22+, or A10+.  The big blind may be prone to shove all of their chips in the middle as a re-raise with any suited ace, any pair, or hands as weak as J10s
  • What is the significance to me (what are my reasonable options)?
    • I'm in the small blind with AQs and 40BB. I'm willing to call a shove from the big blind with this hand but I'll need to exercise some cautioun against the raiser. The raiser must know that the big blind is likely to shove and therefore he's either willing to fold to a shove or is willing to call a shove.  I could re-raise in hopes of isolating the big blind but I would risk playing out of position against the raiser regardless of the raiser's actions.  I could simply call the raise (potentially inducing a shove from the big blind), see what the big blind does, how the original raiser reacts and re-evaluate.
  • Based on all that, what should my response be?
    • I choose to re-raise to 6x.

On further streets, of course, the answer to the first question is additive and ideally the answer to the second question becomes more refined.

Are your opponents analyzing your responses this way?

What a game!

An Agile Mindset in House Construction

New Construction

One of the arguments purporting to negate the logic of agile principles comes from the analogy of building a house.  It is said that no one in their right mind would build a house incrementally - finishing a bathroom, then finishing a kitchen, then finsihing a bedroom etc.   There's no value in the house until the entire house is finished, which is why they are constructed based on task sequence effeciency: all structural followed by all plumbing followed by all electrical etc.

After a conversation with a colleague, Brent Walker, it became clear to me that building NEW software is not analagous to building a house, it's analogous to building a housing subdivision.  The subdivision is a system of houses just as software is a system of functionality.

Developers buy land and install basic infrastructure for the subidivision: roadworks, electrical, and waterworks.  They then build and market houses one at a time to accrue value on their investment, tieing in the basic infrastructure to each house.  They do NOT set out to finish all houses in the subdivision at once when the last finishing task (painting for instance) is completed on all houses.  They serially accrue value one finished house at a time.

In continuing the anaology, the finished software application is the housing subdivision and the incremental valuable story is the house.  Agile principles stress the importance of accruing incremental value by finishing stories one (or a few) at a time as early as possible rather than having them all partially finished at any given time (thus delaying value accrual).  The bedroom or kitchen in any one of those houses is more akin to a task necessary to meet the acceptance criteria of the story.


Many software development projects are similar to house renovations; you want to add value while still accessing the existing value.

In June of 2013 a major (>100 year) flood in our town caused us to consider renovating our basement.  We had to remove the flooring and strip the walls to the studs.  In so doing, we also decided to reconfigure the space from a project room and large common room to two bedrooms and a smaller common room.  Each area to be renovated required some framing, some electrical (lighting), sound insulation in the ceiling, drywalling, mud/taping, painting and cement floor polishing in order to be considered done.

After completing the electrical in all rooms and hanging the drywall in the first bedroom, the question arose as to whether effort should be spent finishing hanging drywall in ALL areas (both bedrooms and common room) before moving on to mud/taping, painting and floor-finishing or whether each room should be taken to completion in series.  Mudding/taping all at once, for instance, would minimize the incidents of mess and dust inherent with the drywalling process.  However, with only 6 weeks until Christmas, the entire basement could not be finished.  It was decided it was more important to have both bedrooms ‘usable’ (drywall hung and providing at least visual barriers) before Christmas to allow for the bedrooms to accomodate likely holiday visitors; the Minimum Marketable Feature given the time constraint.  The state of the common room in-between was less important and therefore effort was not spent hanging drywall in it.  After Christmas, it would be more important to finish the bedrooms prior to the common room even though that would likely require more more instances of drywall dust/mess.

Performing one task across all rooms has the apparent value of being more efficient as there would be less context switching and less instances of disruption but taking that route also DELAYS the principle value of each of the bedrooms; having private spaces ready for use by holiday visitors.

Agile Education

The current 'standard' education system in North America stems from recommendations made in 1892 by the 'Committee of 10', a group of 10 educators headed by the then President of Harvard, Charles Eliot. The recommendations this group made were born of their times, only two decades after the Second Industrial Revolution. The recommendations were heavily influenced by the desire to measure and maximize human performance in a manner similar to that of Taylorism on the manufacturing floor. For instance, the length of any lesson was suggested to be between 52-57 mins as that was the optimal length of time that a worker on the factory floor could reliably perform a mundane task. The goal of the 'education' system was to process as many children as possible in an effecient manner. According to Sharon Friesen:

"Taylor and Thorndike’s models of schooling also defined teacher effectiveness. Relationships between teachers and students were seen as secondary to the importance of teachers managing the class by stressing punctuality, obedience and time on task and delivering information in a timely, efficient manner according to a prescribed schedule established far beyond the classroom. Learning goals were standardized, simple and invariant."

This model might have been effective if all children were created identically, but of course we now know that people learn via different mechanisms (visually, audibly, experientially etc) and can't be treated as a known input to a prescribed process in order to generate a prescribed outcome.

Educators on the forefront of their field, like Sharon, have long understood the need to transform education into a two-way conversation between teachers and students. This transformation does not preclude the need for struggle, hard work, and determination. It simply places emphasis on ensuring that those efforts are directed through consideration of many factors including the particular learning bias of each child and the appropriate environment and level of collaboration suitable for the desired pedagogical outcomes. This can only be arrived at using a mindset of experimentation and 'inspect and adapt' rather than a prescribed 'one-size-fits-all' approach.

At the elementary school that my kids go to, the school council has started an initiative to transform the existing school library into a Learning Commons; a flexible physical and virtual environment where teachers and students collaborate, experiment, and engage in critical thinking on their own and with others. The very nature of education and learning is changing and a key person necessary to help kickstart the change is often a Teacher/Librarian who acts like an Agile Coach; helping the students AND teachers discover new ways of learning, collaborating, and solving problems in an environment and at a pace suitable for the children.


Project grammar

I sometimes wonder if the field of Project Management spends too much time emphasizing management of the noun vs management of the verb.

PROject (n)
A temporary group endeavour undertaken to create a unique product, service or result.

proJECT (v)
To thrust forward.
To estimate or predict based on present data or trends.
To direct one's voice so as to be heard clearly at a distance.
To cause an image to appear on a surface.

Isn't project management really about managing the actions/decisions necessary to achieve a desired outcome?  Focusing on projections of the desired outcome, based on present data or trends, is how we truly manage risk on a project; the risk of shipping the wrong product, the risk of shipping a low quality product, and the risk of shipping late or not at all.  The first key to mitigating these risks, of course, is to ensure that the present data and trends used to make the projections are both valid and valuable.  The second key is to update the present data regularly, accordingly update the projections, and then make decisions.  These concepts describe two of the primary elements of iterative/incremental development.  Successful proJECT management is much more akin to causing an image to appear or hearing clearly at a distance than it is to simply endeavouring to achieve a result.

When you're up to your ass in alligators ...

Most teams use some sort of defect management tool which allows them (and other interested parties) to record defects along with meta-data about the defect such as severity and priority.  Severity is usually an objective value but priority is subjective.  For instance, severity is usually defined in terms like 'High - Results in crash or data loss', 'Medium - Work around available', or 'Low - Cosmetic' etc.  High severity defects are sometimes low priority and sometimes low severity defects are high priority.  For instance, the misspelling of a company name may be low severity but high priority while an application crash generated from a situation that is unlikely to be encountered by the customer may be low priority due to a cost/benefit assessment.  Team members can assign severity but usually only a Product Owner is responsible for assessing the value of addressing (or not) a defect.  This is because usually those people who are responsible for fixing defects are the same as those responsible for adding value via new functionality.  Product Owners need to be able to prioritize the value of fixing a defect against adding new functionality.

When your team is faced with 'draining the swamp' of legacy defects, they must face the need for effective defect prioritization.  The first step in addressing this issue is assessing whether the 'defects' are indeed defects (functionality that does not behave as previously agreed upon by all involved parties) or enhancements (behaviour that has not yet been designed/implemented/tested).  In my view, if the team did not agree that some behaviour was expected, designed, implemented and tested, the behaviour is an enhancement to the current functionality.  Once the enhancements have been distinguished from the true defects, those enhancements can be turned into Stories and prioritized just like any other Story which adds value to the application.  The remaining defects then need to be prioritized in terms of the value they prevent the application from maintaining.  Something of value used to work properly and now does not do so.  How important is that to the success criteria of the product and/or release?

In order to mitigate risk on a software development project, one of the principles of Scrum is that teams try to focus on delivering the next most valuable functionality while keeping the product potentially shippable.  We are to work on the next most valuable functionality in order to insure that if we run out of money or time (and we will) that we have created the most value for the money and time expended.  This should apply in the world of defects as well as enhancements.   Often the difficulty with doing so is that the number of defects in various priority queues are so large that it is difficult to assess whether the team is working on addressing the most valuable defects at any given time.  If 100 defects are denoted as High Priority but we can't address them all in one iteration, which ones shall we address to accrue the greatest value?

In most defect management tools there are usually priority choices like Must Fix, High, Medium and Low.  These classifications are perhaps arbitrary in that the only important thing about them is that each is related to the other by a higher or lower value. However many 'buckets' exist, treating them as static is not an effective mechanism for executing against priority.  Prioritization is a subjective exercise and usually prone to changes based on business conditions and newly reported issues from the field.  To that end, the highest priority queues should constantly be being emptied by the end of any given iteration.  This means that Product Owners must be vigilante about either 'promoting' defects from Medium to High and from Low to Medium (which seems like busy work) or simply limiting the highest priority bucket to a queue size that the team is likely to be able to completely address.  The key here is always making it apparent to the team which defects are the most important to fix in any given iteration.  Very often I see queues of 100's of High priority defects and 10's of Low priority defects.  This is usually the exact reverse of what we'd like to see!  We are much better at managing smaller queues … for instance queues that we can see and contemplate in their entirety.

In order to keep a product potentially shippable at the end of each iteration, some teams adopt a Task Priority list describing a working agreement about the team's default task priorities:
a) Fix any build/install issues (if we don't have a build/install, we can't test)
b) Fix any automated tests (if our tests are broken, we don't know what works and what doesn't)
c) Fix any regression defects (if we have open regression defects then we have likely regressed in value)
d) Fix any current iteration Story defects (standard practice to meet acceptance criteria)
e) Implement new Stories

a) and b) above certainly keep the product from being in a known potentially shippable state while c) keeps the product from maintaining a known value.  Issues associated with d) and e) above are about adding incremental value to already valuable software.  On large multi-team projects, distinguishing those issues keeping the product from being potentially shippable from issues of maintaining or adding value can help with queue size.  For instance Must Fix can incorporate a) and b) while c) can be distributed across High Medium and Low priorities.  Note that in this context, Must Fix is not associated with a value judgement, it is associated with a fairly common Definition of Done that teams use to help them keep a product in a known state.

Of course the best solution to the problem of how to effectively drain the swamp is to prevent the swamp from forming in the first place.

Pragmatic Moneyball

So much of the premise of the movie 'Moneyball' is rooted in the concepts of successful product management leadership.  Once Billy Beane has announced his need (as the General Manager of the Oakland A's) to 'adapt or die', the crux of the solution to his problems rests in discovering the REAL problem.  

After losing their star players to larger contracts offered by richer teams, the scouts and coaches of the Oakland A's begin to discuss how to replace those star players using their standard, time honoured criteria.  When Billy questions their methods the following conversation occurs:   

"We're trying to solve the problem."
    "Not like this you're not. You're not even looking at the problem."
"We're very aware of the problem."
    "OK good, what's the problem?"
"We have to replace 3 key players."
    "Nope.  What's the problem?"
"Same as it ever is, we have to replace these guys with existing players."
    "Nope, What's the problem?"
"We need 38 home runs, 120 rbis and 37 double plays to be replaced."
    "Nope.  The problem we're trying to solve is that there are rich teams and there are poor teams … its an unfair game."

The remainder of the film deals with a product strategy to address the real problem at hand; competing in a league where the payrolls of teams are vastly disparate.  The scouts and coaches were trying to solve the apparent symptoms of the problem but not the problem itself.  The strategy Billy Beane employed is spoken by his assistant, Peter Brand:

"Baseball team owners think in terms of buying players.  Your goal shouldn't be to buy players but to buy wins and in order to buy wins you need to buy runs."  

This product strategy leads to a different way of thinking about what's valuable about a baseball player.  Billy and Peter acquire players whose primary value lies in their ability to get on base (by walk or by hit) and therefore be more likely to score runs.  They are able to ignore other negative factors about those players and as a result acquire players not attractive to the big market teams still using traditional selection criteria.  This in turn allows them to field a competitive team at a fraction of the cost of their competitors' teams.  While not winning the World Series that year, the Oakland A's implementation of this product strategy changed the way Major League Baseball teams managed their teams from that year forward.

Applying the Dreyfus Learning Model to Focus Your Coaching Approach.


Over the past five years, Jaron Lambert (@jaronlambert) and I have helped several companies and dozens of teams transition to agile product development processes.  In working with the myriad of teams and people, we've learned that the best way for us to help people learn agile principles and techniques is to use the Dreyfus Skills Acquisition Model.  This model employs the usage of non-situational rules for novice practitioners.  The adherence to these rules promotes the transition to an advanced stage of learning by providing the student with a foundation for recognizing patterns and principles for application in new situations.  We've discovered (as the model predicts) that skipping this stage of learning can lead to problems absorbing and implementing the philosophies and principles of the agile manifesto.  To that end, Jaron and I have collated a set of rules we have found useful in working with Novice teams.  This is a living collation and we'd be very happy to hear what other coaches and ScrumMasters (or others) think does and does not help their teams' learning process.

Jaron and I will be speaking about the 5 stages of learning that teams traverse (not just Novice) according to the Dreyfus model as they learn agile concepts and philosophies.


  • Co-locate where ever possible, set up your teamʼs space for optimal teamwork.
  • Maximize face-to-face communication; minimize email communication within the team.
  • Minimize distractions. Remove or minimize anything that distracts the team from finishing the work that they committed to (i.e. completing all the Stories in the iteration plan). Inform the Program/Project Manager of any distractions that canʼt be removed directly.


  • The Product Manager is the “messenger of the market” and articulates why we should spend time/money on any development. Product Managers describe what the market needs in a Market Requirements Document (M.R.D) and are responsible for describing those needs in User Stories.
  • Product Managers set the business priority and help define acceptance criteria during iteration planning, answer questions from the team during the iteration, and accept stories before the end of the iteration.
  • Program/Project Managers (Scrum Masters) shepherd the process. They provide the Product Manager with all currently available information so that the Product Manager can make informed and timely decisions. Program/Project Managers answer process questions from the team.
  • Program/Project Managers facilitate removal of any/all roadblocks for the team, ensuring that someone on the team is responsible for any roadblock and keeping track of unresolved roadblocks.
  • All other team members are responsible for delivery: reliably delivering quality software solutions (i.e. implementing stories).
  • All other team members provide the Product Manager with solution options (alternative ways to implement solutions to stories) with associated costs.

Release Planning

  • Review the MRD to ensure that the entire team has an understanding of the goals of the release (i.e. Problems, the users who have them, and the situations under which they have them)
  • Write stories using the template: “As a {persona} I want to be able to {do something} so that {some goal is achieved}”, See “Writing Stories”, Chapter 2 from User Stories Applied by Mike Cohn.
  • Size all the stories in the backlog using a modified Fibonacci sequence (0,0.5,1,2,3,5,8,13,20,40,100). The size of a story represents the overall complexity, difficulty, and effort to complete the story.
  • Add up the story sizes to get the total story points in the release.

Backlog Grooming

  • Product Manager grooms the Release Backlog for their product. They keep it organized and prioritized, and add or remove stories so the Release Backlog always describes expectations for the release.
  • Team Members are responsible for sizing the stories in the release backlog, and breaking stories from the Product Manager into smaller stories that deliver value within an iteration (see “Twenty Ways to Split Stories”,

Iteration Planning

  • The Product Manager decides priorities for the team to work on in the next iteration. Team selects the stories they can complete within the iteration and decides how they work on the tasks during the iteration.
  • Only plan to work on sized stories.
  • Only plan to work on stories with agreed upon acceptance criteria (discuss and agree on the criteria, and document it during the planning). Team breaks each story into tasks and clearly defined acceptance criteria.
  • Agree on the definition of ʻdoneʼ for the team (update it whenever necessary).
  • Agree on ʻRules of Engagementʼ (update them whenever necessary).

Iteration/Sprint Execution

  • The teamʼs priority of work:
  • Keep the build/install working and testable (getting a brokenbuild/ install, and getting broken automated tests working, is always top priority).
  • Keep existing functionality working (fixing defects with functionality that worked before the current iteration is #2 priority).
  • Keep the functionality being built this iteration working (fixing defects on this iterationʼs stories is #3 priority)
  • Build out current stories (implementing new functionality is #4 priority)
  • Philosophies to continually keep in mind:
    • The fewer stories in progress the better (3 things shippable and 2 things unstarted is better than 5 things ʻalmost doneʼ).
  • The fewer tasks in progress thebetter.
  • Donʼt work on anything unless youʼve already agreed with your team mates how it will be tested and how you will know if youʼve been successful.
  • Donʼt add a new story to the current iteration mid-iteration (unless every other story is complete).
  • Donʼt split a story mid-iteration. Teams need to consistently complete the stories they committed to and establish a velocity. While they are gaining experience doing that, they will learn better habits faster by recognizing 0 points for incomplete stories and reflecting on how to better deliver on the iteration plan.

Daily Standup

  • Each member of the team updates the other team members on progress against the stories they are working on:
  • What did you accomplish yesterday (since the last standup)?
  • What do you plan to accomplish today (before the next staandup)?
  • What is getting in your way?
  • What is your latest estimate of how much time is left on your current task(s)?
  • Only people with work assigned in the iteration should speak.
  • Topics outside these questions should be addressed outside the Daily Standup.
  • Does the plan need to change as a result of the above? If so, change it now!
  • If anyone doesnʼt have enough to do today, decide what they will do at the standup.
  • All members of the team watch for “bad smells” in their scrums, and mention any apparent infractions. All members of the team work together to remove “bad smells” from their daily scrums.


  • Demonstrate only what the team accomplished (i.e. Stories the Product Manager has already accepted).
  • Record any issues, bugs, or enhancements that come up (and assign them or add them to the backlog after the demo).
  • Product Manager accepts (or decides not to accept) any remaining stories.
  • Avoid troubleshooting, discussing solutions, brainstorming ideas, exploring functionality, or anything else that takes away from clearly demonstrating the work that was completed this iteration.


  • What was the teamʼs velocity this iteration? Has the team established a consistent velocity? If so, what is it? If not, what is preventing the team from establishing a constant velocity?
  • What did we say weʼd improve / stop doing last retrospective? Did we?
  • Each member of the team has a chance to say (focus on the process, not the people):
  • What went well / what should we keep doing?
  • What could be improved / what should we stop doing / what is holding us back?
  • Team identifies the most important item(s) or issue(s) to focus on next iteration (1 or 2 items / issues is enough).
  • Change or add to “Rules of Engagement”?
  • Modify the teamʼs definition of “Done”?

Agile at the Masters

Watching today's Masters Golf Tournament in Augusta, Georgia I was struck again by something I've noticed before.  In the game of golf, when more than one person has the same score, the person who has completed the most holes is listed as 'ahead of' or 'above' the person or people with that same score.  Evidently, while having more holes remaining is surely an opportunity to get a better score, golf aficionados know that those extra holes are more often than not an opportunity to lose a stroke.  They seem to place more value on what has been accomplished for certain rather than what the potential for the future might hold.  

Thoughts on 'Potentially Shippable'

Scrum calls for the delivery of a 'potentially shippable' product increment at the conclusion of each iteration.  The reason it is 'potentially shippable' (rather than simply 'shippable') is that ideally it should only be a pure business decision as to whether enough value has been accrued to warrant actually shipping.  Therefore, the functionality that is exposed to the user works as intended based on the implemented Stories/Acceptance Criteria which in turn presumes that the quality is fit for purpose.

The value of keeping software in a 'potentially shippable' state at regular intervals is twofold: a) a real/tangible indication of progress for use in making date vs scope decisions and b) the ability to garner meaningful feedback at regular intervals.

If the software is in a 'potentially shippable' state, progress towards the end-goal is based on working, tested workflows/functionality implemented in software and not based solely on overall task estimates.  If the software is in a 'potentially shippable' state, feedback from existing customers, potential customers, and internal stakeholders can be meaningful.  Otherwise feedback can be, at worst, invalid, and at best confusing.

One of the goals of iterative/incremental development is to minimize the difference between 'potentially shippable' and 'shippable'.  Ideally it is simply a business decision whether there is enough value to actually warrant shipping.  In practicality, however, for many teams there are activities that they need to perform prior to actually releasing that they are unable to perform every iteration.  In some cases, the totality of all manual, automated and performance acceptance tests possible and/or necessary to execute and analyze in order to fully assess whether a given build is 'shippable' takes on the order of weeks to months.  In other cases, there is just too much legacy code which is not covered by automated testing to allow for the creation of something considered 'potentially shippable' within any given iteration.

With this in mind, teams need to be able to focus on those activities that they can accomplish inside an iteration which will best lead them to having confidence that the iteration backlog Stories work and that previously implemented workflows still function correctly.  Doing so will lead to a smaller gap between 'potentially shippable' and 'shippable'.  If a significant part of the cost of change in a code base is the uncertainty created by the change and our inability to validate (in a timely manner) that our workflows have not been inadvertently effected, then we should always be striving to minimize the time it takes to do that validation.  Validating quicker leads to finding and fixing problems quicker and cheaper.  Automate, automate, automate.


- acceptance criteria outline the circumstances under which each new workflow functions and the associated expected results
- if the acceptance criteria are met, and we have proved that the acceptance criteria for previously accepted workflows continue to be met, then we are potentially shippable.


- acceptance criteria for any given Story need to include regression tests for previously working functionality (either manual or some subset of long-running automated tests) which the team has assessed are likely to have been effected by the code changes necessary to complete the Story in question.

- alternatively, the Definition of Done can be altered to include a statement about the inclusion of relevant, focused regression tests which are either performed manually or are a subset of an existing long-running test automation suite.

- those manual regression tests then need to become an ongoing part of the automated test suite

The usual objection to this approach is that it means that teams apparently deliver less in an iteration.  This of course is a red herring as the teams were never actually delivering as much as they thought in an iteration because the regression testing necessary to deliver functionality was hidden in the 'stabilization/hardening' period prior to release.  Moving that regression testing forward moves teams closer to the ideal and should lead to shorter stabilization/hardening periods.

I'm often asked "How do we measure if we are 'potentially shippable'?"  My response to this is generally the same, "You're 'potentially shippable' if the software behaves the way you say it does."  Without some way to adequately describe (and ultimately test) this behaviour, it is difficult to know if you are 'potentially shippable'.  This behaviour is, of course, described in stories and their respective acceptence criteria.