Agile Techniques

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!!

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.

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.

 

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?

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: http://www.nasa.gov/mission_pages/apollo/missions/

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.

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.

Renovations

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.

 

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.

Applying the Dreyfus Learning Model to Focus Your Coaching Approach.

Agile2011-badge.jpg

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.

Environment

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

Roles

  • 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”, http://xp123.com/xplor/xp0512/).

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.

Demos

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

Retrospectives

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

IDEALLY:

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

PRACTICALLY:

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

Spike ... Do the Right Thing. [Redux on Aug. 30 post]

Doing the right thing is often context dependent.  I've had occasion with my current clients to discuss  the concept of Spikes and how they are treated by numerous teams.  I've realized that where a team currently resides in the continuum of learning iterative/incremental development has quite an effect on how I discuss this topic.  The current industry norm is to treat a Spike as a type of Story.  This has been reinforced by web-based tools limiting trackable items to Stories, Tasks or Defects.  I've seen novice teams struggle with this notion and here's why:

  • Summarily, the purpose of a Story is to describe some piece of functionality valuable to, and testable by, a customer.
  • The purpose of a Spike is to investigate the solution options and feasibility of addressing a particular problem space or Story.

Stories should have direct customer value as well as a size estimate (representing effort, uncertainty etc) from the team, while Spikes have no direct customer value and are generally time-boxed to no more than 2 days.

From this perspective, Spikes should not be called Stories because they violate the spirit of the principal purpose of a Story (to express something of value to a customer).  I think much of the confusion on this topic stems from our desire to want to name things based on how we manage them.  I think people would like to manage Spikes in the same manner they manage Stories but then assume that means the Spike should be called a type of Story.

I've seen novice teams want (naturally) to do things like give the 'Spike Story' a size and then directly equate that size to the length of the time-box.  This tends to negate the value of using Story Points for sizing Stories in a backlog.

Conversely, if a team treats a Spike as a Story and gives it a size of zero, that is inconsistent with the fact that they are spending time on it.  It also grates against those who look for Stories which we "get for free" (and therefore give a size of 0) as a result of some overlapping work on another Story.  These are subtleties which a mature team understands but a novice team, new to Stories, can find challenging.

So how about Spikes as Tasks?

