The Agile Dentist

I have a crown over one of my molars that was necessary due to a crack which had been causing substantial nerve pain. At the time the crown was installed, I was told by my dentist, Brian, to expect it to take up to 6 months for the nerve to settle down. That settling never occurred. In fact in recent months I had started to experience increased nerve pain due to exposure to cold temperatures and pressure. At my next appointment Brian attempted to make some adjustments to the crown to reduce high spots and noted that the fact that I ground my teeth at night could also be responsible for the continued inflammation of the nerve. I should return to wearing my ‘splint’ at night. At my last appointment Brian determined that the crown adjustments obviously hadn’t had the desired effect and that my only option now was to have a root canal. A 2 hr appointment for this dreaded procedure was booked for the following month, with an associated estimated cost of between $800 and $1000.

I had been bracing myself all week for today’s appointment. The dental assistant administered a topical anesthetic to prepare me for the ‘freezing’ needle that Brian would give me for the procedure. When he arrived, while he was re-acquainting himself with my tooth/crown, he performed some simple experiments that gave him pause for previous conclusions he had drawn. Performing further experiments in a slightly different way than he and I done in the past led to new data. There were existing highpoints that had been previously hidden to him due to the way I had been grinding my teeth and how wearing my ‘splint’ had exposed that differently. Upon seeing this new situation Brian proceeded to perform significant sculpting of the crown and then suggested that we NOT perform the root canal as originally scheduled. He said that he believed that the new data and the resulting sculpting would lead to a noticeable drop in nerve pain within a week. If not, then we could reschedule an appointment for the root canal. We reviewed the options together and decided to wait another week to see if I noticed a decline in the intensity of temperature-related nerve pain. If that occurred it was likely to continue to improve and a root canal would not be required at all.

The currently acceptable solution to the problem took 45 mins instead of 2 hrs and was provided free of charge.

This set of events reminded me of some behaviours we look for on agile teams:

  • responding to change (even late in the process) over following a plan

  • delighting the customer

  • providing multiple solutions to a problem and collaborating with the customer to choose the best option

  • deferring decisions to the last responsible moment

  • maximizing the amount of work NOT done

Regardless of how this ultimately turns out, this is one happy customer.

Organizational Climate Change

Lately, like many of us, I’ve been thinking a lot about climate change. I can’t help but notice as I work with various teams, the similarities between our current climate crisis, and a crisis of time and attention going on inside organizations. The pattern I see is one of false cost allocation. It has impacted the global environmental climate, and I believe a similar phenomenon applies to the climates within our organizations and societies.

The Environment:  False Cost Allocation in 3 Stages

Stage 1: It’s All Free!

We start by seeing that the local impacts of extraction/exploitation are absorbed readily by the local system.  For example, a single campfire’s smoke seems to disappear into the vast expanse of the sky. Janine, warming herself by the fire (the principal beneficiary of the exploitation) doesn’t appear to have any negative effects on those around her.  The cost appears to be based solely on the effort required by her to gather and burn fuel.

Stage 2: It’s Free tor the Org.

As more and more individuals avail themselves of the resource, the local impacts are not readily absorbed by the local system and need to be absorbed by the global system at the cost of another element within the local system.  A series of adjacent factory chimneys produce gases that hinder the growth of vegetation in the immediate vicinity which in turn impacts food availability/quality. Unlike her neighbours, Janine, the factory owner is able (due to profits) to avoid experiencing the negative impacts on the local system by residing elsewhere and /or purchasing (more expensive) food elsewhere.

Stage 3: Turns out it’s NOT Free.

As more and more local systems are exhausted of their exploitable resources in search of higher profits, networks of these local systems have a greater and greater impact on local systems further afield.  The reach of the network trends towards global cumulative impacts. Pollution not absorbed by several adjacent local systems travels globally and impacts the environment of distant countries and continents, pokes holes in the ozone layer, and melts the polar ice cap.  The principal beneficiary of the exploitation is no longer able to avoid the real cost of that exploitation and it is impacting them as well as others.

