Key Read: The Art of Agile Development
The Art of Agile Development is a fantastic book on software development. There is a lot of cliques and fancy names in the world of software development and tech project management. I was never a super loyal follower to any of the methodologies, even agile. Some of the principles set forth in this book are not even normally what one would consider “agile” as this is really a book about the specific xp (or eXtreme programming) subset of agile philosophies. For this reason, I think a better name for this book might be, “The Art of XP Agile Development” or “How to Develop Great Software”.
The key idea is that the success of the product is not about how much time the developers put in, how many lines of code are written, or even how much effort the team puts into development. The real measure is the value to the user, and that’s something that people forget about in the heat of creating and delivering software. In old school project management everybody wins if the project is “on time, on budget, and functions according to the design specs”. Unfortunately, many tech managers -and worse, owners - are running their companies according to this and wonder why at the end of the road they have a product that no one wants and doesn’t bring any revenue (or at least not enough revenue). The real key is being able to adapt. Moving quickly, creating standalone working prototypes, and launching early are important. Being in touch with users, finding out what they really want, and adapting your product to deliver that is how you can be sure you are delivering value, not just delivering a set of finished tasks.
Without going too much in depth, here are some of my favorite topics from the book:
The XP Team
On-site customers, product manager (product owner), domain experts, interaction designers, programmers, designers /architects, technical specialists, testers, project managers, and coaches.
In my experience, development companies hardly ever have on-site customers or domain experts in the office. I am very strongly against giving the programmer a design doc and having him do the work in isolation, as is James Shore. Not only does he see them as necessary, but he recommends having on-site customers in a 2-3 ratio to programmers!
Having the testers as part of the team from the beginning is slightly usual as well. Most of the companies I’ve seen have a “testing phase” where the programmers pass off the finished product to be tested as really interact very little with testers (unless there are big problems with the software).
Take a read through this section yourself and see how balanced and agile you’ve made your development team!
I might not be in the majority on this one, but I personally love pair programming. Being able to think outloud, bounce ideas off of someone else, and becoming quickly aware of simple mistakes makes coding for me much easier, more fun, and just more productive as it’s much more likely the finished product will be well-written and free of bugs. Not only that, but pair programming inherently puts forward James Shores’s other xp values like Collective Code Ownership and Ubiquitous Language.
There can be tough barriers to break in bringing pair programming into your organization, especially if you are not in a position of authority. First, the programmers need to be on board with the idea. I know a lot of programmers who would hate the idea of having to work with someone else all day. Not only that, but you have to watch the match ups to be sure that it will work out (and James Shore recommends rotating pairs daily, maybe twice daily). Some people are just used to going to work and bullshitting, are not experienced enough to contribute, or are for some reason uncomfortable with the other person. Even tougher might be convincing management that pair programming is worth it. Thick-skulled managers might see it as half the work getting done since you have two resources dedicated to the same tasks. Citing successful implementations in other companies and emphasizing quality over quantity is your best bet to winning them over. The key is convincing people that this will yield better software. It will be done correctly, and so ultimately will finish faster.
Having a workspace dedicated to the project is very important to James Shore. He is ardent about the whole team sitting together and not having remote workers, if possible. Sitting together can make everyone’s life easier and allow for communication when needed.
He also says sitting together can help teams “jell” as he writes, "
There’s another hidden benefit to sitting together: it helps
teams jell and breaks down us-versus-them attitudes
between groups. In contrast, distance seems to encourage
adversarial relationships and blaming “those people.”
Whenever I see this (for example, between programmers and
testers), I suggest that they sit together. This helps the groups
interact socially and gain respect for each other
He also heavily emphasizes the use of whiteboards. He recommends rolling whiteboards that can be brought over to any space that needs them. He also recommends whiteboards for iteration and release planning.
Interaction and Release Planning
Releasing early and often makes the most business sense. Not only are you getting the product out and generating cash for the company (hopefully), but you are also monitoring and learning from your users so that you can tailor the project to their interests and desires. Keeping your options open and being able to adapt is a crucial component to agile development, and having index cards on your whiteboard (held by magnets) will allow you to easily change things up when you need to. Here is a sketch of what a good release planning board looks like.
"No aspect of agile development challenges organizational culture more than the transition to adaptive planning.”
He recommends creating new stories and fitting them into the plan with what he calls “the planning game”
Amazon Listing: http://www.amazon.com/The-Agile-Development-James-Shore/dp/0596527675
A full pdf download of the entire book can be found here: http://poetiosity.files.wordpress.com/2011/04/art_of_agile_development.pdf