Multi-Release Burnup

In my experience, Agile projects almost never have a single milestone at the end. The business wants to see multiple milestones along the way, taking internal releases from the development team even if they’re not prepared to make them public. The simplest dashboard I know to illustrate this situation is a burnup chart with multiple goal lines, indicating the goals of each milestone.

This sort of chart is trivial to create by hand or with a spreadsheet. The typical Agile Project Management software, while providing a myriad of ways to view data, never seems to include something as simple and powerful as this. Fortunately, it doesn’t take much time to create your own. It takes a few minutes at the end of each sprint to update the chart, and you can make sure that the data is correct as you do so.

(Continued)

Rough Cut

A common complaint against Test Driven Development is that writing tests and refactoring take too long. In the long run, I’ve found that TDD has improved my skills such that I can complete work faster by writing tests and refactoring than without. I’ve also found that this information is a weak argument for those who have less confidence in their skills, or feel too pressed for time to learn. But that’s not the only benefit. (Continued)

The Wrong Impression about Retrospectives

People get the wrong impression about retrospectives. They read that it’s a meeting where you list what went well, what didn’t, and what you want to change. They describe it like this:

The Sprint Retrospective is an opportunity for team members to bring up anything about the Sprint they feel needs improvement.  For example, a team member might say he felt he had to complete work that should have been completed by another team member.  Or a team member might say she received emails constantly which prevented her from getting any work done….

Or like this:

The format is a discussion and brainstorming. The ScrumMaster facilitates the retrospectives and let the team choose what aspect they want to improve for the next Sprint. Because the team is very technical, most of the discussion revolves around improving engineering practices, i.e latest frameworks, continuous integration, BDD, etc. Improvements get accomplished. But the point is the team thinks that rather than allocating special time to do retrospectives, they said why can’t they just do that within the sprint? The team gets the idea from Kaizen that is implemented in Toyota where the team gather in an instance to find a way where they can improve rather than going to a specially allocated sprint retrospective. (Continued)

Design for Testability

Asked on the Agile-Testing mailing list:

Lesson 136: Testability is often a better investment than automation.

(I’m quoting “Lessons Learned in Software Testing” by Kaner/Bach/Pettichord)

If anyone has practical examples of improving testability, I’d be very interested to understand, and grateful. (Continued)

Build a Cache, not a Stash

There are many times where a call to get some data is time-consuming or expensive. Perhaps it makes a webservice call, or a network connection to a database, or iterates over a large collection to perform a calculation. If the values isn’t going to change rapidly, and might be needed again soon, it’s natural to want to save the value for that use. (Continued)

Lessons from Sailboat Racing

Recently, I was attending a sailing seminar on racing small keelboats. As the lecturer talked about the crew requirements for winning races, I noted a lot of similarities with effective software development teams. Both situations require a small group of people to work in coordinated concert to achieve a common goal. No one on the team succeeds alone–they all reach the finish line together. There is a mix of specialized skills and general work that almost anyone can do. And there is a constant need for improvement, coupled with a desire to go fast. (Continued)

Running cucumber on jruby under ant

I’ve just spent more time than I expected getting this to work. It seemed like it would be easy, since running cucumber from the command line is so easy. But ant is very helpful in sanitizing the environment for subprocesses–a little too helpful, perhaps. After chasing a number of dead ends and increasingly complicated detours, I ended up with this target: (Continued)

Safety Exercise

In my recent posting on Separate Retrospectives, I mentioned sometimes performing a Safety Exercise at the beginning of a retrospective where the situation was unknown or seemed a bit charged with emotion. I was asked about that exercise.

I use a simple poll of how safe people feel. I got this from Norm Kerth’s book, Project Retrospectives (page 110). (Continued)

Contemplating Given-When-Then

This week, Chris Matts tweeted, “Contemplating whether GIVEN-WHEN-THEN is back to front. The system should do <outcome> WHEN <event> PROVIDED <stimulus context>… Hmmm.” Let’s try an example. “Given I have $500 in my account, when I withdraw $50 then I have $450 in my account” becomes “The system should show $450 in my account when I withdraw $50 provided I had $500 in my account before.” It doesn’t exactly roll off the tongue, does it? Putting the result first makes the sentence both more complex and more passive. Yet I can understand the impulse that triggered this tweet. (Continued)

Agile Planning Tools

One of the most exhilarating moments in my coaching career was when I entered the client team room one Monday morning to find they were pulling the cards and tape off of their backlog corkboard, and arranging it in a different fashion. I knew then that they had taken charge of their own process. That team became one of the best I’ve coached.

One of the low points was when several people, including a business analyst, product owner proxy, and the program manager, individually said that they couldn’t alter the “user stories” to cut across multiple components of the system because they were already in the computerized planning tool (and Word documents) and it would be too much work. That team did not appear to be getting much value from their “Agile approach” and had significant integration risk that was being studiously ignored.

One of the most frequently asked questions on public mailing lists and forums devoted to Agile development is “What Agile Planning Tool should we use?” There is always a chorus of answers touting this or that computerized tool, usually without asking any questions about the context. Is there one best tool? (Continued)