The More Things Change…

Posted by Doug Dockery on October 27, 2014 in Agile, SAFe, Scaled Agility, Scrum |

I’ve been reading posts on netObjective’s blog.  NetObjectives was founded by Al Shalloway – one of my favorite Agile movement personalities.  I found a piece he wrote about how where an Agile transformation starts seems to influence it forever.

It’s an interesting read.  I think you’ll enjoy it as well.

How Where an Approach Starts Seems to Influence it Forever

Your Own Inner Voice – Steve Jobs

Posted by Doug Dockery on October 27, 2014 in Uncategorized |


Welcome to the Party Mr. Schwaber

Posted by Doug Dockery on October 25, 2014 in Agile, SAFe, Scaled Agility, Scrum |

Based on his newest blog post, it appears that it’s time to welcome Ken Schwaber to the Scaled Agility party.  Long a critic of ‘frameworks’ that provide a structure for scaling Agile processes through organizations, Mr. Schwaber’s latest blog post announces his newest offering – drumroll please – a framework.

Scrum is fantastic at the team level and Mr. Schwaber should be congratulated for driving Scrum’s acceptance in thousands of organizations worldwide.  However, Scrum alone isn’t enough – simply creating Scrum teams won’t solve an organization’s largest problems (and will, in may instances, simply make the larger problem worse).  Scaling Agility, via a customized framework like the Scaled Agile Framework (SAFe), will.

Agility at the organizational level allows the business, groups of development teams, and all other involved parties to understand priority, plan together, and delivery together.  Scale allows organizations to focus on the creation of value – not in small, two week increments, but at the portfolio level.  Ensuring that the portfolio level initiatives that make or save the most money for the organization are delivered first.  It is these large, portfolio level initiatives that truly make a difference for an organization.  And Scrum alone simply doesn’t address the organizational coordination that these large, multi-team, complex items require.

Setting aside all differences of opinion about Mr. Schwaber’s long held positions about frameworks, I’d like to offer him a hearty welcome to the party.  Scaled Agility is a big tent – there is room for everyone – and Mr. Schwaber’s knowledge and ideas will help make Scaled Agility better for everyone.

How to Build a Minimum Viable Product

Posted by Doug Dockery on October 23, 2014 in Agile, Scrum |


The goal of each iteration should be to provide value.  This graphic illustrates it better than almost anything else I’ve seen.

Agile Smells

Posted by Doug Dockery on October 22, 2014 in Agile |

Okay, that might be the oddest blog title I’ve ever written.  However, I’ve found an amazing blog post that talks about the ‘smells’ of Agile done poorly.

Software Antagonistic Pleiotropy (easy for your to say) is a fantastic blog from Australia that I’ve been reading recently.  Their tag line ‘Because what makes you stronger will also kill you” sort of sums up my feelings about the ‘Agile’ movement in its current state.

Here’s an excerpt from the first part of the Agile Smells series of posts that hooked me:

After seen Agile done well, and badly I started to become aware of “smells”. These smells are signs that despite of an Agile veneer, it’s not agile at all. A side point is that the word Agile has lost its meaning. It became this silver-bullet-buzzwordy thing and now it’s close to worthless. See, the point is not Agile, the point is to get better at developing software.

Here’s the link to the first in this fantastic series: Agile Smells.  Read it.  And go look for the smells in your organization.

The Cost of Context Switching

Posted by Doug Dockery on October 20, 2014 in Agile |

Context switching is simply working on one project, then switching to another – where neither are worked to completion.  I have heard people use a figure of twenty percent (20%) productivity loss as the “cost” that is paid for working on two projects at a time but have never seen where that number came from.

In trying to come up with a better answer for how costly context switching is for team, I found the book Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer and Juan J.Perez, in which they describe a famous proposal by Gerald Weinberg in his book Quality Software Management: Systems Thinking.  Mr. Weinberg’s book proposes the following as a rule of thumb to compute the waste caused by project switching:


Nbr. Simultaneous Projects Percent of Time on Project(s) Time Lost to Context Switching
1 100% 0%
2 40% 20%
3 20% 40%
4 10% 60%
5 5% 75%


While I do not know if the above numbers are 100% accurate, there is no doubt that as a developer working on multiple projects you tend to ‘leak time’ due to having to re-establishing the current state, where you were at, what needs doing, etc. each time you change what you are working on. But the books referenced suggest that this loss is more significant than one might initially think.  The cost is especially significant when a team is working on more than two projects.

It has been said that one of the integral parts of programming is the fact that you have to hold a large amount of information in your head while you craft your code – wiping this clean, as if clearing a whiteboard, and then having to effectively re-draw it all again at a later date is undoubtedly costly and difficult.  A skilled, well organised software craftsman can minimize this risk so that the effort to pick up where they left off takes a minimum amount of time, but they cannot remove the cost completely.

In The Multi-Tasking Myth blog post by Jeff Atwood, the following statement is made concerning both context switching and allowing too many distractions (meetings, email, etc.) to effect the team:

We typically overestimate how much we’ll actually get done, and multi-tasking exaggerates our own internal biases even more. Whenever possible, avoid interruptions and avoid working on more than one project at the same time.

