Breaking News!! Jeff Sutherland’s Scrum Inc introduces “Scrum At Scale” — see it at Agile 2014 session

I was lucky enough to get a preview of the “Scrum At Scale” approach from Scrum Inc a few days ago. In short, it’s a model for conversations around how to think about scaling Scrum in the enterprise. The model is modular, and it is very clear that this approach is more lightweight and flexible than other Agile scaling approaches that get a lot of attention. Alex Brown of Scrum Inc, the Product Owner for the model, as well as Jeff Sutherland, are very adamant that this this not some cookie cutter recipe or methodology to scale Scrum. It’s different than other approaches, in that it’s a model for conversations around inspecting and adapting toward success with Scrum at Scale.

I’m told that the slides for the presentation at the link above will be posted there within the next couple of days, and possibly sooner. The slides will add a lot of detail that the main graphic doesn’t give. I will also add that there is some nuance and detail not included in the slides either. As such, I recommend try to attend one of their live or recorded video presentations to get some richer nuance…. or….

They are also presenting on this topic at Agile 2014 next week. If you’re going to be at Agile 2014, I highly recommend you put their session on your “must see” list.

The model gives a “big picture” view of Scrum in the enterprise, but it also dovetails nicely with the many years of work that Jeff Sutherland and others have put into their Scrum Patterns efforts. As you may know, I’m also a fan of this Scrum patterns concept, and you can see an example of that work on my website — Daily Scrum Patterns.

It’s worth mentioning that I have no business relationship whatsoever with Scrum Inc, so I’m not in any way incentivized to advocate for their approach.  I’m only endorsing it because I believe in the approach and in it’s future.

I suspect that this work will be a game changer in the Scrum scaling space, which doesn’t surprise me, really. It *is,* after all, coming from a company run by the co-creator of Scrum! Nice work Alex Brown, Jeff Sutherland, and Scrum Inc!

Is SAFe(tm) Bad? Is it unsafe? Is it Agile? Are there alternatives?

For much better alternatives to SAFe(tm), see this page.

All my personal/professional opinion.

I’m not a big fan of SAFe(tm). I haven’t yet had time to sit down and detail all of the problems I have with it, but I’ll hit a couple.

1. It’s not Agile at all. It’s a sales strategy.

My biggest problem with it is that it condones old, out of date, and dysfunctional practices that don’t enhance Agility. It is essentially a hybrid approach of Waterfall and Agile, along with a lot of baggage from RUP. This probably shouldn’t surprise anyone since the creator, Dean Leffingwell, was a big salesman/evangelist for RUP. The biggest baggage from RUP is the complexity of a zillion different roles and the fact that SAFe is a “slice and dice” methodology. It’s not a framework. I think the “slice and dice” thing is really just a slick sales strategy. It allows those selling SAFe to immediately disown any practice of SAFe that a potential client complains isn’t Agile or won’t work. It also means that any tiny subset of SAFe is still considered to be SAFe. As such, I just consider this a sales strategy to sell more billable hours. This strategy was also used in RUP, and yet… over the years… which has prospered more? RUP or Scrum? Scrum is a framework, so there is no slice and dicing of the framework itself.

2. It misleads people into thinking that it uses Scrum at the team level.

It claims to use Scrum at the team level, but then completely sells out Scrum in so many ways. It sells out the Product Owner role by giving control to all manner of people over the Product Backlog contents, something Scrum expressly forbids. It sells out the Scrum Master role by suggesting it’s a 25% time commitment. Then, it completely sells out the Development Team by creating Ivory Tower architects.

3. To date, no Agile Manifesto author has endorsed it. That should tell you something right there.

This one is self explanatory. :-)

The reasons I don’t like it are covered in way more detail in these reviews of SAFe by other people who are sharp enough to tell the differences between SAFe and other approaches, as well as the history behind similar practices and approaches

For much better alternatives to SAFe(tm), see this page.

Great Article from Scrum Co-Creator Ken Schwaber on “Agile Value”

Ken Schwaber’s written a great article on Agile Value .  He talks about how value can be defined in Agile, and the article also covers the difference between traditional project management metrics and Agile project measurements.

On a related note, see Common Project Management Metrics Doom IT Departments to Failure

Scrum and Agile Adoption: Backsliding into Waterfall Habits

