A spider web has several external risks.

A spider web has several external risks.

Making sure external risks are addressed in an Agile effort, or any effort for that matter begins with making sure that at least a basic risk management approach is in place. If a basic risk management approach is in place we can integrate the concept of external risks.  Everyone involved should understand the basics of the risk management process being leveraged on the effort.  All risk management processes need to identify who is responsible and how the process fits into the value delivery flow.  Specifically, incorporating the idea of external risks into the process is typically more urgent as the scale and duration of the effort increases if for no other reason than longer efforts are exposed to the trials and tribulations of the outside world longer than small efforts.  The size of the effort affects two main variables used to scale  Agile risk management.  The larger the effort the greater the need for the people involved with the effort to define who is responsible for risk management and how much process is needed to keep things organized.   The size of the effort, while a continuum, will be represented by small efforts (one team and a few iterations or sprints) and large efforts (over 75 participants with at least 6 iterations or sprints) for illustration.   (more…)


Nesting Easter eggs show each layer of the process improvement architecture

One of my children owned a (Russian nesting doll) that is now somewhere in our attic.  I was always struck how one piece fit within the other and how getting the assembly out of order generated a mess. I think I learned more from the toy than my children did.  The matryoshka doll is a wonderful metaphor for models, frameworks, and methodologies. A model represents the outside shell into which a framework fits followed by the next doll representing a methodology placed inside the framework. Like models, frameworks, and methodologies, each individual doll is unique, but they are related to the whole group of dolls. (more…)


When the goal is complicated architecture, everyone needs to coordinate.

Much of the work to coordinate and synchronize goals happens during planning.  As Mike Cohn described with the metaphor of the Agile planning onion, Agile planning is not a one-time event nor are planning activities confined to the beginning of an increment or a sprint. However, delivering work using Agile is not just a big ball of planning. Goal coordination and synchronization activities need to happen outside of planning activities.  Several non-planning Agile techniques are useful for ensuring coordination.  The degree of usefulness is a function of size, complexity and the Agile maturity of those involved. The techniques include:

Test First Development (TFD) in all of its forms (including Test Driven Development, Behavior Driven Development, and Acceptance Test Driven Development) begins by establishing how the developers will prove the work they are planning to deliver.  Expressing how the solution will be proved before writing the first line of code anchors the functionality being delivered to the effort’s goals. All of the test first development techniques can be applied to any size project; however, these techniques require teams that have access to the correct tools and have at least a moderate Agile maturity.   

Definition of Done provides a team or teams with a set of criteria that they can use to plan and bound their work based on an overarching definition of done. A definition of done that includes integration activities or a check against the increment’s goal is an effective means of keeping goals synchronized. The definition of done is applicable to all efforts regardless of size, albeit as complexity increases this technique becomes even more powerful.

Continuous Builds is a process in which every time code is checked back into the code repository the application or product is built (or compiled).  The build is immediately followed by some form of testing to make sure the “build” still works.  Continuously building the software ensures that any one team or developer does not go too far off track because the code and testing act as an arbiter that the product works. This technique is applicable to all efforts (Agile or not, big or small); however, I have noticed that the use of continuous builds requires some experience and maturity with Agile.

Scrum of Scrums (SOS) is a mechanism that brings all of the Scrum Masters involved in an effort together to coordinate a group of teams so that they act as a team of teams. The SOS provides a platform for coordinating and synchronizing goals by ensuring teams are aware of what other teams are doing and whether they have had to make adjustments to the goals.  An SOS is useful for coordinating efforts of all size; however, as efforts scale past two or three teams other coordination techniques are needed in addition to the SOS. 

Demonstrations, also known as demos, are Agile’s mechanism to share what the team has been accomplished.  Scaled Agile efforts often have demos at the team level at the end of every sprint, an integrated demo (all teams) and then a larger demo before a release.  Demonstrations provide the ultimate proof of what has been built allowing stakeholders to determine whether the effort’s goals have been met. Demos are useful for every Agile effort.  Larger efforts will do demos both at the team level and then as a consolidated demo for the overall product.

