Adventures in Agile: Practical Scrum (Intro)
Dec 3 2008Disclaimer: I am not a certified scrummaster, nor have I taken any formal scrum classes. I have, however, worked with scrum a great deal at my job, and wanted to share my experiences.
Let’s face it: Scrum is a Utopian pipe dream. The user stories, working in sprints, task estimations, no deadlines, uncommitted backlog, visibility, transparency, business buy-in, everyone’s happy, fast development, easily responding to change, everyone gets what they want, everybody gets it and works together- it’s all a hot air and completely unrealistic.
Okay, so maybe that’s a little bit harsh. How about this argument- real Scrum- true Scrum- ideal Scrum- is a Utopian dream. It’s a never ending struggle for a more perfect union. The essential problem is we, as humans, are incapable of living up to the requirements of ideal Scrum; and business mentality will never allow Scrum to work in the practical world. It’s a round peg in a square hole. But if you believe- and try- you can get partly there, and that, my friends, will be good enough.
Utopian Scrum
Scrum is dependent on the cohesion of too many disparate factors- mostly three sets of opposing forces. First, the difference between practical feasibility and the unrealistic demands of requirements; second, the need for “When can I get it?” delivery dates from the business versus the complete impossibility of defining those dates accurately; and third, the need for a group of people to fluidly communicate and work together in a variety of situations.
Scrum works- and delivers- when these three completely impossible scenarios are met. Scrum simply sets groundrules on how these groups of people interact and manage their work. But that requires disparate groups of people working and interacting effectively. Unfortunately, most of the time, it’s doesn’t fully happen. The business will never be satisfied with vague, long term deliverable goals. The business wants concrete information so they can make decisions- they want to know when product “A” will be ready for launch so they can do x, y and z and estimate revenues. An uncommitted backlog? Story points? WTF is that? Nor will the business ever fully comprehend the cost/benefit analysis that goes into any sort of feature development. What do you mean let’s wait and see? I want to know what it’s going to be like now! It needs to do x, y and z be be super simple to use- can’t we just have it do this other thing? Why will that take so long? I want to tell you how to do it- and if you already do it, why would we change it? I know how it should work!
My personal favorite is the working together part. Do you really think it’s possible to get a group of introverts- all with their own egos and insecurities- to proactively communicate, share ideas, and work effectively as a team? Heads down, opinionated, or really quiet developers? This is the “this conversation is too simplistic for me” crowd! The “I talk in code” crowd! And everyone on the team can operate without high level direction- and figure out requirements- and bring up impediments or issues when they arise- and ask questions- crowd? Yeah, right! These are programmers!
Practical Scrum
Don’t worry- all is not lost. The principals of Scrum are pretty solid and good ideas, and even if you only get half way there, you’re better off than with anything else. Visibility and transparency are extremely important with any development group, and knowing where you stand with the big picture is solid information anyone can appreciate. Most of the time the business doesn’t really care about when things happen, they just want an accurate estimate for planning. Who wouldn’t want that? When you hit your stride with Scrum, it may not be perfect- but both you, the development team, and the business- are all better off because everyone gets enough of what they need with a manageable amount of overhead.
The main problem with Scrum is that in principal everything make sense. It’s easy to see how it works- the backlog, the sprint, the scrum, the estimations- but when you try to do it, everything false apart. In practical terms, it’s impossible to make all the chips falls as they need to- to make everyone understand what they need to do- and to get everyone in the organization on the same page. Most people either end up with a bastardization of the process, or worse give up out of frustration.
Practical Scrum is that middle ground between where you are now and Utopian Scrum. It’s the half way of making what you have work, and like Scrum, iterating to a better place one thing at a time. Practical Scum is simply understanding how to implement Scrum to make your organization work effectively. The key is not jumping into the deep end with Scrum hoping you know how to swim. Hint: You’ll drown.
I’ll delve into various aspects of Practical Scrum in future posts. For now, it’s important to remember a couple of things:
- Don’t give up. If it doesn’t work, don’t worry, it usually doesn’t.
- Scrum is easy in principal; in practicality, it’s extremely difficult.
- Like everything, you need to move in baby steps when adopting Scrum.
- Remember: If you do it, they will come. This simply means once your team is on Scrum, and you start delivering, people will recognize it works.
- The goal isn’t learning Scrum- or what Scrum is. The goal is learning how to adopt scrum. Like the principals of Scrum, go with the flow. Iterate. Make subtle improvements. Get to where you need to be at a healthy pace.
- Don’t rush it.
I’ll dig into how you get to where you need to be in Scrum in future posts. I’ve been on the brink of giving up too, but am happy I’ve stuck with it. Now we’re starting to hit our stride, and it’s great. Yes, it’s still rough around the edges, but that’s a fact of life with everything.
Getting there isn’t half the battle- it is the battle.