Agile-lite: A slightly more pragmatic approach to going Agile
Let’s start with a disclaimer: In this post, I talk about work, however those are my own personal views and they do not represent the views of my employer.
You might not agree with me, but I feel that full-fat Agile (just like any other project management framework) can be quite cumbersome, unless you have a Traffic Manager or Scrum Master working with you 24/7 to take care of the admin overhead. So when I moved into my current role around a year ago (wow, time flies!), I decided that although I wanted to bring Agile in with me because it had proven extremely valuable in the past, I thought it might be best to go for a more manageable [tailored] version of the methodology; one that worked for the team. Agile-lite if you will.
My team at that point in time had a great deal of expertise in delivering via waterfall methodology, which is absolutely fine. I think PRINCE2 et al. are awesome for some projects, especially when you have strictly defined parameters, fixed deliverables and a fixed deadline, but there was something of an emerging need for incremental/iterative development for certain projects, for example, when dealing with a project with a moving goal-post.
I started out my journey by making a list of what I found most valuable about Agile and I worked my way backwards from there:
What I love about Agile is…
1. It’s realistic — I can make it clear to the customer that I can deliver a certain set of stuff, and we agree that I’ll work towards the desirable objectives as and when resource allows (MoSCoW).
2. It’s focused on exposure — Everyone in the team should have some idea about the bigger picture. Although everyone has a speciality or focus, we are all cogs turning in the same machine and we work together to achieve the same overarching goals.
3. It creates cohesion — People in teams gain a better understanding of each other’s roles.
4. It creates focus — Open discussion gives the team members focus and accountability, so that tasks are completed. Blockers are picked up, discussed and resolved as a team sport.
Next up, I set out how I’m going to achieve each of those benefits on a practical level:
I will enable my team to be Agile by…
1. Exchanging ideas about how we can set expectations: When commencing a project, agree with the customer what are the ‘Must haves’, and be clear about what might not be achievable.
2. Creating a visible Kanban board, so that:
A. All team members can see all the projects in the pipeline.
B. All team members can see what each person is focusing on.
C. The team can break down large tasks into bitesize chunks of work.
3. Asking everyone in the team to invest the time to talk to others about what each person does, how, and why. We will soak up each others’ expertise so that we can share burdens and triumphs.
4. The team will have regular group catch ups and we will think out loud, so that we know what each of us is doing today, and so we can help each other overcome issues as and when they arise.
I then took those principles and I tried to embed them into the process of pushing products/features. I ended up with this [rough] process:
Stating the obvious: If you work with Agile, you’ll know that what the diagram above describes is not true Agile… What it describes instead is a flavour of Agile that works for me. Agile is often sold as one-size fits all. In my personal/humble experience, this is horseshit.
Let’s talk about Kanban
The idea is that if you display the work items that make up your programme of work, productivity goes up. People become aware of the ‘bigger picture’ and in turn naturally adapt and respond to the task(s) at hand.
For a Kanban board, I decided to use Trello.
If we have met, you’ll know that I’m a big advocate for Trello and that I basically don’t shut up about it. If you haven’t tried Trello already, I’d definitely consider giving it a go.
Why I decided against having a physical board
My team and I work flexibly, and that sometimes means that people are not always working in the same room or even on-site.
It’s totally fine if you prefer to have a physical board if everyone’s always working in the office… Just take care not to exclude folks who work off-site. Give them visibility and control over the content of the board.
If you spend some time Googling Kanban, you’ll find tonnes of different layouts used in projecting Kanban boards in a digital context, so this is once again something that I’ve opted customised to fit my team’s needs and I would encourage you to do the same…
I started simple:
This was fine. Until a colleague of mine asked me “Where can I list out things that I think we might want to do?”, so I created the “Ideas pot”:
The ideas pot is exactly what it sounds like; it’s a place where any member of the team can put down suggestions. I personally think this is a good way of enabling the team to think proactively about product management.
Lastly, nowadays I’m using this:
All I’ve done here is that I’ve added the “On hold” queue to deal with the harsh reality that sometimes things get held up and I wanted a place to store them instead of clogging up the ‘Doing’ queue.
What goes on Trello?
Because the team is a mixture of SysAdmins and Developers, we do a significant amount of work which is sort of in a grey area of ‘not-quite-development-but-also-not-quite-support’, so I some times get asked where do I draw the line in terms of what goes on the Trello/Kanban board and what doesn’t. The general rule of thumb which I encourage my team to follow is: If you’ve started working on something which is going to take more than a day to complete, you should put it on Trello.
I know this sounds control-freak-ish, but if I can see that someone is really busy working on X, I will not expect to be able to pull them off to work on Y, which enables me to plan resources accordingly.
The bits of Agile that I’ve left out
Agile is great, bla bla bla. But we should be aware of the bits that suck. Here are the few things that I decided to leave out of my process…
1. I don’t do sprints: I found that the overhead for organising sprints and agreeing terms of reference was a bit strenuous, so this isn’t something I currently do with my team. However we do break down tasks into unstructured timeboxes in a vague sense, so we’re not miles off.
2. Burndown charts don’t work for me: Call me old fashioned but I prefer a good-old checklist.
3. Daily standups are a bit too much: I realise that daily standups are essential in an Agile environment, but it demands a certain level of cultural change which takes a while to achieve.
In the meantime… I trust my team to deliver results. I trust my team to work hard. I trust [and encourage] my team to speak up if they’re not sure about something. For those reasons, I have depriotised daily standups. What I like to do instead is to talk to my team and to encourage them to do the same among themselves if I’m not around— just have a good old natter about what you’re up to that day and ask others what they’re doing. Ask if there’s anything you can do to help. Encourage other team members that are within an earshot to engage in the conversation by asking questions.
I believe this generates a far more organic version of the daily standup.
That said, I keep going back and forth on the idea of having daily standups as I recognise the potential, and there may be a day in the future when I change my mind and decide to give them another go (assuming the team are on-board…).
Just before you go: A note on Agile…
I think it’s good practice remain cautiously optimistic about emerging methodologies. Agile is no exception. While I have found that Agile is a great toolkit for managing decent digital/IT projects, it definitely has its flaws. If you’re in the process of implementing Agile, do have a think about some of the ways you might modify/change the aspects of Agile which may not fit your needs.
Reading this now, (A few weeks after publishing) I realise that all I’ve done here is created a task board… That’s just not Agile. I get that. But I still consider this a stepping stone towards proper Agile.