It’s very common, when an organization is in the Shu level of learning Agile or Scrum, for it to fall into old, bad, waterfall habits.  Today I’d like to talk about two bad waterfall habits:  tracking so called ‘individual velocity,’ and tracking actual effort expended on a task or story.

First, tracking some sort of metric like “individual velocity” is probably an excellent way to completely sabotage your project/product and it’s also a great way to kill your Agile adoption.  A key concept in the Agile Manifesto principles, as well as in Scrum, is team work and “self-organizing” teams.  Self organization is generally the ability for a team to create and execute their own plan of work(Sprint Backlog), as well as decide “How” to do their work.  Whenever there is a single entity (individual on or off the team, department, etc) who strongly influences or makes unilateral decisions for how a team works, there is, by definition, no self organization.  Tracking individual velocity, or any similar “individual incentive” (this can include raises, performance reviews, awards, etc) does not encourage team work at all.  In his book, Agile Estimating and Planning, Mike Cohn says it this way:

“If I am forced to choose between finishing a story on my own and helping someone else, what incentive does measuring individual velocity give me?  Individuals should be given every incentive possible to work as a team. If the team’s throughput is increased by my helping someone else, that’s what I should do. Team velocity matters; individual velocity doesn’t. It’s not even a metric of passing interest.”

Tracking actual effort expended is another really bad waterfall habit.  Tracking estimates and actuals is just another example of where Common Project Management Metrics Doom IT Departments to Failure.  Mike Cohn, an Agile and Scrum thought leader, and a former project manager himself, says this about tracking estimates and actuals:

“On a project, it is far more useful to know how much remains to be done rather than how much has been done. Further, tracking effort expended and comparing it with estimated effort can lead to ‘evaluation apprehension’ (Sanders 1984). When estimators are apprehensive about providing an estimate, the familiar ‘fight or flight’ instinct kicks in, and estimators rely more on instinct than on analytical thought (Jørgensen 2004).

Tracking effort expended in an effort to improve estimate accuracy is a very fine line. It can work (Lederer and Prasad 1998; Weinberg and Schulman 1974). However, the project manager or whoever is doing the tracking must be very careful to avoid putting significant evaluation pressure on the estimators, as doing so could result in estimates that are worse rather than better.

Additionally, keep in mind that variability is a part of every estimate. No matter how much effort is put into improving estimates, a team will never be able to estimate perfectly. Evidence of this is no further away than your morning commute to work. There is an inherent amount of variability in your commute regardless of how you travel, how far you must go, and where you live. If you drive to work, no amount of driving skill will eliminate this variability.”

In a later post on the ScrumDevelopment Yahoo Group, Mike summarizes it this way:

” I’d say you shouldn’t do it because it doesn’t add value commensurate with its cost. Don’t argue with your bosses that it ‘adds no value’ because
comparing what you originally thought a task would take with what it did take can help make you a better estimator.

But, it can be time-consuming to track actuals, especially for a full team where some on the team are probably already decent estimators.

Because Scrum already has solid mechanisms for monitoring whether all the work gets done in a sprint (high team commitment, daily burndown charts, daily scrum, and so on), Scrum does not have the same reliance on early and accurating estimating that a predictive or waterfall approach does.

So–the cost to gather actuals is the same in Scrum or waterfall. The benefit in Scrum is greatly reduced.”

So, be very careful when backsliding into old waterfall habits.  It usually happens in small doses, which is why many Shu level adoptions don’t notice it, especially if they don’t have a skilled Scrum Coach or highly experienced Scrum Master around.  The other thing to keep in mind is that, even if you do have someone skilled around, this old adage still applies:  “You can lead a horse to water, but you can’t make ‘em drink.”

What kind of backsliding into old waterfall habits have you seen?  What do you suggest be done about them?  Sound off in the comments below!

The Summer of Scrum: Ken Schwaber Announces New 2013 Scrum Guide

Ken Schwaber announced today that a new Scrum Guide is coming in the next couple of months.  In my position as a Professional Scrum Trainer certified through Ken’s Scrum.org, I was aware of this earlier this year and I have to say… the Scrum nerd in me is excited!  It’s so great to see that Scrum is evolving, because this is one reason many of the past methodologies and frameworks died out.  It’s also very much in line with the “inspect and adapt” nature of Scrum, so it’s wonderful to see Scrum’s founders and shepherds leading by example.

