Some simple ground rules:

• Nominees have to be a track record of doing something Agile for at least a year
• Not the top 100 of any previous list
• There are no algorithms involved – when I discuss backlog ranking/ordering in my Scrum training I suggest that human ordered lists have more value than those ordered ROI calculations
• I’m most interested in people who write about their experiences (good or bad)
• Please don’t suggest yourself
• I will reject suggested people for no visible reason Ok this one is poorly phrased, the only point is that if  I don’t include someone I won’t write a paragraph about why.
• Inclusion in this list is completely arbitrary, based entirely on my judgement (there is no appeal board :-)

When you suggest someone please tell me:

• Who they are and why they’re interesting
• Where they write blog (or some other source)
• Twitter ID, Google+ link, etc…

If you suggest someone but don’t include their blog it makes hard to find their writing, please make it easy for me. This list will only be about Agile people. Another time I will shine a light on interesting sources outside the Agile community. Suggested #100Agilelessorknowns – not perfect but its shorter.

In the spirit of inspect and adapt I’m open to suggestions that will make this better.

Update: “I will reject suggested people for no visible reason” – It was suggested that this was poorly said. Agreed. When I other talked to the authors of other lists they say they use stats to make the decision to avoid controversy and having to justify their choices. This list will come from the heart and might not include someone who you think should be there. My only point was that when I do exclude people I don’t want to spend the time writing about why. I acknowledge the list is arbitrary as is any human curated list that’s what will make it interesting.

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.

Seven weeks into Kirby’s tenure, during a daily stand-up (Daily Scrum), he is describing about his work to display book prices in the local currency when Ian (usually a calm individual) blurts out: “He’s stealing my work”. John swings into action saying: “Ian thanks, this seems important could we discuss after Standup and let Kirby finish”, Ian agrees sheepishly. John turns back to the team and just says why don’t we pickup again with Kirby. After standup John grabs Ian and says lets go out for coffee. Over coffee they chat and John hears Ian’s view on the situation:

• Kirby isn’t open to suggestions or comments about his code
• Kirby is pushing him out the work that he does regularly
• Kirby often denigrates the quality of the existing code
• Kirby makes it clear that the other developers should be learning from him

After coffee with Ian, John goes for a walk with Kirby to hear his point of view:

• Kirby sees that the code doesn’t have the quality (see Technical Debt) he would expect of it
• Kirby is aware that he’s sometimes seen as pushy and isn’t sure how to solve that problem
• Kirby understands how Ian feels push aside but isn’t sure that this is his problem to help solve

John spends the rest of the day, buying coffee and tea for the rest of team, talking to one person at a time. While they don’t feel as much pain as Ian they feel some of it.

The question is what to do now?

Analysis

First and foremost John can’t take sides here. He can look to find the positives he sees going on but can’t champion anyone’s viewpoint. As soon as he starts to do that he will erode his credibility as a neutral ScrumMaster. The best he can do is get the various players talking and see if they can resolve the problem. To see some of the problems here read Brian Buzzoto’s: “Watch for Triangles”.

My viewpoint as Editor: Many of the things Kirby is doing: working across the code base, doing testing work, writing unit tests, generally raising the code quality are good for the team. The problem is that in doing this he comes across as a know it all.

The key here is remember Tuckman’s Model of Team Formation (Forming, Storming, Norming, Performing). When even a single team member changes the team reverts to forming and after seven weeks they’re rediscovered storming. Storming part of process can’t be avoided, skillful ScrumMastering aka interference, in fact interference make it last longer.

Story

The next day John gets Kirby and Ian to sit down and talk. He sets out ground rules: talk about your feelings, talk about events, use “I” statements not “You” statements. He suggests the goal isn’t to solve any problems today just understand how the other feels. Even if they still disagree, they need to understand the other person’s viewpoint. In future Ian suggests that checkin every day with how their working relationship is with the other person.

… The story could/should continue for weeks. At this stage lets assume that they’ve at least started to understand each other. Maybe we will see hints of this story in future posts.

Analysis

It’s striking that this problem occurred in part because the team weren’t involved in the interview process. Hiring well is a very difficult problem, its even harder when the people who will spend the most time with the new hire haven’t met them before. I find it very effective to involve team members in the interview process. I would even get the potential hire to pair program with the rest of the team as part of the interview. There is nothing like a few hours of coding (spread across the entire team) to get a sense of what working with them will be like.

[1] Any resemblance to the author of this blog is purely accidental as Kirkby is purely a fiction of my imagination.

[2] To make this work the team need some basic interview training so they avoid the various legal pitfalls. Ragnwald had some great examples recently in: “I hereby (fictionally) resign”

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.