Dynamic Testing (execution of the code), by definition, generates results that are compared against some expected result (even exploratory testing).  Those expected results represent an instantiation of the goals and objectives of the overall effort.  Testing, while important, without the structure of test-first development is a very weak tool for coordinating and synchronizing goals. Do not use this technique alone regardless of the size of the effort. 

Techniques for synchronizing special types of goals and objectives such as process improvement or technical goals are: 

Retrospectives are a platform for teams and teams of teams to examine their performance and to make changes to improve their delivery of value.  When an effort or organization has productivity, quality, and/or efficiency goals, retrospectives (using techniques such as the 6 Thinking Hats) are highly effective.  The retrospective provides a platform to share the objectives and then to synchronize on the steps needed to meet those goals and objectives.

Common Architectures and Standards are typically an instantiation of the technical goals and objectives of the organization. Efforts of all size can use a set of standards or a published architecture to effectively coordinate activity.  Examples of using an emergent architecture to provide guidance can be seen in the SAFe concept of the architectural runway.  The runway is “built” just ahead of the need of the teams generating the functionality that will leverage that architecture.

The effectively coordinating and synchronizing goals is a requirement for any effort, if the effort is going to deliver value efficiently. Agile efforts often use many of these techniques in combination.  Each technique interlocks and overlaps with other techniques so that an environment is created that supports team’s ability to self-organize and self-manage.   The number techniques and how strenuously they need to be pursued is a function of how many teams are involved, Agile maturity and complexity.  Conceptually an effort with two collocated teams and simple business problem to solve will need less goal coordination than an effort with many teams that are spread across the globe. The one absolute when it comes to goals and teams is coordination is always required.

little boy building a block tower

The bigger the project, the more complicated the role of the product owner gets.

The Product Owner (PO) role in organizations that are scaling up Agile projects requires not only nuances how the role is applied but also requires refocusing the typical activities in the role (however this does not mean that they don’t they get out of buying pizza or other relevant food occasional).  The primary responsibilities of a scaled product owner are: (more…)

Listen Now

Subscribe on iTunes

I am on vacation for two weeks and could not leave you without some Monday morning mind candy, therefore, we are doing two very special shows this week and next.  This week I have included the responses to the “if you could fix any two (or sometimes just one) things” question I ask at the end every interview from the three most downloaded interviews of 2013.  The top three and one extra were::

SPaMCAST 224 featured Mike Burrows. Mike focused his wishes on:

  1. Changes agents need to take their role as change agents seriously.
  2. Delay is expensive.

Link: http://spamcast.libsyn.com/s-pa-mcast-224-mike-burrows-kanban-values

SPaMCAST 246 featured Tobias Mayer. Tobias focused his wish on:

  1. People, not management or consultants, need to own scrum. (One wish was enough for Tobias)

Link: http://spamcast.libsyn.com/s-pa-mcast-246-tobias-mayer-t-he-people-s-scrum

SPaMCAST 270 featured Alan Shalloway.  Alan focused his two wishes on:

  1. Everyone needs to acknowledge there are laws of software development.
  2. Assuming that everyone involved in delivering software is highly motivated.

Link: http://spamcast.libsyn.com/s-pa-mcast-270-alan-shalloway-sa-fe-lean-kanban

And just because I could . . . a bit of lagniappe, SPaMCAST 138 Featured Jo Ann Sweeney. Jo Ann focused her wishes on:

  1. Reminding the listeners that change often starts before IT starts a project there we need to listen carefully to the stakeholders.
  2. Project teams should care about end users.

Link: http://spamcast.libsyn.com/s-pa-mcast-138-jo-ann-sweeney-communication

If these excerpts tickled your fancy listen to the whole interview by clicking on the links shown above.

Next week the best excerpts from 2014!

The Mythical Man-Month

The Mythical Man-Month

