Blog

Agile Coach Camp 2012 is happening in Ottawa this year, from June 22-24:

We are proud to welcome everybody to Agile Coach Camp Canada in Ottawa. A two-day highly collaborative, self-organized event with an Open Space for everyone involved in coaching, training, mentoring and leading Agile organizations, teams, and individuals. ScrumMasters, team leads, change agents, Product Owners, managers are welcome, and so are individuals assuming other roles.

It is run as a non-profit, low-cost, community-organized event.

Facilitation will be held in English

While I can’t attend, I’m delighted to be a sponsor and help to make this event happen. If my sources are correct there are still a few spaces left. Attend if you’re available and if you’re an Agile business signup as a sponsor. By sponsoring you’re helping to raise the dialog in Agile/Scrum around Canada..

Preparing for Tonight’s Agile Ottawa Retrospective

Tonight’s retrospective is divided into two parts:

1. Retrospective of the past year’s Agile Ottawa Events
2. Discussion of Various Retrospective techniques

A great retrospective takes a little bit of preparation from all parties. For the first part I would like you to spend 10-15 minutes gathering your memories and recollections of the past year. To jog your memory, use: https://agileottawa.wordpress.com/, http://www.meetup.com/Ottawa-Scrum-Users-Group/events/past/ and http://www.linkedin.com/groups?gid=1981258&trk=hb_side_g (Agile Ottawa on LinkedIn). Also consult your email archives.

Read More…

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. Cascade calls her old friend John who seems to be having more success with Scrum.

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…

In the past few weeks I’ve noticed a worrying up tick in the number of people asking questions around how to pass their upcoming Agile/Scrum XXX test (i.e. PMI-ACP, PSM, CSM, CSP). They want to know what to read and what magic incantations to invoke.

Scrum (Agile, Lean, Kanban, …) aren’t something you really learn or understand by reading books. These are things you learn by doing or practicing. The focus shouldn’t be on certifications it should be on delivering valuable software.

My promise: If you take my ScrumMaster Training we will focus on learning by doing and not on slides. The focus is on the successful use of Scrum to build working software not passing a test.

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…