This is the second essay from our short-list of entries to our essay competition.  All week we will be releasing an essay with the winners finally announced at the end of the week (16 September 2011).   

Becoming More Agile

This essay describes my own experiences from adopting an agile framework (specifically, scrum). It describes the problems that my team and I encountered during our first scrum project (referred to as “Glacier”) and how we have adapted to improve our approach during our second scrum project (referred to as “Forest”). It’s aimed more at developers but may be of interest to anyone practising scrum.

 

Background

At my waterfall organisation, the bulk of our live applications are legacy code (succinctly defined by Shore and Warden^{Shore, Warden. The Art of Agile Development. Microsoft Press (2008)} as “code you are afraid to change”). We have collectively been guilty of this:

• solo developments leading to single points of failure
• specifications re-written half way into the development lifecycle, requiring significant redevelopment
• no timeboxing
• irregular reviews during development
• no formal testing, test scripts, cases or plans
• the only copy of code being the compiled assemblies!

Realising that this could not go on, we vowed to change. Scrum was introduced for Project Glacier.

 

Project 1: “Glacier”

Glacier took 35 sprints to complete. I summarise our difficulties:

The project came in way over time and budget, but scrum had opened our eyes. We learnt a lot for our second assignment, ”Forest”.

 

Project 2: “Forest”

Forest is still in development at present. In light of our past mistakes and current experiences, I offer some recommendations.

 

Before You Start, Prepare

Every scrum project needs a “sprint zero” - that is, a preparatory sprint:

• the right team
• the right “tin” (hardware infrastructure)
• necessary preparatory training (including scrum training)
• a team working agreement
• a definition of “done”

Get the Right Product Owner

Just as developers generally make for poor testers, a poor choice of product owner can lead to problems. It might be tempting to have someone who more “speaks your language” – say, a “proxy” product owner who has some technical knowledge - but it’s dangerous; there is no substitute for a product owner who is interested in maximising product value. Insist on a customer and try to get them on site (even if it means a temporary relocation).

Keep your product owner involved. Our burn down charts during Glacier often looked like this:

Typical Burn Down Chart for Glacier Project (11th Hour Completion)

Here, we caused the stories to be signed off far too late. In some cases, the sprint failed – lack of communication and misunderstandings between the developers and the product owner were too late to fix:

Typical Burn Down Chart for Glacier Project (Insufficient Product Owner Involvement)

Strive for the perfect burn down: as soon as a story is ready for the product owner, get him/her over, get it tested and get it moved into Done. Target that blue line – a steady progress, not a sprint to the finish.

 

The Team Working Agreement

Recognising the different behaviours and communication styles across the team members during our first project made us see the need for a team working agreement (or “contract”) to which any team member must agree before joining. Here’s ours:

• trust and respect each other
• be open
• join in – don’t hide behind props (paper, smartphones)
• have courage – if you are struggling, tell the team. If you are not clear about a story, tell the product owner. If you are not going to complete a story in the sprint, don’t cover it up!
• give and receive feedback regularly
• share your skills
• have a “when is done, done?” list

This is not set in stone; expect to refine your agreement over time.

 

When is Done, Done?

While the product owner defines his/her version of “done” (through functional and UAT scripts), so should your developer. Three sprints into our Forest project, we realised that our code was incomplete. A codebase without any associated unit, functional, coded UI or integration tests really has no guarantee of value. We were too busy working on functional coding but, criminally, had not considered testing. Our oversight meant that our first three sprints yielded not one “potentially shippable unit of value” and, strictly speaking, every sprint had failed - our project had become full of technical debt^{Term introduced by programmer Ward Cunningham in 1992 to describe a “deferred investment in quality” - http://c2.com/doc/oopsla92.html}, without our ever really realising it.

Technical Debt

You are never free from technical debt. It’s always there; it’s just up to your team how you manage it. Untested, non-refactored code and impediments all add to it. The longer you leave it, the more debt you accrue. By reducing your debt you reduce the snowball effect.

Our debt is currently being repaid through unit tests, coded UI tests, automated builds and by code coverage reports. This fixing has caused delays. It’s been quite painful having to refactor and introduce tests to accommodate existing code (far from the ideal of test driven development), but it’s also been empowering and satisfying.

Our “done” criteria, thought of as a technical working agreement, keeps debt reduced. It has evolved from functional acceptance to something far more substantial:

• all new functionality uses test driven development
• unit tests to have code coverage of 90+% (and an agreement as to why the non-covered 10% is acceptable)
• repetitive or mundane tasks (e.g. UI testing, complex builds or test deployments) automated where possible
• coded UI tests (where applicable) pass
• integration tests pass
• gated check-in in place with check-in policies (“No check-in comment? No check-in!”)
• code refactored to the team’s approval with appropriate coding conventions used
• acceptance tests (as defined by product owner) all pass

Finally:

• product owner agrees it is done.

Reduce your technical debt by writing maintainable and refactored code. If it’s done very frequently, refactoring need not be a trudge and keeps your code smell free. Test driven development gets you closer to bug-free code. Let your developers get a kick from this. Help them find the delight in writing clean, verifiable code.

 

The New and Improved Scrum Board

In light of past mistakes, our scrum board now looks like this:

Our Current Project’s Scrum Board Layout

 

(The reverse side of the board is also used – it provides an effective exploratory space for team discussion.)

The use of colour and greater maintenance of the board has helped enormously. Our simple board rules are:

• white cards (by the product owner) describe the story
• yellow cards (by a developer) describe a story’s tasks
• story cards and task cards are linked by a unique ID, written on each card
• green cards (by anyone) are team appreciations
• red cards (by anyone) are impediments
• blue cards (by anyone) are other non-project work, sized and treated like a standard story
• when the first task relating to a story is started, the task and its parent story aremoved into the In Build column 
• developers move a task card or story card from To Do to In Build or To Test
• only when a story’s last task is done and has been added to the To Test column, is the parent story also moved to the To Test column. The developer performs this move. At this time (or as soon as possible) the implemented story is demonstrated to the product owner 
• only the product owner can move a story (and its tasks) from the To Test column to the Done column. (Developers can only move Other Work cards into the Done column)
• having the goal of each sprint written on the board is a useful visual reminder to keep focus. If you don't know the objective of any sprint, don't even start it!
• if the card is not in the To Do column, it must include the developer’s initials and a start date, otherwise it goes back into the To Do column!

We are dependent on this board now. While our dependence on the board has grown, the use of electronic process support tools has dropped. Why? It’s far more “hidden”. A physical board is big, colourful, dynamic and immediate; drilling down through a labyrinthine application is far less spontaneous and provides opportunities to “hide behind the tool”^{Electronic tools used for process management still have a significant role for automated tasks, such as work item queries or automated progress report generation, but they should support the process, not replace it. Keep the front line physical.}.

For those colleagues who cannot be located with you, take a daily digital camera photo (use a phone) and store it on your network^{A camera has other uses as well – a shot of the scrum board at the beginning and the end of a sprint provides good discussion material for your end-of-sprint retrospective and goes some way to achieving ISO9001 “Quality Management Systems” accreditation.}. Or grab a webcam, set it to refresh every 30 minutes, point it at the board and send the URL to anyone who wants it. Your stakeholders will feel more involved and you continue to demonstrate your openness as a team.

 

Personal Timeboxing

Our scrum project has a number of timeboxed stages:

Global Timeboxed View of A Project

This timeboxed structure can be refined further, to include a team member’s day:

Refined Timebox View of A Scrum Team Member’s Day

Francesco Cirillo's Pomodoro Technique (http://www.pomodorotechnique.com/) describes a timeboxed structure to a team member’s day. This “25 minute personal sprint” approach instils a natural discipline, a sense of achievement, improves focus and improves your estimation skills. The technique may eventually become so natural that you may no longer need a ticking plastic tomato^{There are also smartphone apps such as Pomodoro Time Management for iPhone (iTunes link: http://bit.ly/itunespom) or Pomodroido for Android (http://www.pomodroido.com/) but again, if you can, keep things physical and therefore visible.}!

 

The Importance of Fun

Introducing some fun or colour into your week bonds your team and increases productivity:

• the pomodoro and a red “do not disturb” baseball cap add more discipline to your work
• planning poker cards (http://www.crisp.se/planningpoker) liven up a planning meeting and help make the estimating more unbiased
• “Brian the Build Bunny”, (http://www.woodwardweb.com/gadgets/000434.html), Martin Woodward’s customised Nabaztag smart rabbit, is a fun visual representation of the current status of your build. Green and red lava lamps can do the same thing, if you are looking for something a little more sedate!
• a simple hotelier’s bell (or a klaxon if you’re feeling disruptive) can be rung every time a story is signed off.

Be creative; keep it visible and fun. Just remember the professional part - you never know who could turn up!

 

Keeping the Team Well Oiled

Despite problems during the Glacier project, it made sense to try to keep the same team for Forest, as they had started to bond^{See Tuckman's four stages of group development - http://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development} and this was a valuable commodity. Simple ideas can further improve team morale and motivation:

• lunchtime technical video sessions or demonstrations
• use your scrum board’s reverse side as a focal point. Draw on it; bounce ideas off it
• follow the sprint review and retrospective meetings with a social event
• local voluntary evening “geek meets” can provide consultancy for the price of a pint!

 

Conclusion

Is scrum working for us? Yes! Since its adoption there have been moments of difficulty, apathy and questioning as to whether the extra overhead is really worth it. Well, it really is. The team have bonded more (both professionally, technically and socially), have become more open, have more energy and they talk more (and more openly). We’re also failing faster – a good thing – and are able to identify dead ends much sooner. We’re far from masters of the process, but we’re not “scrum buts”^{Term introduced by Jeff Sutherland when devising a scored competency test for use with Nokia. Take the test for your team at http://antoine.vernois.net/scrumbut/ .} either.

Software development should be productive and fun. The conclusions shared in this essay have hopefully given you food for thought in your organisation. Happy scrumming!

Add comment

Name (required)

E-mail (required, but will not display)

Website

Notify me of follow-up comments

Refresh

Send

Cancel