In the seventh essay of The Mythical Man-Month, Brooks returns to the topics of organization and communication using story of the Tower of Babel as a metaphor for many of the engineering fiascoes seen in software development. In the story of the Tower of Babel, when communication broke down, coordination failed and the project ground to a halt. As projects become larger and more complex, communication and organization always becomes more difficult and more critical.

The essay Why Did the Tower of Babel Fall? presents three mechanisms to facilitate communication.

  1. Informal Communication, which includes all of the telephone calls and conversations that occur in and among teams. Healthy teams and teams of teams talk, interact and share information and ideas.
  2. Meetings are more formal and include reviews, technical briefings, demonstrations, sprint planning and release planning events. Done well formal meetings, whether part of an Agile framework or not, can find problems and share information and knowledge.
  3. Project Workbooks are the repository of the evolving intellectual property that defines any significant endeavor.

Brooks goes into depth on the definition and structure of the project workbook. While the workbook that Brooks describes is a physical construct we should consider that the idea of workbook is less of a document then a structure for grouping information. All the project documents need to fit into the workbook and be part of the overall structure of project information so that it can be reused and inherited from. The ultimate goal of the workbook is ensure that everyone who needs information has access to the information and gets the information.

Workbook Mechanics: In order to meet the goal of ensuring of everyone access to the information they need, the workbook needs to be maintained and organized. For example, Brooks suggests ordering and numbering all project memorandums (we would call these emails now) so that people can look through the list and actually see if they need information. Brooks points out that as size of the effort, project or program goes up, the complexity of maintaining and indexing the project communications increases in a non-linear fashion. Today’s technical tools like wikis, SharePoint and hypertext markup make curating and sharing information easier than paper and microfiche (if microfiche is before your time, Google it). As a reminder, capturing and reusing IP is required in all types of work. As a coder, it is easy to fall prey to the idea that the code and a functional system is the only documentation required; however, this is false. For most large efforts, capturing decisions, designs, architectures and even the occasional user manual is an option that can be ignored only if you want to court a communication failure. Remember however that over-reliance on documentation is not the goal.

Brooks uses the formula (n2-n)/2, where n is the number of people working on an effort, to define the possible communication interfaces. As the number of people increase the number of interfaces increases very quickly. Organization is a tool to reduce the amount of interfaces. This is one of the reasons why small teams are more effective than large teams. Scaling Agile is often accomplished by assembling teams of small teams. We use the metaphor of trees or flowers are often to describe the visualizations of team of teams. Communications spreading from a central point can look like a tree or flower. Organizations leverage techniques like the specialization and division of labor to reduce the number of communication interfaces.

There is often push back on division of labor and specialization in Agile. This push back is often misplaced. Within a team the concept of T Shaped people, which eschews specialization, increases capabilities; however, teams often specialize thus becoming capability teams. Capability teams often tackle specific types of work more effectively and efficiently by reducing learning curves. Capability teams fit into Brooks’ ideas on organizing to reduce the communication overhead.

Brooks proposes that each grouping of work have six essential needs.

  1. A Mission,
  2. A Producer,
  3. A Technical Director or An Architect,
  4. A Schedule,
  5. A Division of Labor, and
  6. Interface Definitions Among the Parts.

Four of these essentials are easily understood; however, the roles of the producer and technical broke new ground and extended the ideas Brooks began in The Surgical Team. The role of the producer is to establish the team, establish the schedule and continually acquire the resources needed to deliver the project. The role of the producer includes many of the classic project and program management activities, but also much of the outside communication and coordination activities. When small effort with a single team the roles of the producer and technical director can be held by the same person. As efforts become larger and more complex the roles are generally held by separate people. The role of the producer in the Scaled Agile Framework (SAFe) is handled by the Release Train Engineer. The technical director focuses on the design and the technical components (inside focus). In SAFe this role is held by the System Architect.

