Taking the Technology out of Agile – #UKGC12

This is my write up of the session that @pubstrat and I curated at UKGC12. Large apologies for the delay.

@pubstrat and I have been meaning to have coffee and general catchup ever since UKGC11 and I am hugely glad we finally managed it as it set my brain buzzing – will be stalking him for more regular meet-ups as a result.

The conversation built on earlier discussions about how we might apply agile principles outside of software development and into the wider project management process. The reasoning for this is twofold – firstly that coders have developed Agile in response to working in a shifting and boundary-less world which is the situation we are all faced with and secondly because of a need to harmonise project and software management practices if you want technology dependent projects to work. More on this background here.

The UKGC session focused more directly on how we might approach amending project management practice – the subtitle of the session could be ‘plan for the permanent eradication of PRINCE2’.

I’ve broken this post into sequential steps for project management. Apologies for the bullet points – I will expand on anything that doesn’t make sense if you ask…

**Scoping the project**
Scoping the project is about setting up the boundaries and ensuring that you have a clear vision as to what you are trying to achieve. This is even more important with respect to Agile projects in my opinion as they can, if not tightly managed, take off in unexpected directions and you end up with an outward focused spiral rather than a tight development process. The points we discussed with respect to this in the session were:

• Be less obsessed with edge cases – agile is about focusing on the main body of the work and dealing with exceptions as exceptions rather than core functionality. Its interesting to reflect on exactly how that feels culturally in the public sector.
• Understand the minimal viable product – This is not a limit on ambition but instead a clear description of what actual achievement that you can build on looks like
• Don’t run away from it because it’s difficult – run towards it – problems are not reduced by hiding from them
• Create a lean start up mentality – don’t try and plan for every eventuality instead get the basics in place and build as you need to.

**Creating the team**
Teams are created – they don’t just happen. I think too many project managers ignore this piece of the puzzle and then wonder why the developers seem to be masters of passive resistance. You need to set a context that all participants can work in.

• Find emotional connection – stop imagining that you can get programmers and non-programmers to speak the same language. Instead focus on the emotional and narrative impacts of the project which is where these different skills and knowledge bases can come together
• Bringing different cultures together – any large project is about blending internal and external cultures. Do this knowingly and create a new culture for the project.

**Project structure**
Agile relies on working forward in defined ‘sprints’ that move you closer towards your goal. We discussed the resonance that this has with action research or experiment based policy making and the fact that this would involve accepting a greater degree of uncertainty in the project process that a waterfall approach would (falsely) bring:

• Base your project plan on iterations and experimentation – create iterations that involve testing parts of your core proposition and build in a formal review cycle to capture learning and actively use this to inform the definition of the next iteration
• Focus on the impact and objective – ensure that you have a clear set of project metrics that will allow you to describe each of these iterations in terms of your overall objective
• Positive byproducts – look for and design in positive byproducts – in terms of code or learning – that can mitigate the perceived risk from the agile approach

**Communication and Reporting**
A big part of the communication process was seen as both building internal and external confidence at the same time as helping with the ‘cultural integration’ from the first section. One of the ideas that Stefan suggested was getting non-coding participants to actually sit in on a scrum meeting to see how the process works. At Public-i we have a daily scrum for the whole company that works on this principle – though I think the frequency may dilute the impact a bit its really useful. More specifically we talked about:

• Stronger informal feedback loops – if your process is iterative you want to be communicating more regularly so that the end of iteration review is not a horrible shock to people. You need to use this regular feedback to strengthen shared use of language and understanding and just embed the habit of conversation between different parts of the project team.
• Making your reporting agile – critical path and milestones are both still important but they need to reflect the project iterations and milestones, the idea of minimum viable release and also be mutable in the future – we don’t write the whole plan in detail at the start – instead we fix on the next critical decision or delivery and sketch it out beyond there. This is very disconcerting for someone used to PRINCE2 but much more honest with respect to how project actually work….
• Use new forms of feedback – we discussed how to include different feedback mechanisms – for example video or blogs – in order create a more consistent way of communicating

This is a bit barebones I’m afraid but I will follow this up as I am working with our project manager to design a project management template based on these principles which we will share when its done. In the meantime please shout if I have forgotten anything!

Thanks to all who participated.