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… There are 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 utilized 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. 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 utilizing 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 upfront 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 unraveled 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 organize. 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 unraveling 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, prioritized 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 on 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 for for 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 — Set up 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.
Hi and thank you for visiting my site.