Why I Would Never Go “Enterprise Scrum”

April 19, 2011 1 Comment

I’ve had some recent debates regarding whether we should start an “enterprise Scrum” initiative, i.e. WE WILL BE A SCRUM SHOP.  I would have completely supported this several years ago.  Now, I am completely against it.

In an organization of any significant size or age, there typically have been methodologies that have been introduced, pushed, then they fade away into the far recesses of everyone’s memories.  One characteristic of these methodologies is that they have very specific rules.  You can’t add to, change, or remove any of the rules.  Why?  Well, because you wouldn’t be “doing” X methodology!!!

People have a habit of dogmatically following whatever methodology management makes them follow.  Now let’s say we are doing “Enterprise Scrum”.  This means that you are performing the following ceremonies:

  • Release Planning
  • Sprint Planning (every sprint)
  • Daily Scrum (every day)
  • Sprint Review (every sprint)
  • Sprint Retrospective (every sprint)
And, you have the following roles:
  • (1) Scrum Master
  • (1) Product Owner
  • Team (self-organizing)
And you will have the following artifacts:
  • Product Backlog
  • Sprint Backlog
  • Burndown/Burnup charts (some say Scrum requires these, I don’t think it does as it’s not clearly articulated and varies by source)
So we’ve gone enterprise Scrum.  We’ve introduced this “by the book” Scrum.  However, we’ve also preached “inspect and adapt”.  But, in Scrum, the above items are non-negotiable…you can inspect and adapt all you want, but you can’t change the ceremonies, artifacts, and roles.  Can you add to them?  Sure, but you can’t “change” them.  And, in reality, making “inspect and adapt” a cultural “habit” is spectacularly difficult and rarely truly attained.

What if we have a Scrum team that wants to do a retrospective every other sprint instead of every sprint?  Blasphemy!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.  Really?  What if the team, Scrum Master, and Product Owner are all cool with it?  Now we have a bunch of stress, spinning, and politics because we want to make a change to our enterprise standard Scrum.  In reality, this is perfectly okay.  However, since we’ve pushed “Enterprise Scrum”, we have totally boxed ourselves in.  There will even be people who will not want to add techniques because “Scrum doesn’t say so”.  Do those people truly understand the essence of Scrum?  No.  But they will cause disruption and waste

What if you don’t want to do iterations?  What if you want to deliver continuously instead of iteratively?  No Iterations?!?!  Blasphemy!!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.

You know all of this could have been avoided?  By NOT saying we are going “Enterprise Scrum”.  I believe the best way to roll this out is by pushing Agile and Lean and what makes sense on a project by project basis.  Along with this there should be some foundational elements that are standard regardless of the methodology/toolset that is used. In addition, there needs to be a COE that can ensure that consistency is maintained without bureaucracy, and that knowledge gained is effectively utilized to continuously improve.

Please don’t misunderstand my intention here.  I am not bashing Scrum.  I LOVE Scrum.  I always use Scrum when I execute projects.  However, I’ve had rare cases within the same company where Scrum was NOT optimal, but Kanban was.  I was very thankful that Scrum was not the required standard.

Advertisement

Filed under Agile, Process, Scrum

Scrum Does Not Tell You How To Build Stuff

November 6, 2010 Leave a comment

There have been some respected leaders in the industry that evidently just don’t get what Scrum is meant to provide and, more importantly, what it’s not.

Scrum does not tell you that you have to use TDD, BDD, Continuous Integration, Continuous Deployment, OOP, etc. Scrum also does not tell you that you have to use User Stories that are estimated with the Fibonacci-ish scale. It doesn’t tell you how and if to do exploratory testing, load testing, performance testing, acceptance testing, or anything else.

Why? Because it wasn’t meant to. Are all of the things I mentioned above good things? Absolutely! Is every team ready to adopt them? NO.

