Ah, the elusive, well-executed stand up meeting. In my experience, the stand up or daily Scrum is often the first thing we try to implement when introducing a team to Scrum and also the first thing to deteriorate as teams mature or don’t mature. But what actually makes a good stand up and what are some symptoms to avoid for a poor one? I’ve been circling this for awhile now and here is what I’ve come up with – including the ‘eyes closed stand up.’
Coming up on Agile2015 is hitting me right in the feels. This will be my fourth Agile Alliance conference, my fourth job in as many years (actually fifth), my second time presenting at an Agile Alliance conference, my second time presenting in Washington D.C., and my first time really feeling like I have no idea what I’m doing.
I was recently talking to a former co-worker on one of my previous Scrum teams about team rooms. A fundamental of team formation and performance is teams being together and bonding through work and fun. While many companies proclaim they’re practicing Agile/Scrum, co-location and team rooms seem to have become more optional than mandatory. While we cannot completely get away from distributed teams, it seems that often even with teams that have members in the same place those teams are not sharing a space. From this practice I’ve seen teams having a harder time forming, norming, and performing (though they don’t seem to have storming problems). What benefits are teams missing when they don’t have a shared space? And even when they do have one, are they then lacking the ability to work with distributed teams?
We [the Agile community] value transparency and prioritization among many other things. We prioritize (or order) the most important things or the riskiest things to work on first. This is not new. What happens when it all is important or is all very risky or there is lack of clarity between the business and the team? Who has the final say in the priority of work items?
I’m going to start off by saying that I know Scrum and metrics don’t necessarily get along. But I will also acknowledge that it’s a necessary evil in most cases. And in a lot of cases it doesn’t have to be evil. Metrics are simply: a method of measuring something. In Scrum, we measure a lot of things. We measure the size of our work items, we measure the effort or time it takes to complete them. We measure our accuracy. All of this is in our quest to become predictable as a team and to improve (and we need to start with a baseline measurement to know if we’ve improved). But when others start taking notice of our metrics, that’s when things get tricky.