Agile Practices

I’ve been reading Agile Software Development, Principles, Patterns, and Practices by Bob Martin. I’ve found the book to be interesting so I thought I would take the opportunity to write an overview of certain parts of the book.

The book is all about Agile(in the title) and all practices to deliver higher quality software. I have personally found it a problem saying the word ‘Agile’, because in the software development industry it has become to mean different things to different people. Just go ahead and have a conversation with any developer or project manager and ask them what they think is Agile and you’re bound to get a few different responses.

What I like about the book is that Martin starts the book off with the Agile Manifesto, front and center. A reminder of what are the core principles of Agile. It’s easy to get lost in the sea of different types of Agile methodologies, I thought this is a good way to start the book.

Individuals over processes and tools

In any organisation, the people are the most important asset to the company. We shouldn’t just look at the coding skill of a programmer but their overall value they bring to the organisation. Do they work well with others? are they an effective communicator?, good at managing their tasks etc.

A group of average programmers who possess other useful skills (apart from just coding) can be a powerful thing. In addition to that, it’s more important to build a team than an environment. Build the team and the right environment will naturally build itself.

Working software over comprehensive documentation.

This is about finding the right balance. It doesn’t say have no documentation, but short and concise document.

One of the problems with having an extensive documentation is keeping it up to date with the code. Every time you change the code, you end up having to maintain the code and vice versa.

Martin’s first law of documentation

“Produce no document unless its need is immediate and significant.”

I have to admit I’ve been guilty of violating this principle in the past by wanting to have big up front design. A little design is fine, what this is saying is don’t have too much design.

Customer collaboration over contract negotiations.

More human communication and less through documents. Creating a feedback loop with customer and the developers.

Giving a development team a specification and walking off and coming back in the future with no communication will lead to a failed project.

Responding to change over following a plan.

We can go ahead and make plans for the far future with deadlines, but the project rarely is delivered on time, high quality and sometimes it’s not even what the customer wants. Having shorter iterations are more effective, as it give more opportunities to change course if the project isn’t going the direction the client wants. More communication between the client and development team to raise concerns. Overall making management of the project a lot more nimble. However I don’t see no harm in planning for the medium term and the long term but keep in mind that it’s a rough plan, rough so it shouldn’t be dependent on. The only plan we can depend on is the plan for the next week or 2 and no more.

Many Methodologies

Yes there are many Agile methodologies, what’s important is you stick to the general principles of agile., SCRUM, Feature Driven Development, eXtreme Programming but what is most important I believe is having clearly defined principles that you follow, with constant communication with the customer, and short iterations gives the project a higher chance of being successful.

That’s an overview of the first few chapters of the book, next time I’ll be covering some of the more technical sides of the book.

Ced