Regardless of whether the cumulative negative impacts have been caused solely by human activity, it is widely accepted that CHANGE in human activity can reduce and perhaps reverse the current cumulative negative impacts affecting us all.  Our continued unwillingness to see the true costs of our actions will only continue us down the path of further accumulation of global impact.

Personal Time and Attention: False Cost Allocation in 3 Stages

This same pattern can be seen in the work environments that most people experience today.

It’s All Free! (Local impacts are absorbed by the local system)

Increasing demands on an individual’s time and attention by an organization are compensated for through the time and attention from a large and involved social fabric.  This social network consists of the nuclear and extended families as well as the community. As an example, Jonathan and Janine work during the day and rely on relatives to look after their children during the day.  Their retired parents are more than happy to help raise their grandchildren. The principal beneficiaries (Jonathan and Janine) of the time and attention spent don’t appear to have any negative effects on those around them.  The true cost appears to be based solely on the time incurred by Jonathan and Janine for the income they receive.

It’s Free for the Org. (Local impacts are absorbed by the global system)

As more and more time and attention is spent away from the social network, the primary beneficiary switches to an entity (an organization) less aligned with the local system’s values.  As Jonathan and Janine are required to spend more time and attention on their respective employers after hours, the quality of time spent on themselves, their family, and friends is diminished.  This leads to social, behavioural, and educational impacts for their community. These deficits are absorbed by civic, provincial and federal programs mostly paid for by the parent in the form of taxes.  Unlike those people surrounding Jonathan and Janine, the organization often avoids the direct costs to the local system. The proliferation of global and mobile communication that has brought an expectation of ‘always on’ time and attention for organizations has accelerated this phenomenon.

Turns out it's NOT Free. (Local impacts lead to global impact accumulation)

As the drive to increase profits continues, not only are employees expected to ‘do more with less’ (thus incurring more time and attention away from their social fabric)  but corporate tax structures are also reduced to the point that the civic, provincial, and federal programs cannot be adequately funded. Healthy relationships are eroded within all levels of the system and impacts of these exhausted social networks are manifested in the general population by poor education, increase in mental and physical health issues, and homelessness.  This in turn leads to a dearth of future employees for corporations and a decrease in their ability to compete in the global marketplace. At that point, the principal beneficiary of the exploitation is no longer able to avoid the real cost of that exploitation and it is impacting them as well as others.

As with climate change, the challenge that is incumbent upon leaders of organizations is to make a shift in behaviour before it’s too late.  Organizations need to be led within the context of a larger human system. They cannot be driven by the single goal of profits without regard for the real costs born by the people in the system. Profits need to be the result of a larger vision which incorporates how the world and the organization’s employees will be better off because of the organization’s products and services.  Further, those products and services need to account for the true costs of their development and leaders must regularly re-assess those true costs. Once that vision has been established, organizations will begin to realize that their employees should be #1, their customers should be #2, and 1 and 2 together will lead to truly sustainable profits.

For more reading on what has helped shape some of my views please visit:

Jason Fried on “How to make work less crazy”

Steve Denning on “The dumbest idea in the world: maximizing shareholder value”

The Value of Learning

Last night during a panel discussion on the application of agility outside software development, I was asked how to quantify the value of learning.  I was caught off guard by this question as learning has always been at the core of agility in my mind and so I've never thought about the value of it separately from agility.  This experience prompted me to think about the difference between creating value regularly and learning regularly.

The agile manifesto values working software over comprehensive documentation.  Scrum focuses on the delivery of a (potentially) shippable product increment at the end of every sprint.  What probably doesn't get spoken of enough is that the value of accomplishing working product regularly is not just in the incremental value of the delivered product but the value of learning whether we are delivering the RIGHT value.  If we aren’t, we have valid evidence to support a change in direction.  Having functionality that is potentially shippable is NECESSARY to facilitate a valid learning feedback loop.  One could argue that the value of the delivered functionality is secondary to the learning created by the valid feedback loop.

