Stable Teams Really Do Matter

  For years now Rally has been performing a large ongoing experiment on the Agile world. As a side effect of providing one of the better known tools they’ve managed to see a lot of data accumulate about what makes an effective Agile team. In a report called “The Impact of Agile Quantified” they’ve sanitized the data and then run some statistical analysis on it.  Here’s what they saw: Dedicating Team Members to one team doubles productivity, reduces variance throughput and leads to a small reduction in defects. They note that this is a fairly common practice among teams. Stable Teams – keeping a team intact for the long term resulted in 60% more productivity; teams were more predictable and responsive. Limiting Work In Progress – reduces defect rates; however, if your WIP limit is already low, reducing it further might affect productivity. Relative/Story Point Estimation[1] – They divide the world into teams that: A – Don’t estimate; B – Estimate Stories in hours; C – Estimate Stories in Points – tasks in hours, and D – teams that only Estimate using Story Points (i.e. teams that have dropped task hours). Their discovery – the teams (A) not using estimates had 2.5 times as many defects as the teams (C) using Story Points and Task hours. An additional surprise – teams (C) using Story Points and task hours had fewer defects than (D) teams only using Story Points. Some of the discoveries in this one could use further investigation. Team Size – 7+/- 2 – the findings suggest that teams before the Agile norms are more productive, but have a higher defect rate and reduced predictability, whilst larger teams were more predictable. The authors note that the larger teams typically also used “Story Point Estimation for Stories and Hours for Tasks” – this might explain some of the productivity differences. The authors recommend sticking to the traditional recommendation of 5-9. Before switching all your teams to 3 people or less – which is tempting with the promise of more productivity – also consider the effect on the work if even one team member leaves. This is another datapoint that bears digging into. I was surprised to find that stable teams are less frequent among the Rally customers than my own. Rally noticed that 1 in 4 people changed every 3 months. Experience at my regular clients suggests that it should be less than that. No matter what the frequency, we have to appreciate that every change is expensive; both in terms of the knowledge lost and the consequent slowdown while team members renegotiate their relationships. It’s hard to build the high performance teams that we all seek when we have frequently changing membership. As with any set of measures, I think the value isn’t so much in the number as the signal regarding what to look at in our teams. In addition, I suspect some high performing teams will probably be doing things that don’t show up well in the larger dataset. For instance, I’ve seen many high performing teams with less WIP than the number of team members. Instead they swarm all work, etc. The report from Rally is well worth reading, although it’s sixteen pages long. (You will have to give away your email address). To my friends at Rally, there are many interesting questions to be asked here. If we look only at stable teams – what do we learn about team size? If we look only at mature teams (>1 yr old and stable) – do any of our discoveries around team size and estimation change? What about time to fix defects vs. productivity or quality? What about time to fix defects vs. team size? Story size vs. productivity vs. defects? Distributed teams’ productivity? What about the highest performing teams – what where they doing…? Have you considered releasing your dataset to the rest of the world so we can help you mine it? Two reasons: more eyes will spot more ideas and the Agile ideas have always been developed and evolved in an open fashion. Perhaps you could release with the rule that anything someone else discovers from it has to be shared openly. Hat tip to Dave Nicolette who first pointed this paper out to me [1] In the paper this is referred to “Full Scrum” – which is odd since Scrum doesn’t require Estimation at all.

Story Splitting – a Play – “Spike Sherman”

