Scrum/Agile and Doing it Right

TL;DR:

Here are some things you can do to implement scrum more effectively around your workplace.

1. Explain it to your customers
   1a. Communication comes from your side to the customers, not the other way around
   1b: Code is still a process, and adding and removing features is not a simple task
   1c: Sprints are often enough communication
2. Sell it to your developers
   2a. Explain the good and the bad to them
   2b. Get them to like the idea before you move forward
3. Help your developers build a new workflow

Disclaimer: Let me start by saying that I am not some Scrum Trainer.  I am a developer who's been working with scrum for years.  I don't teach new teams how to do scrum, unless it happens to be my team ask for my guidance.  But I've worked at 6 different organizations who implement Scrum in one form or another, and so I have experience on my side.

Scrum is a hard transition.  It sounds easy, but I've yet to see a company get it together and follow all the (sometimes arbitrary) rules, in the last 5 years.  I see a lot of failures in scrum implementation, and since this is a software development blog (mostly) I figured I'd offer my perspective to try to help people to be more effective at using this...management style.

Please note that I am a fan of scrum.  What I am presenting here is an honest perception and some realistic ways to improve the implementation of scrum where you work.  Please don't think I'm bashing scrum when I point out its flaws.  I believe it's important to see the flaws so we know what we need to focus on improving.  For this reason, I'm not going over obvious things, like using Kanban or Burndown.  These are the strengths of scrum and most companies are already using them well.  This post is about the weaknesses and how to alleviate them.

Scrum Definition

Scrum is a term from Rugby, a sport where punching people in the face is nearly mandatory.  A "scrum" is kind of like a huddle, where a team puts their heads together and plans their next play (more like after the huddle, but the same ideas apply).  That's why Scrum is called that.  The team is all equal, with everyone contributing their ideas--sometimes loudly--until a decision is made.  But the term is usually used in combination with the term Agile.  Note that this definition emphasizes two important things about Scrum, two of my favorite features.  All team members must be equal, but all teams must also have leadership.  Just like the quarterback can end a huddle and make the final say, or call an audible in a football game, we have to keep our teams focused on a singular objective, but from the same perspective, developers are all brilliant minds, and ignoring any one of them is a bad idea.

Agile Definition

Agile means flexible.  You're considered "agile" if you have a high dexterity and can do things like gymnastics.  In a company, you're agile if you can change at the drop of a hat.  The boss comes out of his office and announces that suddenly everything changed -- and you shrug it off because it may be 4pm on Friday, but you're agile  You'll be done with the changes at 4:30 and still out the door at 5.  So when we combine the terms, some companies actually use the words "Scrum Agile" like it's some sort of holy grail.  We're talking about a team, putting their heads together to make the next strategic play.  And we're talking about doing it often, and with as large a playbook as possible.

Programmers Are Not Agile

I'm sorry if that sounds mean, but it is simply true.  Programming is about wrapping your head around complex logic.  It takes some time spent sitting there staring at the screen just to get your brain open to the idea of changing it.  In the programming world, this is called "ramp up time".  Programmers simply are not agile.  If you throw some massive project at them at 4pm on Friday, they have 2 choices: work through the weekend, or go home and worry about it Monday.  There is no agile fix they can do.  Do not assume that implementing scrum or agile will somehow make your programmer's work faster or more flexibly or some silliness like that.  It simply is not how things work.

Teams Are Agile

Fortunately, scrum's major claim to fame is that it makes programmers more agile.  Because companies put teams of programmers on projects, scrum allows companies to leverage the inherent agility of the team around the fact that they're programmers and scrum effectively gives the illusion of agility to the programmers themselves.  Basically, because not every programmer is engrossed in a task at a given time, there appears to be flexibility in assigning tasks to the programmers because among the ten programmers, one of them will finish before the others and be able to start on the randomly inserted task.  This shows the customer that they don't have to wait for the whole team to finish, and their requests get done faster, which is the agility that we really see in a scrum environment.

Scrum Is a Sales Pitch

Let's face it, scrum is just another style.  The reason people are doing it is because it sounds better than the way they're doing things now.  In my opinion, it is better, but that doesn't make it anything more than another style for doing things.  The major problem with styles, is that not everyone likes them.  In education for example, teachers are told to teach in different styles for kinetic, visual, and auditory learners.  In management, it is much the same.  Different companies require different styles of management.  The argument for scrum is that it's the best management style for "programmers"-- so it is a specific use case, but that is also dependent on whether or not the programmers (and the managers) are SOLD on the way it works.  And the problem with sales pitches is that they're brief, and often miss important aspects.

