Getting some SCRUM on Part 2

So in Part 1, I talked about the development impacts of SCRUM and agile.  In this part, I’m going to discuss what we’re seeing from a project methodology impact.

It ROCKS!

As surprised as I was about the impacts of SCRUM and agile on development, I’m even more surprised about the impact it has on project delivery.  Now, to be clear, SCRUM doesn’t cover the entire lifecycle; SCRUM is about getting quality code out the door.  Some will disagree with this, but SCRUM doesn’t cover business valuation of the project, what happens after it is released, call center impacts, etc..  There are additional agile project management approaches that do.  Read this book; I can’t cover the material as well as the authors did. 

 

Getting Rid of the Bureaucracy

The biggest problem with the waterfail methodology is it inherently adds a lot of paperwork, sign-offs, meetings and a ton of bureaucracy.  SCRUM and agile is all about doing the least amount necessary to produce a quality product.  If I never see another 3 ring binder full of what’s called requirements, I’ll be a happy, happy man.  So how does SCRUM achieve this?  Well, by applying common sense:

Co-locate people – Get all of the necessary people in a room or general area and have them work together to solve the problem.  If there’s a question, walk over to the person and ask them them the question.  How simple is that!

Empower the people – You’ve hired your employees because you think they are smart enough to get the job done.  SO, LET THEM!  This doesn’t mean they have free reign to do everything they want; there are rules and guidelines after all.

No extra meetings – Co-locating and empowering the people helps tremendously.  Eliminating 2 hours of meetings a day doesn’t sound like much until you realize that you’ve added another work day back into the week.  You’re probably getting 2 maybe 3 work days in a week; adding another is a huge productivity boost.  Don’t believe my numbers, track what you do for a few weeks and see how many hours are really productive.

2 – 4 week deliverables – results in immediate feedback, immediate reprioritization and laser focus on what’s important.  Forget the fluff; you don’t have time.

Eliminate change control – What!!!!  Are you crazy, you can’t do that.  Well, that’s exactly what you do.  Embrace change; that’s what happens in a project; don’t try to fight it.  Instead of change control, you keep a running list of work in force ranked order.  Yes, you have to force rank it; there is 1 and ONLY 1 top priority.  You have the chance every 2 – 4 weeks to change priority and the business loves, loves, loves it. 

You won’t do everything – Guess what, you’ll never get to the things at the bottom of the backlog.  Shhh, this is our little secret, don’t tell the business folks.  By the time your 6 – 8 months into a project, your list will be dramatically different than when you started.  Once you get towards the tasks at the bottom, there will be a new higher priority project and off you go.  Stuff at the bottom eventually is just thrown away or handed off to a maintenance group.  Enjoy.

Eliminate the requirements binder – Now I’ve really gone too far; haven’t I.  Once again no, no, no.  I’m not saying that you don’t write down what needs to be done, but you don’t have to write down every last little detail, such as “button 127 is 26 pixels from, blah, blah”.  Besides, no one reads and understands a 100 page requirements document.  Since you are sitting next to each other, here’s a novel idea; stand up; ask the QA, BA and business person to step over to the whiteboard and scribble out what needs to be done.  Yup, 3 weeks of meetings boiled down to an hour on a whiteboard.  Now, for compliance reasons, you’ll have to track this, so do that, but don’t track every little detail.

You Can’t Hide the Truth

In scrum, it is simple; you track what’s planned for the next release (2 – 4 weeks), what’s in progress, what’s in testing and what’s done.  For each sprint, you track the work that’s remaining (burn down chart).  Every day, you determine how much work is left on your task and the points/hours are tracked.  Within a few days, you can see if you’ve taken on too much work.  After a few sprints, what you end up with is velocity.  Once you know your velocity and you know how many points you can do in a sprint, it is easy to see how much work you can get done by when.  Dedicating people to a project lets you know exactly how much you are spending every week or month.  Tie these two facts together, add in capital spending and you can quickly calculate the cost of the project.  Simple math; not Enron math.

Brutal honestly is a key part of SCRUM.  Daily you track progress, every few weeks you show what you’ve done and weekly you track spend.  There’s no hiding where you are if you are honest.  Weaker developers are easy to spot in a scrum project.  Each developer picks the tasks and works them.  With pair programming, qa defect tracking and points completed, the weaker ones stand out.  This leaves you with two options; help the weaker developers improve their skills or replace them.  Sounds harsh, but you can’t carry dead weight if you want a quality product.  Let’s face it, we all know the developers that are assigned to waterfail projects that are hidden.  It is easy in waterfall, because they can take a week task and drag it out for months.  Those days are gone in SCRUM.  What I never understood is why these people are allowed to hang on and drag down one project after another.  Brutal honesty; they can’t hide.

