Friday, 31 December 2010

An agile attitude

agile adj (sometimes agiler, agilest) able to move, change direction, etc quickly and easily; nimble; active. agilely adverb. agility noun.
ETYMOLOGY: 16c: from Latin agilis, from agere to do.

When you think of a public sector organisation, is the word agile up there? Responsive? Dynamic? Able to react immediately to changes in external forces/factors/politics/leadership?

Or, do you think of a cruise liner akin to the Titanic, with a Captain at the helm, reading from maps with nautical tools, who, on seeing the icebergs in the distance can do nothing but try and avert disaster, hauling frantically on the wheel, deep down knowing that the iceberg is going to hit, but desperately trying anyway?

3 months ago, I think, I saw a conversation on my stream between @rikbarker and someone else. A female programmer as it happens, now a PM, but I'll not embarrass her. She is not above the parapet and wouldn't appreciate being hauled there. Anyway, they were discussing the agile software development approach. I've no idea why it pinged, only that it did and I followed the conversation with interest. By the end of it, I tweeted something along the lines of 'I wonder if we could implement agile dev strat in local gov'. And there it ended. And idle musing commenced.

Fast forward a month and it came up in a discussion with someone else, but in my organisation. There was interest, but my thoughts on the subject were nowhere near cohesive enough to pitch it to someone who could, and I think would, run with it.

Fast forward again, to Tuesday. A social visit to a friend, @rikbarker, turned into a long conversation about agile approaches, local government, social media, doing more with less and about the most amazing business approach I've heard since seeing Futuregov in action - Technophobia. I seriously can't enthuse enough, I sat and listened to a friend tell me all the things I wanted to happen when we do web and digital were possible, could be possible, that magic could happen, that sanity could be retained, that money could be spent wisely. I'm not easily swayed. Man talked about the best kind of sense. But agile came up again. And again. Totally pure application in this case, in a developing environment, but again I thought 'why don't we do this?'

So today I asked on Twitter again, how do we do this, and the floodgates opened. People involved in the rolling discussion to this point: many - people utterly confused about where I am coming from and what relevance a programming approach has to public sector: many. Except one person, @pubstrat, who I think is in exactly the same place I am at the moment, but it is nice to know I am not chasing rainbows, nevertheless.

You see, it's nothing to do with IT. Nothing. At all. Wipe those two letters entirely from your mind. Instead, think of agility and what it means. As public sector employees, we are told we should be pro-active because that is where best value lies. I want to argue with that, if only because I don't believe you can be pro-active in an environment where your stakeholders are entirely out of your control. And lets be brutally honest about this, in the public sector, they are. Leaders are politicians, Councillors are politically aligned, our citizens too, the ones who care and actually show up to meetings. Central government control our spends and those are being cut but those cuts could also be reversed in a moment, should something unlikely but possible happen. So we are beholden to central party politics, local party politics, and local mood. These things can spin on a penny, elections being the most obvious flare point.

These are not in our control. So instead of planning around the way things are expected to be, how about we acknowlege a lack of control and plan for it? Yes, plan projects. Create project queues. Have processes for incoming job requests. But set a priority and revisit it. Frequently. In the process of gathering requirements, an often long and arduous task, review every few weeks with a quick phone call to the source of the requirements and check that things are still the same. If they are, all well and good, 3 minutes on the phone. If they're not, react and reassign, and then realign the project. If you don't check, what then? It might mean you procure an item based on a false set of requirements which are no longer valid.

This is agility. Quick moving responses to every changing influences. It's not a strategy. It's not a tick list. It's a culture and an ethos. Accept that technology is moving faster than we can keep up with and check in with people that what they wanted a month ago is still what they want. It doesn't have to involve scrum meetings or frequent breakouts. It does if you're in IT but that's not an issue I am addressing here, it's been addressed far better than I ever could over there. Instead, I'm simply musing on a concept which says:

  • discuss requirements
  • agree objectives
  • prioritise objectives
  • agree first challenge
  • agree first review point
  • implement first challenge
  • review appropriateness/effectiveness of solution to first challenge
  • adjust everything else around whether first solution met initial requirements
  • discuss if initial requirements have changed
  • if changed, respond appropriately, acknowledging you've only wasted 2 days, 2 weeks, 2 months and not 2 years
  • agree next challenge
  • implement next challenge
  • rinse and repeat
Review, review, review. Check. Talk, collaborate, ask questions, build lightly, implement lightly, don't spend weeks and months writing strategies and policies which are irrelevant by the time they're published. Be dynamic. Switch directions in an instant.

As an addendum to this, our whiteboard has our work queues on it in our team. My bit is tagged with progress post it notes. I didn't think about what I was doing when I did it, only that I did it. And I did it because I wanted to change states in an instant, if I needed to. I did it because they're progress bars. And I did it because priorities, for me, in a job description which spans insane amounts of information and stakeholders, be able to respond in an instant. Small beginnings. I don't know if they can replicated upwards, but I do know this blog is for dreaming in and this is my dream.

11 comments:

  1. I have to admit that I am conditioned by experience and find it hard to believe that someone like you exists in the NHS back office.

    My "agile" daughter works as a radiographer at Royal Preston so it's reassuring to know that there's hope yet for the public sector with ladies like you around. @communisage

    BR.

    Mike Cowburn

    ReplyDelete
  2. I like your approach, but your piece seems to this unIT interested party to be full of many of the words that are so offputting to joe public about the public sector - challenge, review, project queues etc.

    Any chance of a dumbed down version for those less IT-able than yourself?

    Would it be:

    Try something
    Does it work?
    Retry if necessary

    ReplyDelete
  3. Hi Mike,
    I work where I work because...we can change. I believe that we can change and we can deliver service better if we can change and ensure that in doing so we always check ourselves to ensure our motives and outcomes are right. Frontline staff in the NHS are balancing things on a knife edge which do mean life and death. I think the job of the 'back office' is to make that work as easy as possible, by delivering the right tools, systems and processes for them to do amazing things across.

    Anon> Agreed but the point of agility is the fundamental missing item, thus;
    Ask questions
    Try something
    Check it worked
    Retry if necessary.

    Consultation, communication, collaboration.

    ReplyDelete
  4. Anon>

    For me Agile comes down to the age old question of how to eat an elephant .... one bite at a time !

    Whether public sector or not, IT or not, we end up with some big projects floating around. They end up taking so long (relatively) that the needs etc have moved on the meantime. But if I turn that big project into a series of little projects, all sorts of things become possible.

    But it feels like a massive culture change from where we are at present.

    ReplyDelete
  5. Hmmm, the question is fast becoming, how do you shift a culture the size of each pub sec orgs. One brick at a time, or everyone stands at the starting line and someone shouts go!?

    ReplyDelete
  6. Funnily enough, this is quite similar to the way I used to work in public sector. But I was part of a specialised, limited-time regen team in a small area (about 4 wards). We knew we had a set budget over a set timeframe, but we also knew that we were subject to the whims of central and local politics and more importantly, the needs of the area. It's an exciting, exhausting, brilliant way to work, and our biggest barrier was always the long-term funding of our partners. We knew we had to turn talking into results in very short timescales - but working with, for example, the NHS, was very very hard as their funding was allocated over timescales of 20 years or more, particularly on capital projects. We did make it work - eg witness the new health centres as just one legacy - but it could get intensely frustrating for all concerned. I can't see a fix for that aspect, but I'm not exactly at the sharp end these days.

    ReplyDelete
  7. If your organisation is used to using Prince2, or indeed, needs to use it for various reasons, you can still embed Agile project management within an over-arching documented project structure. A key element of any good project management which often (nearly always?) gets over looked is that you don't carry on if there is no longer a business case. The Agile 'one bit at a time' helps retain a focus on that, as well as allowing prioritisation of the forthcoming workload to make sure the highest impact changes are enacted first.

    ReplyDelete
  8. One (of many) difficulties with adopting "Agile" in the public sector is that it works very well in a product development lifecycle where changes have immediate effects and the pos/neg feedback comes quickly.

    In a public sector environment, how do you achieve that kind of rapid feedback?

    ReplyDelete
  9. I've been following this conv. on Twitter as an interested bystander (who didn't know what Agile was). I certainly agree with you as it reflects how (good) design process works - constant iteration. I'm especially interested in how this could apply to service design if you're suggesting that iteration is not just during 'project development' but continues beyond 'project completion' - i.e. that the project is never complete, but in a state of constant redesign and development. To me that sounds exciting.

    As a resident I like this approach as it removes the 'public consultation window', something that annoys me incessantly, especially if I only discover something the week after the window's shut and am expected to sit on my hands for 5 years until that project/strategy/approach is next reviewed. Though I see Anonymous 2's point - this assumes people *do* give feedback.

    ReplyDelete
  10. Caroline> That's incredibly helpful, because apart from the blog cited which explains agile implementation in IT in local gov, specific examples seem to be hard to come by. I do think a teams attitude would be key to this but also stakeholders who understand what's happening and understand the importance of immediate decision response. No committees.

    Anon> No committees? I am of course being flippant but if Pickles is serious about devolving power, then I think it might be possible for us to change our cultures from within. If we response relentlessly in immediate terms for requests for decisions, for example, does that mean that outwards requests for response can be expected then to reflect a similar rate of response?

    P@> I think we are, I shall investigate with my friendly neighbourhood Business Analyst.

    gail> Hmmmm that's really interesting. Agile consultations and reviews. A constant conversation and adjustment, essentially. Hmmm.

    ReplyDelete
  11. Anyone who feels inspired by this - or skeptical about it - I recommend you read Steve Denning's article about 'Agile' working methods in Forbes magazine.
    http://blogs.forbes.com/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/

    Nothing to do with technology. Everything to do with building a team that can get something done, then getting out of their way. Like the lady said, #JFDI.

    ReplyDelete