Of the 4Ps I mentioned in my original post this is actually the one that I am finding hardest to define and articulate. Most of my thoughts are about what doesn’t or hasn’t worked rather than a way forward and I am trying to avoid that. Alot of this seems to bleed into the idea of Products not Projects but we’ll see where we get to.

In my career I have been all sorts of PMs except the big one. I have been a Project Manager, a Production Manager, a Programme Manager and a Product Manager. I have studied & used Prince2, Scrum, DSDM and MSP and various other bespoke interpretations. Each and everyone had its strengths and weaknesses and to a great extent each of them depended on the manner they were implemented and adopted for their success. Prince2 doesn’t *have* to be a bureaucratic, paperwork creating monster, Scrum can quickly become as bogged down with external issues as anything else.

I do think the ‘agile’ movement was one of the first attempts at something that really was targeted at modern web/software development and thus does have a whole lot of benefits. The guys at GDS have just written a great post about how they used agile. I very much enjoyed my time at Jiva working in a Scrum team – it was certainly the most productive I ever felt and the near instant gratification of ideas > code > production was an eye opener.

The thing is though in my (relatively limited experience) this kind of Agile (bit a big ‘A’) only works when you have those kinds of multi-disciplinary teams working closely together – preferably in one physical location. [I realise companies do run distributed Agile teams but even then they are teams working on a common goal with a common employer.] The simple fact is most of us in my corner of the public sector are never going to have that luxury. Teams consist of 3 or 4 people and if you are lucky one of those is technical. As I mentioned in my People post it is helpful if people have picked up additional skills but the reality is things like in-house specialist web designers or UX people are rarer than hens-teeth. These roles are out-sourced and with pressure on budgets these days they are only out-sourced when projects are already tightly scoped.

The fact is procurement and the processes that surround it remains as big a part of my job as the delivery of my actual objectives and is almost the polar opposite of ‘agile’. Things like the G-Cloud are very welcome but they haven’t really filtered down to many of us yet and so the challenge is how do you act in an ‘agile’ way when weighed down with procurement rules designed for the purchase of particle accelerators.

So my thinking of how to be more ‘agile’ (with a small ‘a’) has increasingly been about turning it on its head a bit and taking a new look at how we scope and then communicate these pieces of work that we need done.

I was very much inspired by a post I read a while ago from Gez Smith about ‘How to Buy Digital Engagement Software‘. It could easily have just been titled ‘How to Buy Digital..’

There is alot of great stuff in the article but for me thing that clicked, and synched up with my desire to be more ‘agile’ within my own reality was this one;

3: Write user stories, not lists of functionality.
At the end of the day, what are you looking for in buying software; a bunch of functionalities, or a series of ways for real people to do real things? Sometimes, people seem to think they’re protecting themselves by writing a detailed list of things software must do, as they have a checklist to compare against the final outcomes. But if you try to play that slightly legalistic game, then you actually make it easier for people to use semantics to do things the way they want. Instead, give potential suppliers a list of goals you want people to be able to achieve by using the software, and let them explain how their software will meet these goals in return.

One of the things as a Product Manager/Owner in Scrum I found most interesting and fulfilling was writing user stories. The ‘As a user..’ template most commonly used forced me to boil things down to the really core needs and get away from the traditional shopping lists of functionality & capability that so often end up dominating. Combining this with the ‘lean’ concept of data driven decisions and you end up for user stories that you can back up and are more useful for both the person writing them and the eventual supplier delivering the solution.

Doing things this way also allows suppliers to offer you something you might never have thought of yourself. The fact is there are always people out there more expert than you and if you give them space to be creative you will often get unexpected but improved results.

Most people reading this will probably just think this sounds obvious and would have been doing it for years. The fact is though this still seems radical to many in positions of power and so to even try it on something of any scale it again comes back to having people sufficiently high in the hierarchy to support the concept and push it through.