I wrote a short post called “Is The Daily Stand-Up Harming Your Team”.\u00a0 After getting some feedback on it, I have\u00a0refactored it and here is the new version.\u00a0 (I have deprecated the old version):<\/p>\n
Here is a short definition from “Planning Extreme Programming” (Beck\/Fowler 2001):<\/p>\n
Have a short meeting every day so everybody knows what’s going on, and what’s not.<\/p><\/blockquote>\n
The\u00a0Daily Stand-Up\u00a0meeting is meant to be a very short meeting with several related purposes:<\/p>\n
\n
- \n
Team Alignment or “sync-up” – who is working on what, what’s been done, what do we need to discuss…<\/div>\n<\/li>\n- \n
Expose issues that need to be handled (impediments, etc.)<\/div>\n<\/li>\n- \n
Eliminate other meetings that can “hog time”<\/div>\n<\/li>\n- Allow some other people not on the team to hear about things the team is doing<\/li>\n
- etc – put your own things you value about\u00a0Stand-Ups here.<\/li>\n<\/ul>\n
Those all bundle up to one thing: Daily communication about important stuff.<\/p>\n
Good Communication Is Essential for Software Development<\/h4>\n
Programming is done by individuals who must communicate with each other.\u00a0 Finding ways to communicate well makes things a lot better.\u00a0 The Agile Manifesto itself puts a lot of focus on the importance of good communication.\u00a0 A quick glance at the Manifesto and Principles makes this clear:\u00a0\u00a0Individuals and Interactions<\/strong>, Customer Collaboration<\/strong>, Responding<\/strong> to Change, business people and developers must work together daily<\/strong>, face-to-face conversation<\/strong>, self-organizing teams<\/strong>, the team reflects<\/strong> on how to become more effective.\u00a0 Almost every Value and Principle somehow reiterates the need for good communication.<\/span><\/p>\n
I “buy in” to all of this.\u00a0 In my opinion, a BIG part of becoming and staying effective\u00a0in software development is to continually improve our ability to communicate – team member to team member, team to customer, business people to team, and whatever combination you need.\u00a0 As we find problems with traditional communication methods (such as\u00a0meetings, emails, documents, charts, yelling, \u00a0etc.) we need to explore “better”.\u00a0 Even more important,\u00a0when we find something is working for us\u00a0we should explore how to make it even better.\u00a0 Whatever we do, no matter how good, there is always “better”.<\/span><\/p>\n
A little Background:<\/h4>\n
A number of years ago (about 10 or 11 years I guess) I started visiting Agile\/Scrum\/XP development teams\/departments and observing Stand-Ups and other meetings – just for the fun of it . \u00a0I’d been\u00a0doing XP\u00a0for several years, and loved visiting other teams – mostly for my own enjoyment, but also to learn how others were doing things. I have visited a number of teams and departments over the years – about 20 or so.\u00a0 I am not a consultant as such – so these were casual visits.<\/p>\n
What I noticed in visiting teams doing Stand-Ups<\/h4>\n
I noticed a few harmful things in a majority of the Daily\u00a0Stand-Up meetings I observed.\u00a0Things such as:<\/p>\n
\n
- Individuals taking a long time (5 or more minutes each rather than 2 minutes)<\/li>\n
- Meeting taking too long (45-60 minute standups – more like “lean-ups” after a while)<\/li>\n
- Too Much Detail, Not enough Detail<\/li>\n
- People not showing up on time<\/li>\n
- Too many people (10 or 20 people) – attendees are hearing about stuff that isn’t relevant to them.<\/li>\n
- Mumbling and Grunting<\/li>\n
- Discussions\u00a0between 2 or 3 team members to resolve some aspect of something<\/li>\n
- Yelling<\/li>\n
- No one is interested in what the others are saying (and often without any reason to be interested)<\/li>\n
- Issues brought up are never addressed<\/li>\n
- Needed follow-up meetings never occur<\/li>\n
- Same report every day<\/li>\n
- Dogmatic enforcement of rules<\/li>\n
- … I can go on and on. I used to take notes and had about 20 different issues that commonly showed up.<\/li>\n<\/ul>\n
I have seen a lot of these same dysfunctions on teams I\u00a0‘ve worked with over the years.\u00a0\u00a0Some of these teams have discovered ways to reduce or even eliminate most of these\u00a0“Daily Stand-Up” dysfunctions.<\/p>\n
There have been\u00a0countless blog posts, book chapters, workshops, conference sessions,\u00a0etc. on solving “Daily Stand-Up”\u00a0problems – which is great.\u00a0 It is a good thing to\u00a0recognize\u00a0problems and solve them.<\/p>\n
But I think there is a “next step” we can take.\u00a0\u00a0For me, when I see something causing this much\u00a0trouble for so many different folks and teams,\u00a0in so many dfferent ways, over and over again\u00a0– I start to wonder if there is something\u00a0we are all missing.<\/p>\n
My first question was: Why do so many teams have so many problems with Stand-Ups???<\/h4>\n
The Daily Stand-up is a fixture in most Agile\/XP\/Scrum environments.\u00a0 It has a very simple purpose, and is a very simple meeting – and yet, many teams continue to have these problems. Why???\u00a0 Well,\u00a0 that is too complex for me to cover completely\u00a0here (I could cover some of that in a future post if anyone is interested)\u00a0–\u00a0what I want do\u00a0do instead is\u00a0share what I have discovered\u00a0after investigating this for about\u00a05 or 6\u00a0years. I’ve done\u00a0a number of\u00a0“5-whys”\u00a0root-cause analysis sessions,\u00a0and retrospectives\u00a0on vairous Stand-Up problems, and I’ve read as much as I could find on the topic.<\/p>\n
Here is what I think I have found:<\/p>\n
At the bottom of many of my “5-why” Sessions<\/h4>\n
You’ve probably all done something like a 5-Whys analysis. From Wikipedia:<\/p>\n
The 5 Whys is a question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem.<\/p><\/blockquote>\n
With manny of the\u00a0dysfunctions I was investigating,\u00a0I would end up at about the same place.\u00a0 Typical starting questions were:\u00a0“Why do team members think the Stand-Up is boring”, or “Why do we have too many things we need to cover in the Stand-Up”, or “Why does our Stand-Up take so long”.\u00a0 As often as not,\u00a0the near the bottom of\u00a0my “5-why” session was this question: “Why do we think we NEED Stand-Ups?”, and the\u00a0answer I often\u00a0end up with is “The Daily Stand-up exists\u00a0because we are not in continuous alignment. We need the meeting because there are things we are not communicating during the day”.\u00a0 So that leads to this question: “Why aren’t we in continuous alignment?”.<\/p>\n
Why aren’t we in continuous alignment?<\/h4>\n
That is:\u00a0If we could be in “continuous alignment”, and find we have nothing to communicate in the Daily Stand-Up, we wouldn’t have any of the dysfunctions of the Daily Stand-Up because we would no longer be holding them.<\/p>\n
Would it be good to be in Continuous Alignment?\u00a0 What if it was\u00a0possible to effectively and efficiently stay in\u00a0“continuous alignment” how would that change our thinking about\u00a0the need for Daily Stand-ups?\u00a0 Some teams have been very happy with the Daily Stand-Up, and find that it brings a lot of value.\u00a0 Still, even in those environments, there is always room for improvement.\u00a0 In Agile\/Lean\/XP\/Scrum it is important to continuously scrutinize the practices we are using and innovate even better ways to do things.<\/p>\n
It seems worthwhile to me to at least explore the possibility that there is something even better than\u00a0well functioning\u00a0Daily Stand-Ups.<\/p>\n
Are You Saying\u00a0We Should Just Stop Doing\u00a0Our Daily Stand-Up?<\/h4>\n
Of course not.\u00a0 But this hints at\u00a0an important “next step”:\u00a0 Let’s figure out how to\u00a0have continuous alignment.\u00a0\u00a0Some common\u00a0practices that many teams already use are things like:\u00a0Task Boards that everyone can see and that are dynamically updated as work gets done, sitting together (so you can hear anything imporant that is happening), pair-programming, switching up pairs frequently (several times a day),\u00a0raising “blocking issues”(and solving\u00a0them)\u00a0immediately rather than waiting until a meeting,\u00a0 TDD, CI,\u00a0and whatever you can think of.\u00a0 The more complete and meaningful you can be with dynamic communication the better chance you have of being in continuous alignment.<\/p>\n
Of course – these practices will not necessarily elminate the need for the Daily Stand-Up – lots of teams use them and still find they have a need for the Stand-Up, but they will very likely\u00a0resolve a lot of the traditional “Daily Stand-Up” issues I listed above.\u00a0 A shorter Daily Stand-Up that is more meaningful\u00a0for the team could be a worthwhileend result.<\/p>\n
What are the Costs of “Continuous Alignment”<\/h4>\n
The “costs” for being in “continuous alignment” should be small – it’s a matter of discovering the things you need to communicate and a mechanism for doing having those communications.\u00a0 Most Agile teams are already doing a lot of the practices that help provide good communication throughout the\u00a0day – it’s just a matter of fine-tuning them, or “turning them up a notch”.\u00a0\u00a0Becomming better at communication is a benefit in any team situation. We can choose the Daily Stand-Up over Continuous Alignment, vice versa, or both in some combination.\u00a0 Each time we find something in a Daily Stand-up that should have been communicated earlier we should look into it and figure out how we could have communicated it dynamically.\u00a0 The main cost is that you’ll need to pay a lot more attention for a while – but as you smooth things out it will become natural to gravitate to better forms of communication.<\/p>\n
What My Experience Has Shown Me<\/h4>\n
If we have continuous alignment, there is little need for a Daily Stand-Up.\u00a0 When it gets to the point where we gather in the morning for our Daily Stand-up and consistently find we have nothing useful to share\u00a0it is likely that the practice can be retired.\u00a0\u00a0In the “Lean” sense, a\u00a0practice is\u00a0waste if it brings no value.\u00a0 Waste is not neutral, it diminishes the team – it is a cost that has no return.\u00a0 With my current team we’ve worked without Stand-Ups for over\u00a0a year and have found no need for them.<\/p>\n
Here are some of the practices we follow that allow us to do this:<\/p>\n
\n
- We work together througout the day<\/li>\n
- We meet at any time there is something important that needs to be addressed<\/li>\n
- We pay attention to update our dynamic “information radiators” as we work<\/li>\n
- Anytime we need help we ask for help<\/li>\n
- Anytime someone asks for help, we help<\/li>\n
- We meet face-to-face for all meetings whenever possible<\/li>\n
- We all work on the same thing until it is done or there is nothing further that can be done with it (“one story at a time”)<\/li>\n
- We solve blocking items immediately if possible, and communicate with each other when anything changes<\/li>\n<\/ul>\n
My Advice – A Few Ideas<\/h4>\n
If you want my advice it is this:<\/p>\n
\n
- Examine your Daily Stand-Ups regularly<\/li>\n
- Pay attention to anything that comes up in the Stand-Up that should have been communicated earlier<\/li>\n
- Hold a retrospective with a focus on the Stand-Up – do this several times a year<\/li>\n
- Find better “dynamic” communication techniques<\/li>\n
- If you are not doing pair-programming, you should practice it and learn how to make it work for you<\/li>\n
- Switch up pairs frequently – every few hours<\/li>\n
- If you can’t stand the idea of pair-programming, do some Code Dojos and Katas to experiment with it<\/li>\n
- Sit together – all team members working within easy talking distance of each other<\/li>\n
- Do more work as a team – QA and Dev pairing, “Customer” and Dev pairing, QA\/Dev\/Customer teaming, and so on.<\/li>\n
- Improve your “information radiators” and keep them updated throughout the day<\/li>\n
- Try “Mob Programming” where everyone works at the same computer all together at the same time<\/li>\n
- Talk with each other\u00a0during the day<\/li>\n<\/ul>\n
That’s just a start.\u00a0 You will probably come up with better ideas than I have.\u00a0 Please let me know what you find.<\/p>\n
So: Are Daily Stand-Ups Harming Your Team?<\/h4>\n
Might be.\u00a0 If there are better ways to do things, and you\u00a0don’t at least explore them, then you might\u00a0be stuck\u00a0with practices that are\u00a0not as useful as they could be.\u00a0 In the old days, I heard a lof of\u00a0“That’s the way we do things here” excuses.\u00a0 More recently I see the\u00a0“Cargo Cult” approach to things: “The books say this is the way to do it, so this is what we do”.\u00a0 I’ve seen a lot of tricks suggested to fix problems with Daily Stand-Ups (like using a 10-lb talking-stick to keep things short) and feel that whenever you need to resort to a “trick” like that you probably should be looking for a root cause instead.<\/p>\n
What do you think? Are Daily Stand-ups Harming Your Team?<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
I wrote a short post called “Is The Daily Stand-Up Harming Your Team”.\u00a0 After getting some feedback on it, I have\u00a0refactored it and here is the new version.\u00a0 (I have deprecated the old version): The Purpose of Stand-Ups Here is a short definition from “Planning Extreme Programming” (Beck\/Fowler 2001): Have a short meeting every day […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-354","post","type-post","status-publish","format-standard","hentry","category-agile-stuff"],"_links":{"self":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/354","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/comments?post=354"}],"version-history":[{"count":16,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/354\/revisions"}],"predecessor-version":[{"id":374,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/354\/revisions\/374"}],"wp:attachment":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/media?parent=354"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/categories?post=354"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/tags?post=354"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}