One of the criticisms of applying agility outside of software is that you can’t/don’t release a partially completed gas plant or piece of farm equipment to customers.  They only get released when they’re ‘complete’.  All the value is present or none of the value is present.  I would argue that position only takes into account the functional value produced regularly, not the learning feedback loop.  When applying an iterative / incremental approach to other fields such as manufacturing or construction, that learning feedback loop can still be achieved without a holistic 'potentially shippable' product increment via the use of robust test fixtures.  This has tremendous value in these domains because most of the risk in manufacturing/construction is in the engineering/procurement rather than in the construction delivery activity. 

Sapiens, Revolution, and Empty Maps

In his book entitled 'Sapiens', which explores the nature of the 4 defining revolutions in the history of homo sapiens, Yuval Noah Harari argues that the Scientific Revolution was based in people succumbing to the understanding that they didn’t know the answers to important questions.  He writes:

"The Scientific Revolution has not been a revolution of knowledge. It has been above all a revolution of ignorance. The great discovery that launched the Scientific Revolution was the discovery that humans do not know the answers to their most important questions."

Until this revelation, those questions were answered only by religious leaders and elders or the questions were deemed unimportant.  

One of the first indications of the shift toward a scientific mindset in Europe was the creation of world maps containing ample empty space - a clear admission of ignorance of parts of the world. That started to change in 1492.

I believe we are in the midst of a revolution in business and project management.  For decades, practitioners in these fields have asserted that we have all the answers if only we could execute on them.  More and more, the business world is understanding and accepting that increasing complexity is forcing us to face our ignorance.  We need to be comfortable WITHOUT fully populated schedules and plans. We need to have more empty spaces in our maps. The increasing complexity of our work provides us the opportunity to discover things we thought were not possible instead of relying on what we think is predictable.  It is perhaps counter-intuitive to see wisdom in acknowledging our ignorance but it is exactly this wisdom that will separate those companies that will thrive from those that will become extinct.

Just as in the Scientific Revolution, it will be empiricism (the core of agility) that will guide us to discover answers to existing questions and new questions rather than the audacity of thinking we know all the questions, let alone the answers.

Vive la revolucion!!

Behavioural Economics: Lessons in Leadership

Richard Thaler, a recent Nobel prize winner in Economics from the University of Chicago has changed the way many economists think about their economic models by including elements of psychology.  This is known as Behavioural Economics.  Rather than assuming that the entities involved in the models make rational decisions for their well being, Thaler has popularized the idea that those entities should reflect the reality that people make decisions that undermine their overall long-term being. 

Last month I had the good fortune to listen to the Oct 25 episode of the Freakonomics podcast entitled “How to  Launch a Behaviour-Change Revolution”.  During this 45 min podcast, the hosts explore the genesis of Behavioural Economics and a research project called “Behaviour Change for Good”; a play on words for positive, long lasting change.  This research by Angela Duckworth and Katherine Milkman had the goal of helping people make truly lasting behaviour change by helping them make better decisions for their overall long-term being.


As a kickoff to their research project, Duckworth and Milkman hosted a two day summit attended by luminaries from the field of psychology, including another Nobel prize winner Daniel Kahneman.  You may know Kahneman from his work on cognitive biases as discussed in his book “Thinking Fast and Slow”.  During the 2nd day of the summit (30 mins into the podcast) Kahneman comments on ‘the best idea I ever heard in psychology’.  The idea he refers to is from Kurt Lewin, a German-American psychologist from the early 20th century.  Lewin’s idea was that in thinking about behaviour, we should consider that there are always two opposing external forces; driving forces and restraining forces.  His novel insight was that behaviour is really the equilibrium between those forces.

Therefore, when trying to induce change in behaviour, one can choose to either reduce the restraining forces or increase the driving forces.  Our natural predisposition when changing anything is to increase driving forces.  When we want to move an object, we move it.  When we want to change a person, we try to cajole and incent in order to change that person.  Kahneman argues that we need to change our perspective and instead of asking ‘How can we get this person to do X?’, instead ask ‘What is preventing this person from already doing X?’  Lewin asserted that reducing the restraining forces is usually much more effective than increasing the driving forces.  Those restraining forces are likely reflective of the system within which the person is working.  Changing behaviour involves changing the constraints within the system.

Consider the significant implications this has for leadership.  Rather than trying to directly change a person’s behaviour, leaders need to be asking what they can do to make it easier for the person to change their behaviour; to reduce the restraining forces.  Kahneman states that the way to make things easier is almost always controlling the person’s environment.  Whether it’s changing counterproductive incentives, social pressure, or any other organizational impediment, the premise is that if A is a restraining force on B then let’s work on reducing A not driving B.


Later in the podcast Kahneman is challenged on his assertion that “you have to overpromise to get ANYTHING done”.  After all, he has done the seminal work on cognitive biases that lead us, as a psychological mistake, to be overly optimistic.  Kahneman maintains that making practical incremental improvements in results may be useful but to really make a difference, to create ‘big successes’, likely requires being unreasonably optimistic at the outset.

This concept also has implications for leadership.  My experience applying Scrum values and principles to the execution of large oil and gas construction projects mirrors these assertions.  The EPCM team’s success on a $2.4 billion program of three natural gas processing plants was in part due to the team’s commitment to goals that seemed entirely unreasonable at the time.  According to McKinsey, the global normal performance for mega-projects (>$1B) in this domain is a cost overrun of 30-40% and a schedule overrun of 40-50%.  The EPCM leadership team and the execution team collaboratively set their sights on being 10% under budget and months ahead of schedule.  Our approach to achieving these results was to acknowledge that we didn’t know HOW we were going to solve the problems in front of us but that we were going to  commit to regularly understanding our current priorities, and then tackling each seemingly unsolvable problem one at a  time as a multi-discipline team.  We didn’t solve all of them, but we solved most of them.  The EPCM leadership also focused on reducing restraining forces by removing impediments preventing team members from working collaboratively.  Namely, co-locating the team, implementing cross-discipline team composition, and promoting the idea that the identification of upcoming problems was a vital and important activity. The results were that the first plant was in service 38 days early, the second was in service 86 days early, and the third was in service 167 days early; the plants were delivered 10% under budget.  This had immense implications for the economics of the projects as revenue was generated early.

“If you solve one problem, and the next one … if you solve enough problems you get to come home.” - Mark Watney, The Martian

As always, we prosper from conversations with our colleagues outside of our immediate domain.

Billy Goat

I’ve taken a year off from writing this blog in order to spend time attending and contributing to numerous conferences around the world.  In that time I’ve heard a lot of disturbing things about Scrum.  It’s time to write again.  

Do you remember the first time you bought a piece of Ikea furniture like the Billy bookcase?  You brought it home, looked at the front of the instruction book and thought, “It’s a bookcase, how hard can it be?”  You then started to build the bookcase.  Along the way you realized you’d done something in the wrong order and had to undo and repeat some steps.  Occasionally you thought ‘that seems stupid’.  What seemed like it should have been obvious, wasn’t.  That didn’t mean it wasn’t simple and correct; it just meant you didn’t fully understand holistically how all the pieces were supposed to fit together.  If you’re experienced at this sort of thing, a brief review of the instructions can provide you with a view into the mindset of the designers on how to build the bookcase and you proceed with ease.  At worst, following the instructions methodically one by one usually provides you with a recipe to get your desired result, even if it takes an excruciatingly long time.

If you’re experienced at this sort of thing