Brooks leverages the metaphor of the Tower of Babel to focus on the need for communication and coordination. Projects, team and organizations need to take steps to ensure communication happens effectively. Techniques like meetings and project workbooks are merely tools to make sure information is available and organized. Once we have information organization provides a framework to ensure information is communicated effectively. Without communication any significant engineering effort will end up just like the Tower of Babel.

Are there other mechanisms for organization, communication and coordination that have worked for you? Please share and lets discuss!

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

Ready, Set, Go!

Ready, Set, Go!

At the beginning of most races the starter will say something like, “ready, set, go.” At the team-level the concept of ready to develop acts as a filter to determine whether a user story is ready to be passed to the team and taken into a sprint. Ready to develop is often considered as a bookend to the definition of done. As a comparison, the definition of done is applicable both at the team level and at scale when multiple teams are pursuing a common goal. In practice, ready does not scale as easily as done. Ready often requires two sets of unique criteria for scaled Agile projects, Ready to Develop and Ready to Go. (more…)

How many people is too many?

How many people is too many?

When determining how large an Agile program can be, one of the oft quoted “facts” is that the number of people involved in an Agile program is governed by Dunbar’s number. Dunbar’s number is the limit of the number of people in a group that can maintain stable social relationships. The term, social relationship is a reflection of regular interactions, the ability to recognize another member as part of the group or are committed to a common goal. These attributes are important to any project and are perhaps more important in Agile projects because they rely on team cohesion to minimize bureaucracy and control mechanisms.

The concept of Dunbar’s number is based on research originally performed through the observations of primates and then extended to humans in the early 1990’s. In June of 1992, Robin Dunbar  published “Neocortex size as a constraint on group size in primates” in the Journal of Human Evolution (Volume 22, Issue 6, June 1992, Pages 469–493). In the paper Dunbar noted a correlation between the size of a primate brain and the average social group size. From the abstract, Dunbar wrote:

Group size is found to be a function of relative neocortical volume, but the ecological variables are not. This is interpreted as evidence in favour of the social intellect theory and against the ecological theories. It is suggested that the number of neocortical neurons limits the organism’s information-processing capacity and that this then limits the number of relationships that an individual can monitor simultaneously. When a group’s size exceeds this limit, it becomes unstable and begins to fragment. This then places an upper limit on the size of groups which any given species can maintain as cohesive social units through time.

While group size of 150 is often quoted as Dunbar’s number, 150 is an approximation. As noted in the “Limits of Friendship” by Maria Konnikova (October 7, 2014) Dunbar’s number can range from 100 – 200 (ish) people based on factors such a social gregariousness. Other limits of group size have also been published for example Drs. Peter Killworth and Russell Bernard have published numbers in excess of 200 people.

Based on Dunbar’s number, the Scaled Agile Framework Enterprise (SAFe) suggests that the largest Agile release train (ART) should include approximately 150 people. The ART is supported by a framework (SAFe), hierarchy (release train engineer and Scrum masters) and bureaucracy (product management and product owners). Agile being practiced by a single team of 5 – 9 people would not require this degree of overhead to ensure coordination.

Scaling agile is a balancing act between the efficiency of team-level Agile techniques and the concessions made to control when Agile is scaled up to deal with larger efforts. Historically, very large projects tend to be less efficient. Capers Jones in Applied Software Measurement, Third Edition[1] (p295) indicates that productivity falls for all types of projects as they exceed 1,000 function point points. Function points are an ISO standard method of measuring software size based on a standard set of rules. Simply put the larger a project is in function points the larger the team (or team of teams) needed to deliver the project which yields the need for more control processes all other things being equal. He further makes the point (p 307) that as project size increases, so does the probability of cancellation.

Scaling Agile leverages many of the techniques used by team-level Agile, such as small team size, small batch sizes and Scrum. These techniques are are very lean but are perceived limit the amount of value that can be delivered within a specific period of time. As Agile projects grow in size additional techniques are needed to maintain control. Dunbar’s number (or similar ideas) provides a limit to try to avoid letting a piece of work become too large to manage. The number act as limit to the number of people involved in a piece of work. Applying additional constraints, such as releases or SAFe’s program increment, add a dimension of time as constraint. The combination of constraints on the number of people and the how long those people will be working provide an explicit constraint on how much work can be delivered.

