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

Your Scrum Team Might Be Too Big

January 4, 2011 Leave a comment

According to the ways of Scrum, the optimal Scrum team size is between five and nine people. Interestingly, I’ve seen this as a point of concern (sometimes contention) when I’ve coached people on Scrum. Please note that this is not a rule that must be followed at all costs. God gave us a brain, so we should feel free to use it.

While I know it’s rare, I personally have seen successful teams that consisted of 10-15 people. I belive that if a team consists of any more than 15 (or so) people, you are reducing your velocity.

Now you have a bloated team.  What should you do?  Well, first thing you should consider is to take some ideas from Kanban. Visualize the work, make the process and policies explicit, limit work in progress, measure/minimize cycle time, etc. (read more on Kanban here)   The purpose of all of this is to gain clarity on what kind of work is actually taking place.  In addition, you will gain insight into the quality of the deliverables and where the bottlenecks are.

Once you have this information in hand, you then have three choices.

  1. Split the team into multiple teams.I have seen large teams have several very distinct types of work occurring. If there are distinct types of work, i.e. completely different categories of stories/requirements with different goals, and the team is forced to act as one, then there is waste. For example, during the standup, there will be members of the team that have to endure hearing the updates about requirements that they have no interest in, nor can they contribute to the delivery of those items (usually). This is likely the optimal choice.
  2. Reduce the number of people on the team.This is the tricky one. You may find that there are people that don’t have the necessary skills, or you may find that there are too many people with one very distinct skill set. If one (or both) of these scenarios holds true, and you are sure that these folks can’t contribute in other areas, then make haste and remove the people from the team. Everyone (including those let go from the team) will end up happier and more productive.
  3. Keep everything the way it is.This is a very, very unlikely choice. I have never personally experienced a time when it was a good idea to keep one team larger than 15 people. I would love to hear from others where this has worked…well.

If you are a Scrum Master, and you are experiencing team bloat, then it is your responsibility to recognize it, determine if it’s an impediment towards improvement, then handle it.

Filed under Agile, Scrum, Teams

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

How Does a New Scrum Master Learn the Mastery of Scrum?

September 28, 2010 Leave a comment

Learning to be a Scrum Master is hard. But what’s the best way for a new Scrum Master to learn to be a Scrum Master?

I had it easy. When I learned, I had an awesome team. They were open, engaged, and always wanting to improve. The Product Owner was awesome also. Again, open and engaged. The thing they all had in common was that they wanted to learn Scrum. I introduced Scrum to our department. I read a little, implemented a little. Screwed up, tried again. Read a little more, tried a little more. And so on. It was basically a self-study program with help from blogs, books and the team itself.

For me this was easy. I was never really a “command and control” person anyway. Sure, I had my tendencies, but pretty mild. I knew that my team were the ones that “really” knew what to do anyway…so why not give them the tools to empower them and help them be focused on quality and value? There wasn’t a lot of “unlearning” that had to take place for me.

After that first (great) experience, I became an agile coach. Now it was my time to help teams transition to Scrum by educating the team, Product Owner, and Scrum Master. Well, admittedly, I was winging it for a while, but through trial and error I fell into a pretty good groove.

What I’ve done recently is come up with three options/approaches to helping others become Scrum Masters.

  1. The coach leads

    With this approach, the coach plays the role of the Scrum Master, while the soon-to-be Scrum Master watches, and helps. Then, after a while (depending on their comfort level), there is a switch, and the coach becomes the observer/helper.

  2. The coach observes

    Here, the new Scrum Master will be the acting Scrum Master. However, the coach will be there to observe (and help) while the new Scrum Master is facilitating. The coach would only correct/advise/encourage in private.

  3. The coach advises

    In this scenario, the coach is not directly involved in any of the ceremonies. They are only there to advise. The new Scrum Master and coach would regularly meet to go over gotchas, issues, etc.

  4. Coach? What coach?

    This is how I learned. We didn’t have a coach. But, we were completely free to do what we needed to do to be successful. And, there was complete buy-in from the team and leadership. Oh, and we were allowed to make mistakes. And, I think what really made it work was that none of us had any “baggage” from other environments. I recently had change careers (retail to software), and most of the folks on the team were relatively fresh college graduates. After working with many teams, I’ve found that this is indeed a rare situation.