Over the years as a coach, I’ve written about and worked with the Dreyfus Skills Acquisition model.  This 5 stage model of learning describes that the way to become experienced at this sort of thing is to, each time, follow the instructions until you start to recognize patterns and understand how these types of designs fit together.  With significant repetition you start to be able to look at something foreign and understand what the ‘aspects’ are … the things you should pay attention to in order to grasp an understanding of the whole.  Eventually you get to a place where that grasp comes naturally enough that you can also start to see improvements to the design.  Finally all of this becomes intuitive.  Sometimes this is also referred to in the context of Shu-Ha-Ri.

In the realm of agility, it appears there are many who are not experienced at this sort of thing.  This should not be a surprise.  Working in an iterative/incremental and inspecting/adapting fashion is relatively new to the industry and is significantly antithetical to most of the approaches preceding agility.  And of course, practice takes time.  Did I forget to mention that, according to the Dreyfus model, you can’t skip stages in the learning process?  From the Dreyfus brothers’ original paper: “...avoid the temptation to introduce intricate and sophisticated aids which, although they might improve performance at a particular level, would impede advancement to a higher stage or even encourage regression to a lower one.”

So with all this in mind, I am continually troubled to read and hear about how Scrum doesn’t work.  Simply do a search for ‘agile doesn’t work’ or ‘Scrum doesn’t work’ to see what I mean.  There are countless articles and blog posts on this topic.  I’ve overheard and/or participated in similar conversations.   I’ve even been involved in conversations with self-professed agile pioneers and authors of books on agility who have bashed Scrum unabashedly.  Invariably, in my opinion, the arguments in these writings and conversations have occurred as a result of one or more patterns:

  • the core nature of agility is misunderstood

  • how the Scrum framework fits together and is intended to function is misunderstood leading to ‘Scrum-but’ or worse, ‘Dark Scrum’.

  • people and organizations aren’t prepared to make the changes necessary to truly experiment (including change their development and testing skills)

What leads to these misunderstandings?  I believe it is a result of people and organizations skipping stages in the Dreyfus model;  specifically, not focusing on the basics first until they grasp an understanding of how the Scrum framework functions.

We don’t magically know how to ski or fly a plane.  These are both complex activities requiring a learning process involving inspection and adaptation.  Why do we expect to be able to learn how to effectively use the Scrum framework without practice and practice of some basic rules to start?  My opinion of what those basics are has changed over the last 10 years, but the need to practice the basics has not.   

I can think of three main reasons why people and organizations don’t practice the basics.  The first is that Scrum is deceptively simple, just like the bookcase, and it is tempting to assume you intuitively understand it holistically and therefore can skip the basics.  The second is that it is HARD to do well, and often requires a shift in skills and culture.  The third reason is that there has been an overemphasis by the community (mea culpa) on an agile mindset over mechanics; a balance is required.

Ron Jeffries has written at length about what he coined as ‘Dark Scrum’.  It is the embodiment of Scrum practiced without its original intent.  It is the version of Scrum that far too many people know.  Scrum, as intended, requires culture and skills transformations that organizations all too often are just not willing to make.  For instance, the need for XP development practices (or something similar), becomes obvious if one actually follows the Scrum framework’s requirement to regularly deliver a potentially usable and releasable increment of functionality that meets a Definition of Done.  All too often people and organizations are either unwilling or unable to learn new techniques in their core skills. 

There are many ways to BE agile; Scrum is only one of them.  For solving complex problems, Scrum works. It works because it is so simple.  It works because it is a framework, not a recipe.  It works because, by design, it is not a 'silver bullet'.  It doesn’t actually fix anything in and of itself; it only presents the regular opportunity to do so.  Scrum as it is intended, at worst, simply exposes all the dysfunction in an organization that prevents that organization from reaching its goals.  At best, Scrum provides a framework to deliver a continuous flow of value in a sustainable way.

Regardless of where you and your organization are in your agile journey, you won’t get to where you want to be without intentional practice in activities and domains with which you are unfamiliar.  It’s a never ending journey of learning.

So rather than have people decry “Scrum doesn’t work”, I’d much rather hear those people say “We were unwilling to learn.”

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.