Scrum Is for Managers, Not Programmers

As we've established, scrum is a management style, and therefore, it's designed around how managers think.  It does a much better job of acknowledging how programmers think, but in the end, what it really does is rewrite a programmer's workflow.  I'm OK with a different workflow, but the truth is, most scrum trainers, and scrum devotees forget about the details, what that different workflow really means for the programmers.  They only repeat the phrases "User Story" "Task" and "Backlog" as if none of that affects how programmers work.

So That Was a Long Explanation

So all of that detail was just to get you to this point.  Here are some things you can do to improve the implementation of scrum around your workplace.

1. Explain it to your customers

Your customers (even those in your own organization) don't know what scrum is, and chances are you've said something silly like "bi-weekly releases" and they think that the programming world has magically changed.  You need to take the time to be clear with them.  Developers are still the same people they were, many anti-social, and most unable to speak non-developer business language (sorry guys & gals, it's true).  This "Agile" approach may result in more direct contact with developers, but it is not suddenly the job of the developers to take phone calls from your customers.  Trust me, you don't want them to do that when they're fixing a bug that was written by another developer whom they aren't fond of.

So that means that 1a: Communication comes from your side to the customers, not the other way around.  I know this may sound backward from scrum, but the reality is that we have seriously increased the customer's interaction by demonstrating the product to the customer in demos every sprint or two.  They are gaining from scrum by being able to communicate more often, but it has not changed the fact that communication still must be initiated from your side.

Additionally, your customers may perceive scrum to mean that each user story is completely independent.  As any developer will explain to you, code builds on itself.  You can't build the attic room to a house without at least building the frame (or the attic).  Your customers won't see it this way.  While there may be independent user stories that can be implemented without their counterparts, the customers must understand that 1b: Code is still a process, and adding and removing features is not a simple task

The sad truth of 1b is that most scrum training tries to explain this, but does so very poorly.  And finally, there's 1c: Sprints are often enough communication If you followed scrum correctly, you designed your sprints around a single unit of work for your team.  That means that, aside from requirements clarification, meeting with the customer in the middle of the sprint is only going to distract from getting the requirements complete.  Your customers need to understand that, in the old days, it would be months between communication, or worse, they couldn't change a feature except by renegotiating the contract for the software.  They don't need unfettered access to communicate with the team all day every day.  If the team chooses to be more open, so be it, but it's the team(read developer)'s choice, not the customer's.

2. Sell it to your developers

That's right.  These people may work for you, but they're bright men and women, focused on independent thinking as part of their job.  They need to be onboard with the idea, which means you need to 2a: explain the good and the bad to them and 2b: get them to like the idea before you move forward

Don't take the comment about explaining the good and bad lightly either.  There are downsides to scrum.  For one, there will be more meetings, though ideally they'll be shorter which should make up for that.  But that means they will get more interference with their 'ramp up' time--like the daily stand up for example.  It also means a more structured schedule, because of things like the daily stand-up, programmers who were used to more flexibility in the past tend to lose some of that flexibility in order to be around the team more--even if that means being around their remote machine during more traditional office hours (when I'm least productive I should note).

3. Help your developers build a new workflow

This is the piece that most companies miss.  They'll set up some agile software and say "yay, we're agile, we're scrum" and teach their Project Managers that there's a new workflow, but they never sit with their development team and take the time to develop a new workflow for them.  This goes way beyond teaching them to watch the backlog, and how to add tasks to user stories.  For one thing, scrum starts to require source control to be used differently.  Branches become a much bigger deal, as do rollbacks.  This means your team may need to convert to a different source control/build system altogether.  This is a BIG deal, and too many companies seem to ignore it completely.

Some examples of workflow ideas that I've either implemented or started researching for this very reason:

• Use branches for prod, test, and dev.
• Use separate branches for prod & test fixes, so they are separate from your general dev code & fixes from other sprints
• Consider individual branches for each user story, and consider the extra work this burdens devs with
• Emphasize clean coding practices, like DI, SOLID, and DRY making your code more "Agile"
• Consider frameworks like Docker to make CI simpler
• Implement Continuous Delivery at least to Test & Dev, Consider full Continuous Deployment
• Negotiate for easier-to-use tools for Agile
• Use whatever tools you can to make your Agile software take up as little time as possible (IDE plugins, etc)