Finally, at the end of each sprint (2 – 4 week release), you show off what you’ve done.  Hey, we all like to show off and it is fun to see the users reactions.  What we’ve seen happen is that once they see the screens, 5 more things come to their mind.  They take these ideas, look at the prioritized work and inject them where they need to be.  The users feel so empowered that they don’t want to miss a demo.  You can’t believe how powerful this simple practice is.  Plus, there’s no hiding what didn’t get done, what looks bad or what’s broken.

How To Get Started

This is the hard part.  If it is so great, why doesn’t every CIO, CTO and VP in the IT organization jump on the bandwagon and demand that we get scrum’n?  Well, they are usually focusing on other things, like that latest prod issue that’s costing a few hundred thousand dollars a day.  Now you’re thinking, “Cool, we’ll start a grass roots movement and they’ll be forced to do this once they see how wonderful it is and how brilliant I am.”  Nope, that’ll get you part way there, extremely frustrated and the target of senior management’s anger.  I don’t have the silver bullet, but here’s how we’ve started and been pretty darn successful:

• Top down support – If your C’s and VP’s aren’t onboard, then don’t try.  I’m serious, don’t try or you’ll end up miserable and frustrated.  Take your time, present a coherent argument in terms that they care about: costs, transparency, discipline and productivity.  If you speak about sprints, burn down charts, burn up charts and backlogs, you just as well save your breath; they don’t care about this stuff.  They want to know what’s going to reduce spend, improve quality and reduce time to market.  They will absolutely love it if they don’t hear the business folks say “That’s what I asked for, but that’s not what I wanted” ever again.
• Bottom up support – yes, you need to have support from the folks in the trenches.  You’ll find a number of engineers and lower level managers that won’t support SCRUM.  The brutal honesty and simplicity of the methodology just won’t fly in their minds.  You need to talk to your peers, let them borrow your books and evangelize.  Don’t get too crazy before you engage upper management or you’ll be in deep doo doo.
• Training – Once you’ve got management onboard, you have to get people trained.  Don’t try to figure it out on your own.  Reading books and blogs is good, but they can’t answer your questions like a trainer can.  Get the folks that will be part of the first few projects and get them trained.  Scrum Master training is an excellent start.
• Train management & the business– yes, you have to get them to training.  You need their support and they need to learn all the new lingo and what to expect.  Most of your leaders are there, because they are smart people.  Most trainers provide a 1/2 day management training and it is invaluable.  If they won’t go to training, don’t proceed.  SCRUM isn’t just an IT thing; it is a way of thinking.
• Coaching – don’t, don’t don’t try to go it alone.  Hire someone to be a coach.  I thought after training that I knew how “this scrum thing works”, but deep down, I knew that we needed more help.  I knew just enough to be dangerous and not enough to be useful.  Having a coach there to guide the business, management and the dev teams is some of the best money we spent.  Someone from outside of your organization can provide honest feedback that can’t be easily said from people inside the organization.  Get yourself a coach and GO TEAM!
• Reading – do it all the time, don’t stop and learn, learn, learn.  SCRUM is a mindset, not a set of rules.  See what’s worked for others and what hasn’t.  As soon as you think you are done, you aren’t.
• Start Small – don’t try to boil the ocean.  Pick one or two key projects, train the teams and get started.  Don’t pick a couple of loser projects; you want the high important ones that will get funding and attention.  Don’t try to move the entire org overnight to SCRUM or you’ll never succeed.  What we are seeing is that after a few months, it will be hard enough to contain scrum.  Start small and let it build over time.  Yes, there are testimonials about changing the entire organization; good for them.  I wouldn’t recommend it.

Summary

I guess the best advice I can offer is don’t wait.  Start doing some research, find one or two upper management folks that will listen and get the ball rolling. 

No, “waterfail” isn’t a typo.  If 80% of all waterfail projects fail, how can it be called anything else!  SCRUM succeeds by going back to the basics:  small teams tackling one thing; simple math to track progress and brutal honesty about all facets.

Be prepared for a lot of hard work resistance and hard lessons learned.  You aren’t going to get it right the first time.  You’ll have to be Darwinian and adapt and change based on the environmental forces around you.  We’re not rock’n and roll’n completely; we’re pretty new to this and learning.  I’m 100% convinced that I won’t be writing a blog post about how SCRUM failed.  I see a lot of success in our future.

 

References

These are people and sights that I use; these aren’t the first picks from a google or bing search:

• http://lucamackenzie.com/Home_Page.html
• http://www.scrumalliance.org/profiles/9-bob-schatz, http://www.agileinfusion.com/
• http://www.scrumalliance.org/profiles/31-jim-schiel
• http://www.scrumalliance.org/profiles/87-james-n-smith, http://www.winnowmanagement.com/

Advertisement