Inspired by frequent questions on the subject of “What percentage of time should I allocate for Analysis, Development and Test in a Sprint”.

John gets a call from his friend Cascade. Cascade’s team is struggling, three sprints running they’ve been unable to build a potentially shippable product. The developer’s complain there isn’t enough time in a two week sprint to get their work done. They want three week sprints. The testers complain that the only get something to test in the last three days of sprint and even then its usually too buggy to work with.

John does some digging and finds the following data about (expressed in Story Points). The team had committed to 41 points of Stories sized: 5, 8, 13, 5, 8, 2

NB The in several cases a single story is both in (Analysis and Development) or (Development and Test) at the same time.

Read More…

After six months ScrumMaster John has finally found someone to fill the role of Senior Software Developer on the team. The goal is to find someone who can round out the team and play many roles (see: Bottlenecks). After many interviews they’ve settled on Kirby[1] who has over 20 years experience developing software, both server side and GUI. He is a self proclaimed expert in most of the technologies the team uses and that’s where the problems start. In addition the team members assume that he is being very well paid, perhaps better than any of the rest of them.

Attempting to learn the basics of the code base in his first few Sprints, Kirby takes on GUI, Middle tier, Server and Testing Tasks. He asks his teammates for code reviews and the code is pretty good, however it becomes clear that he can be touchy on some subjects and isn’t eager to receive negative feedback. On the subject of feedback he says: “I’m a Senior Developer, I don’t need to learn from you, it should be the other way round”. At first the team just try to accommodate his needs, but after five to six weeks tensions begin to rise. Ian (the Middle Tier guy) feels threatened, he sees Kirby trying to occupy the niche he has occupied on the team. To compensate Ian spends more time doing server side work, which in turn causes Doug some concern. Even Tonia feels a little bit threatened as Kirby starts doing some automation work. Read More…

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 a first order view of the code, it hints where you need to look no more).

Story

During the Standup Ian reports that he is starting his third day of refactoring[1], a monster class called BuyABook. ScrumMaster John’s antenna go up immediately, after all the team had split all tasks in one day or less. After standup he stops to have a quick chat with Ian to find out what is up. Ian explains that this class depends on many other classes and as a result it very difficult to test. He continues that he’s been reading the Feather’s book: “Working Effectively with Legacy Code” but it’s a struggle to put the ideas into practice. When he’s finished John talks to Doug and Martin finding that they’re having similar problems.

John puts on his thinking cap, he knows the team needs practice and knows that they need a safe place to do it before they use the ideas in the main stream code. After a few minutes Goggling he stumbles on the idea of coding dojo’s and based on the experience of others: TDD Randori Session, TDD Randori Workshop and My First Coding Dojo. The idea behind a Coding Dojo is taken from the world of Martial Arts. It is just a safe place to practice. In this case John imagines the team would like to be able to practice the ideas that Feather’s proposed either on artificial problem or on a small problem in their own code base. He sees them getting together in a meeting room with a projector and solving a small problem as a team. Read More…

Scrum Team digging a hole

The first law of holes is “When you’re in one stop digging”. In the last sprint the team discovered that they’re in a hole – in this case they had dug themselves into technical debt.

We join the team this week in their Sprint Planning session, they start by rechecking their Retrospective action items:

• Respect the “Definition of Done” – write Unit Tests (their complete “Definition of Done): Checked In, Peer Reviewed, Unit Tested, Manually Tested)
• Temporarily add Unit Test column to their story board
• Install Sonar (a platform to help visualize Code Quality) to help improve awareness of Code Quality and Technical Debt
• Spend 20% of their time in the next couple of Sprints to tackle Technical Debt Issues (Ed note: From experience this seems a bit low for team that have accumulated a fair amount of technical debt, but the team will have to learn on their own)

They start by discounting their historical velocity (currently at ~20 Story points) by 20% to account for paying down the Technical Debt (16 Story Points). Then they recheck the “Definition of Done” for each story they’re about to commit to. At this stage Product Owner Sue pipes up to protest that all this focus on technical debt doesn’t help her get features out the door. She’s concerned the CEO will banging on her door soon. Doug explains that if the team doesn’t start to tackle the technical debt now the delivery of new features will slow down even more, while the bug count rises. He explains that the next 3-4 sprints will be rough the situation needs to stabilised (Ed: He’s optimistic) . ScrumMaster John reminds Sue that she is responsible for the product that the team delivers. In turn the team is responsible for deciding how much they can deliver and for ensuring its quality. Sue raises the flag of surrender but says she is really concerned and wants to revisit this two sprints from now. Read More…

Cross Skilling is starting to happen and already there are fewer bottlenecks. John is starting to have more time to step back from the day to day and look at the big picture. He’s heard that most Scrum teams become more productive over time and he wonders how is team is doing. He pulls up the CFD for the current release:

and immediately notices that the rate at which stories are being selected has slowed down in the past few sprints. Historically the team has a trailing average of 30 story points a sprint. In the past few sprints they’ve only achieved 25 and 22. Is this drop meaningful? Is it related to the team’s cross skilling efforts? John decides to ask the team what is going on. He writes a short note, describing the problem he’s seen (without his own suspicions) and asks the team to reflect on the discovery. After Daily Scrum John invites the team members to talk about the problems they see:

• Cross Skilling has slowed the team to a small extent
• Interruptions are down, so if anything the team should be more productive
• Unit Tests aren’t getting written for very often
• Ian and Doug report that they’ve spent a fair amount of time in the past few sprints implementing a new story only to find it broke an existing story.
• Its also noted that there are several places in the code that have become rather hairy and are difficult to change safely.

Read More…

Its day four of the sprint and ScrumMaster John is studying the Story + Task wall to see how the sprint is progressing. After a few minutes he sees three things that standout:

1. Martin the only team member who knows how to make changes to the database has his name on four tasks that are in progress. Two of those tasks are blocking the remaining work on their respective stories.
2. Ian the business logic developer has his name on three tasks, two of which are blocked by Martin. The other task is blocking continued work on another story.
3. There are six stories in progress even though the team has previously agreed on a WIP (Work In Progress) limit of 3 stories in progress at one time.

Analysis

The team is currently blocked on Martin’s database related tasks. However even if that bottleneck were resolved they would still be blocked on Ian’s tasks.

The team isn’t respecting its own WIP limits. Read More…

The team are holding a daily standup mid-sprint. During the meeting Tonia the world’s best tester answers the obstacles question by saying: “The test server is down for the third time this week and I will spend the day writing new test cases.” Meanwhile Doug doesn’t raise any impediments but notes that he has spent his third day trying to write Unit Tests for a previously completed class (Ed: The team doesn’t know about Test Driven Development yet). This task was originally estimated to take one day. Read More…

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 sprints using the one “person off” strategy the production support problem wasn’t completely fixed but the team was starting to spend less time on support. However John started to notice a new problem, even though production support wasn’t the primary cause there were still alot of interruptions, he still noticed that team members were being interrupted (a mix of drop by, phone calls and email).

John spent the next few days just taking notes on the interruptions. Discounting friends dropping by for coffee or smokes and calls on personal phones (presumably family or friends), he could still see that his team members were being bothered 2-3 times a day. Taking the best notes he could without outright spying on people, some of the interruptions were obvious:

• a couple of people called Martin every time there was a database problem (big or small)
• team members attended meetings (corporate, HR, …) sometimes more than one
• Tonia (the world’s best Agile Tester) has become a focus for Agile testing questions with people stopping by her desk 2-3 times a day to ask questions about Agile testing.

To track these issues John didn’t need to spy, he just watched the flow of people in and out of the team space, listened for phone calls and read the email trail that filled his inbox.

Once John noticed the issue he mentioned into a standup and asked people to start tracking what sort of interruptions they had. In the retrospective the team discussed sources of interruptions (again using a timeline as reminder). Read More…

When we left John and the team they were just getting the shipping features ready and were waiting to go live with the site. This turns out to be a blessing and a curse. Its a blessing because the business is making money, a curse because with it come support issues.

John spends some of his time and energy just watching the team and their flow everyday. In the first two sprints after the release the team struggles and fails to meet its planning commitments. At first he’s ok and just says its the inevitable post release hiccups (I don’t agree with John on this one, its not inevitable I think it was a first warning sign – ed), but when its clear that its continuing into the 3rd sprint he starts to get worried. John notices that team members are being interrupted often several times a day. Most of the interruptions are support issues.

Read More…

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 well on the way to getting stories completed. This time they committed to 8 stories with sizes ranging from 2 – 8 points. Every couple of days they get a story accepted. Things are going awesomely well.

Story

• As a Canadian book buyer I want to Amazon to ship my book to Canada so I can get my book home – Story Points: 8
• As a Canadian book buyer I want to Amazon to calculate the import duty on my books – Story Points: 3
• As a Canadian book buyer living in Ontario I want Amazon to calculate the local sales tax (HST) – Story Points: 2
• …

Read More…