100% of the teams that I’ve coached were not ready to take on the additional stress of learning these practices that Scrum does not require. The FIRST thing they had to work through was how to be a team. How to understand what commitment means. How to respect and trust each other. How to feel and be empowered. How to build trust with the customer that had been long lost or most likely never existed. How to better predict what will be delivered. What it means to deliver VALUE.

Focusing on these things is many times almost more than a team can handle. I’m surprised that anyone would think it would be a good idea to right away add on top of this the pressure of learning new technical practices. The fact of life is that most enterprises do not have the processes, infrastructure, or culture that allows quick adoption of modern development practices. Change takes time. Take a deep breath and embrace it. Only then will you be able to make real change.

Filed under development practices, Process, Scrum

Tips on Knowing if Your Daily Scrum Sucks

October 18, 2010 3 Comments

Below are some tell-tale signs that your daily Scrum sucks.

  1. The team members stand at attention and salute the Scrum Master.
  2. There is an infestation of clucking chickens.
  3. You have a hard time hearing everyone over the loud yawning.
  4. There’s lots of very descriptive, helpful answers to “what did you do since the last meeting?” like “stuff”, “things”, or even better…”nothing”.
  5. The team members who did nothing since the last meeting happen to be the “rock stars” pre-Scrum…oh, and they never, never, ever, ever have anything standing in their way.
  6. Every meeting reminds you of the movie “Groundhog Day”.
  7. The first 5 minutes is spent waiting for the projector to warm up.
  8. You get to meet a new member of the team almost everyday, while never having a chance to say goodbye to the dearly departed.
  9. Most’s answers to “what are you going to do today”,  are “get sign-off”.
  10. Big Brother is there to make sure the team is “on track”.
  11. Most meetings consist of discussing episodes of “Fringe”.
  12. The meetings are typically very lonely, as you are the only one that shows up.
  13. Bullies are allowed to…well…bully.
  14. Everyone has their laptops open IMing each other about “how stupid this meeting is”, while the Scrum Master or Product Owner is assigning tasks.
  15. You get to hear intriguing, long presentations about each and every detail on things like how to install and set up subversion, or maybe even if you’re lucky you may hear why Lisp is the best programming language in the world!

While many of these are a bit tongue-in-cheek, they actually represent the many dysfunctional daily Scrums I’ve attended.  And yes, I’ve been guilty of participating in the dysfunction.

So, let’s hear from you guys!  What kind of signs have YOU seen that your daily Scrum sucks?

Filed under Agile, Meetings, Process, Scrum

Effective Meetings Mean More Than Discussing

July 12, 2010 Leave a comment

Many companies have been trying to reduce the overhead of meetings, to no avail. I have a really simple idea. Never set up or attend a meeting where the goal is to “DISCUSS” things. Here’s some examples of meeting invites I’ve had over the years:

  • Discuss technology direction
  • Discuss production outage
  • Discuss ORM
  • Discuss contract

Of course these meetings never have agendas. And what work is actually accomplished? None! A friend of mine compared these kinds of meetings to bar conversations. You know those; lots of fun dreaming about “what ifs” and coming up with a plan on how to “make it big”. And what happens after those conversations? Nothing. It’s as if they never happened.

Let’s rewrite those meeting invites to be a bit more productive.

  • Decide whether to build the application using .NET or Java
  • Create an action plan that minimizes production outages and define a clear escalation path in the case that they do occur
  • Decide whether to use Hibernate or EJB
  • Decide whether to accept or reject the proposed contract

Notice that the verbs imply finality, “discuss” does not. “Decide”, “create”, “define” means that you will leave the meeting having made progress. You now have a definition of “Done” for the meeting. You will never know when you are “Done” discussing.

Filed under Meetings, Process

Stop Talking, Start Drawing! A Quick and Dirty Value Stream Example.

March 25, 2010 2 Comments

Recently I was helping a team out in a sprint planning session. All development is very waterfall (that’s a topic for another post), and it follows a very well defined, albeit inefficient, process.