Reading the experience posts John learns:

• It’s best to start with small problems
• Bring a real mouse, not just a laptop trackpad
• Pair Programming is best – one driver and one navigator
• Ask the pair to explain their decisions, making it clear to the audience what is happening. In addition it keeps the audience engaged.
• Rotate the pair partners every 5-7 minutes
• Get enough Pizza for everyone
• 90-120 minutes is about the right length
• Small steps
• Ask questions if you don’t know what’s going on
• Hold a retrospective at the end

John gathers the team together and proposes the idea. They agree instantly, but Ian points out that “BuyABook” class is awfully large to get their heads wrapped around in 90 minutes. Instead they agree to tackle a smaller problem get the “ChargeBookToMasterCard” under test[2]. They agree to run the Dojo the next day at lunch.

They gather in a meeting room with a projector, a laptop and couple of other developers from a sister team that is also working on the bookstore. John had invited everyone to spend a few minutes preparing for the session by studying the code before hand. After a brief introduction to Coding Dojo’s (see Wouter Lagerweij’s presentation via Slideshare), Ian frames the problem. ChargeBookToMasterCard is difficult to test because all the existing constructors require access to the MasterCard processing server.

After a few minutes of struggling to understand the myriad of methods on the Mastercard, they realize that “ChargeBookToMasterCard” really only uses three of those of methods. They conclude that using a Facade to wrap the MasterCardProcessor is the simplest way to go. With the Facade they can either pass in the real MasterCard processor or a fake that can be used for testing. (Ed: Yes this essentially manual mocking and real Mock tool would be faster to use). Once they’re able to construct a “ChargeBookToMasterCard” now they can start trying to test the public methods and refactor the ones which are complex. At the end of 90 minutes they’ve got a good start at refactoring a previously challenging class. If they’re happy with the code quality they could check it in, otherwise a developer can use the work as inspiration to do the actual tidy up. Since Coding Dojo’s invite us to take risk they usually don’t result in code that you can use.

During the retrospective Ian says that the exercise has helped him see a way of biting off a smaller chunks of work when paying down technical debt. In addition Doug says he now has a much better understanding of the payment system. The team agree to hold another Coding Dojo next week.

Analysis

For a couple hours of time and the price of some Pizza the team members have gained a little confidence at doing something that had previously seemed hard and risky. While there are still many more hills to climb, knowing that its possible is often one of the biggest barriers to paying down Technical Debt. When we see just how small some problems are it becomes a bit easier. In addition all the developers on the team have learned some new ideas today. It will take months to get the team to the place that we see as possible but they will only get there one step at a time.

Notes:

[1] I always take exception to this misuse of the word refactoring. Refactoring is “is a series of small behavior preserving transformations”. When we have to talk about a multi-day refactoring its long past the point of small. If they must happen I call them rework or rebuilding.

[2] Serendipity. Just after inventing “ChargeBookToMasterCard” I grabbed Feather’s Legacy Code book of the shelf, open a random page and find a very detailed example of the problem we will tackle on pages 106-113 The Case of the Irritating Parameter (link to Google Books)

Part of an ongoing series called Scrum Master Tales. The series covers ScrumMaster John and his team as they develop an online bookstore.

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.

Once the planning actually gets going the team finds that they can’t even commit to 16 Story Points of work. They realize that it will be hard to write Unit Tests for some of the new stories. The team commit to installing Sonar and then look at the Technical Debt Backlog for key items. Based on what they’ve picked up from “Laurent method” they’ve found a few large files that change frequently. They’ve discovered that several of these are 10,000+ line “God/Monster classes”, the class that everything else hangs off. When something small changes in these classes it ripples through the entire code base.

After the Sprint Planning Meeting John modifies the Story/Task Board to look like:

Adding the “Definition of Done” at the top (permanently) and a “Unit Test” column (only until Unit Testing becomes a habit).

On Day 1, Ian (the unofficial Build Master) and Doug sit down together to get Sonar up and running. After spending a few hours getting it configured in their CI system they have a pretty page of Java projects to visit from their dashboard.

After having some fun looking at the worst violations, they come to realize that the default configurations of PMD can be very noisy (with warnings for method name too long and too short). They quickly decide to load up PMD in Eclipse and make a first pass at simplifying rules. Even after simplification they find the code base still has over 10,000 rule violations. They agree to raise the issue in the next Daily Scrum. They also decide to write a short note to the team explain which rules they dropped and why. In addition they discovered that their existing Unit Tests only provide 10% Code Coverage.

