Friday, 12 July 2013

??? Agile ???

So a good person in our local community just asked 'Can you learn Agile through books or courses, or is it based on experience and a gut feeling' ?

I've been trying to do Agile for as long as I can remember. OK, the last 7 years, but that's like a long time to me.

My gut feelings are these:
- Books are great. read them. Absorb them. I've got a shedload of books on 'Agile' and I've read about 2% of them.
- Books/courses are shite when compared to sitting next to someone who has been there, done that. Why? Because real world problems are not the problems in the book. The guy next to you can help you with your problem today.
- If you're working for a company that says 'I want us to go Agile' ... it'll probably fail. If any of these apply, it will defintely fail:
 - You have a PM that has MS Project
- You have a PM that talks to you in terms of 'resource available'
- You have a PM
- You don't talk to the client daily (be that verbally, through emai, skype etc)
- You have a company that deals with its client through legal contracts that specify deliverables on specific dates
- You work in an environment where every system change is negotiated through email / change requests / workflows
- ... and a lot more

Now that's a big list.
And most companies will be able to tick a box there.
You, as a developer, can make you're life easier, and more enjoyable by driving agile techniques within your team, and within those constraints, but it ain't agile. Its partial-agile.
And for a long time its the most I could have. And that was cool. In itself.

But, the last three months, I've been working on a pretty shit-hot team, with an amazing client.
We do this :

We use a board. (AgileZen, Pivotal, Trello). They raise issues/features. They prioritise them on a daily basis (ie when they add something).
We communicate mainly via email(rare) and the board (They are several timezones away from us - YES- remote !) and a chat client (hipchat).
We do the features/issues. The features/issues are so small that each team member pushes 4 or 5 a day.
Small changes == small bugs == small signoff.
Every time we push to master, it goes live (auto-magically).
Yes.
Live.
No getout.

That's it.
If you can get to a place where you have small features, with daily contact with your client, and you push code live 30 times a day - you'll be happy.
You won't care about whether or not you are 'Agile' or not - you will just have a decent workflow. Which builds trust. Which minimises deadline requests. Which makes for happy clients, and happy developers.

It's not for everyone, I realise, but its the most 'Agile' I've ever felt.
Companies that say 'We can't automate our deploy', or 'The developers can't talk to the client' or 'We can't deploy live' or 'We can't break down features that small' .... they don't want to be agile. They want to think they can agile.

3 things you need:
- Automated deploy, every time you commit (its important)
- Small feautures (you can still have epics)
- Access to the client

That's it kids !

And remember - no book or course can replace the experience of your own failure.
Happy coding peeps !