2012 – © - All Rights Reserved

A Training Division Presentation

Agile Development:

Keeping Daily Stand-ups Efficient and

Meaningful

By Dave Zimmerman

• Start: Daily Stand-up meeting

• Ridding even small inefficiencies to all-team-meeting that occur every working day can have large impacts on an organization’s time, money, morale, etc.

• Is our efficient (10 to 20 minutes in length) stand-up meeting meaningful?

• If not, chuck meaningless tasks

• Meaningful daily stand-ups still held high as a core principle for successful self-organizing teams

• Because of ability to eliminate meetings several times its length

• Consider these tweaks before jettisoning this precious baby with your bathwater

• The three basic questions to this meeting:

• Did? Doing? Dam?

• “Dave’s 3-D Daily Stand-up: Did, Doing, and Dam”

• What I Did\accomplished yesterday

• What I plan on Doing today

• What Dams\Impediments stand in my way

• The biggest problem (without an effective use of tools and leadership)

• What teams do:

• see the goal of this meeting as extracting answers of these three questions from team members

• What teams actually should do:

• use answers to these questions as the factual beginnings for a collaborative, requirements-conquering daily exercise

• Leadership is key to making the latter process a possibility

While this row in the task board does a fair job of showing the “Did”s, and a good job of showing the “Doing”s, it gives me no visibility into the “Dams” of an individual or team.

• The task board

• Early form: sticky-notes on the wall

• Today’s version: Team Foundation Server

• Both give us a nice visual of the progress of tasks we see as required to complete the requirements we have committed to for this sprint

Below is the “out-of-box” Scrum task board shown in Team Foundation Server (2013- with update 4).

• Configure the tool to show all 3 questions (Did?, Doing?, Dam?)• Get more of these questions visibly answered • Not take up valuable time asking them

• Address missing visible dams (previous slide example)• Configure TFS to show the these work item types on task board:

1. Sprint (or Iteration) Bugs: • See MSDN’s Add bugs to your backlog or task board• Instead of choosing the backlog or task board - create another work item type

• Call it “Iteration Bug” or “Sprint Bug” • Keep “Bug” as is

• If producing “shippable product” every sprint:• Each feature’s “Definition of Done” must pass early tester – testing early as possible during

sprint• Bugs still discovered during and after sprint (which we defer a fix for until later iterations)

• Notice important additional visualization for task type of “READY FOR TEST” column

2. Configure TFS to show an impediment in your task board: • A Scrum Master becomes appreciated when:

• He/she actively removes impediments the team runs into while trying to get things done

• Impediments becomes a first-class citizen on task board• Highlighting these important visual facts for our team’s stand-up conversation is

key

• (Note: Since we do not assign an hours capacity to the Scrum Master, I do not require remaining work for these work items or a remaining work burn downchart gets distorted by these.)

The colors used for bugs (red) and impediments (orange) above are

configurable as well.

• Tweak tools to make the 3-D’s our visible starting points

• Rather than making the goal of the meeting getting 3 D’s answered in everyone’s 10 to 20 minutes

• Get to the meaningful and interesting business of organized collaboration during those precious minutes

• Other visual gaps in the “Did’s” (what was accomplished since our last stand-up meeting)

• Can be equally egregious at turning stand-ups into tedious status gathering meetings

• A naïve response to this issue might be:

• “but every task board’s done/completed column shows what was completed…”

• But to that, any team who uses task boards in practice knows that this is only a reliable visual on day 2 of Sprint 1 for a team on a typical task board. After that, the visuals quickly get muddied…

• We want “statusy” information answered visibly as a starting point to the agile development stand-up

• Don’t waste valuable time with whole team extracting it from each individual

• Using TFS as my illustrative tool, I unfortunately don’t have quite as convenient of a configuration recommendation (My feedback to Brian Harry’s team was to use the nice visual that occurs when one selects the view of the task board that highlights an individual team member [instead of “All”]

– still showing all tasks, but grays out those work items not assigned to that team member.)

• In TFS, I use one of two options:

• [Option 1] Use the Iteration Backlog Board view:

• Rather than use the standard “Board” view, click “Backlog” to see the tree view of the iteration backlog items.

• This allows you to select “Column options” to see the “Changed Date” (and time) next to each work item.

• I like this because…

• You can see long titles better than you can in the task board

• The date is visible for everyone

• Colorization of requirements (Bug vs. Story) is visible

• I don’t like this because…

• I have to work to read the “State” of tasks, rather than visually seeing them placed from left to rate.

• This view does not yet allow me to order the rows by changed date.

• [Option 2] Keep the task board view, but have the information off screen:

1. How do we best gather this information for our use?

• Most work item tracking systems have ways to query and present work items - TFS is no different

• Here’s a visual of the web query editor for my “Sprint Backlog (changed since yesterday) query when using the Sprint process template – drawing your attention to key query terms to make this happen:

Steps:

1. Use the “Tree of work items” query • So we always see the work items in the context of the requirement

