Posts Tagged ‘Agile’

Retrospective activities for Gathering Data: “Learning Matrix”

October 8, 2010 Leave a comment

One of the under-emphasized aspects of Scrum is the importance of the sprint retrospective. We all know about the stand-ups and the various planning meetings, but not all teams take the retrospective as seriously as they perhaps ought to. And it’s a bit of a shame, really. The retrospective is where the team can make tweaks and adjustments to a their process and really take ownership of it. Ownership leads to accountability, accountability leads to results.

If you’re looking for resources, I recommend “Agile Retrospectives” by Diana Larsen and Esther Derby – the exercise I’m about to describe comes straight from Larsen and Derby’s book. If you’re not looking to dive into a full-blown retrospective process (for some teams, it might seem a little bit too “New Age”), here’s a quick exercise you can try next time you hold a sprint retrospective: the “Learning Matrix”.

The Exercise:

The basic idea of the exercise is this…mark out a 2×2 grid (can be done on a whiteboard or some flip-chart paper) like this:


The four quadrants (going from top-left, clockwise) are:

  • “Smiles” – things we liked
  • “Frowns” – things we disliked
  • “Bouquets” – appreciations/thank-yous
  • “Light bulbs” – ideas/things to try

How it works:

  1. For 5-10 minutes (depending on the length of the sprint), the members of the team identify items/issues/topics that fall into one of the 4 quadrants, recording each onto a Post-it note.
  2. After the time period has finished, each team member presents his/her stickies to the team by posting them onto the grid and giving a brief description.
  3. Close out the exercise by allowing some time for the team to discuss what they’ve discovered

What to do next:

Try to identify a few key items for the team to focus on for the next sprint. It’s probably important to emphasize that we’re talking about identifying “a few key items”. Depending on the size of the team and the length of sprints, realistically you can’t expect the team to be able to attempt too many of these “process experiments” and be able to focus on what they’re really here to do – deliver great software. The other reason I think it’s a good thing to limit the number of things that we’re tweaking in the process is that it’s just “bad science” – too many variables in play while you’re trying to verify your hypothesis.

Dot Vote!

One quick and easy exercise to try for prioritizing the items and deciding what the team wants to focus on is the “dot vote” (“Prioritize with Dots” in Agile Retrospectives). For this exercise, each team member is given a number of coloured sticky-dots. The exact number allocated depends on the number of items on the board and how many items you want to select, but pick a number, try it out…tweak it as you see fit. Team members place their sticky-dots on the items they see as being highest priority – they can put all their dots on a single sticky-note or spread them out – it’s entirely up to them. The items with the most votes are the ones the team will focus on next sprint. Ties can be resolved with a team discussion and/or revote.

Some observations/thoughts:

“Idea Generation” vs “Idea Evaluation”

I think one of the keys to effective brainstorming is to separate the “idea generation” process from the “idea evaluation” process. This can be tough – particularly as most of us in software development are “solution oriented” – but it pays off. This is why I think it’s important for the team to start the exercise with 5-10 minutes of “me time”, rather than launching straight into a free-for-all discussion. I also think it’s important to hold off on the idea evaluation process until each team member has had a chance to present his/her ideas

Facilitation skills

One of the skill-sets that I feel often goes under the radar but is hugely important, particularly for Agile teams is having good facilitation skills. To keep the retrospective on track, there is typically somebody (usually the Scrum Master) facilitating the meeting and keeping the team on-track and focussed on the task at hand. As the facilitator, it’s important to understand the impact your behaviour can have on the process and the team’s level of comfort and trust. For example, you might naturally be a take-charge, “I’ve got a solution for your problem” type of person, but as facilitator, you will need to take care to ensure that your “style” doesn’t negatively impact the team’s ability to have open and honest discussion in a high-trust environment. Another example where this may be an issue is if you’re in a position of “traditional” (read: “org-chart”) leadership – depending on your leadership style and/or how the team relates to you, you may or may not be best suited to the role of facilitator. Bottom line: if you don’t think you can do it (and not everybody can) – find somebody else who can fill that role.


It should be common sense, but it’s worth repeating. If everything is top priority, then nothing is. Be really diligent about focusing on what really matters to your team.


Categories: Agile Tags: , ,

Lessons from a month in hell: unit tests need love too!

September 29, 2010 Leave a comment

My last month (sprint and a half) have been spent “merging” and “refactoring” the codebase for a supposedly “new” system that is being developed to (eventually) replace a legacy platform. One of the things I’ve come to appreciate is that developers are perfectly capable of writing brand-new code with a lot of the characteristics of legacy systems. In his book, “Working Effectively with Legacy Code”, Michael Feathers defines legacy code as “code without tests”. I’d add that code with bad tests can be almost as bad as code without tests. In fact, because unit tests are code, poorly written tests – test that are hard to read, hard to maintain, etc. actually contribute to the technical debt.

If you’re not sure what bad tests look like (and conversely, what good tests look like), I highly recommend you check out Roy Osherove’s “The Art of Unit Testing”. I also recommend checking out Osherove’s video test reviews – educational and entertaining at the same time.

This post isn’t so much about what constitutes a good or bad test – it’s more to highlight the fact that unit tests need to treated with the care as production code. If you believe that your production code should be readable – you should expect the same out of your unit test code. If you believe that your production code shouldn’t be thousands of lines long – your unit test shouldn’t be either. Don’t like your production code to have too many responsibilities? Expect the same of your unit test code. You refactor your production code has your requirements change and as your design emerges – do the same for your unit tests.

There is perhaps one exception – or at least something I might consider doing slightly differently. We all know about the “DRY” (don’t repeat yourself) principle. For unit tests, I am inclined to err on the side of readability over full-on adherence to the DRY principle – sometimes I prefer to be more explicit in the “arrange” part of my unit tests (“arrange”, “act”, “assert”). In particular, I tend to do this when there are fakes (mocks or stubs) involved – it’s important that somebody reading the test knows that there are fake objects involved in the test.

Some code hygiene issues that are specific to unit test code (and might not necessarily apply to production code)…

  1. Separate integration tests from unit tests – this is something you don’t generally have to worry about with normal code, but when you have a test suite that you want people to actually run – especially, when you have any reasonable number of test suites – you want to allow people to be able to run their test suites quickly (for example, Friday half an hour before beer o’clock). Separating integration tests from true unit tests will allow people to identify which tests are likely to be pretty quick and painless to run and which tests could potentially take a while. This is also useful if you find your CI build getting painfully slow.
  2. Keep the number of ignored tests to a minimum – Ignored tests are like commented out code. At minimum, add a comment (e.g. nUnit’s Ignore attribute allows you to add a comment) so that people know why the test is commented out. Generally, I don’t like to have too many ignored tests kicking around – far from being the great communication tool that well written unit tests can be, ignored tests just add noise .
Categories: Agile Tags: , , ,

On the importance of progress

March 10, 2010 Leave a comment

Well it certainly has been a busy month (ok, over a month) since my last post. New project went live, the Vancouver 2010 Winter Olympics – and to top it all off, a new full time position. It was definitely nice to have a little down time to do some reading and thinking.

I recently read an article on HBR outlining a list of “10 Breakthrough Ideas for 2010” (subscription required for the full article, but you’ll get the gist of it from the sample). On the topic of “What Really Motivates Workers”, the authors discussed the results of a multi-year study where they tracked the day-to-day motivation levels of knowledge workers. The findings, while potentially surprising to leaders and managers shouldn’t be that surprising to most knowledge workers. Whereas a survey of leaders and managers identified “Recognition of good work” as the number one factor for motivating workers, the survey of the actual workers showed that the factor that had the biggest (positive) influence on workers’ emotional state was this: “Progress”.

On days when workers have the sense they’re making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak. On days when they feel they are spinning their wheels or encountering roadblocks to meaningful accomplishment, their moods and motivation are lowest.

Call it apophenia, but as always, I seem to find a way to relate things to each other – in this case, Agile software development.

Technical Practices (i.e. “stuff that devs do”)

In a recent interview (actually the first technical interview for my current position), I was asked: “What do you like about TDD?”. I can’t recall the exact words I used, but I said something along the lines of:

I enjoy the rhythm, the groove you get into when you’re writing a few lines of test code, watching it fail, writing your code, watching it pass. The rhythm of Red, Green, Refactor is very satisfying

How does this relate to “progress”? Well when I do TDD, typically I work to implement the smallest bit of functionality I possibly can. I might implement the “happy path” on my first pass, an edge case next pass, an error case after that, etc. Depending on the complexity of what I’m implementing, I’ll go through the Red, Green, Refactor cycle every 5-10 minutes. Every time I go from Red to Green – that’s progress. Every time I refactor my code and the tests pass – that’s progress. Every time I check in my code, the continuous integration build runs, incorporating changes from the rest of the team, all the tests run – that’s progress.

Contrast this to the “other way”. I spend a few hours writing. I might do some testing by clicking around the application – seems to be working. A day later, another developer pulls down the source code – it won’t build. You have to go back and try to figure out what happened. That’s *not* progress. So we eventually fix the code so that it builds. A week later (if you’re lucky), the QA is doing some manual testing on the application – the application blows up due to an unhandled exception. Now you have to think back to what you did a week ago. That’s *not* progress.

You get the idea.

Team-level Practices (i.e. “stuff the entire team is supposed to do”)

One of the (in my mind) more important things Agile teams need to do when planning their iterations is defining what it means to be “done”. “Done” means we have met the acceptance criteria (which means that you have to first define them). “Done” means that when you’re done with a user story or feature, it’s shippable. It doesn’t require “tidying up” later. It doesn’t require a “stabilization phase”. It’s done and you don’t come back to it. If the customer wants to change something, well that’s another story – something be prioritized and scheduled just like any other story. But at the end of that iteration, it’s shippable – no “If”s, “and”s or “but”s.

In other words, the team is always making forward progress. Now, of course, if the client keeps requesting changes that’s not forward progress and quite rightly would be demotivating to a team (“I want that button green….now I want it blue….now I want it red…”). My personal hunch about this is that by requiring the customer to place the change request and prioritize their other requirements around these changes will eventually change behaviour simply by calling attention to the requirements churn.

“Working software over comprehensive documentation”

The preference in Agile methodologies for working software over documentation (note the wording: “working software over documentation” – doesn’t mean you never do documentation) – is another nod to the importance of progress. Few people regard spending months and months doing big up-front analysis design, writing reams and reams of documentation, “progress”. Shippable software – working software – is progress.

The “Progress lens”

So next time you’re feeling really positive (at work or in life in general) – think about what you’re doing through the “progress” lens. Maybe you’ve fixed a bug that’s been…erm…bugging you for a coupe of days. Or you’ve finally got your head wrapped around an idea that you’ve had trouble grasping. Or you’ve just run a new personal best 10k – not a world-class time by any stretch of the imagination, but a personal best nonetheless. Or maybe today was just a little bit less crappy than yesterday – that’s still progress.

Categories: Agile, Management Tags: , ,

When teams fail to meet their sprint commitments…

December 18, 2009 Leave a comment

It is bound to happen: the team over-commits on the work they are plannng to deliver for a sprint. It happened just this week, actually. Ok, I’ll be honest – the team has been slipping for two straight iterations now. So what’s a team to do?

The initial instinct of many teams is to increase the duration of the sprint – in our case, from 2 weeks to, say 3 or maybe 4 weeks.

The more appropriate response, however, is somewhat counterintuitive: decrease the sprint duration.

This approach is described in Johanna Rothman’s excellent intro to Agile project management, “Manage It!”.

Why does this work?

We can start thinking about the underlying reasons that might result in a team to miss their sprint goals.

  • Why did the team miss their sprint goals?
    • They didn’t have enough time to complete what they committed to.
  • Why didn’t they have enough time?
    • There they overcommitted.
  • Why did they over-commit?
    • They were wrong about the effort required to complete their commitments.
  • Why were they wrong?
    • Their estimations were off.

So if we drill down to actual root causes here, we find a perfectly plausible reason for the slippage: the estimates were off. We need to do better estimates. Increasing the sprint duration is really just an attempt to alleviate the symptoms – not address the root causes.

How does a shortened iteration help with better estimates? If we are using our sprints properly, then should only be committng to stories that can be completed during a single sprint. Shorter sprints force the team to decompose stories into smaller chunks (Rothman calls these “inch pebbles”) in order to fit them in. Smaller chunks are generally easier to wrap your head around and easier to estimate. Smaller chunks tend to have less variation and are therefore more likely to be delivered on target. In Lean terms, we can think of smaller sprint commitments as smaller batch size – a good thing.

Of course, there is no guarantee your team will learn how to better estimate what they can commit to. Even if this were the case, shortened iterations have one additional benefit: you know that you’re off track sooner. And knowing, as they say, is half the battle.

Categories: Agile Tags: ,