We were talking about how to “streamline” the process to deliver this particular product, which was nothing more than an electronic representation of a printed document.

We talked and talked. We were “talking” about the process. I decided to draw the process we were talking about so the entire team could visualize it. It is a very quick and dirty value stream map, and can be considered incomplete, but sufficient for the needs of the team at this point in time.

Below is a re-drawing of the first stab minus the “details” 🙂

Delivery Process

I then asked the team if there were any opportunities to improve. The collective answer was “no, the process is already streamlined“.

Okay, sweet. But, I’ve never seen a process that can’t be improved. Ever. And I’m old.

Then I asked how “long” we stopped at each step in the process, i.e. how long each step took. Below is the same drawing plus the weighting.

Delivery Process With Weights

Delivery Process With Weights

Notice any thing interesting? Anything stand out? Well, I’m sure you caught it. The “unit test” box is 40 hours, while everything else is 8 or less. Hrmmm….I wonder? Could we maybe do something there?

Well, we explored it a bit, and found that how we’ve been doing things is throwing them over the wall so the consumers of the documentation can eyeball and test this stuff. Guess what they did if they found something wrong? They spent time creating a document to tell the developers what to change. Then, back around it went.

So, an option the team came up with to reduce the time spent in the unit testing “state”, was that when unit testing began, they would have the developers sit by the folks who actually tested the documents, then they would “tell” them what to change…then change it…then send it back to test. No emailing and creating painful documents describing what’s wrong. Just good old fashioned face to face conversation. The team is confident that they can significantly reduce the 40 hours of unit testing.

Will this work perfectly? No. There will be more opportunities for improvement…as always. But, you know what? We would have never explored this option of we would not have visualized the process by drawing it.

Oh, guess how long this took us? About 20 minutes. Yup…20 minutes. That’s it. How long did we talk in circles before we drew? Hrmmm…about 1/2 an hour, and it got us nowhere.

So, as soon as you start talking and talking and talking and talking and getting nowhere. Get off your butt, and start drawing.

Filed under Process, Teams

Scrum Needs More Than Just Chickens and Pigs

March 21, 2010 2 Comments

If you’re reading this, I assume you already know the “chicken and pig” roles in Scrum.  If not, go here to check it out.

Okay, pigs have “skin in the game”, and chickens…well…don’t. Since some people hate the chicken and pig metaphor, I’ve also referred to it is “committed” (pigs) and “interested” (chickens) (I didn’t come up with this, but I don’t remember who did).

The chickens are not allowed to talk in the daily Scrum meetings. They are only allowed to provide feedback in the Sprint Review (and of course at any time to the Product Owner, Scrum Master, or as requested by the Team).

I think there are two kinds of chickens. There is the kind that provide no valuable input. They historically have done nothing other than cause distractions. Whatever it is your building may have an indirect impact on their lives at best. These people are typically in some kind of management, or senior role.

The second kind of chicken are those folks we typically refer to as “SMEs” (Subject Matter Experts). We may or may not be building a solution for them. However, we rely on their expertise to enable us to deliver value. These kinds of chickens are usually are involved in legacy application development or re-platforming efforts. You probably won’t experience this group if you are doing new development. These types of chickens are needed when the Scrum team just does not have enough of the institutional knowledge needed to consistently deliver value.

Both of these types of chickens have one thing in common. They do not have “skin in the game”. If the project fails or succeeds, there typically will be little (or no) consequence for them. What they do NOT have in common is this; the involvement (or lack thereof) of the second kind of chicken can either bring a team to success, or to a miserable failure.

Teams will typically lump both types of chickens together and treat them the same way. It’s really insulting if you think about it. If I was *critical* to the success of a project but am labeled a “chicken”, and if I identify a risk, I shouldn’t have to wait to speak until spoken to (which is implied with chickens), or until the Sprint Review.