I also want to drop another hint.  There are some other interesting things happening in the Scrum world this summer that I cannot yet talk about.  Subscribe to my blog to stay tuned!

Scrum On!

Other posts you might be interested in:

Release Cadence Report: Agilists and Software Developers, Take 10 Minutes to Help the Software Community Get Better

The blog post I’m writing to you today is to encourage you to take 10 minutes of your time to fill out the “Release Cadence Report” created by Ryan Cromwell, an Agile community leader that I respect very much.  I get emails often from people wanting me to fill out Agile surveys, and I usually just don’t have the time.

This survey is different, and I took the time(about 10 minutes) to fill it out.  I suggest you do as well.

.
In short, please take 10 minutes to take the survey, then pass along the link to fellow software professionals and Agile enthusiasts.  The survey will only be open for a limited time, so please just take the time and get ‘er done!  I’ll let Ryan take it from there.  See below.
——-
Charles Bradley
Professional Scrum Trainer, Scrum.org
Scrum Coach-in-Chief, ScrumCrazy.com
.
————————–
logo-header
The current information and data available to organizations contemplating Scrum, Agile, Kanban, XP, etc. have grown very stale.  For the most part, the same practices, frameworks, methodologies and trends show up year after year with little exception.  The question is no longer if Agile is the place to be, but how to get there.  I think we are in need of an evolution in our discussion of Agile.
.
Today I opened the Release Cadence Report survey to move the needle towards what I hope is a more useful conversation than the state of Agile.  The report will be publish freely so that everyone can look at the relationship between Release Cadence and things like Market Capability, Employee Satisfaction, Patterns & Techniques used to achieve the cadence, Methodologies, and more.  With it, I hope that we can start talking about how companies have navigated their way to successful products as opposed to iterated their way towards challenged projects.
.

You can fill out the survey at:

.
Ryan Cromwell
————————–

Kanban vs. Scrum: Kanban is NOT for Software Development, but Scrum is!

Last week I was a panelist at the Agile Denver meeting, where the title of the panel was Kanban vs. Scrum! The Big Smackdown!

If you click through the link, you’ll notice that the title was misleading, on purpose, as is the title of this article(“Kanban vs. Scrum…”).  However, I want to catch the attention of those who think that this is even a valid question or consideration.  The title also speaks to a common problem in the industry that has been around for several years, and won’t seem to go away.

There are a number of software teams and organizations that think they should choose between Kanban and Scrum as their software development process.  This is a GIANT and RISKY mistake, in my professional opinion.

It’s not an either/or proposition.  Scrum is about software development.  Kanban is about change management.

There are several reasons why choosing Kanban as your team’s software development process is a mistake.

1.  You are applying Kanban to the incorrect context.

Would you use a hammer to insert a screw in a wall?  You can, but you’ll probably damage your wall in the process, and the same is true of Kanban as a software development approach.  David Anderson, the creator of The Kanban Method, has apparently said this over and over again since 2005, but no one seems to listen.

Don’t take my word for it, listen to David:

“Kanban is NOT a software development life cycle or project management methodology! It is not a way of making software or running projects that make software!” — David Anderson

“There is no kanban process for software development. At least I am not aware of one. I have never published one.”  — David Anderson

“It is actually not possible to develop with only Kanban.  The Kanban Method by itself does not contain practices sufficient to do product development.” — David Anderson*

(*The first two came from the “over and over..” link above.  The last quote was sent to me via email from someone at David’s company.  I think they just pasted in something David had already written)

I should also mention that others have mentioned to me that David talks out of both sides of his mouth about Kanban, Agile, and software development, perhaps trying to capitalize on the fame and success of Agile software development.  That may be true, but it may also be true that David has been saying all of these things for years and no one is paying attention to what he says, which is unfortunate.

2.  Kanban is modeled more after the assembly line and manufacturing.  Scrum is modeled more after creative product design.

Which do you think more closely resembles software development?  Laverne and Shirley on the assembly line at the Shotz Brewery? Or the group of NASA engineers on the ground who saved the lives of the Apollo 13 astronauts by coming up with a creative solution to a problem within a time-box?  If you think software rolls off of an assembly line, then I think that it is unfortunate that you’ve never worked in a creative software development environment — it’s AWESOME!

