As someone with the word agile in their job title, you might think I would find it reassuring to hear it being commonly used in government buildings across the country. However, as I have blogged about before, there still seems to be a lot of confusion around what the word agile means. Instead of changing the way people work and possibly making them happier in the process, misunderstanding agile could be making the situation worse.

Government is in danger of adopting so called “Cargo Cult” agile, where teams follow the process religiously and completely miss the point, hence changing nothing. The word then becomes so misunderstood and diluted (which some argue is already the case), that those who do understand the meaning of the word, change it (possibly to “DevOps”). Those who have just understood the meaning of agile are once again left behind and feel as though the carpet is being pulled from under them. In an attempt to help, I thought I would write about what agile means to our team.

We understand that agile is not a thing to be done. Agile is an umbrella term, a mindset and at its core, a really simple set of statements that form a manifesto. The creators of the Agile Manifesto aimed to change the way people build and deliver software, and they are succeeding.

Our team, and any other that seeks agility, should keep the manifesto close to heart, as it’s hard to argue against any of statements within it. However, to better explain how our team implements the agile mindset, I’ve tried to think about how our team goes about making this work in reality.

 

1) A Mindset of Continuous Improvement  

The Japanese have a single word to describe a mindset of continuous improvement: Kaizen.
Screen Shot 2016-05-11 at 08.17.35

An individual (or team) with a Kaizen mindset is never satisfied with the status quo, they seek out opportunities to improve the process they are using and respond to criticism with intrigue.

 

Screen Shot 2016-05-11 at 08.21.14

  • Feedback on our work – For continuous improvement to occur you must have feedback and, as the sign on our wall suggests, we seek it out as often as we can. We constantly pair on tasks, run team critique sessions and publicly release what we’ve produced. People are great – they tell us what is wrong with, and what is great about, our prototypes. We received feedback on our GP Lookup Prototype within minutes of it going live. This feedback allowed us to quickly iterate our designs and code.
  • Weekly retrospective – Using a variety of formats we get together and examine how we’ve been working together on a regular basis. For us, this session is both group therapy and a chance for us to do something about the things that are slowing down delivery.

 

2) Coordination (without meetings)

The Ancient Egyptians used whips, the Industrial Revolution brought us the production line and multiple wars use military discipline to coordinate teams of people. We use a wall of Post-its.

IMG_3335

  • Our wall – We use a combination of Scrum and Kanban methodologies (aka Scrumban) to be able to quickly see who is doing what and what stage they are at. We use colour coding to quickly see how each task helps us to reach our goals and have deliberately made it a low effort to maintain. It is crucial in coordinating the efforts of our team.
  • Standups – We want to avoid traditional meetings, so every morning we get together for 15 minutes and “walk the wall”. This involves examining the progress of each task that is being worked on today, or has recently been completed, with those working on it giving a brief update and asking for help where needed.
  • Show and tells – We celebrate our work each fortnight and invite guests who want to know what we’re up to. Our format is simple: team members take it in turn to relay what they’ve been up to, what they have learnt and what they’re doing next. They are loud affairs, as we clap the efforts of our peers religiously.
  • Self organising and multi-disciplinary – Each member of our team chooses what they work on each day and are therefore accountable to the team for completing those tasks. The tasks must help the team achieve its goals, which we agree together during our planning sessions. If someone is away, other team members volunteer to step in to help complete the work.
  • Tools and environment – The Agile Manifesto suggests that talking to each other is more important than tools and we totally agree. However, we still need tools. Crucially, we pick our computers, we pick our software, and we use multiple tools for similar jobs, depending on what we feel is appropriate. The same goes for our environment. We remove desk dividers, create a shared table and do whatever we can to “make our house a home”.

IMG_3307

 

3) Transparency (admitting we don’t know what we don’t know…)

 

  • Trust – Teams that work in this way need to trust each other and transparency helps to build that trust. Our team trust each other because everyone in the team knows what other team members are working on. We are co-located, so you can physically see team members working together and we regularly see each others progress at Show and Tells.
  • Honesty – When we start building a new service, we don’t know the needs of our users and, therefore, we don’t know what the service will look like or how users will interact with it. There is nothing wrong with that and we are honest about this. As we talk to users and build and test prototypes, their needs emerge and so does the service. If testing shows we’re going in the right direction, we iterate and improve the product. If we’re not, then we pivot and try something new. As companies like Google X have taught us, the key is admitting what we don’t know and creating an environment where that’s okay.
  • Estimates (or the lack of them) – We don’t estimate the time our tasks will take and we don’t use story points. We aim to make each task achievable within a two week period and break them down into smaller tasks, whenever possible. Estimating is a great way to help demystify and understand a problem but I would argue that the end estimate itself does not have great value.
  • Deadlines (or the lack of them) – As we don’t do estimates, we also don’t do deadlines, as they often lead to many more negative behaviours than positive ones. We don’t want to create a situation where somebody is late in completing a task, when in reality they had no idea how long it would take in the first place.

 

Our team believe in the agile mindset and, currently, implement it as I’ve just described. It will be, and should be, different to other agile teams. Our implementation is constantly changing. If you want to come and see how we work, please get in touch and we will do our best to get you along to a Show and Tell.

 

10 comments

  1. Comment from Stacey

    Great blog post Benji! Some interesting points about estimations and in particular, in deadlines. How do you avoid working towards deadlines when faced with pressure or commitment to senior/project stakeholders and budget holders to get a thing done?

    Would be interested to talk more!

    Reply
    • Comment from Benji Portwin

      Thanks Stacey! This is probably an oversimplification, but we try to avoid committing to deadlines. Our budget is done every six months and we hope that working product will be out justification for renewal… Let me know if you want to come to a Show and Tell

      Reply
  2. Comment from Gary McAllister

    Would be great to see your backlog.

    Reply
    • Comment from Benji Portwin

      Hi Gary, our backlog for the coming weeks is on the photo posted on the blog, is that what you mean?

      Reply
  3. Great blog post – thanks for sharing how you do things in your team. I agree that it is very important to revisit the agile principles and remember why we are doing thins in certain way in Scrum rather than just mindlessly adopting the framework.

    Reply
  4. Cracking blog you lot!

    1 question: what is your definition of ‘done’? I can’t quite make it out on the picture. Oh, and I’d be interested in taking the NICE crew to a show and tell in the future. Let me know when suits.

    Reply
    • Comment from Benji Portwin

      Thanks!

      Our definition of done is : 1. Work is availble to view & 2. It has been discussed at standup and stamped as Done (We “walk the wall” at standups, but didn’t want to lose “what you did yesterday piece”.)

      You’d be more than welcome to come to a show and tell, just pop Team@digital.nhs.uk an email :)

      Reply
  5. Great blog post Benji, really enjoyed it, especially the value of Trust within a team is often underestimated.

    Is your team based in Leeds or Manchester, I would be interested in going to a Show & Tell?

    Reply
    • Comment from Benji Portwin

      Thanks Neil, much appreciated!

      We have team’s based in Leeds and London and it would be great to have to you along. Just drop team@digital.nhs.uk an email and we will help make it happen :)

      Reply

Leave a comment