To summarize the research around this topic, people are proven to be very poor multi-taskers.  Switching from project to project is an extremely costly activity and should be avoided as much as possible.  The timebox of the Sprint, that forces our teams to work on an agreed upon, fixed set of activities; and the rigor put in place by the accountability of the Daily Scrum allow Agile teams to avoid context switching to an extent.  But even when our teams must switch from one project to another, the practice of not allowing changes to the ‘scope’ of a Sprint coupled with the concept of ‘thin slicing’ value allows the team to focus on delivering specific user stories and therefore, value, prior to moving their focus to a new set of activities.  While these techniques allow us to combat the costs of context switching, the only real solution is to prioritize the team’s work, and Sprint on that work until it is complete.  Only then can the team switch to a context without a significant cost.


Scaled Agile Framework (#SAFe) 3.0

Posted by Doug Dockery on October 16, 2014 in Agile, SAFe, Scrum with Comments closed |

SAFe 3.0 Big Picture

Distributed Scrum Game: Epic Bedtime Story

Posted by Doug Dockery on October 15, 2014 in Agile, SAFe, Scaled Agility, Scrum with Comments closed |

I collect games and activities to demonstrate Agile concepts, Scrum, Scaled Agile Framework (SAFe), etc.  Since I’ve been at Rally Software, I’ve led several, of what we call, SAFe Workshops.  Basically, a group activity that leads groups of teams through release planning and the activities required of teams of teams working on Features for a release.

The following is a new activity that I found on that demonstrates why teams should be co-located.  Distributed teams are an unfortunate fact of life, but the make things more complex – especially for new teams.

Epic bedtime story


The goal is to create a children's book of 10-12 pages within 40 minutes using 2 to 6 teams.

Timing – 40-60 minutes


-Paper (20 to 50 sheets)
-Markers or crayons (1 box of 10 colors by team of 5)



  • If you have the opportunity to do so, set up the room so that teams of 5 will already be together.
  • Select one person in the room to be the creator, sit him/her in front of the room. Works even better if you have somebody you can give the book after.
  • Explain roles and how the game will be played.
  • Walk across the room, gives advice during sprint 1 but not sprint 2.
  • Ask team how confident they fell they will succeed and why they should not for retrospective.

You will recognize the analogy there with Scrum roles vs specialties vs cross functional teams.

Creator (only one creator) – The creator is the one with all the answers. He is not a member of any team and is shared.

  • Wants a Story that can be read to a baby and that the kids could be reading by themselves when they are old enough to read.
  • Wants only one main character.
  • Wants images and texts to be on the same page.
  • Does not want the book to be more than N pages long.

Writers  – The writers will decide what will happen in the story and write the script.
Illustrators – They draw the images, have to be consistent with the writers and editors choices.
Editors – Editors will decide on the overall look of the book, page orientation, grammar, consistency.

Teams are distributed

They need to sit as far away from each other as possible as if they were in different countries or even timezones.

And one last tip that could be really helpful

A children’s book can be simplified as the following…

  • Cover page
  • Introduction
  • Exposition
  • Rising action
  • Climax
  • Falling action
  • Resolution
  • Lesson learned


Part 1 - Explain the roles and how the game is played - 5-10 mins


Part 2 - Planning (10 mins)
  • Give teams 10 minutes to self organize and plan the work, knowing they will have to work together, split the work and listen to the Creator.
Part 3 - Sprint 1 (10 mins)
  • 10 minute sprint to create a draft
  • 5 minute retrospective (internal to the teams)
Part 4 - Sprint 1 retro (5 mins)
  • 10 minute sprint to create a draft
Part 5 - Sprint 2 (10 mins)
  • 10 minute sprint to create a final version.
Part 6 - Demo/Review/Retrospective (15 mnins)
  • Review with the Creator, what does he/she thinks of the result.
  • The whole group discuss about the difficulties they’ve had.

Learning points

  • Teams want and need to communicate to each other even when they are not in the same team/location.
  • We “may” have trust issues and that affects quality and effort.
  • Overcompensation.
  • Not knowing what’s going on at the other end makes some team members insecure. Teams are performing better when they have better visibility (trust).
  • People not familiar with Scrum understand the challenges and how deciding to work with distributed teams has an impact.

How to Split a User Story

Posted by Doug Dockery on October 14, 2014 in Agile, Scrum with Comments closed |


Is your Agile transformation in the ‘Valley of Despair”?

Posted by Doug Dockery on October 13, 2014 in Agile, Scrum with Comments closed |



  1. 1.
    the complete loss or absence of hope.
    driven to despair, he throws himself (or his boss) under a train”
    synonyms: hopelessness, disheartenment, discouragement, desperation, distress,anguish, unhappiness

  1. 1.
    lose or be without hope.
    “we should not despair – Agile metrics can save us”
    synonyms: lose hope, abandon hope, give up, lose heart, lose faith, be discouraged, be despondent, be demoralized, resign oneself

If your Agile transformation is heading for an early exit or the ‘Valley of Despair”, metrics can save you. We all know that you can’t compare teams on the basis of velocity, but metric driven, objective decision making is possible and will make a tremendous difference. Rally Software’s Insights product is the best way I’ve found so far to collect metrics and be able to make fact based decisions about your Agile teams. Click this link for more information about Insights.

Copyright © 2013-2014 Doug's Blog All rights reserved.
This site is using the Desk Mess Mirrored theme, v2.2.4.1, from