What do we call this third group? They really aren’t chickens as defined in the Scrum context. However, they aren’t pigs either since they aren’t the Product Owner, Scrum Master, or Team (those who do the actual work). We will fail without them.

Filed under Process, Roles, Scrum, Teams Tagged with ,

Face It, Your Memory Stinks

March 14, 2010 1 Comment

Seriously, it really does. You can’t remember everything. No matter how good you are at “Simon“, your memory just isn’t good enough.

Okay, so I’m stating the obvious. If we all know we can’t remember everything, why is it then that in soooo many meetings, nobody writes down what was decided, discovered, or uncovered? Sure, there are some folks that are writing “something” down during meetings. But, those are typically their own personal notes, the stuff that applies to THEM and not the team-at-large. They could be doodles, or possibly an attempt to look like they are attentive to what’s going on, when in fact, they are actually zoned out (I’m guilty of that). Who’s recording the important knowledge for the benefit of the team and organization?

I was observing a planning session a while ago. The team asked a business SME to come in and answer some questions regarding complex business scenarios. It was a rich, active discussion. People were learning new things left an right. It was beautiful. This dialogue lasted about 20 minutes or so. Guess how many people wrote this incredibly critical information down? NONE. That’s right, not one person wrote anything down. Sadly, I’m starting to realize that this is a common occurrence.

This is why we have the same meetings over and over again. How many times have you been in a meeting and you think, “Huh? We’re having this meeting AGAIN!?!?”. There is a very simple solution. WRITE IT DOWN, send it out, and store that precious information in a central location that’s easy to get to (can you say “wiki”?).

Whose responsibility is it to make sure something is documented during these meetings? It’s everyone’s, including yours. If you see that information is just disappearing into thin air, don’t hesitate…ask “okay, so who wants to take notes?” If you get no volunteers, then announce that you will do it…and then take care of it.

Filed under Process, Roles, Teams

Process is Not a Four Letter Word

January 20, 2010 3 Comments

I grew up as an only child.  I had no brothers or sisters to “share” anything with.  It was all MINE.  When I became a teenager, I completely rebelled against all authority.  This probably had something to do with my only child-ness, but probably had more to do with me being a spoiled jerk.

I hated all authority…teachers, parents, pastors, police, you name it.  How dare they tell me what to do!  I felt that their only purpose was to make sure everyone followed arbitrary rules that MADE NO SENSE, and they were determined to make my life hell.

As the years went by, I calmed down, settled down and became a family man.  But, I don’t think I’ve ever shaken off that old “to hell with authority” attitude.  I’ve just learned to live with it 🙂

I think this is one of the reasons that I fell in love with Scrum, and agile in general.  It had that familiar aroma of my old days of rebellion.  Agile ideas came about really out of necessity and a spirit of rebellion.  There were arbitrary rules that were imposed on organizations about how to build software that MADE NO SENSE!  So, how about we rebel, and do things OUR way, i.e. the way that makes sense.

Now, let’s consider the word “process”.  Over the last several days I’ve realized the profound effect this word has on people.  People immediately cringe.  For some reason, the word “process” paints a picture of arbitrary rules that MAKE NO SENSE that we have to follow.  It implies bureaucracy and micro-management.

Now, let’s set something straight.  “Process” is critical to the success of any endeavor.  If you let the process “evolve” without paying attention to it, it will cause chaos.  One thing that people don’t understand is that a process always exists, whether it’s documented or not.  It may feel like “free-style”, but it’s a process.

I’ve been involved in some conversations recently about role definition.  This is a classic problem that plagues every company…not having a clear definition of roles.  Here is the problem; without a clear understanding of a PROCESS, you will never be able to clearly define ROLES.  The first thing that should happen is to clearly define what the process is in how to deliver software (or anything).  I’m not talking about creating artifacts.  Documentation does not equal process.  It supports the process, and may be a by-product of the process, but documentation alone is not the process.  But be careful.  I’ve seen to many times a “process” created that people end up slavishly following without ever even attempting to improve it.  A process must evolve along with the changing culture, technology, and business needs.

