Avril is a talented artist and QA super star. While we worked with her team she would always paint pictures to express what was going on. In this very honest piece (re-posted from her own blog with permission) she shares the story of what it was like for her team to try Agile in words and pictures.
The department I work in (Technology) did a bit of an experiment last year to get agile software development going for a bit – that was a really interesting time to live through.
(If you want to bone up on Agile: wikipedia article is here)
We had two mentors, Nigel and James, who took us through the process – they took us out to the Lonely Planet (an interesting story of a company that went entirely agile in every team) to show us the workings, and they worked through our issues with us. I have nothing but praise for these guys, they know their stuff:
I need to point out that this was not their actual heights or what they looked like. I rather think James was affronted by this picture! hehe.
This is their company website: Lunatractor
Basically agile is a way of an attempt to cut out the pointless crap around a project, allowing the teams to run themselves, giving everyone a say at allocating their own work, making the workflow obvious, and doing small, continuous releases of working software so that there are benefits straight up (releases every two weeks, known as a ‘sprint’). This way you actually start to get the benefit of project immediately, not wait months for requirements, and every two weeks, a reassessment of the next most important bit of work comes in.
The way we ran it was a modified version of ‘scrum’: the work was assessd, broken down into small do-able units, written out onto cards, which were stuck on ‘the wall’. Each bit of work was a ‘story’, and the stories went through development, testing, etc cycle.
An example of a story: “As a member, all my leave without pay must be factored into my service”. Then we’d take that and break it down into the tasks we needed to do and how long they would take. The devs would develop it and i would come up with test cases and a way of testing it.
‘The Wall’ was the source of truth, and anyone could come and look at it and see the stories was we were working on. If you moved a bit of work on, you physically moved the card to the correct spot on the wall. It was a really good way of keeping track of who was doing what. If you worked on a card, you put your avatar on the card (we all were represented by a different picture).
At the start of every day we had a 15 minute stand up, where we discussed what we would be doing that day. We used to run our stand ups sitting down cause we were all lazy.
All the team sat together and conversations happened all the time about the work. Sometimes there was cake. My team appear to be obsessed with morning tea. This is not a bad thing.
Work was nutted out on the whiteboard, lots of yelling and gesticulation happened, and everyone knew at all times what they were doing. We all leveled up in how to interact with the other people we worked with.
It was a great project to work on. Of course, not everyone liked this approach, and it did not suit everyone as it was very different in mental approach to very traditional software development (lots of specs and paperwork).
At the end of each sprint we did a retrospective : what we did well, what we should do better next time, what the problems were. The first few sprints were hard, very very hard. There were a lot of arguments. We had some defections from the team. There were some bodies – we put their little avatars into the ‘graveyard’ bit of the wall when that happened. By the end we were churning out 8-10 fixes and enhancements every two weeks, which was an incredibly fast pace – and we got no return prod defects from our work. Something to be proud of.
Also at the end of each sprint we invited all the stakeholders to come to a presentation, which was usually prepared with much hilarity that day – this is me and Nancy and Erica getting the powerpoint slides ready:
This is Mick and Aaron doing their very amusing presentation to the stakeholders at the end of their sprint:
I attempted to do a presentation once but my public speaking is ATROCIOUS. I actually forget what I’m talking about quite easily and I also say “fuck” a lot when I’m stressed. IT DID NOT GO DOWN WELL.
We did very well and we got the backlog of work done, we fixed defects we found on the way, it was an excellent process.
Ultimately though my company is not an agile based company, and the methodology was misunderstood and not adopted. We hit a lot of problems working against the status quo – Prince II methodology (which to me seems to be just moving shit around spreadsheets but not actually producing anything at the end of it – PLEASE can someone tell me why I’m wrong if i am!).
There have been a few more projects that have been done agile methodology, also with success, but the value is not really recognized and i doubt there will be more.
This picture represents the fight of us against the status quo.
I would not mind working for another company that does agile properly one day, though that being said, I’m aiming to get out of doing software and get into doing art full time. So back to what they call waterfall but what is actually V-model software development for me!
Such a pity!
Such inspiration, at any rate.
As a postscript since this was written Avril let me know she’s working on new agile project, and things are changing for the better.
Hi James/Avril,
I don’t think your definition of Agile is correct – Agile is merely a set of best practices to make project management more adaptive to the evolving and dynamic nature of software projects.