Maybe my Laverne and Shirley reference is oversimplified.  The reason to use Scrum instead of Kanban for software development delves down into process control theory, and the difference between a “defined process” and an “empirical process.”  In short, a defined process works better when the inputs and outputs to the process are well known and repeatable (like a manufacturing line).  An empirical process works better when the inputs and outputs to the process are less known and very difficult to repeat.  No two software features are alike.  This is why it’s darned near impossible to measure software productivity directly, even though some naive “bean counters” still try to.  Like the stock market, no one metric will predict it accurately, but a range of indicators can help predict it more accurately.  So, in summary, Scrum is based on empirical processes like product design.

One of the very key parts of empirical processes is the characteristic of inspecting and adapting the product.  Think of yourself making a pot of soup from scratch, without a recipe.  Think about all of the “taste-tweak ingredients-taste” experiments(feedback loops) you would need to get a pot of soup that tastes good.

Scrum has the frequent feedback loops built in, for a variety of audiences(Dev Team, Product Owner, Stakeholders, Users) , and for a variety of topics(process-Sprint Retro, product-Ordered Product Backlog, product-Sprint Review, product-Valuable/Releasable Increments).  Kanban has no such built in loops, but again, that’s because it wasn’t designed for software development!

3.  From a Complexity Science view, Kanban is for ‘complicated’ work while Scrum is for “complex” work.

I know the Kanban folks don’t like hearing this, but I think Ken Schwaber was right when he said this, and I think history will prove him right about Kanban as it was described in David Anderson’s book.  In short, the Cynefin model defines 5 domains, of which 2 of them are “complicated” and “complex” work.

‘Complicated’ work is best solved via ‘good practice’ and ‘experts’ who can find ’cause and effect’ fairly easily. When I think of ‘complicated’ work, I think of an the IT support person who sets up your computer or trouble shoots it.  Yes, you need an expert to solve these problems, and the vast majority of the time, the steps to solve these kinds of problems are fairly consistent and repeatable.  They are not exactly repeatable, just mostly repeatable.   If the steps were exactly repeatable then they would fall into the ‘Simple’ domain of Cynefin.

‘Complex’ work is best solved via ‘safe to fail experiments’ and one can only ascertain cause and effect after the fact.  Each Sprint in Scrum is a ‘safe to fail’ experiment because, while the Sprint increment is always releasable, the business side of the house makes the decision on whether it is safe/valuable to release it or not.  In the case of an increment that is un-safe, the team course corrects and comes back with an increment the next sprint that is hopefully safe or more-safe.  These safe to fail experiments can be repeated over and over again until it’s time to release the increment.

Applying Kanban Correctly

Having said all of the above, there IS a time and place for Kanban — a correct context, if you will.  If you’ve been reading closely, that context is as a change management process, which is ‘complicated’ work, and requires that there be already existing processes in place.  So, if your software team is doing XP, Scrum, Crystal, Waterfall, RUP, DSDM, FDD, etc, then you can layer Kanban on top of it to help find bottlenecks and waste.  Also, for all of those teams out there that don’t use a software development process(framework, approach, etc) that is named in the industry, you’re probably doing cowboy coding, ad-hoc, or command and control project management — none of which is a software development process either.  So, layering Kanban on top of crap will still yield crap.

For those that want to apply Kanban at the enterprise level to monitor the flow of work through their Scrum teams (Or XP, Crystal, etc), or want to use it for IT support or Dev Ops, I say have at it and I hope it helps you.  I imagine just visualizing your workflow alone will help in those contexts.  I myself have recommended and coached Kanban for a couple of teams — but only because those teams exhibited the right context for Kanban to be successful.

Bottom Line

Having said all of this, just visualizing your workflow and the other Kanban principles is not enough for software development.  Software development has things like business value, technical complexity, and user experience/acceptance/adoption — all of which are not addressed directly by Kanban.  Scrum does address these areas, as I have shown above.  But hey, let’s not forget, the Kanban Method is “not a way of making software or running projects that make software.”  Would you criticize a hammer for not doing a good job of being able to insert a screw into a wall?

Related Articles

ScrumCrazy.com update:

  • Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
  • Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.   Contact us for more info
Follow

Get every new post delivered to your Inbox.

Join 288 other followers

%d bloggers like this: