Agile Software Development In 5 Minutes

Recently, I have been doing lots of recruitment for .NET consultants. Each of the CV’s we receive all stress that they are experienced in working in agile development shops. This is great. We are an agile development company so these people sounds like a great fit.

Agile Software Development - Embracing Change

Agile Software Development – Embracing Change

So we get them into an interview and ask them, ‘What does agile mean?’, ‘How do you know if your team is truly agile?’ It’s at that point we get the standard list of responses:

    • We do Test Driven Development.
    • Daily stand-ups.
    • We pair program.
    • We use continuous integration.
    • We use SCRUM, KanBan, XP etc.
    • Use work in iterations.
    • We use story points.
    • We calculate team velocities.

These answers are all well and good, but they don’t describe what an agile team is. These are all just facilitators to being agile. What’s even worse is that these interviewees seem to have not heard of the agile manifesto.

To describe what agile is all about, you can sum is all down to the following, (quoted from the agile manifesto website).

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Following on from the manifesto above, there are 12 core principles behind the agile manifesto. I won’t quote them all, but you should go and read about them here.

One thing you will notice from the 4 points of the manifesto above is that they are mostly focused around people.

Agile Manifesto is all about team work and collaboration.

Agile Manifesto is all about team work and collaboration.

Individuals and interactions over processes and tools

Software systems are built by teams of people, and to do this properly they all need to work together and have good communication. This isn’t just software developers, but includes, QA, Business Analysts, Project Managers, Business Sponsors and Senior Leadership and anyone else involved in a project at your organisation. Processes and tools are important, but they are irrelevant if the people working on the project can’t work together effectively and communicate.

Working software over comprehensive documentation

Let’s face it, who reads 100 page product specs. I certainly don’t. Your business users would much prefer to have small pieces of functionality delivered quickly so they can then provide feedback.  These pieces of functionality may even be enough to deploy to production to gain benefit from them early. Not all documentation is bad though.  When my team works on a project, they use Visio or other similar tools to produce diagrams of (and this is not an exhaustive list):

    • Deployment environments.
    • Database schemas.
    • Software layering.
    • Use case diagrams.

We normally print these out on an A3 printer and plaster them all over the walls so they are visible to everyone. Small, useful pieces of documentation like this are invaluable. 100 page specs are not as 9 times out of 10 they are invalid and out of date before you have finished writing them. So remember, the primary goal is to develop software that gives business benefit, not extensive documentation.

Customer Collaboration over contract negotiation

All the software that you develop should be written with your customer’s involvement. To be successful at software development you really need to work with them daily. This means inviting them to your stand-ups, demoing to them regularly, and inviting them to any design meetings. At the end of the day, only the customer can tell you what they want built. They may not be able to give you all the technical details, but that is what your team is there for, to collaborate with them, understand their requirements and deliver on them. The customer also has the right to change their mind from time to time, which leads us onto the final point.

Responding to change over following a plan

Your customer or business sponsor may change their mind about what is being built. This may be because you have given them new ideas from the software you delivered in a previous iteration. It may be because the companies priorities have changed or a new regulatory change comes into force. They key thing here is that you should embrace it. Yes, some code may get thrown away and some time has been lost, but if you are working in short iterations then this lost time is minimized  Change is a reality of software development, a reality that your software process must reflect.  There is nothing wrong with having a project plan; in fact I would be worried about any project that didn’t have one.  However, a project plan must be flexible enough to be changed, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.

Going back to the original point at the beginning of the post where people talk about iterations, stand-ups, TDD etc. They are all very valid, but they are tools to help you achieve the 4 agile manifesto statements above.

Participate with Coding in the Trenches on Facebook

Participate with Coding in the Trenches on Facebook by Click the button above.

This entry was posted in Agile, Code Quality, Process, System Design and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s