Practical Agility

I blogged about using Heilmeier’s Catechism as a checklist before starting software projects over on my company’s blog.

Have a read, you might enjoy it, and don’t forget to comment!

Heilmeier’s Catechism – a checklist for software projects

I blogged about rolling your own Salesforce and SQL match codes to help de-duplicate data over on my company’s blog.

Have a read, you might enjoy it, and don’t forget to comment!

Matching Salesforce Data to Back Office Systems

I blogged about collaborating with customers rather than just delivering what they ask for over on my company’s blog.

Have a read, you might enjoy it!

It Hurts when I do this – an open letter to software consultants

Hallo again, it’s been a while. I could come up with a whole list of excuses for the lack of updates recently, but it really boils down to two related things:

Firstly, I’ve been spending a lot of time updating my company’s website, which has been a big effort in addition to actually working on customer projects.

Secondly, I’ve started to blog over there, so there are a few posts to read on that website already. I’ll link to them with some separate posts , so that the RSS feed updates correctly.

I will be blogging again here, I promise. I’ll try and keep the corporate blogging about consulting best practices and this blog about agile, but there’s going to be some cross-over for sure.  Rather than duplicate content on both blogs, I’m choosing to link to what I post over there from here (and potentially vice-versa when it’s appropriate).

In a previous post, I tackled a question from an architect friend of mine about whether it was possible to have anything worth releasing in just three iterations. In this post, I want to answer another question from the same conversation:

When we are building software with a traditional phased approach, we have  a lot of time to think about design. How do we avoid bad design if we are moving so quickly?

When you’ve been part of the Big Design Up Front school, you try to anticipate all requirements that may come your way and design for them up front, completing the design of the software before development begins. The problem with this approach is that you end up with a lot of code that you do not need, for a lot of anticipated requirements that never came to fruition, or were removed from scope as the project progressed.

When I was having this conversation with my architect friend, he assumed that I was going to propose an alternative of no design up front, but of course this approach is worse than BDUF.  Let me say that more succinctly:

For anything other than the most trivial of projects, too little design is worse than too much design.

If you don’t think about design at all up front, the best outcome you can expect from your project is a mish mash of features that probably do not hang together as a product. Your most likely expectation is to throw away lots of code and have a dead ends and false starts.

So how much design is enough design? The ideal approach is first to think about the end game for the project. What is the vision for the product / project? What would that look look like (at a very high level)? If your customer expects some upfront specifications, spend the time to create a short document using the Big Picture documentation pattern, as described in Agile Documentation by Andreas Rueping:

Problem: How can people be introduced to a project without being confronted with a deluge of technical details?

Solution: A good feel for a project is best conveyed through a description of the “big picture” of the architecture that underlies the system under construction.

Andreas goes on to describe the documentation pattern as describing the overall architecture, showing how the system is composed of subsystems and modules and explains the basics of the system’s behaviour. It also explains the design principles and the motivations that led to the design, as well as naming the technologies involved in the design. Most importantly, it abstracts over any details, technical or otherwise, that are irrelevant to an overview.

For detailed design, think about what is in the current iteration, and what you expect in the next iteration (some people call this the back burner iteration), and design for that. This is just enough design. Document your design using a wiki, and keep really detailed function and module level documentation in the tests where it belongs.

Maria Spelterini

When designing for an agile project, you will always be walking the tightrope between too much and too little design. It’s a scary place to be at first.

When you fall off on the too little design side you will either have a patchwork quilt of requirements that are not a product, or you will throw away code and have dead ends.

If you fall off on the too much design side, you will end up with lots of detailed design, code and dollars spent on requirements that are no longer needed.

I never said this was easy – this is why we earn the big bucks, right? But, just like a tightrope walker, actually getting up there and falling off a few times will make you better at it in the long run. Over time, you will become the Maria Spelterini of Agile design.