User Stories are a common tool used by Agile Teams to capture the spirit of a requirement without too much detail. Sometimes User Stories are too large for the team to complete safely in one Sprint. In fact, I recommend that you split the Stories  into small enough sections so that you’re completing 5-10 Stories per Sprint; it improves the flow and makes it easier to deliver complete chunks of value at the of the Sprint. In my classes I frequently ask teams to present what they’ve learned to their peers. At UBC they took it one step further. The teams were challenged to summarize Richard Lawerence’s Story Splitting Flowchart: They created a play, “Spike Sherman”. Our story opens with Diane preparing the original User Story, “Cong + Sherman”. Clearly too large – so the team’s splitter, Jason, applied the patterns from the handout and broke the Story into its constituent pieces: Cong and Sherman. Once split, the Story was sent to Yurika to be checked against INVEST: (Original idea from Bill Wake: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/): Independent – dependencies between Stories limit the flexibility of both the Product Owner and development team. The Product Owner should be able to ask for Stories in whatever order makes sense. Negotiable – the elegance of a User Story is that the precise details are left until later. It gives the Product Owner and team a chance to delay unnecessary decision-making until implementation begins. It allows the team to discover new options right up until they’re done. Valuable – Each Story needs to deliver some small sliver of value all on its own. In other words, the customer has to be able to see the value. This pushes us towards slicing our work into vertical chunks; and not technological layers. Estimable – If the team, through lack of experience, can’t estimate a Story, they shouldn’t fake it. Instead, they should run a short experiment to gain that experience. These experiments are called Spikes. Sized Appropriately – Stories at the top (approximately the next 3 Sprints) should be small; so small that the team should be able to get 5-10 similar-sized Stories completed every Sprint. Stories in the middle of the Backlog (between 4 -10 Sprints out) should be larger. The team might only complete 1-2 of these in a Sprint. Stories of this size are often called Epics. Further out and the Stories are very large. Testable – It is clear how you will test this. (Source: User Stories in the Agile Atlas by Charles Bradley and Mark Levison) Cong was tested against INVEST and was found to meet all of the criteria. He was returned to the Product Backlog for estimation and implementation in an upcoming Sprint. Sherman was also brought before the INVEST checker; unfortunately, it was discovered that he couldn’t be Estimated. He was immediately taken out into the hallway, and a Spike was conducted by Jack. Spike: a special User Story the team uses when there is some special risk involved. Usually the team don’t have enough information to give an estimate. Spikes are: Timeboxed usually 1-2 days work for one pair Experimental solutions that touch all relevant layers Are always throwaway code The purpose of the Spike is to give the team enough information to do an estimate later. It’s written quite rapidly without any real concern for code quality. Eventually Sherman was returned, and now it was clear a split was required. He was returned to Jason who applied the splitting patterns again. Once he was split, the two halves of Sherman were appropriately sized. All’s well that ends well. No harm came to Sherman. Thanks to Cong, Sherman, Diane, Yurika, Jason and Jack for the most entertaining presentation I’ve seen in a long time.  

ScrumMaster Tales: The Team collaborate on Acceptance Criteria

The team has just completed Sprint Planning, committing to four stories: As a first time book buyer I would like to read a review so I can see if a book is worth reading. A review has text and isn’t empty A review has an author name A review has a title At most a […]

ScrumMaster Tales – Waiting Too Long to Create Acceptance Criteria

The recent Backlog Refinement session helped split the upcoming User Stories. The team was able to get from a very large Story: “As a first time book buyer I want to read a trustworthy review before I buy a book” to: As a first time book buyer I would like to read a review so […]

Early Feedback Reduces Anger and Frustration

Have you seen a developer react after they’ve spent three days writing a feature, only to have the tester say, “Um,..N o that’s not right.” after 5 minutes? Its not a pretty sight. Have you ever been part of Post Mortem (a meeting on about a project after it has finished) that went badly wrong […]

Daily Scrum Tools

Daily Scrum is about a group of humans working out how they will collaborate for a day. It isn’t a status reporting meeting. Its not for management. It can’t be replaced by electronic status reports. Tools like iDoneThis and the deceased TweetScrum remove the human interaction which is the entire point of the event. If […]

ScrumMaster Tales–The Team Learn How to Learn

The Team are struggling to payoff the Technical Debt (or mess) that they’ve spent the last six months accumulating. They’ve started to institutionalize writing Unit Tests (by adding it to “Done”) and they’re using Sonar to help track Code Coverage, PMD warnings et al. (Ed: Don’t take Sonar or any other measure as more than […]

Scrum Master Tales – More Interruptions

Part of an ongoing series called Scrum Master Tales. The series covers ScrumMaster John and his team as they develop an online bookstore. Last time we read about our team they were suffering from a very high rate of interruptions after the product had gone live: The Story of Production Support. After another couple of […]

Scrum Master Tales–The Story of the Changing Needs

Caveat – given the way I’m writing this series occasionally things will happen out of order, i.e. I will be reminded of points I wish I had made earlier. John, Sue and the rest of the team have started another sprint this time they committed to fewer stories and part way through the sprint are […]

The ScrumMaster Tales

I’ve been struck how little is written about being a great Scrum Master. There is heaps written about Scaling Agile and a lot of great Technical books, but very little on playing individual roles well. The ScrumMaster Tales are intend to fill this gap. Cast of Characters ScrumMaster John – he’s been in the software […]