2. Filter linked work items by “Changed Date >= Today – 1″ or …”>= Today – 3” • For your query used on Monday

3. Match linked work items first (OR some prefer — not pictured) “match top-level work items first” in which case you will need to use the same “Iteration Path” filter on your top level work items as you do on the linked work items

4. Configure the “Sort columns” to order by “Backlog Priority” (field name varies by template) “Asc” (Ascending) then by “Changed Date [Desc] (Descending).” • This ordering is helpful because primarily we want to review requirements in the order they appear

on the task board for our own visual mapping when facilitating the discussion; secondarily, we want the information concerning the order things were worked on since last stand-up rising to the top.

2. For stand-ups the Scrum Master should always have other monitors available where valuable information is readily available for facilitating the discussion around the current visual being discussed

• In this case, this goes a long way towards facilitating efficient and meaningful daily team coordination meetings rather than inflicting team-torturing daily status meetings

• Poor Meeting Conduction Style:• The Scrum Master goes around the

room and addresses the 3 questions to each of the team members, e.g. “So let’s find out from team member Sally…” (or visually answer if following the strategies of my posts thus far) … what she “did” yesterday, is doing today, and if she has any “dams” in her way…

• This not only confuses but completely sends the wrong message to an agile team

• To me this question belongs at best to a one-on-one conversation between a Scrum Master and a team member and at worst an employee review or perhaps as a caption to the scene depicted in the New Yorker’s cover of Steve Job’s and St. Peter at the pearly gates

• “Dids, Doings, and Dams” subject of the question:

• always addressed to the collective “You” in English

• First: “Stand-up Monologue”

• On a very practical level the dynamic of jumping from requirement to requirement that one person may have contributed to, and then often times revisiting those stories as subsequent people are interviewed is very disorienting

• Only the person talking (and maybe the story owner) can follow what the heck the person is prattling on about

• Therefore, people mentally check out of what is best described as the “stand-up monologue”

• Second: “Self-Organizing Teams”

• Agile software development is fundamentally founded on the principle of self-organizing teams working together to meet the commitments they had made at the start of a sprint, and working on things in the order of priority for that sprint

• Using TFS as an example, I have often seen the Scrum Master “use” the filter by person feature in the context of a stand-up meeting

• (In my opinion, I would say “misuse” this feature that is effective at best for individual task list views allowing one to drag-drop his or her assigned work back-and-forth through the states of completion)

• As a result of this practice:

• The team’s daily focus becomes the achievements of the individual

• Rather than how we collectively are organizing ourselves in a way that gets each of the sprint’s requirements across the line to “done” – in order of priority

• In contrast, when a team keeps the task board filter set to “All” and addresses unfinished requirements top-down on the task board, they daily reinforce the agile development mindset that we are all working towards our commitment to rolling out working software according to the agreed upon priorities of the business

• Because of our discipline in looking at the stories in this fashion, our collective conscience is pricked on a daily basis if crickets chirp when addressing higher priority stories and no discussion ensues about their progress

• My growing sample size of experience (and many I have spoken with) is mounting evidence for me that those who adopt the second approach to stand-up meetings more quickly self-correct the situations where even though individuals may be “working like dogs”, they get to the end of a sprint and must collectively hang their heads

• Either the team gets to the end of a sprint and:

• One: were unable to mark requirements as done due to straggling tasks

Or

• Two: completed requirements but neglect requirements of higher priority commitments up the task board

• Again, my experience is that the latter approach fosters a situation where teams collectively take credit for victories

• This dynamic is best illustrated for me by the team captain of the 1980 US Hockey team Mike Eruzione when he insisted that his fellow teammates squeeze onto the gold medal podium with him rather than adhering to the tradition of having team captains enjoy this honor

• And while hanging one’s head is self-correcting, I find there is something even more motivating about the victories collectively experienced

• Job Satisfaction

• Biggest goals in coaching agile teams is to get them to experience the joys of this level of cohesion as quickly as possible

• it is ultimately that which fuels velocity and a wonderful by-product (job satisfaction) of the whole endeavor

• “One Team One Dream”

• This mindset is best characterized by the phrase which has become a running theme for years at our company

• As I have just done, it is quite natural to hear my coworkers refer to Intertech as “our” and not “our boss’s” company

What’s Next?

Stand-ups are one piece of the Agile methodology that companies need to implement to realize the full benefits of the practice. Once you’ve mastered the Stand-Up and are interested in taking that next step, Intertech has deep experience working with companies to implement Agile methodologies throughout the organization. In fact, we’ve done it at our own company and practice it daily.

• Learn more about our Agile and Scrum Consulting practice on our website. You can find case studies as well as descriptions of the full breadth of our consulting and implementation practices.

• Along with our consulting practice, we offer private, on-site Agile Training options as well as bi-monthly public classes at our headquarters. Check out our Agile and Scrum Class Offerings.

Want to read the entire eBook? Download it here!

• Want to see an Intertech stand-up in action?

• Watch our video on How We Use Agile: