Blog

In the past few years a number of Agile people I respect have published top 100 or even top 200 lists. While I like many others appreciate the attention they’ve brought the whole idea seems very anti-agile. Agile promotes a democratic meritocracy. These lists do the opposite, they create “hero’s” people whose ideas are more important others. Instead I think we should be widely read in the Agile community often reaching outside our immediate realm. To that end I’m asking for your help creating a list of voices we should hear more from. My goal is find ~100, the limit is more from my time and energy than the lack of more people we could find.

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…

I was asked earlier in the week the ultimate goal of my Scrum training. Someone wanted to know, did I expect my students to use Scrum? That has given me pause for thought, Scrum is an excellent tool in many situations but not the only one. I’ve never worried if people use Scrum, what matters more is if you help your organization by delighting your customers/clients.

To that end the goal of my course: Open peoples eyes to what is possible, help them see opportunities/impediments and awaken a spirit that won’t let go. All else is an implementation detail.

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…

Due to an unfortunate mistake on my part the RSS feed hasn’t been updating correctly since the beginning of November. You should now see 7 posts that you missed in that time.

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…

This episode has been brought to you by a quick trip to California.

Tom Stafford wrote about his use of Psychology to avoid Bystander Apathy. Interesting his approach point to a specific person (or persons) and tell them exactly what to do has been standard training for first aiders for years.

Sharp Brains had an excellent series “Under­stand­ing the Human Brain and How It Responds to Stress”:

• Octo­ber 17th: The Human Brain and How it Responds to Stress
• Octo­ber 24th: Grey Mat­ters
• Octo­ber 31st: The Lit­tle Brain Down Under
• Novem­ber 7th: Stress Response Explained
• Novem­ber 14th: The Human Brain Likes Balance

Study Hacks described a study of elite vs average violin players. The difference in their practice wasn’t their dedication, on average they spent the same amount of time – it was how they practiced. Elite players spent time stretching their skills, pushing their boundaries and practicing the uncomfortable. In addition elite players consolidated their practice into well defined blocks (two a day) vs. the average who spread their practice through out the day.

Stephanie West Allen shares evidence that SWOT analysis may lead us to dead ends.

Garth Sundem suggests that “Everything You Thought You Knew About Learning Is Wrong”. In an interview with Robert Bjork it is suggested our learning model of attempting to master one skill before moving onto the next might be completely wrong.

In a New York Times article: “The Rise of the New Groupthink” this week Susan Cain claims that teams and collaborative work give rise to groupthink. Groupthink is not out of the question, as Christopher Chabris and Daniel Simons demonstrate in “The Invisible Gorilla” group think is a risk – cite the example of the Georgian War in 2008:

When Mikheil Saakashvili was elected president of Georgia in 2004. he was only thirty —six years old. He stocked the government with loyal ministers who were also in their thirties and lacked military experience but sympathized with their leader’s views about the importance of reclaiming the breakaway regions from Russian influence. Over the next four years they managed to convince themselves that it was a good idea to fight an army that outnumbered theirs by twenty five to one. It’s not hard to imagine how a group of like—minded government officials could take a set of opinions that none of them held with great confidence individually and aggregate them, by deliberating among themselves and reinforcing one another’s public statements, into a high-confidence conclusion.

Read More…