Starting with Scrum
Starting with Scrum can be a daunting experience. You find yourself reading through the Scrum Guide or going through Scrum books and suddenly you think you’re in over your head. Adopting a new process can be a challenge – change is hard. But worry not! Here are a few pointers to get you started down the path.
First Rule
If you’re looking to change from Waterfall or any kind of process (including no process), you’re on the right path. I’ve been in software development for more than 30 years and doing agile processes in one form or another for over 15. Trust me – agile is the way to go! So, now that you’re committed (even if you think you may need to be committed), where do you start?
The first rule is – make a change. Start with something and make a change. If you’re looking at adopting Scrum, it’s likely you’re not happy with how your team is performing right now. Making a change – any change – can begin to improve the team’s performance and morale. While it’s best to adopt the Scrum process as it’s been formalized, making even smaller incremental changes can still realize great benefits.
Setting a Goal
The first thing you should do is set up a goal for your transformation. What do you want to accomplish? What does success look like? Then establish some time frames. What do you want your team doing in 3 months? 6 months? A year? Be as specific as you can be at this point. Try to put some SMART1 constraints around it. With a goal in mind, communicate it with your team so everyone can get on board. Get their feedback and modify it if you need to, but once the team agrees, put it up somewhere visible – a whiteboard or a wall in the team area. Constant visual reminders can do wonders for focusing effort.
Next Steps
Your next step can be one of several. The big thing here is to find a change that you and your team are comfortable making and then committing to it.
Inspect and Adapt
The core of Agile (and therefore Scrum) is the inspect/adapt cycle. To really get your transformation going, you need to review your team’s past work. I recommend scheduling a retrospective every two weeks or so – the same length as a “standard” sprint. Retrospectives are typically less than an hour. The basic version of a retrospective is:
- What went well?
- What didn’t go well?
- What actions will we take? (This is your action plan)
You’ll find that teams are very good at finding the things that went badly, but they may need to be encouraged to explore things that went well. Offer up some things you noticed that went well. By identifying those things that went well you have the opportunity to celebrate your successes.
For your action plan, focus on no more than three things to change. And make sure you timebox those activities – usually until the next retrospective. This allows you to make some changes and see whether they’re working or not. It also ensures that you’re not biting off very large chunks that aren’t possible to complete.
I put this one first in the list because I think it’s the key to making good, continuing progress on your transformational journey. Without inspecting and adapting, you’re just going to be repeating the same habits that resulted in you exploring adopting Scrum in the first place. Check your progress and make changes where needed so you can move forward.
Instituting Stand-ups
One of the most common things for teams to implement early is the stand-up – a fifteen minute (maximum) meeting of the entire team. At the stand-up, you typically answer 3 questions:
- What did you do yesterday?
- What are doing today?
- What’s in your way? (Blockers)
That’s it. Keep it short, make sure everyone stands up (hence the name), and make sure everyone answers the three questions. A couple of other rules – only the team talks and no one solves problems at the stand-up. Postpone any in-depth discussions until after stand-up.
One of the challenges is that if the team is just standing up and giving a status report (I’ve seen this MANY times), you’re not really doing stand-up as intended. It needs to be a commitment to the work to be done today. And the team needs to be talking to the other members of the team, not to managers or stakeholders. It’s important that the team be focused on the work they’re doing and that any managers or stakeholders there are to observe only, not to receive updates or to direct work.
One mistake I see around stand ups is the perception that now that you’ve got your stand-up established, you’re agile, right? Nope! You’re on the path. It’s the thousand mile journey that starts with a single step. You’ve taken that step, but there’s still a looooong way to go. Just please don’t go around telling everyone “you’re agile”.
Break Up the Work
I believe another big bang for your buck is creating timeboxes for your work. Humans, by our nature, are pretty bad at estimating things. We’re pretty good at estimating relative to other things we know (like this peach is heavier than this pear), but when it comes to just estimating something – how much that peach weighs – we’re pretty bad at it. When it comes to time, we’re worse. Remember this the next time someone asks you for the GANTT chart for your year-long project. About that…
How do we overcome our failures in estimating? By chopping up work into small chunks and focusing on doing a little at a time. Studies show that developers can estimate work of up to 1 day pretty well. Beyond that our accuracy drops precipitously. You’re going to need to identify the work that needs to be done next – have someone knowledgable prioritize it – and then start breaking the top priority items into tasks (of no longer than 1 day). When the amount of time you estimate hits that two-week limit, you’re done. Start working on it.
By breaking up the work into things that can be completed in a two-week period (the “standard” sprint length) and then working with developers to divide the work into tasks of no longer than a day, we are far more likely to get accurate estimates and are far more likely to be successful in completing that work. Correct and precise? Perhaps not, but more accurate certainly. A note of caution: don’t allocate more than 80% of the time – make sure you leave a buffer. Just trust me on this for now.
Something you probably ended up doing during this effort and didn’t even realize was using relative estimating. “This is about half of the effort of that. That other thing is twice the effort of this.” Because we’re better at relative estimating, we are more likely to be successful about estimating the level of effort of items when we compare work items. Estimates are one of those key skills your team will need to develop to excel later on. The good thing is that humans are good at relative estimating. Yay us!
Focus on What’s Needed NOW
You should have someone who is driving the product – a product manager or salesperson or similar. That person should have a good idea of what needs to built and should be able to tell you what’s more important than other things. For this step, get this person to prioritize the features and functionality that you need to work on in an ordered list. Have them create what’s called a Product Backlog – a prioritized list of work. Once you have a Backlog, you can begin working with the team to estimate the work. This will give your product’s owner the information they need to communicate to customers and stakeholders. Just remember that your team is pulling in work from the top of that Backlog – those are the most important items.
Avoiding Command and Control
One major failing many teams experience while adopting Scrum for the first time is that when things go wrong – and they do, for whatever reason – there’s a compelling desire for some to step in and start dictating what work should be done and who should do it. One thing I love to say about Agile is that we have the precept that “we treat everyone like adults”. Do you think your team wants to fail? Or do you think they want to succeed? Obviously, it’s the latter. Which means – let them do it their way and sink or swim on their own. Command and control is a hard instinct to overcome. Resist it! By empowering your team, you allow them to set the parameters for their success – or their failure. But they own it. And you know they’ll want to improve their results next time. Give the process a chance to succeed and for the team to learn. Again, change is hard. Be patient.
Identifying Bad Choices
Sometimes you decide to try something and that something doesn’t work. Maybe it’s pair programming. Maybe it’s the Product Owner you’ve selected for your project. When do you know it’s a bad choice? This is a tough one and I recommend getting some guidance from someone you trust, someone who’s been down the road before and knows the pitfalls. It’s possible that a bad implementation of Scrum can damage a team and sour them to the entire concept. I’ve seen it before, but with good coaching and good direction, you should be able to salvage most bad situations.
When you find yourself on the cusp of dropping a change you’ve made, look less at reverting back to what you did before and more toward what alternatives exist. Maybe you’ve been doing retrospectives a certain way and they seem to be getting stale. Remember – the heart of Agile is “inspect and adapt”. Why is it happening? Then decide – do I want to persevere or pivot to something else? You should be considering that at every step of the way – persevere or pivot? You’ll notice that it’s not persevere or retreat. Pivot to something new. Continue the forward momentum. Don’t abandon a practice just because there’s some resistance. It is a little bit of a balancing act, but the longer you do this, the better you get at it.
Scrum is Easy to Learn, Difficult to Master
You will likely hear, read, and think this many times over your transformation. And it’s true. Scrum, like all Agile methodologies, is pretty straight-foward. It’s also something that teams, ScrumMasters, Product Owners, and coaches continually work to improve. Teams that aren’t learning aren’t growing and improving. The same goes for ScrumMasters, Product Owners, and coaches. You need to be continually working to improve your team and yourself.
I love the analogy of the martial arts. The beginning student receives a white belt, signifying the start of their journey. The student progresses, earning other colored belts, until they achieve a black belt. The black belt master, having learned everything about his or her craft, continues to hone their skills, every day wearing their black belt. Eventually, though, that black belt fades to white, showing that the master is really still a student. The same is true of Scrum.
Closing Thoughts
Yes, adopting Scrum can be a challenge. It’s most definitely manageable and while it may feel like it, it’s not insurmountable. With some perseverance and an iterative, incremental approach, your team will start making improvements. Make sure you track their progress. It can help you look back at the path you’ve traversed and the challenges you’ve overcome. If you run into problems, reach out to people who can help coach you and guide your transformation. In short order, you’ll get your team making those steps down the path to starting with Scrum.
Notes
1. SMART is a mnemonic for making something Specific, Measurable, Achievable, Relevant, and Timely. The ART part is different for different practitioners, but the intent is to make them something specific that you can measure progress toward completing within a short period of time.