To some extent, Scrum practitioners discourage defining processes.  It appears to me that maybe this whole “stick it to the man” gets a little too out of hand…even for me!

If you don’t control the process, the process will control you, and it won’t be a good thing.

Filed under Process Tagged with , , ,

Creating the Sprint Backlog in New Scrum Teams

December 28, 2009 1 Comment

If you’re new to Scrum, here is something you need to know about teams first trying it out…ready??

…drumroll…

The team doesn’t know what they need to do

There, I said it. Whew, glad I got that off my chest.

In Scrum, we ask team members to break product backlog items (typically stories), into tasks that take 16 hours or less to complete. You will find that, most of the time, the team will have incredible difficulty in doing this, and they will likely come up with tasks such as “analyze, code, test”. Bleh. Those are B.S. tasks that really don’t mean anything. It’s hard to define “DONE” for those types of tasks. You may have to accept those tasks in the beginning, but it is your responsibility as a Scrum Master to coach the team into creatively thinking through task definition.

Here are some reasons I think teams may have a hard time defining tasks.  It is best to look at all of these as impediments, and your job as a Scrum Master is to remove them.

  • Lack of Empowerment
    Teams under the tyranny of “traditional” development are rarely empowered. They are used to being told what to do. While creating solutions, team members will actually do what needs to be done and then move on to the next thing. The problem is that they’ve never had to articulate the steps they take to complete what they need to complete.  And, to top it off, managers rarely understand what it “really” takes to deliver a solution. 

    This will not be a quick fix.  You will have to work with leadership and come up with a strategic plan on how to empower people.  In the meantime, even though you tell the team “your empowered’, if the rest of the organization does not support it, there will be constant struggle.  However, as a leader, it is your job to work both sides of the fence, i.e the team and the organization.

  • Fear
    In an extreme command-and-control environment, people lose all common sense. They are not confident making any decisions, let alone actually thinking for themselves. 

    Here, the team will need lots of praise and protection.  If they know that you have their back, they will, over time, come out of their shells.

  • Lack of Knowledge or Skills 

    If the team is new to that domain, or the team just does not have the skills, i.e. a Cobol programmer “trying out” Java development, there is no way they can effectively decompose stories into tasks.

    This is one of the toughest situations to deal with.  If the team is just the wrong team, the only thing that can be done is to escalate this impediment to leadership.  This one is particularly hard because I guarantee that there will be others who think some of those on the team DO have the knowledge and skills, likely because those folks are “well liked” or popular.  Just remember to be honest always, and over time, change will happen.

  • “The Dominator” 

    Sometimes there is one person on the team who holds the key. They know the domain, they know the technology. No one else does. THEY are the ones who define the tasks. If the tasks aren’t good enough, who cares, as long as “The Dominator” is okay with them. This is a tricky one. It is your responsibility to either a) get them off the team or b) clearly set the expectations and time-box the needed change in behavior.

If you are a Scrum Master or coach on this team and you don’t have “tribal” knowledge, it will be a true test of your patience.

But, hope is not lost! A while ago, I was in this situation. I was in a sprint planning session, and I saw the familiar signs emerging…”Ummm…yeah…we need to analyze”. “Oh, I suppose we need to code too”. UGH. I was helpless. Luckily, there was a strong technical lead attending that understood the domain and technology. He patiently walked the team through the decomposition of the stories into “real” tasks. It was a real humbling experience for me. I thought I could get ANY team to decompose stories into meaningful tasks. Boy, was I wrong.

So, if you’re in this situation, determine the “root cause” of why the team can’t decompose stories into meaningful tasks. If it’s an impediment, handle the impediment. If it’s because you are lacking the knowledge necessary to coach the team, find someone there who can.

Filed under Agile, Process, Scrum Tagged with , , , ,