Get my team Agile

Introducing my team to Agile

If your team has never worked with Agile then be patient with them. Don't get too hung up on doing the process 'right', instead focus on building the right behaviours and mindset. The beauty of agile is that continuous learning and improving is built in from the start. By the third time you've done something it becomes second nature. So three days for standups to get better, 3 sprints for your retrospective and planning events to improve, and three lots of Programme Increment planning to get this working. So all in all, give yourselves a year to go from no agile to nailing it and teaching others.

Step 1: Get the basics right

This is all about getting into a routine of daily standups. If you don't do it daily it DOES NOT WORK. And then include weekly or fortnightly retrospectives. You will rapidly bond as a team and learn and get better

Step 2: Get epic

Your strategic thinkers in the team will be worried that you maybe good at getting stuff done - but is it the right stuff? This is all about looking at enough of the big picture to set a direction and prioritise where to focus

Step 3: Stich it together

You are good at getting stuff done, you have a strategic focus. Now you need to hold a 'Programme Increment' (PI) planning session to link your daily activities to your strategic direction. Don't underestimate the difficulty of getting the right people together at the right time for this

My adventure introducing my team to agile

Step 1: Get the basics right (6 weeks to become effective)

Having the luxury of my small team being physically located together, the first thing I tried was a daily stand-up - but doing this once a week, with a computerised task list. This failed: Once a week meant we spent most of the time reminding ourselves what the task list was, and being computerised, no-one understood the software yet. No-one felt ownership of tasks and nothing progressed. It's worth noting that neither my team nor I had any experience delivering an agile project at this stage.

It was only when we printed out the tasks on paper, cut them up and stuck them up on the wall that we realised how much work we had promised to do. We did three things. Firstly we hid everything in the backlog so we weren't overwhelmed by what else we had to do. Secondly we started daily stand-ups by the Kanban board on the wall, moving the cards between TO DO, IN PROGRESS and DONE. Thirdly, we bought an old fashioned bicycle hooter which we hung up by the Kanban and every time someone moved a card into DONE they honked the hooter. Childish but effective!

After a couple of weeks of daily stand-ups we started holding fortnightly retrospectives. An hour where we would ask ourselves what went well, what didn't and what we should try differently. I also presented the next lot of tasks for the next 2 week sprint.

The regular and frequent retrospectives create a fast learning cycle. We rapidly adjusted the time and format of our daily stand-ups, moved our sprints to run Wednesday to Wednesday (rather than Monday to Monday) so those working part time could more easily engage.

And one of my team asked how I was making the choices for what tasks to do next. I replied that I was making it up as I went - not the answer they were hoping for! Which pushed us to look more strategically.

Epic

Big chunks

Review every 3 months

Medium chunks

Review every 2 weeks

Feature

Small chunks

Review every day

Stories or tasks

Step 2: Get epic (3 months to become effective)

We already had a fairly clear view of the future we were aiming for. Previous workshops had drafted a vision (short and punchy) and a description of what a good future feels like (12 pages). We refreshed our understanding of this and broke the work into a number of high level chunks (epics). We chose the 3 epics that by fortunate accident reflected the majority of the tasks on our sprint board and drafted out an epic business case for each one. We started with a 'Lean business case' template off the internet and rapidly realised the important bits were the WHY are we doing the epic and the prioritised list of features the epic needed delivered to be considered complete. We also stuck an epic Kanban on the wall. At which point my boss asked if we were sure we were focusing on the most important area of work. And I said probably not, but at least we can see the enormity of our task, and we can see we are making progress against a subset of the epics - even if not the most important one. Our delivery machine is working, and it's roughly going in the right direction.

Step 3: Stitch it together (9 months to become effective)

This was the hardest step because it involves STAKEHOLDERS and LEADERSHIP. And it all evolves round a planning event called "Programme Increment" (or PI) planning. Learning from everything else we had achieved, we set our expectations low for the first PI event (like all agile things, the learning cycle meant by the 3rd one we were getting pretty effective). Our agenda followed roughly: an ice breaker to get people switched off from their in-box, a retrospective of the last PI, a discussion on a hot topic and then go through each of the epics, reviewing the epic business cases and agreeing the priority of the features. Then finally agreeing the priority order of the epics (no tied places allowed).

After a few of these sessions we learned: with 20-25 people in a room for 1/2 day the maximum number of epics to usefully discuss is 6-8. The chair really needs to keep focus - no more than 10-15 minutes discussion per epic, including 3 minutes to read each business case as no-one ever pre-reads. It is a good session if you get the epics listed in priority order. It is an excellent session if you also get the features prioritised. And the underlying important part is that ALL the stakeholders agree and own the priorities. To write up, all we do is summarise the retrospective and draw up a grid of epics and features in priority order (top left is highest priority feature of highest priority epic, bottom right is lowest priority feature of lowest priority epic). This grid is all the guidance we need for the next 3 months to feel empowered to make day to day and week to week decisions.

The hard work is in the preparation: One to one chats with anyone who has not been to a PI before to explain how it works, reading time for the epic business cases (not that anyone reads them in advance), and asking my SRO the epic priority order they think we should be agreeing (it's always useful to have a fallback / starting position). A 1 page progress dashboard helps to remind everyone what we are doing and why and where we have got to.

And the 3 month PIs come round far faster than we think - so we try and book calendars and meeting rooms at least one PI in advance.

Final thoughts

Building the machine top down appeals to my inner system engineer - but is unrealistic if your organisation is not well practised in agile delivery. Building bottom up runs the risk of doing work that may not be top priority, but it does give a really easy, step by step and iterative opportunity to learn the agile basics by practising. Don't get hung up on terminology or 'doing it right' - get the basic concept of daily stand-ups working and the rest will sort of fall in place. Training courses help but doing it helps much more. And find someone who's done this before and learn from them.