Scrum Won’t Always Work

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?

Advertisements

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

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.

Scrum Needs More Than Just Chickens and Pigs

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.

Face It, Your Memory Stinks

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.

When Should Waterfall be Used Instead of Agile?

I just read a thread on the Scrum Development yahoo user group about when it would be appropriate to use agile and when waterfall would be better.

This brought to mind all the conversations I’ve had over the years regarding “when to use agile”. There are many folks in organizations that believe that waterfall is best suited for some projects.

So, I’ve been searching for those “types” of projects.

Now, let’s be clear. I am using the term “waterfall” in the strictest sense which means that:

  • Requirements have to be complete and signed off before technical design begins.
  • Technical design has to be complete before development begins.
  • All coding has to be complete for testing begins.

If we “kind of” follow this, then it is chaos. ¬†The question we have to ask is … is it even possible to meet the strict requirements of waterfall? ¬†My answer is NO for software projects, or any projects with a large amount of¬†unknowns or required creativity and flexibility.

Can you ever successfully¬†elicit and document a complete set of requirements at the most granular level? ¬†This is what waterfall requires after all. If there is even a remote chance that a) the customer isn’t sure what they want, b) the customer may change their mind on what they want, or c) there is even a small amount of complexity, then it is very, very high risk and just not very smart to use waterfall. You just can’t…stop kidding yourself.

So, is there ever a reason why you would want to use waterfall? Sure! Here they are:

  • The culture is not ready to work cross-functionally.
    • Any agile methodology requires a cross-functional team. If the culture cannot sustain cross-functional work then you are forced into communication by documentation. Yeah, good luck with that. You should think about coming up with a strategy to make people hunger for cross-functional collaboration.
    • Not everyone “wants” to work in a cross-functional team environment. They need to either be coached up or coached out.
  • Management makes you use waterfall.
  • You can confidently define everything up front, there is little or no chance there will be changes, and there are no unknowns.

Let’s not pretend anymore that waterfall is actually appropriate for any complex software project with humans working on it. ¬†With complexity come unknowns, and with unknowns, the amount of bureaucracy necessary to handle “change management” is ludicrous. ¬†I have yet to experience any software development project that did not have at least some kind of complexity. ¬†If you say “agile doesn’t work for all software projects”, then you have a misunderstanding of what agile truly is.

Expiring CSP (Certified Scrum Practitioner)…Do I Care?

Scrum Rocks

I love Scrum. ¬†It’s freakin’ awesome. It is simple and yet wonderfully challenging. When implementing for the first time, impediments (of which most have always been there) smack you in the face, and you are forced to make a decision…knock them down or ignore them. ¬†Sadly, the path of least resistance is to ignore, so that is what tends to happen.

Scrum makes you focus on empowerment and value. ¬†Scrum also forces “the business” to be a part of the process with the Product Owner. ¬†Scrum forces you to deliver potentially shippable code at regular intervals.

One of my favorite things is the “chicken” and “pig” thing. ¬†The pigs are the ones whose neck is on the line to deliver value, i.e. the Scrum Team. ¬†The chickens are the ones whose neck is NOT on the line. ¬†You know those folks…the ones who distract the team from focusing on the goals at hand. ¬†I’ve had lots of those back in the day…and they sucked. ¬†With Scrum, we can draw a line in the sand. ¬†We can identify those who have skin in the game, and those who don’t. ¬†Now, we shouldn’t just flip the bird (no pun intended) to the chickens…they may very well have very good input and feedback. ¬†However, this information must be funneled through the Product Owner, not directly to the team. ¬†Of course we could have made this¬†delineation with our traditional methods, but the methods never clearly called out this distinction so people had to rely on their common sense, which meant that it never happened.

Scrum, But…

I am so sick of hearing this. People continuously ask themselves “Are we doing Scrum or not?”. That’s not the right question! The question should be “Are we improving in our ability to deliver value to the customer or not?”.

Scrum is empirical. It is meant to change. What are the non-negotiables? Ummm…I’m not really sure. Some people say the daily scrum. However, I’ve seen times when the team is all in the same room and highly functional, and the daily scrum is completely unnecessary since communication is organic.

What about the retrospective at the end of every sprint? Ummm…I’m not really sure. If you have 2-week sprints, wow, do they get stale. What about at the end of every other sprint? Shouldn’t the team decide? Are we “doing Scrum” if we decide to do them every other sprint? Well, I guess it depends on who you talk to.

What about the burndown chart? It’s in the Scrum Guide, right? It doesn’t say that it’s required, but it doesn’t say it’s not. Okay, so we don’t have a burndown, but we meet our sprint goal, and have potentially shippable product at the end of the sprint…so are we “doing Scrum”? I guess it depends on who you talk to.

Uh-oh, what if we have more than one Product Owner? Well, I’ve seen it work for some teams very well. But, Scrum says you have only one. Are we “doing Scrum”? I guess it depends on who you talk to.

My point is this, Scrum is a light framework that supports the agile (and lean) principles. If you know what you’re doing, go ahead and do what is right for you team…making sure to not lose sight of continuously improving, and delivering high quality value to the customer. Don’t worry if “your doing Scrum or not”.

Now, if you are new to Scrum, or agile in general (i.e. don’t know what you are doing), PROCEED WITH CAUTION! Spend LOTS of time digesting information, reading blogs, books, etc. before you start. I’ve seen many folks attempt to adhere to a book after a quick skim and fail spectacularly when trying to implement Scrum. You should seriously consider getting someone in to help you.

To Renew my CSP, or Not to Renew? That is the Question!!

I have a confession to make. The only reason I got my CSP was purely a PR move. I had been practicing “real life” Scrum for some time. However, for some reason corporate America cares about certifications. I’m starting to believe that certifications, ALL certifications, are purely marketing tools, and nothing else. Why is it that all of the absolute worst project managers that I have ever worked with had a PMP certification? Or, why is it that some of the absolute worst system admins that I’ve met had a MCSE certification. Even some of the worst Java programmers I have met had a Sun Certified Java Programmer certification. Hrmmm…I think I’m starting to see a trend. Typically, at least in my small part of the world, the truly talented folks rarely have any certifications.

Okay, so let’s get real. It’s the game you have to play. Right now, I’m not in a place where I have to play these kinds of games. I’m employed full time in a great company, so I don’t have to worry so much about “PR” moves such as certifications.

Okay, so I think I’ve answered my question. No, I don’t care about the CSP right now. So no, I’m not going to renew my CSP.

Process is Not a Four Letter Word

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.