Is ‘Agile’ important?

I’ve linked to this on Twitter but I just wanted to comment on it here. Bob Marshall has written this brilliant post titled Agile Development Doesn’t Work and I think it is a must read for anyone in web development (especially on the management side).

It can be summed up with its introductory statement;

Q:
How to build great software?
A:
Build a great team, and have them build it for you.

It basically talks about the fact that getting talented, motivated people is the key to success and not the process you use. I remain a big fan of ‘agile’ development but increasingly worry that ‘Agile’ development has become a victim of trying to become mainstream. Look at the price of the courses, the reams of words written about it, the software springing up to support it and the ever growing lists of ‘rules’.

When it works well ‘agile’ is very powerful but I wonder if that is because on those occasions it attracted great teams who could have delivered amazing stuff no matter what the ‘management fad‘*?

GOVUK, to use my standard example, have recruited a small army of very talented, resourceful and dedicated people who would probably deliver brilliant work no matter what framework they were working within – though I do wonder if part of the reason (though maybe a small one) they signed up was the allure of working with agile so it becomes a bit of a chicken and egg kind of thing?

*Bobs phrase not mine 🙂

Scrum-ptious Applications

One of the things I miss from my time at Jiva (apart from the team of course) is working closely with everyone to actually build the product and the way we used to Scrum in a relatively flexible way to give us a framework to work within.

Of all the myriad roles I’ve had over the years Product Owner in the Scrum sense was the one I felt fitted me best. I enjoyed the agile nature of things and also the user focus of creating stories, the collaborative manner that work was estimated and especially ‘show and tell’ element at the end of each sprint. The whole aspect of protecting the ‘doers’ from the ‘talkers’ suited me as well and all-in-all given the right product it is something I would very much like to do again.

I don’t really get to work that closely with projects these days but I do continue to maintain an interest in the area and over time have come across some tools that I would like an excuse to use one day soon.

Scrumy is actually something I looked at a while ago but had forgotten about. It allows teams to create story ‘cards’ online and drag’n’drop them according to their status. At Jiva we went old school with a great big wall, lots of drawing pins and stacks of index cards – which was brilliant (and also a great visual) but perhaps something like this is more practical especially with remote teams. Even office based using a projector could give you the big wall effect when needed! PivotalTracker is a similar tool and one I enjoyed using in the past. As far as I can tell there isn’t much to split them on features but I enjoy the sense of fun that Scrumy exudes (though I also appreciate the fact that Pivotal is entirely free!).

MeetingMix got a bit of coverage this week on Techcrunch and it is a simple idea done well. Essentially it just aims to improve the planning and management of meetings. Recently we started to look at structuring meetings at work slightly differently based on this article about how Google run meetings and I’m pretty sure at least some elements of this app were inspired by the same thing. The ability to easily collaborate on an agenda is obviously possible via something like Google Docs and the same is true of live note taking during the meeting but this pulls these things together in a very elegant manner and the clock letting you know how much time has been expended on each agenda item is nice. I do think this is the sort of thing that could really help meetings but I do wonder how many organisations would be in a position to have a spare projector to allow this to be visible independently throughout the meeting which is how it would make the biggest impact.

Planning Poker is a nice little site that helps remote teams quickly handle the estimation of stories for the upcoming sprint or beyond. A moderator enters a story (this is another reason where tools like Scrumy and Pivotal come into their own above the old school index cards – copy and paste!) and the dev team gets to vote on score to give it for the coming sprint (I’m not going to explain estimating etc for Scrum here – lots of articles about it out there..) This should speed up the process considerably with discussions taking place around ‘poker’ to give the stories context (this can be via Skype, Campfire or anything else). It has pedigree as well as its developers are major evangelists for Agile development.

All of these tools obviously are only there to support you and your project and don’t do much to help if things are not going well elsewhere but I think they could be useful and are well worth considering amongst any suite of applications used to manage agile projects.

Crouch, touch, pause, engage!

For those of you who aren’t glued to their TV screens during the Six Nations the title of this post is a reference to the instructions given by a referee in rugby before each and every scrum.  Why am I talking about rugby?  Well as a part of my job I find myself being introduced to all sorts of new ideas and the latest of these is using the Scrum methodology for running projects.

classic rugby scrum
classic rugby scrum

Scrum is an agile methodology that, at least in theory, looks like a god send for those of us more used to the forest destroying, will sapping, momentum stalling Prince2 system of running projects (and yes I know Prince doesn’t have to be like that but in my experience its how it always ends up!).  Scrum aims to empower the developers and also be flexible enough to realise that specifications change over time and creates a framework that can evolve with that but also regularly deliver solid outcomes.  It seems that I am going to take the role of Product Owner for Beanbag, which after some background reading seems to suit me fine.  As far as I can tell the role of the Product Owner is to act as the voice of the user/customer, set priorities for each ‘sprint’ (a short, in our case 3 week, period of work with deliverables at the end), make sure that the priorities are also supporting the business needs and then to get out of the way and let the developers do their work.  To maintain the rugby theme its kind of a scrum half role, pointing the guys who do the hard graft in the right direction but leaving them to do the nitty gritty then grab the glory at the end!

According to some of my reading it has quite a bit in common with the Product Manager role that alot of web and software companies have and this makes sense and this kind of role seems to be a bit part of what my job is settling down to become (with a chunk of what Tara Hunt used to call Pinko Marketing as well).

This week will be the first time I really get involved in this aspect and I’m really looking forward to seeing how it works out.  3 weeks in and the job is still pretty exiting as it evolves round me and the more time I spend on Beanbag the more sure I am of its potential and this Product Owner role will give me a real opportunity to start influencing the direction of things a bit which is something I have missed since leaving JISC.