The order of these articles are not motivated by chronology but by what I have witnessed as the biggest inefficiencies by agile teams as I have mentored agile development teams on agile practices and tools. To keep things brief, please allow me the luxury of interchanging the variety of agile terms for the same concepts (e.g. Stand-up or Scrums, Sprints or Iterations). And for the sake of illustration when it comes to tooling, I will most often be using Team Foundation Server (TFS) for the purposes of illustration, but these agile development techniques should apply across many tool-sets.
Given that, let’s start with the Daily Stand-up meeting. (For the sake of sanity, please insert the equivalent agile term of your choice – i.e Iteration/Sprint) Ridding even small inefficiencies to an all-team-meeting that occurs every working day can have large impacts on an organization’s time, money, morale, etc. But wait! Those of you with already efficient stand-ups (most say 10 to 20 minutes in length) should pause a moment and answer the question – is our stand-up meeting meaningful? If not, you just need horse sense (and not a process engineer) to tell you to chuck meaningless tasks. But hold your horses! After years of agile practice under our belts in our industry practice, meaningful daily stand-ups is still held high as a core principle for successful self-organizing teams because of its ability to eliminate countless other meetings several times its length. So consider these tweaks before jettisoning this precious baby with your bathwater.
Every agile team out there seems to have grasped that this meeting has to do with the answers to some variation of three basic questions:
(Now, having a popular practice like this in our industry survive this long without having someone attach a goofy mnemonic to it has got to be a record – so for the record books – let’s call it “Dave’s 3-D Daily Stand-up: Did, Doing, and Dam”
OK, for your personal use you may want to leave “Dave’s” off, and please use good discretion before using the homophone that adds an “n”
to the last word [though both meanings could apply in this case.] LOL — I digress.
What I Did\accomplished yesterday; what I plan on Doing today; and what Dams\Impediments stand in my way.
The biggest problem I have found is that without an effective use of tools and leadership, many teams see the goal of this meeting as merely extracting the answers of these three questions from team members rather than using the answers to these questions as the factual beginnings for a collaborative, requirements-conquering daily exercise. The former meeting sounds like dental work (or some controversial Guantanamo exercise), while the latter meeting is something I want to be a part of. Leadership is key to making the latter process a possibility, but the lower hanging fruit of effectively using our tools is the topic I hope to reasonably point the way to in this blog series.
Since the dawn of agile teams, one of the most popular visual tools used in the stand-up meeting has been the task board which early on usually took the form of sticky-notes on the wall, but today’s tools have evolved into its electronic tree-saving look-alike. Regardless, it gives 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).
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. To get more of these questions visibly answered (and not take up valuable time asking them) I always see how we can configure the tool to show all 3. In the TFS example above, we can address the glaring omission of visible dams by configuring TFS to show the following work item types on the task board as well:
- Sprint (or Iteration) Bugs: See MSDN’s Add bugs to your backlog or task board, but rather than choosing the backlog or the task board, just create another work item type and call it “Iteration Bug” or “Sprint Bug” and keep “Bug” as it is. If we are going to produce a “shippable product” every sprint, each feature’s “Definition of Done” better include making it past a tester who tests as early as possible during our sprint. Yet inevitably, there are bugs discovered in our work after the sprint or even during the sprint which we defer a fix for until later iterations. Also notice the addition of the “READY FOR TEST” column which I add as an important additional visualization for this task type.
- Configure TFS to show an impediment in your task board: A Scrum Master becomes appreciated especially when he/she is actively removing impediments the team runs into while trying to get things done. This makes impediments a first-class citizen on our team’s task board and 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 down chart gets distorted by these.)
The colors used for bugs (red) and impediments (orange) above are configurable as well.
Rather than making the goal of the meeting getting the dry 3 D’s answered in everyone’s 10 to 20 minutes, let’s tweak our tools to make the 3-Ds our visible starting points so we can more quickly get to the meaningful and interesting business of organized collaboration during those precious minutes.
Download our complete Mastering The Daily Agile Stand-Up eBook!