I believe Spike activities have much more in common with Tasks than Stories.  However, there are inconsistencies and pitfalls here as well.  If a team treats a Spike as a Task inside a relevant story for an iteration, when the Task is complete, then the relevant Story should technically be removed from the iteration and returned to the release backlog (unless it is determined that the entire story can be completed before the end of the iteration) for future prioritization along with at least some of the resultant child/replacement Stories.  Depending on the the size of those resultant Stories (and the team's velocity) some of them may remain in the current iteration.  If we emphasize striving for completing all stories initially planned in an iteration we end up having to make exceptions for Stories containing Spikes.  Another pitfall is that when a team employs "yesterday's weather" for their next iteration, they need to ignore the size of a Story containing the Spike task.   Again, these things may be easily comprehended by a mature team but perhaps are contentious for teams transitioning to Agile methods, inexperienced in the use of Stories, and looking for absolutes (and THAT is a subject for a future post!).

How about neither Story nor Task?

In my experience, Spikes are generally an extension of Backlog Grooming and as such could be considered release overhead.  Spikes are generally not included as part of the release backlog but they likely result in a set of more defined Stories which may be part of the release backlog.  Perhaps it would be better for some teams to simply reduce team member availability during an iteration to account for the Spike time-box?  After all, we do this for things like Backlog Grooming meetings.  The one drawback to this approach is that there would be no explicit/transparent way for the team to manage the time spent on the Spike activity.

So why isn't a Spike just a Spike?

While the notion of a Spike overlaps the notion of Story in that both have a goal; and the notion of a Spike overlaps the notion of a Task in that both represent an activity, I think the differences between the 3 are signficant enough to warrant maintaining/managing a separate entity - 'Spike'.  This is easily accomplished on a traditional index card wall, but is usually explicitly prevented when utilizing a web-based management tool.  I believe this is one of the mistakes we as a community made when we transitioned to using these tools.  When we were using index cards we simply called it a Spike and off we went.  We didn't have to choose to create that entity as a Story or a Task so there was less confusion. 

Of course this is all just semantics ... Story, Task, Spike, Backlog Grooming ... what's the big deal?  The answer to this lies in the fact that we use words to communicate intent and without some consistency in the meanings of these words, it is difficult for people new to the concepts to keep it all straight.  The English language itself is full of inconsistencies and similarly, it is not until one is familiar with the patterns that one can grasp and remember the exceptions.

In the end what do we care about?

I really only care that the size of the release backlog is consistent with the team's current understanding of the backlog, and that the team's velocity actually represents the rate at which they may be able to reliably and sustainably address prioritized items in that backlog.  As Spikes occur, the resultant child/replacement stories will likely affect the cumulative size of the release backlog and the product owner can make the relevant business decisions with current information.

So depending on the individual team and their circumstances, any one of the 4 options might be the right thing.  If you're using a web-based tool (that limits your trackable items to Stories, Tasks and Defects) to manage your iterations and your team is relatively new to the use of Stories, consider treating Spike activities in the same way you treat other iteration overhead activities.

The Test

I've spent a lot of time over the past year thinking about and working with the Dreyfus learning model and the concepts of Shu-Ha-Ri as they apply to the evolution of agile software development teams.  During that time, I've also seen that much has been written about the Nokia Test.  This test, developed by one of the co-creators of Scrum, aims to assess a team's level of adoption of Scrum practices and principles.  Specifically this test was developed to help teams avoid the traps of 'Scrum but'.  Scrum is a fantastic approach to software development that I heartily endorse but I'm not sure that assessing adherence to the approach should come before assessing a team's ability to deliver what the business needs.

Rather than worry about whether 'we are agile', teams should primarily be concerned with whether they are providing the business with what it needs: a continuous flow of potentially shippable functionality and information pertaining to a realistic rate of progress which can be used to make timely business decisions.

How about asking these three questions to start instead:


  1. Does the team regularly deliver potentially shippable and incrementally valuable functionality at the end of each 2-4 week iteration?

  2. Can the team's product owner, given the team's historical velocity, predict with a satisfactory level of confidence, what value from the Release Backlog is likely to be shipped by a particular date?

  3. Is the team actively improving on 1 and 2 above?


If a team cannot answer 'Yes' to all three of these questions, using Agile techniques (and specifically following the Scrum framework) will likely lead the team in a direction consistent with one of the primary reasons to use agile techniques - project risk mitigation.

If the team can answer 'Yes' to all three of these questions, applying Agile techniques (and specifically following the Scrum framework) will likely lead the team to an increase in velocity.

It's ALWAYS been the problem!

When I started working full-time with Agile development techniques in 2004 I also had the good fortune to start working with the concepts of Pragmatic product management.  What quickly became apparent to me is that the two approaches in their respective fields were beautifully suited to one another.

By articulating the market problems, the nature of the people who have them, and the circumstances under which they experience those problems, Pragmatic product managers communicate to development teams what is really necessary to build great solutions; context.  We've all heard the stories of how the software industry's predilection for waterfall methodologies from the 1970's through the 1990's led to an inordinate amount of 'failed' projects.  Early proponents of agile development techniques ascribed those failures to the waterfall process itself, rightly arguing that performing development tasks (specifically testing) in phases and a lack of iterative feedback were the biggest causes of these 'failures'.  However, I would contend that just as large a reason for those 'failures' was product management's inability to communicate what was actually required for those projects to be successful.  Too much emphasis was placed on building to a specification which had often been created and disseminated without providing sufficient context to the people responsible for providing solutions.  Because of this lack of context there was no framework for negotiation with a customer or stakeholders and therefore much of what was built was not actually required to meet the customer's needs.  This resulted in unnecessary delays and cost overruns at a minimum and often the creation of ineffective solutions which quite rightly were considered 'failures' regardless of whether they met the specification.  Even if the solutions were built iteratively, the focus on the specification, rather than the problems in context, might very well have led to the same ineffective solutions.

Many software development companies do not have the luxury of having real-time access to actual customers.  Nor is the concept of building a product based on a single customer's requirements necessarily attractive.  Instead these companies rely on their product management organizations to represent the needs of customers within a market.  There is a hierarchy of proxy which is created as a result.  The customer is a proxy for the market and the product manager is a proxy for the market.  If the product manager is too busy performing strategic tasks and does not have time to fulfill his product ownership duties for the team then a proxy of a proxy is incurred with all the risk that entails.

All too often, agile projects rely on an internal 'product expert' to act as the team's Product Owner.  The danger of this is that the product expert understands the existing incarnation of the product very well but may not have the viewpoint of a customer who has issues with the product.  Properly implemented agile development techniques usually provide the transparent and tangible progress necessary to make informed business decisions.  However, without a clear sense of the relative value of the problems to be solved it is difficult for the team to understand and embrace those business decisions.  This is where the value of the MRD resides; providing the context necessary for a Product Owner to make sound decisions throughout the development process on behalf of the product manager.

In the end agile product ownership is a subset of all that a product manager is responsible for.  From a Pragmatic perspective, product ownership entails the 'Product Planning' tasks of the product manager: Market Requirements, Road Mapping, User Personae, User Scenarios, and Release Milestones.

The Pragmatic Market Requirements Document (MRD) focuses on market problems, the people who have them, and the situations under which they experience them (scenarios).  It also focuses on valuing/prioritizing those problems, people, and scenarios.  Hmmmm ... sounds suspiciously like a good start on a backlog of stories!  A story used in an Agile project usually takes the form of: A <type of user> needs to be able to <perform some action> in order to <get some value>.  This is essentially a statement of the circumstances under which a user experiences a problem.  I suppose technically it is an anti-problem as the real problem is the users inability to get the required value by performing the desired action.  Nonetheless there is a direct correlation between the primary elements of a Pragmatic MRD and a product backlog used in an Agile project.  Each scenario is prioritized using the following additional context: impact, frequency, and criteria.  The value to the persona of solving the scenario, the frequency with which the persona experiences the scenario, and the value to the to the Product Manager /Business of solving the scenario, all provide valuable context necessary for establishing business priority.  Once these scenarios have been prioritized, the product manager has a solid starting point for a product backlog.  Further, the entire team has a solid understanding of what problems they are trying to solve and for whom, and what the relative value of those problems is to both the market and the business.  With this context, the team is much better equipped to be able to produce solutions appropriate for the target personae and any decisions around solution options/modifications can be made in the context of the user and the business value.

agile2009_webbadges_speaker

Self-organizing teams at Quarry Bistro

My wife and brother-in-law own and operate a French/Italian bistro in our little mountain town.  They've been in the restaurant industry for 2 decades and are in their 6th year at Quarry.  Naomi runs the front of the house and David runs the kitchen.  Over the years, I've picked up a lot of knowledge about what it takes to run a successful restaurant.  It is a labour of love and not an endeavour to be taken lightly or for dreams of huge monetary returns.  I have been fortunate enough to be on the periphery of this and, apart from the odd dish washing shift, have had the luxury of being the unofficial taster of countless culinary gems paired with just enough wine.

During the peak season, when Quarry is busy and tables are turning quickly and constantly throughout the evening, Naomi has often said that the reason is that the team has an innate ability to do two things: prioritize their work and look out for each other.

In the dining room, the staff need to execute on priorities as inputs continue to change: new customers at the door, food ready to be served, tables in need of resetting, patrons ready to order, patrons telephoning for reservations, patrons finishing their first or second course, tables need to be cleared, patrons ready to pay.  All this has to be looked after in a timely manner while keeping the ambiance of the room relaxed and enjoyable.  While there are specialists on the team, each team member must be able to look after any of these tasks.  Further everyone has to be on the look-out for gaps in service which have occurred simply because at any given moment, only the top priorities are being looked after.  Upon noticing a gap, what separates the great team members from the ordinary team members is their ability to seamlessly pick up small tasks in the seconds in between their own top priorities.  There is an understanding that the overall room efficiency and success is everyone's responsibility.

Similarly in the kitchen, cooks glide past each other in tight quarters, knowing what motions to expect from each other and trusting that each person will be where they need to be given the current state of upcoming orders.  The sense of timing necessary to serve up to 60 patrons with 3 cooks is astonishing.  It means that those cooks need to be constantly evaluating priorities, executing on those priorities (usually in terms of time at temperature and time between courses), and when necessary helping a specialist with too many high priorities while tending their own tasks which, for a short moment, are better spaced than their colleagues'.  David has stated that when this culinary ballet is on form, the adrenaline rush is the reward.

One of the reasons all of this works is the way the team is compensated.  Tips are pooled as the philosophy is that if the team is working well together, all patrons' experiences will be improved and thus all will be more likely to tip more.  Further if the team feels one of its members is underperforming the team has a vested interest in either helping that team member or recommending that he/she be replaced.

A lot of what I've learned about great teams, I've learned while eating carbonara at the bar ...

But WHY, dad?

Asking 'why' is perhaps the most valuable of all questions both in life and software development / product management.  Being the father of two toddlers, I get asked 'Why?' a lot.  I only wish the team mates on some of the teams I coach were so inquisitive.  Knowing the 'Why' is often the difference between success and failure.  This is, of course why User Stories take the form they do: As a <type of user> I need to be able to <perform some function> so that I can <get some value>.

Both the type of user and the 'so that' clause provide valuable information in the form of 'Why'.  Without this information, a team could go horribly astray.  Asking 'Why?' helps provide valuable context.

Here's a simple example:

The user needs to be able to enter surface positional data.  Why?

The directional drilling engineer needs to be able to enter surface positional data so that he/she can perform anti-collision analysis.  Why?

The directional drilling engineer needs to be able to enter surface positional data so that he/she can perform anti-collision analysis, avoid drillstring collisions with offset wells and therefore avoid tremendous expense and/or injury/death of drilling personnel.

Clearly knowing who needs to enter this data, and why, puts a different context in front of the team around the requirement of simply being able to enter surface positional data.

My sons make me answer this question a lot and software development teams could learn a great deal if they if they continually did the same!

The fifth element.

The most overlooked of the 12 agile principles described alongside the agile manifesto is perhaps the hardest to come by - building teams around motivated individuals.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.


There it is ... that term four words in to the first sentence ... 'motivated'.

A very subjective word.  Some people are motivated by money, some people are motivated by the recognition of their peers, others by visions of climbing the corporate ladder.  What this term means in the context of agile principles though is something much more specific: 'motivated' by pride in their chosen profession and the desire to learn and improve.

All too often in large traditional organizations, software development team members simply have a job.  Occasionally they've simply been beaten into submission and can be resurrected by agile techniques.  Very often however, the people that survive for long periods in large organizations are those that are mediocre and are valued because they don't rock the boat.   These are the people who will, at best, go through the motions of implementing agile techniques while giving no thought to the principles and philosophy behind them.  At worst these people will simply figure out ways to 'game the system'.  Of course the ultimate responsibility for tolerating this behaviour lies with management.  Either way, having a motivated cast of characters is crucial to the success of an agile project.