Day 2 During Daily Scrum – Ian describes what they’ve learned from installing Sonar and trying to configure PMD. After the meeting the developers have a five minute to chat to agree on a strategy to handle the PMD issues. They agree just to eliminate PMD warnings as they work on a class. When there are too many warnings to eliminate in one sitting, they agree to at least chip away at some and create a technical debt card/postit to capture the bigger issue(s).

Day 3 Splitting the God/Monster classes proves painstaking and slow, first the functionality has to be moved to a new class then that class has to be passed in to all the places its required, …, finally test cases need to written.

…Ed we could keep going but its clear that the process is slow and painstaking. Let’s take a step back and find some options for the team.

Analysis

I happen to know that the team haven’t got a lot of experience with Unit Testing or Restructuring Legacy Code. Let’s give them some reading/study options. From experience I start with the simple Unit Testing before growing them to Test Driven Development (and beyond):

• Unit Testing in Java (Manning MEAP) – Lasse Koskela (early access as the book isn’t completely finished)
• The Art Of Unit Testing (Manning) – Roy Osherove (.NET)
• Pragmatic Unit Testing in C# (Pragmatic Bookshelf) – Andy Hunt and Dave Thomas with Matt Hargett

Once they’ve mastered the basics they will need to start thinking about how to make how to make the larger scale changes that will be necessary, good reading choices here include:

• Working Effectively with Legacy Code – Michael Feathers – its from 2004, but the problems the book helps you solve remain the same
• Mikado Method (Draft PDF) and Book WordPress Site – Daniel Brolund and Ola Ellnestam – while still in draft the book looks close to being finished.

In the course of breaking dependencies in the legacy code the team will likely find a mocking framework handy, in the world of Java things have evolved alot in the past few years:

• MockIto – uses a literate style (my personal preference) without also requiring states i.e. recording/playback so I would definitely take it out for a test drive
• PowerMock – promises to handle some of the difficult things to mock (statics, final, etc.) in legacy code
• JMock hasn’t had a release in a couple of years but is probably still worth a look

Story

By end of the Sprint the team have completed the Stories they originally committed and they have made some of the Monster classes are a bit smaller, the team realize that the size of the problem. They’ve also started to do some of their reading and appreciate the tools that they have available to solve their problems. In addition since they’ve got Sonar installed they can already see some of the improvements.

With a spot of luck perhaps in the next few sprints they will make their codebase marginally cleaner and easier to work with.

Part of an ongoing series called Scrum Master Tales. The series covers ScrumMaster John and his team as they develop an online bookstore.

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.

Analysis

The team have just discovered Technical Debt (see my article “Technical Debt a Managers Perspective”) or a mess (where Uncle Bob would argue that I misuse technical debt). Either way it would appear that the code is slowing the team down. At the start of the project they appeared to fast but now they’re slowing down. In reality they weren’t really going fast, instead they weren’t ensuring that they were really done.

Back to the Story

Doug remembers reading about the problems of technical debt (aka a mess) recently and suggests that this is probably what they’re starting to see. The team agrees to run a 2 day spike to investigate this issue and they warn Product Owner Sue that this will affect what they’re able to deliver.

Coding Java the team have a rich supply of tools available to them:

• PMD – “scans Java source code and looks for potential problems” examples: Dead code, Duplicate Code, missed private and final markers, over complicated code etc.
• Sonar – “Sonar is an open platform to manage code quality” – it uses static analysis tools (including PMD), code coverage tools et al to measure the state of the code. It plugs into the CI server and keeps data on an ongoing basis.
• Sort – Laurent Bossavit taught us this year’s ago: “getting a file list of all source code files, then sorting that list by (decreasing) file size. I start with the largest source file, and see if there’s a reason it’s the largest”

Doug and Ian decide to use PMD and Sorting by filesize as a starting point, as Sonar takes a bit longer to configure. Each time they find a major issue they take write it down on a large postit note along with some reference information (i.e. the files involved anything else. Ed note the precise format doesn’t matter – what matters is that the developers understand the issue its describing and will be able to guess which stories they might affect in the future). By the end of the first day they’ve come up with over 50 postit that contain noteworthy items (vs. a missing private or final which can be fixed in a few seconds). On the 2nd day they sit down with the rest of the team to prioritize the items using slows us down the most as criteria. During the remainder of the Sprint team members tackle smaller technical debt items (< 2hrs) when the items are related to the story they’re working on.

During the retrospective the Technical Debt problem comes up and the team start to discuss where it comes from. John starts by asking the team to review the existing “Definition of Done”:

• Checked In
• Peer Reviewed
• Unit Tested
• Manually Tested

A few minutes of conversation led the team to realize that the while most code was peer reviewed, very little was Unit Tested. Perhaps the bigger issue was that they didn’t have a good idea roughly how much of the code was unit tested or if the existing Unit Tests where of good quality.

Their SMART Actions (see: Agile Retrospectives):

• Respect the Definition of Done – write Unit Tests
• Temporarily add Unit Test column to their task wall
• Install Sonar to help improve awareness of Technical Debt
• Spend 20% of their time in the next couple of Sprints to tackle Technical Debt Issues

John promises to post this above the task wall to ensure that the team sees them.

Next week we will see how the team fare (Ed – I’m stretching this out over several stories because Technical Debt takes time to be weeded out).

Part of an ongoing series called Scrum Master Tales. The series covers ScrumMaster John and his team as they develop an online bookstore.

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.

Risks

• With this many stories in progress, many of them will remain incomplete by the end of the sprint.
• Many of the stories require multiple handoffs, example: Brad (BA) –> Ian (Middle Tier) –> Martin (Database Specialist) –> Ian –> … –> Tammy (Tester). Each handoff increases the risks of miscommunication, bugs and other mistakes all due to incomplete knowledge transfer.
• The teams lottery number sits at one. I.E. if any of Martin, Ian or Tammy win the lottery and decide to leave the organization the team will struggle because no one else really knows how to play their role.

Story

John raises this as an impediment at the Daily Scrum and asks for quick meeting right afterwards. He shares the three observations and asks the team what they think. Team members say things like: “Database work isn’t my speciality/skill” and “I wouldn’t be as productive on that”. As a result they say that they moved onto lower priority work. To get through the sprint without another disastrous ending (see: The Story of an Incomplete Sprint), John asks what they can do to offload Martin and Ian allowing them to unblock higher priority work. Among other ideas the team decide:

• to temporarily abandon work on the lower priority stories
• to pair with Martin and Ian to get the higher priority stories sooner

During the retrospective the team focused on the problems with only one team member being able to do certain key tasks (Database work, Business Logic). Rather than address it piecemeal Martin suggests that they create a Skills Matrix:

Image Credit: Jon Miller – gemba pana rei

That shows the inventory of skills across the team. (Ed note – when I facilitate one of these we spend 15-20 minutes coming up with a list of potential useful skills for the team). After an hour of work the team assembled a matrix that helped spot many areas where they only had one person who could do the work. It turns out the gaps are larger than can be addressed in the next couple of sprints, so the team decides to focus. They choose:

• Grow Database Skills so at least three team members can make database changes without requiring Martin to oversee all aspects of the work.
• Grow understanding of the Business Logic so that coding team member can work safely in that layer without requiring Ian’s help.
• Teach all team members the rudiments of Exploratory Testing so that stories are tested sooner and developers get earlier feedback on their work. Tammy will receive an additional benefit because most Stories will really be done by the time they reach her. (Ed Note – they still haven’t discovered ATDD, BDD or even TDD yet).

To grow skills in those areas they agree to us a mixture of pair programming, interactive workshops and one on one coaching. While these activities will slow the team down in the next few sprints, the benefits of getting higher priority work done faster will soon out weigh.

Finally the team posts the skills matrix in the team area and commits to revisit it in six to eight weeks.

Part of an ongoing series called Scrum Master Tales. The series covers ScrumMaster John and his team as they develop an online bookstore. Tell me what problems you would like to see John tackle next.

Update: As I went to compile a cast of characters I realized that I was using Doug and Martin interchangeably between posts. I changed this post to make Martin our database guy.

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.

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.

While it is difficult to diagnose from a distance Saakashvili would have been wise to seek diversity of thought in his cabinet as we recommend on teams. Where that diversity is lacking its important to seek fresh ideas from outside sources to challenge our own thinking.

However Cain overplays some of the research that she uses to make her points. In particular she cites DeMarco and Lister’s Coding War study where the authors demonstrated that developers who had privacy were more productive. What is missing is the circumstances around it. DeMarco and Lister weren’t studying teams and so the results don’t speak to teams. Perhaps more relevant in this case are the studies found in “Making Software What Really Works, and Why We Believe It” – Andy Oram and Greg Wilson – which is equivocal saying that depending on the type of work some teams benefit from team rooms and others don’t.

Roger Brown and I have done on an InfoQ interview the subject: Creativity and Brain Science with Mark Levison and Roger Brown.

Finally Keith Sawyer (author of Group Genius) provides an excellent rebuttal: Does Solitude Enhance Creativity? A Critique of Susan Cain’s Attack on Collaboration which provides details in some of the other errors Cain made.