1 Applied Software Measurement, Third Edition, T. Capers Jones, McGraw Hill, 2008

Different songs have a different cadence.

Different songs have a different cadence.

If you listen to the radio, talk or music, you will notice that the cadence you hear varies song-to-song, show-to-show or podcast-to-podcast. One cadence simply does not fit all people or situations. Songs, talk or software development the concept is the same.  In Agile, there are three types of cadence variation. They are innovation or recovery sprints, slow then fast and irregular sprints. Organizations tend to push towards a standardized cadence however they a few twists and turns might add a lot of value.

Innovation or Recovery Sprints. Innovation or recovery sprints are sometimes used to demarcate periods of significant development effort. These types of sprints are generally part of larger cadence cycles, just like the changes of seasons mark the boundaries of solar cycles within the overall annual cycle. Activities in these types of sprints often include training, vacations, planning for future sprints or roadmap building. Knowledge generation activities in these sprints often include infrastructure building, prototyping, spikes, building out the architectural runway for the project and hackathons. Sometimes these innovation and recovery sprints are used for catchup or overall integration testing (if not possible during standard sprints). A Scaled Agile Framework Enterprise (SAFe) program increment is generally 8 – 12 weeks long made up of 4 to 6 2-week sprints. The last sprint is an Innovation Planning (IP) Sprint. All of the teams involved in the program increment participate in the IP sprint. In February 2014, Mike Cohn described an overall cadence of 6 x 2 +1, 6 2-week development sprints followed by a 1-week sprint for catchup, recovery and improving the team’s capabilities. The primary goal of innovation or recovery sprints is to improvement the capability of the team (or teams) involved. Learning, planning, exploration, reduction of technical debt and recovery improves the ability to deliver value when the next overall cycle begins.

Slow Then Fast Sprints. This variation is similar to the ebb and flow of cadence in a concert. The overall cadence at the beginning of many concerts I have attended are  generally slower than the cadence at the end. The cadence builds up to generate excitement so that then end of the concert is a crescendo. Recently at a monthly meeting of the Cleveland Agile Group, Chris Bohatka described a project that began with 2-week sprints, however 2 months before the end of the project shifted to 1-week sprints. The shift in cadence used the knowledge and team esprit de corps that had been built to accelerate the cadence and provide new functionality on a weekly basis. Interestingly it was noted in the presentation that the team probably would never go back to the longer/slower cadence. This is one of the VERY few times I have ever seen this behavior. Typically managers indicate that their teams will start with three or four week sprints and then accelerate, then the teams never accelerate their cadences. In theory this behavior seem to make sense however follow through is generally poor because team settle into a rhythm and get comfortable.

Irregular Sprints. While I have heard of Agile teams with irregular cadences, I have never actually seen a team perform in this manner over any significant period of time. Teams that are alleged to have irregular cadences often modify their cadence based on the story size and their inability to break them down. Sometimes implementation of continuous delivery, Kanban or a kanbanny-form Scrumban are confused with irregular cadence. These techniques, heavily influenced by lean, either don’t leverage or deemphasize the idea of cadence. They focus more on the continuous flow of work than on the time box that cadence generates. This is not the same thing as irregular cadence. Irregular cadence is most often a reflection of lack of discipline or a problem with how stories are being groomed.

A sustainable pace is one of the benefits of Agile. Sustainable is sometimes thought of as delivering prioritized user stories every “x” weeks, month in and month out. Innovation and recovery sprints interspersed at regular intervals are a great idea to ensure sustainability. Teams need to learn, innovate and in some cases catch-up to their promises. Interspersing innovation or recovery sprint at regular intervals is reflection of a higher order cadence. Using the knowledge gathered by working as a team, delivering functionality and innovation team can accelerate the cadence, or at least has the option so that functionality can be delivered sooner AND feedback cna be gained sooner. Irregular sprints rarely make sense unless teams are ready to move to continuous delivery. Cadence in Agile projects promotes predictability and discipline which are attributes valued by both IT management and the business.


In a recent discussion of the concepts of Cost of Delay (CoD) and Weighted Short Job First (WSJF) the used of tables and mathematical formulae led to a discussion of accuracy and precision.  The use of  math and formulae suggest high levels of accuracy and precision even though the CoD and project sizes used were relative estimates. One of the questions posed in the class was whether the application of WSJF, or for that matter ANY prioritization or estimation technique is actuate enough to use in making decisions when the input is imprecise estimated data. Techniques like CoD and WSJF when used to prioritize work are generally based on estimates, rather than ultra-precise measures. Remember the of techniques like WSJF is to generate accurate priorities so that the most important work gets into the pipeline. Prioritization based on frameworks like WSJF require an understanding of the concepts of accuracy and precision and what is required in terms of accuracy or precision when prioritizing work. Often the two concepts are conflated however the two concepts of accuracy and precision are different but interrelated.

Accuracy is defined as how close a measured value is to the true value (www.mathisfun.com) or as freedom from mistake or error (www.merriam-webster.com/dictionary/accuracy). In some instances, accuracy is easy to judge. For example, (Pi) to 10 decimal points is 3.1415926535 (if you are a geek, PI to a million). Whereas Pi calculated to two decimal points is 3.14. Both are accurate. Judging accuracy gets messier when the outcome is unknown, for instance generating an estimate for project prioritization. In order to judge accuracy we generally apply a decision making rule or standard which is typically expressed as a confidence interval or a degree of risk. Another popular alternative is to use a comparison to a relative measure, such an analogy or story points. In order for anything to be perceived as accurate it has to be within the standards set so that the organization can have confidence as they prioritize work.

Precision is a reflection of exactness. In the example of Pi, the 3.14 is accurate but not precise. Calculating Pi to a million decimal points increases the level of precision but doesn’t make the calculation precise. PI is an irrational number we will never be able to calculate PI precisely. In software development, most activities required to deliver business value have some level of variability in performance. Variability makes precise prediction difficult or impossible. Estimates of software development are imprecise by nature. Imprecision driven by the variability in the processes and by the inability to know all the factors that will be encountered makes precision difficult at best. Precision is typically generated by padding the estimates, cutting or adding scope so that the outcome matches the estimate, or in some cases fibbing about the results.

Given effort and consternation that often are often taken to generate false precision, a better avenue is to define an acceptable level of precision so that accuracy is an artifact of doing the work rather than an artifact of controlling how the work is measured. For example, estimating that a piece of work will be done at 2:33.06 PM EST takes far more effort than estimating it will be completed this afternoon.  Both estimates could be equally accurate although the later has more chance at accuracy. Techniques like CoD and WSJF when used to prioritize work are generally based on estimates, rather than ultra-precise measures. The goal is to generate accurate priorities so that the most important work gets into the pipeline. Like many things in Agile and other iterative frameworks, just because a piece of work is not at the top of the list today does not mean its priority can’t increase when the list is reassessed. Organizations have to decide what level of precision is really needed and whether they are willing to trade precision for accuracy.

This weekend I am going to run the 35th Annual St. Malachi Church Run in a time of roughly fifty minutes. The race is five miles long and the forecast is for a very cold rain. In this case, my estimate is probably accurate (time will tell), but not precise. Last year, I actually ran the race in 49.06.36 minutes. The measured results are very precise and are accurate within the tolerance of the measurement system used (chips in the race bib). While I feel faster this year, but I am a bit heavier and a bit older which increases the possible variability in my speed. In terms of setting expectations, I think I would rather be accurate than precise so that my support team can meet me with the umbrella without have to stand in the rain too long themselves.

PS March 14th is Pi Day – have an irrationally good day!