How to become an Agile team
Part 2 — The Setup
Hopefully, you’ve read Part 1 of this series which covers the benefits we realised when transforming our team to Agile. Part 2 now deals with how you can get yourself and your team in the right place to kick off your Agile adventure. These are the first 4 steps from below:
Step 1 — Limber up before you Sprint
Sprints, MVPs, Backlogs & Standups and much more…
Make time to get down with the Lingo — If you’re looking to implement this for your team, you’ve got to get yourself — and them — across the basics first. There are some fundamental changes and challenges your team is going to have to get their head around. It’s going to feel pretty alien at first, so you need to make sure you’ve done your homework and that you’re reasonably confident about handling the what’s and the why’s (there will be a lot!). If you’re lucky enough to know any other teams already Sprinting, head along to their ‘Planning’ sessions and ‘Standups’ (they call them their ceremonies). ‘Scrum Masters’ (think Agile team facilitator / operational delivery manager…. see step 2) are always pretty keen to spread the word on Agile!
Getting your team across the line — start planting the seed a good month or so before you want to kick off. Agile isn’t something you can just ‘switch on’. It isn’t something you can surprise a team with. It is such a fundamental change to the way you work, they need to be on board (or at least willing to play). Share some useful articles and videos and prep them for your kick off. During the kick off, the key goal is to get everyone to agree to give this Agile thing a go! If you’ve got some people not simply willing to play, then you’re going to have your work cut out.
Some of the questions we had were:
What’s wrong with the way we’re doing things? But where’s the project plan? What about my BAU that’s not part of the Sprint? So who tells who to do what? What about people picking ‘my’ stuff ! I don’t want to be involved in ‘their’ stuff! Doesn’t ‘Minimum Viable Product’ just mean unfinished or basic? (See the article ‘7 IAQs when implementing Agile’ for our answers to these!)
A few sites and resources we referenced for setting the scene were:
· Scrum: The Art of Doing Twice the Work in Half the Time
· When to use Scrum? Waterfall vs. Scrum vs. Kanban vs. Scrumban
· Understanding Scrum in under 10 mins
Step 2 — Understand the rules of the roles
Team. Product Owner. Scrum Master… Really, there’s only 3 roles — Getting your head around that is a big shift.
Team — All team members are equal. That doesn’t mean the same. We’ve found that it works best when you’ve got all the skill-set required in the team to cover the problem at hand. We started out with a Sprint team based on subject matter expertise and specialist skills. This was a mistake for us. It meant that in certain Sprints people weren’t being fully utilised throughout, and there were bottlenecks and people waiting for the “expert” to finish their piece and send it down the production line. We then changed tack and pulled the team together based on the Sprint goal. This is the focus of the whole Sprint (more on this in Step 5) rather than its component parts.
To create the most effective and efficient team, we had to ignore reporting lines. We were then able to ensure the right balance of skills and asked people to get involved in unfamiliar work which was still well within their general capability. This immediately resulted in people being engaged and productive throughout. Not rocket science, but a change to working practices that cut across our team structure. It required some planning and a few Sprints running at the same time, but meant that we were fully utilising everyone’s skill-set to the max. We’ve found that Sprint teams of 4 to 6 people work really well. Small enough to avoid a committee, but large enough to deal with big problems in the timeframe.
Product Owner (PO) — They can be anyone. They’re the person that is fighting the cause to have this piece of work go live. They own the problem that your team can help solve. They can be stakeholders, or they could be part of your team. They’re basically the person that knows if your solution (or product) is effectively going to solve the (business) problem. Getting the right ‘engaged’ PO is key, and tricky! Agree up front their role and contract this with them. This means they need to be available throughout the Sprint to answer queries and ensure the solution is true to the (business) requirements. That doesn’t mean cancel everything and sit there patiently waiting for the team to call. But they need to answer messages, review designs and provide feedback pretty sharpish. Without them you’ll likely end up with something that’s not quite what they’re after, which in turn will need to be unravelled in the next Sprint. The ‘good’ news is it’s only a week or two you’ve lost if it all goes a bit wrong. But it’s still pretty annoying if this happens. (We’ve got some newer thinking on the PO, check out our Iterative Insights update)
Scrum Master — More of a coach or facilitator than a Master! Their role is to help the team stay focused and on the sprint board (see ‘Trello’ in step 4). Having someone with a foot grounded in reality is pretty useful, especially when the team are so focused on the Sprint. A good Scrum Master is someone who can give the team the support and space required to self organise. They are not a ‘Project Manager’. However, they can help remove any blockers or issues that the team can’t shift on their own, especially when copious BAU activities or other distractions start creeping in. The Scrum Master isn’t there to tell the team what to do, or how to do it, which is pretty difficult at first. Nobody likes to see colleagues struggling or go in the wrong direction! However, asking timely questions usually prompts a good decision or action.
We’ve found that once you get into it, a Scrum Master can manage a couple of Sprints concurrently for the type of work that we’re doing. It doesn’t work when you’re trying to be both a team member and a Scrum Master on the same Sprint. Diluting the roles just confuses everyone and dilutes the result. It also doesn’t work when the Scrum Master is too busy to attend the planning sessions or Standups… This happened in our team, other meetings got in the way, and the team was left to sort itself out, which unfortunately meant things started unravelling and going off course. So ‘Being present for all meals’ was one of our key Retrospective actions (a Retro is a Sprint debrief — see step 9). However, our Agile guru’s have said that the team can handle the Standups on their own once they’re really cooking with gas!
Step 3 — Get back up on your Backlog
A Backlog full of features, prioritised and ready to rock is a joy. Having an empty Backlog is not.
One of the key benefits of Agile is the transparency of work. A visible Backlog (this is the future work to get done) can help remove apprehension or ambiguity about the ‘what’s happening next’ syndrome. Effectively, you can now see around corners.
To make it on to the Backlog it’s got to be agreed work the team will do at some point. Remember back to Step 2 about the engaged Product Owner? You ideally want the backlog to be generated by them. And there might be several of them! But without an owner, work is unlikely to get done or get done effectively. To hit the top of the Backlog it’s got to be pretty urgent or critical. That’s not to say the Backlog will look the same every day, as it’s a fluid beast, subject to change and based on competing priorities (and Product Owners negotiating for team time!). But it’s all there and all visible. We use Trello to house and keep track of our Backlog. Trello is an online project collaboration tool (more on that in Step 4).
The next Sprints are then planned around what’s at the top of the Backlog. There’s nothing better than working on a project that’s really valued. And nothing like knowing there’s plenty more where that came from.
Step 4 — Setup your Agile ecosystem
Slack for non-slackers. Hello Trello. Hats on in Hangouts. The cool tools that work for our team.
When you start working in an Agile way, you need the tools in place that are going to help you work effectively. This is especially important if you have a remote team given that Agile is all about efficient team working. Software Development teams sometimes go for more complex and expensive options (like Jira), but we opted for 3 simple, consumer-grade, and free solutions. Given potential IT security issues, we wouldn’t advocate using these free versions for highly sensitive or commercial in confidence projects.
Slack — A very slick team communication tool, loved by the team. It’s got a great app and works well on Mac and PC.
We setup a new channel for every Sprint or project, and keep all comms for that Sprint within Slack. Your email traffic should drop considerably! This means everything is within one place and you can refer back if needed.
You can, and should, customise your notifications (like you can most apps) to avoid getting overwhelmed with alerts. We learnt this the hard way, too. Slack is easy to configure. We also have general channels for fun and non-Sprint messaging. Our team uses these a lot and it allows for connection and banter. It’s also got a ‘Bot’ (a smart algorithm which is responsive to comments), as well as loads of integrations and apps you can play with.
Trello — A planning tool that allows you to create boards with lists. The lists then contain cards. Again, another great mobile app is available for this.
We usually set up a new board for each Sprint and use a pretty standard set of lists: Previous Retro actions, Sprint goal, Features, Tasks, In progress, Blocked, Review, and Done.
The idea is that you move the cards that represent tasks, from left to right. The aim is to get all the tasks from ‘To do’ into ‘Done’ by the end of the Sprint. Simple. The cards can contain comments, checklists, due dates, documents, links etc. No one should assign you a task and only you can move a card you have been working on (more on this later in step 6). We keep all ‘the work’ within the Trello cards as you can add attachments. The Board plays host to the thinking and the outputs which means no more emailing, and one single source of truth!
Google Hangouts — Google’s version of a video call. The quality is excellent. You can add effects, hats, glasses and generally have a lot of fun (we always get smiles from passers by).
Hangouts have been indispensable for the daily 15 min Standups (think progress ‘check-in’. More in step 7) and general team bonding across locations. You can integrate this with your Trello board which generates a unique fun name for the call. The benefit of a video call as opposed to a standard conference call is there’s nowhere to hide. It’s easy to pick up on body language and engagement. However, remember to tidy up if you’re working from home! You can create a new account using your work email address, so don’t need to use gmail. We’ve also used Appearin as an alternative video solution, which is great quality and has some good features too. Lastly there’s always Skype, but it just feels a little flat after using these.
Now that you’re all prepped it’s time to look at the Sprint itself. That’s where Part 3 of this guide comes which covers steps 5–9:
