An Agile Reading List
April 25, 2010
I love books. Proper, paper books. I’m always recommending titles to people, so thought it might be a good idea to pluck ten books from my bookshelves that I regularly recommend to anyone who wants to learn about Agile development, or improve their skills.
Now, please note that my background is with XP as that is the process that has worked the best for myself and for the teams I have worked with. As such, recommendation number one is:
Extreme Programming Explained (2000) – Kent Beck
This is the book that kicked it all off for me back in 2000, and it still remains the most concise and readable introduction to XP. It’s also an important text for anyone wishing to understand what it means to be “Agile”.
User Stories Applied (2004) – Mike Cohn
Human society has used stories for a very long time to convey information, yet writing user stories is often not as easy as it should be. This is one of those books that I ummed and ahhed about buying: what could a book on such a “small” subject really offer me? The answer was quite a lot, because there’s a great deal involved in learning to write effective stories. More than that, writing stories is just the first step – what we do with those stories is an important part often glossed over.
Agile Estimating and Planning (2006) – Mike Cohn
In many ways, this leads on from User Stories Applied. How do we turn a stack of stories into a tangible piece of software that delivers value to the customer? The whole spectrum of estimation, prioritisation and planning is given coverage, explaining not just how we do things, but why we do things.
Domain-Driven Design (2004) – Eric Evans
Anyone who says that Agile doesn’t do design is talking nonsense. Unfortunately, the lack of books on the subject of Agile design doesn’t help to dispel this myth. Domain-Driven Design is a much needed addition to the Agile library. Two core concepts, the use of common language and a strong model, are presented and elaborated upon to form a simple, elegant, yet powerful framework for designing large systems. My only negative point is that the book could probably be condensed into one half the size without losing the clarity of vision.
Refactoring (1999) – Martin Fowler
I picked up this book not long after reading Extreme Programming Explained. This book was very influential on me, because it made me realise we don’t have to be satisfied with the final implemented solution to a problem – people who haven’t read the book often raise an eyebrow when I mention things like “code smells”. Designs and code go stale more often than we like to admit, and this book provides a readable, in-depth guide to tackling the overhaul of code in order to improve the design, readability and maintainability. Those of us who use dynamic languages in our large-scale projects might find some of the refactorings unimportant, but the concepts are still invaluable.
Test-Driven Development (2003) – David Astels
To refactor code safely, you need to have an excellent test suite to ensure you don’t break anything or introduce (or even fix!) unexpected side-effects. This book is an excellent introduction to the subject – very clear and concise, yet often overlooked in favour of Kent Beck’s book. The bulk of the book uses examples with Java and JUnit, but covers other xUnit implementations for a variety of languages. The choice of language is unimportant as the concepts are equally valid.
Agile Testing (2009) – Lisa Crispin / Janet Gregory
An impulse purchase from Amazon that ended up being an essential book in my library. Although aimed more towards a QA team nervously wondering if they’re obsolete in the New Agile Order, this book is an incredibly good resource for anyone involved in a software project. Every aspect of testing is covering in a very approachable and comprehensive style, including the different roles testing plays and how testers can incorporate their role as part of an Agile team. Developers needs to remember that there’s more to testing than their own TDD test suites, and that’s where an Agile QA team comes into play.
Continuous Integration (2007) – Paul Duvall / Steve Matyas / Andrew Glover
There are quite a few good books on continuous integration, but this one manages to provide both a decent introduction to the subject and a good balance between theory and practice. Although I’d used CI long before I’d read this book, I must admit I’d never really needed more than a superficial knowledge. This book helped fill in some massive gaps in my knowledge and understanding.
Agile Retrospectives (2006) – Esther Derby / Diane Larsen
This book covers a much-neglected part of the Agile process: reflection and self-improvement of teams. Regular retrospectives to give teams time to identify where things are going well, where things are not going well and seek out ways to continually improve themselves. The book introduces the concepts behind retrospectives, gives a framework for running them, and presents various supporting exercises that can be used.
Principles of Software Engineering Management (1988) – Tom Gilb
This might seem an unusual one to finish with. Why is it even on an Agile reading list? Because it’s easy to forget that “being Agile” is not new, or a fad, or sprung up suddenly. This book covers evolutionary delivery, estimating and dealing with risk, planning and code inspection. Although written for a “traditional” software engineering audience it reads in places more like a proto-Agile manifesto, a genuine reflection on the discipline and where it was heading at the end of the 80s. I really wish I’d discovered this book at university, rather than ten years later, because it would’ve changed my approach to software engineering outside of academia. Even reading twenty years after it was published, it still offered a very relevant text.
The Urgent / Important Matrix
September 6, 2009
I’ve been attending management training courses the last few months, with one one-day course per month. The most recent one was on Time Management. I wouldn’t say I’m the greatest time manager, in fact a little disorganised, but luckily my public image is much better than my own mental image: people tell me that I get things done on time. Checking back, it’s true – but I always feel I can do better.
So it was great that one thing in particular grabbed me during the course: the Urgent / Important Matrix. The matrix struck me as a great way to evaluate workloads and priorities in a lightweight way, and I’m going to start using it at work to see how it pans out. I believe it originated in Stephen Covey’s “Seven Habits of Highly Effective People”, a book I haven’t read but have just added to my Amazon wish list.
Grab your current To Do list, or whatever else you use to track tasks, and go through each in turn. For each task, you assign an Urgency rating and an Importance rating. To keep it simple, your urgency is either Urgent or Not Urgent, and your importance (yep, you guessed it) is either Important or Not Important. You might find it easier to draw a large 2×2 grid with Importance on the x-axis, and Urgency on the y-axis. Write down the tasks in the appropriate box for their Urgency/Importance combination.
Now take a look at those tasks on the matrix.
At one extreme, we have the tasks that are neither urgent nor important. These are likely to be time-wasters and should be dealt with appropriately. Do, Delegate, Dump or Defer. If they’re quick tasks, or you have nothing else to do, do them: get them completed and off your list as soon as possible. Better yet, delegate the tasks to people who want to tackle thm and are able to get the work done. Otherwise, dump or defer the task. If it doesn’t need to be done, get rid of it from your list or defer until you know it can go. If it becomes important or urgent later, it’ll come back – we all know that from experience!
At the other extreme are the tasks that are both important and urgent. Your website has been Slashdotted, your data centre is currently engulfed by flames, or your new project rollout has failed spectacularly and it needs to be fixed ASAP. This section of the matrix is reserved for crises. You need to focus on dealing with those tasks straight away, but you also need to ensure two things: make sure you don’t end up firefighting the same issue again later on, and make sure other tasks don’t start creeping into this part of the matrix while you deal with a crisis task.
That leaves us two bits…
Urgent but Not Important tasks are ripe for delegation, if possible. If you can’t delegate them, they should be dealt with quickly and efficiently. Focus on resolving only the urgent aspect(s) of the task so you don’t use up valuable time needed for other tasks. Ultimately you’ll end up with a task struck off the To Do list, or one that is now no longer urgent or important.
Important but Not Urgent tasks are the interesting bit: these are usually the main tasks of your job role. I found this rather surprising, because I started off thinking most of my work was in the Urgent + Important category (my customers would certainly say they are), but it isn’t. Suddenly things seemed much clearer and more manageable. You need to keep on top of these tasks though, allocating sufficient time to get tasks done. Otherwise, they will end up rising in urgency and become crisis tasks.
If you’re struggling to find the time to do everything on your To Do list, give the matrix a try and see if it helps. You’ll probably find some tasks that can be delegated, some others that can be dumped and a few that can be struck off the list by finding a spare few minutes during a hectic day (great when you’ve hit a problem and need to take a break and do something else). More importantly, you’ll spot the ones that absolutely need to be dealt with first, and the ones that really matter to your day-to-day work.
Further reading:
Agile Retrospectives
August 24, 2009
One problem faced by my team is that we’re not really a team, more a group of teams and individuals lumped under the generic title of data management. We’re Python and .NET programmers, SQL developers, DBAs, reporting and data warehousing specialists, data integration engineers, Salesforce developers, intranet tool builders… and we do more than our job roles. We’re all working on different things, but you appreciate that while our tasks and projects might not be the same, the issues we face are similar. Our customers, mostly internal, are similar – we talk to the same people and use a common business language / jargon. We face typical problems: inter-departmental communication, scheduling of work, dealing with defects, refactoring code, juggling priorities, coping with the office environment. In hindsight, it sounds obvious: it’s the same set of problems that face anyone in IT, or most lines of work for that matter.
I decided that we needed to pool knowledge, get a bit of team bonding going and try to figure out how we can collectively tackle the irritations we face. We also needed to share and celebrate our successes.
A few months ago I picked up a copy of “Agile Retrospectives” written by Esther Derby and Diana Larsen. Even if you don’t practise agile development, retrospectives can be a very useful way to close projects or provide regular team reviews. In my case, it was a great way to get the team talking to each other and sharing their problems and successes. We’ve opted for a 2-hour monthly retrospective, with a general reflection on the time between the current and previous retrospective. One thing I really need to do more is set some proper tasks and goals from the meeting as we tend to be a little vague at times. We also find ourselves focusing on problems we can’t easily fix because they lie outside our immediate control. We need to work on the things we can do ourselves first.
A typical retrospective, as defined in the book, is broken up into five sections:
- Set the Stage
- Gather Data
- Generate Insights
- Decide What to Do
- Close the Retrospective
Set the Stage is a simple welcome and introduction. This is a chance to get everyone to say a couple of words so they feel comfortable talking and contributing. So far, I’ve stuck with asking the question “in one or two words, what’s on your mind?”. It can be uncomfortable for some, but it can be quite revealing too, and it certainly takes the edge off things – once you’ve said one or two words, more will often follow.
For the Gather Data part of the retrospective, the aim is to grab as much raw information about the project / iteration / month covered by the retrospective. Different people experience different things – in our case, the fact we’re all doing different things means we cover quite a lot of events. Some of these overlap (server problems, office temperature, distractions) while others can be specific to one or two people. I use the “Mad, Sad, Glad” game, accompanied by suitably coloured sticky notes, to get the team to write out anything and everything that comes to mind. We’re often talking quite a lot, and as people stick up notes on a wall it prompts other ideas and memories. When done, we collectively cluster the notes and then choose labels for each cluster – it’s perfectly fine if we discover the need to recluster as we label, because we’ve spotted something interesting or have found a better way to cluster.
Generate Insights is about analysing the data gathered: looking for patterns and discussing our stories. For our retrospectives, quite by accident, this ended up becoming part of the clustering process mentioned above. It felt a natural transition, so we’ve kept it that way for now. Things will obviously change when I decide to switch the game to something different.
Next up is Decide What To Do. Using sticky dots, we then vote on what cluster is most important for us to take a look at. Obviously, things that are affecting us negatively will be most likely to want attention, but it’s nice to see the good things voted for as well. We then brainstorm ways we can tackle the cluster before voting on what suggestion we want to do. I’ve found making a list of things we need to Start Doing, Stop Doing and Keep Doing to be simple and interesting for the group. The only downside, which is my fault, is pinning the team down on setting actions that are achievable by us. Too often we hope for other people to change, when we could (and should) more easily work on change amongst ourselves.
Finally, Close the Retrospective. Wrap things up and let the restrospective coach know how things went. I like the Helped, Hindered, Hypothesis game where everyone writes a note to me to tell me what helped them during the retrospective, what didn’t help, and what things I can do next time (the “Hypothesis” part of the game – struggling for an H?).
It’s early days for our retrospectives, but there’s plenty of scope for improvement and mixing things up to keep it relevant and, above all, fun. It’s proved a great way to vent some steam, think about the way we do things and give ourselves a pat on the back for the good things we do. We don’t celebrate success as much as we should, which is a shame because we all want to do the best we can and get a little recognition when we achieve that. I’m enjoying hosting them and it’s a great help for me as it provides the opportunity to work on things I always felt I couldn’t do well: like leading a group, facilitating team discussion and planning something IT-related that isn’t a software project.
Give them a go sometime!
For further reading….