I give my team (and anyone else in the organization who wants to be a Scrum Master) those three options. #2 is the most popular. However, I just had someone pick #3.

So, which the best option? It depends. It depends on the experience of the new Scrum Master and of the team. It also depends on who the coach is in the organization. For example, I am a manager where I work. I don’t have the word “coach” in my title, even though this is something that I am responsible for. As with most organizations, having “a manager” present may send the wrong message, no matter how cool you think you are! There are some teams where there would be no issue, but there may be others where it might be questionable. You have to be aware of this, and make your decision accordingly.

As an independent consultant (coach), who is brought into an organization to introduce Scrum, then #1 is typically the best. If the coach is there to help “improve” their implementation of Scrum, or if maybe the organization is backsliding, then maybe #2 is best. When there are experienced Scrum Masters that are experiencing new situations and need to just bounce ideas off of someone, then #3 is best.

As far as #4…I’ve heard about many teams that tried to “do it on their own”, and completely tanked. They didn’t have that utopian environment that is oh so rare. So, if you do decide to do it on your own, start reading. Read, read, read, and read some more. Blogs, books, and user groups. Ask questions on these user groups…you will find a wealth of knowledge and people who want you to be successful. Also, twitter will be your friend. Personally, I have gotten so much out of following Mike Cottmeyer, Alan Shalloway, Ron Jeffries, Scott Ambler, Mike Cohn, and Esther Derby (to name a few). They post awesome information and articles that are thought provoking and hard to find otherwise.

I would love to hear from others on this topic. What are the approaches you have taken in coaching, or have seen others take? How did YOU learn to be a Scrum Master?

Filed under Agile, Scrum

Scrum Won’t Always Work

June 7, 2010 3 Comments

Well, this is my fourth refactoring of this post. This was supposed to be a quick one! I fully intended on this post explaining why Scrum will always work. Simple! But, as I thought through this, and kept rewriting my post, I’ve completely changed my tune.

What does it mean for Scrum to “work”? I’m going to define “working” as “delivering more to your customers with higher quality than you did before and continuously getting better”.

Does Scrum always work? In my opinion, no. It depends on the type of team that is being introduced to Scrum whether nor not it will work.

The Team that Rocks

If you have a team that is consistently delivering value, is a cross-functional “team” and not a group of individuals, is continuously improving and has a good, productive relationship with their customers where the customers define what they want and collaborate with the team, then Scrum may set them back. I believe that the additional overhead in the form of sprint reviews, retrospectives, sprint and release planning, and daily stand-ups that Scrum adds may make an already high performing team less productive. The team, in some form, is already doing something that produces the same results as these activities. For these types of teams to improve, Kanban is likely be more appropriate.

The Team that Does Not Rock

I really wanted to title this “The Team that Sucks”, but I thought that would be too offensive. Anyway…Given a team that is not consistently delivering value, is not a real “team”, or has a bad relationship with their customers, I believe Scrum will always work. The team will always be better than it was before. Typically these teams have no process (even though they think they do), so anything that brings discipline and communication will allow the team to improve. I have never, ever seen this to not be the case. I admit that at times the improvement is small, but it is an improvement nonetheless. Of course one thing that’s crucial is to have a strong, experienced coach.

As far as the roles introduced by Scrum, you will have a hard time convincing me that there are times when a product owner role is not needed. I’d have to say that the #1 problem I see in “troubled” teams is the fact that they have no idea what to work on next. What do they do in this case? They start guessing. Oh, and they never really know when they are “Done”. If I do nothing else but involve a strong product owner, that alone typically propels the team forward.

As the team matures, however, they will inspect and adapt (the essence of Scrum). Many “advanced” teams may be considered by Scrum-ists to be doing “Scrum-but”, or maybe even not doing Scrum at all, since they have adapted to be the most productive and efficient they can be. Which helps verify that Scrum will not always work.

What do you think? Will Scrum ALWAYS work?

Filed under Roles, Scrum, 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

Scrum Alone is Not Sufficient

January 13, 2010 1 Comment

There are some who believe that Scrum alone is sufficient to run complex, big, expensive, scary projects and/or programs.  Some people think that Scrum instructs us how to code. It does not.  It provides a framework and a set of principles (as does any sound agile methodology) on which to base our development and delivery practices and processes.  The only way that Scrum is sufficient alone is if the teams are completely self-organizing, highly skilled and efficient, the business has a clear, sound vision that is clearly understood and communicated, and the management fully supports the efforts put forth by the team.  I have never experienced nor have a heard of a company that attained this utopia.
Let’s talk about the real world.  Most developers are average at best, there are politics, hidden agendas, attitudes, kingdoms, and lots of other “stuff” that prevents this paradise.  Since that’s the case, you can’t be done at Scrum.
The Scrum framework provides guidance regarding key roles (Scrum Master, Product Owner, Team), ceremonies (sprint planning, daily scrum, retrospective, sprint review) and artifacts (product backlog, sprint backlog).  It provides no other guidance.  In Scrum, “the team” decides how to handle things.  How do we manage requirements?  The team decides.  How do we handle vendor relationships?  Let the team decide.  How do we make sure we are compliant?  Let the team decide.  I think you get the picture.
Below are some things that Scrum does not address.
  • How to code
  • How to test
  • How to manage code
  • How to manage risks
  • How to document and manage requirements
  • How to manage the budget
  • How to estimate
  • How to decide whether to build or buy
  • How to deploy into production
  • How to operationalize the product
  • How to train new users on the product
  • and the list goes on and on and on
My point is this…if you are successfully doing Scrum alone, good job.  But it’s not enough (unless you have achieved utopia).  The team likely will not have the knowledge or experience necessary to decide how to do EVERYTHING.  Now you need to take that next step.  Bring in CI and TDD.  Start measuring your productivity by bringing in some lean/six-sigma tools so you can better improve.  Heck, I think there’s even some stuff in the PMBOK that is pretty useful!

Filed under Scrum Tagged with ,

How Many Scrum Projects Can a Developer Be On?

January 1, 2010 1 Comment

This post was inspired from a question that was asked on the scrumdevelopment yahoo user group.  The question was regarding several things.  First, how to handle a developer on multiple Scrum projects, second how to sync the sprints, and third what tools can be used to handle the multiple projects.  I’m addressing the first and second aspects, and not the third about the tools.

Having developers on multiple projects is a very common thing. It is the wrong thing.  If the project solutions have to integrate eventually, then it makes more sense…but in that case, the developers on multiple projects should be used in a different capacity. More leadership and guidance and less actual coding.

If developers are on multiple projects and the projects are unrelated, you’ll have to stagger the sprints, i.e. they shouldn’t start and end on the same day. Imagine developers having to attend 3 sprint planning sessions in one day, 3 retrospectives in one day, 3 standups in one day. I tried that once with 4 projects…yeah it sucked. Developers on the teams were doing nothing but attending meetings. Their first impression of Scrum was “meeting hell”. Plus, you can only be in one place at once, so some of the projects suffered due to lack of attendance.

If the projects have to integrate, the sprints should sync up, as the goal is potentially shippable software…and you can’t ship unless you integrate.

Either way, it is bad to have developers on more than one…”maybe” two projects. The cost of context switching is too high. I know it sounds impossible to have developers on only one project, but if you make it happen, you will not regret it. It’s just scary because we’ve been trained that “multi-tasking is good”. That is a big fat lie.

Filed under Scrum Tagged with , ,

← Older posts