Thursday 4 November 2010

Are we Agile yet?

So I was lucky enough to attend an Agile Fundamentals talk hosted by Steven List of Thoughtworks. Like a lot of companies we've been doing our own version of Agile for a while and thought it would be an idea to send a few guys to the talk and revisit the basics to refresh ourselves with the core fundamentals.

Cracking talk - Steven was a great speaker I jotted down a few notes and thought it would be an good to get them on here.

Agile manifesto:

http://agilemanifesto.org/

So you think you're Agile? So did we. Then we looked into the Agile Manifesto:

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

I don't want to go into all the Agile background, founding members, etc, etc and I certainly don't want to turn into the Agile Police but it's worth highlighting that the items on the right are important there's no doubt we need them and will use them if and when required BUT the items on the left are much more important. That is if you want to get the full benefit of using Agile. Any time we lean towards the items on the right it's worth someone whispering "but that isn't the Agile way". Someone should do an app for that.

Which 2 goals do you want?

http://en.wikipedia.org/wiki/Project_triangle


The project triangle

The project triangle. I loved this. What I like about Agile is the bluntness of it all. It's very open and transparent so we're not fooling anyone. If you want the project to be cheap and quick then it won't be good quality. If you want a product quickly and of a high standard then it won't be cheap. Of course you can always go for a high quality product that is cheap - but it won't be quick.

One of these factors WILL ALWAYS SUFFER. Think about the 2 goals your team wants to aim for and stick to them. "Two out of three ain't bad" [Meatloaf, 1977]

Bugs are things you find in the garden

http://www.agile-testing.info/defect-inventories/

Ok maybe I've exaggerated the point but whatever it's called or however we phrase it a bug, a defect, an issue it's all the same thing - a change to the working code. And that's exactly how we should treat them. Write a new user story put it on your board and into your backlog. If it's urgent then prioritise it at the top. Next iteration it's fixed. Job done.

Also Steven discouraged the use of bug tracking software. Or more accurately he suggested if QA or the team want to use a bug tracking system that's fine as long as there is also a user story that address the problem on a wallboard. This mirrored my experience with bug tracking software. Everyones bugs become vital (showstoppers) and any trivial bugs have a tendency to get left untouched.

More us less them

http://jamesshore.com/Blog/The-Crucible-of-Great-Teams.html

Some points in the talk reminded me how good it is to work in an Agile team. I'm not talking the dev team I'm talking about the whole team - product owners, PM's, BA's, testers the whole schabang. Not all of us will have (or want) the full set of roles to make up an ideal Agile team but however your team is setup the main principle is that the team succeeds or fails TOGETHER. It's not John's code, Neal's test or Adam's web service. It's our code. Our product.

It's very obvious to say but working as a team errrm works! Want more productivity, looking to improve quality? Have the team sit together, encourage collective ownership, use activities to help them bond and ask them to find solutions within the team. You might be surprised. As Steve put it during his talk "STOP BEING A HERO".