When is Scrum Not Scrum?

I must admit that I'm surprised with firing somebody from Scrum Alliance for not following "the only and true path of Scrum". I agree with most Tobias practices - I also use different sprint/iteration lengths for different projects, I also changed the original Scrums's backlog into something a bit easier to maintain that suits better our projects, and so on.

I think that this leads us again into discussion about agile certification. I don't really care if I use one particular methodology. I prefer to adapt only the practices that I really need to deliver software faster with better quality. Scrum gives us great guidelines, but if I find something outside of Scrum that can suite my team better, I'll follow and leave Scrum behind. This is agile to me.

Marcin

I fully agree with what Tobias says in his blog. There appears to be a marketing phobia around Scrum these days and the Scrum Alliance oblivious of their enthusiasm soon would take themselves into a counterproductive mode.

I used to like many things in Scrum and found that many practices in it were imbibed from the rationale in TOC (Theory of Constraints, TOC Thinking Process and Critical Chain Pradigms). Therefore they were very practical.

Today the Scrum Alliance appears to have made a mockery of this great system by touting a 2-day Certification Program and to me it looks a total farce of making a fast buck. The so called certification program adds no value. I wish Scrum Alliance took accountability and responsibility for those they certify as official Scrum Masters and Scrum Trainers. I remember reading with great interest, Kent Beck writing about certification in his XP Second Edition and how accountability should play an important role where the certification organization takes responsibility and accountability for those certified and the value add caused by such progarms.

I have been practicing, coaching and training in XP and other Agile Methodologies for over 6 years now.

Hope someone from the Scrum Alliance takes note of this and stop the Fanatism and Sales Pitch that they are creating around it. They may end up killing the great valuable Golden Goose in their effort in trying to cash-in on it too fast by unethical advertising and PUSH SALE.

All Agile Methodologies profess that Customers should Pull Value. You cannot force it down their throat and make money out of it.
I donot see a win-win for people attending the Scrum Master Training programs all around the world paying through their nose for it and falling into trap of yet another rat-race run by the Scrum Alliance

While I don't begrudge the creators of an agile practice a chance to earn money from their work, I also recognize that this push for "standard agile" isn't being done for my benefit, much as they'd like me to think so.

I'll twist, mutate, fold, spindle, and mutilate Scrum as much as I need to to fit the team I'm working with and the environment they work in. If the Scrum Alliance doesn't want me to call it Scrum, too bad.

Everything that he is recommending is already in XP. So, if scrum doesn't want him, we (The XP community) will take him ;-)

To be clear, I wasn't kicked out of the Scrum Alliance for challenging the process (other good Scrum coaches do the same), but for challenging the Scrum Alliance leadership on issues of transparency and accountability. I believe that an organization promoting Agile methods should be run according to Agile principles. Anything less would be (and is) hypocritical.

Then I'm yours. I am an Agile mercenary :-)

If the core Agile principles are respected and integrated into all that you do this is a great approach. If they are not, it is likely you will end up back with a process that resembled what you did before Scrum, or perhaps is worse. Just a cautionary note. The principles drive the practices.

Tobias, thanks for adding your comments. The principles do indeed drive the practices; hence the inherent ambiguity around what it means to be an "expert" agile practitioner. And so then how do possibly hope to certify this in any meaningful way?

Whether we're shopping for programmers, plumbers, doctors or agile coaches, when we're signing a check, all of us would like some way of knowing that we're getting what we're paying for. Unfortunately, there's never a substitute for shopping around until we find a service provider that works.

Tom Gilb talks about a philosohpy called "No Cure No Pay". Going by that, the least the Scrum Alliance can start as a part of the Certified Scrum Master (CSM) Program is to ensure that Potential Employers of CSMs are able to provide feedback on the quality and ability of the CSMs they employ to Scrum Alliance over a transparent website that is visible to all.

It is very easy to print certificates and collect money. It needs a high level of commitment to make sure that Value is delivered - to the person, to the employer and to the industry, if that was the intent of the program. That's what we learn in Agile. People who preach have to practice it first to retain and build the credibility they need for others to trust them.

This may also help evaluate if the CSM program is truly adding value to the industry practicing Agile.

Scrum is for a dumb manager who can understand it in 60 mts and start implementing it the next day without any frills..... and get to see how dumb they are and how dumb their team is within one month. This starts a retrospective and initiates a self driven "systems approach to continuous improvement". Scrum is an intelligent repackaging and extreme version of Theory of Constraints (TOC), TOC Thinking Process, Critical Chain Paradigms (Haystack and Student Syndromes).

I heard Ken Schwaber on the latest goggle video and he almost says the same thing in his lecture on Scrum to Goggle Managers. He used TOC words like Throughput and Inventory several times indicating where his inspiration for Scrum originated.

XP is for the intelligentia and the intellectuals. It is more a philosophy of Agile Values and Principles than a set of Prescriptive Practices like in Scrum. It takes a long time to internalize within an organization and needs tenacious and committed people to make it work and cause the cultural change in deep rooted tradtional management paradigms. XP is PURE in its rationale and a flawless theory for Agility to succeed. It is not something that is a quick fix like Scrum.

May be Scrum will finally help people understand XP better. Scrum is for starters while XP is for those Agilists who have understood Agile. Scrum is a like a Candy that you can pop in and start chewing it immediately. Then quickly discover that it is not tasty and try the next one...and keep doing it till you find a Candy that you relish. XP is like a 15 course meal that takes some time to carefully prepare before it can be served and relished.

This is what I have found in my 6 years of experience in working with organizations trying to transition to Agile.

wow - what a great statement about having no clue what Scrum is about.

Am I dumb or not ? I have used 2 years implementing both SCRUM and XP. Since I am a manager I guess I am dumb and my developers are intelligent. Funny this works out fine.

Isn't XP 13 cources ? You havn't been drinking too ?

I agree with what Tobias says, but the fact he sees a need to say it at all raises questions about how Scrum is practiced in his organization.

Product Owners are definitely supposed to be pigs. Who said they weren't? They make most of the key decisions. How could they do so if they were disconnected from the team? The most successful agile projects I've been on have enjoyed very close involvement by the PO - sometimes daily.

There is no "rule" about 30 day sprints. Most projects I work on use a two-week iteration length. I'm currently on a project that has a 3-week iteration length. The most effective iteration length depends on the circumstances of a particular project. The one-month guideline is based on the fact that most businesses operate on a one-month "pulse". People can adapt easily to things that happen on a monthly cycle, and this may include things like incremental delivery and demonstration of software under development, and iteration planning meetings, and so forth. It may include those things, and maybe not. No big deal either way.

There's nothing in Scrum that "insists" anyone record the hours they spent on tasks. When this happens, it is a throwback to Gantt-style management methods. It has nothing to do with Scrum.

Taskboards are great as information radiators in the immediate physical environment of the project team. I tend to favor the simplest possible tools - cards, taskboards, whiteboards, etc. But there are times when electronic tools are useful, too. Not everyone who has an interest in the project may be in a position to see your taskboard every day.

Backlogs on the wall - great idea. Where does Scrum say you shouldn't do it?

Estimation meetings - great idea. Where does Scrum say you shouldn't do it?

Agile engineering practices are out of scope of Scrum, which is (by intent) a lightweight management process wrapper and not a "methodology". In my experience, combining Scrum with XP has yielded the best results for software development projects. Other methodologies can work well with Scrum, too. Why should Scrum "insist" on any particular methodology? Scrum is only one tool among many we can apply to software projects. It is unnecessary for a single tool - any tool - to try and be all things to all people. Each tool should just do its own job. Scrum does its particular job very well indeed.

ScrumMaster role - wouldn't it be pretty if there were a lot of self-organizing teams that actually organized themselves? I think that's a beautiful long-term goal for our profession. In the meantime, the ScrumMaster role (even if by another name, such as "process facilitator" or "team coach" or what-have-you) is not only necessary, it is a critical success factor for agile organizations.

Like many who commented, I agree with the sentiments Tobias expresses, but I disagree that the dysfunctional practices he mentions have anything whatsoever to do with "standard" Scrum.

I was about to comment on this thread in some detail but then came upon Dave's comments. After working with Scrum and XP in three different organizations I would pretty much echo every point Dave made. In my experience, bringing Agile into an organization boils down to taking a set of principles (and associated practices) and tailoring them to fit the context and then being committed to remaining responsive to change the process as the team and circumstances (internal or external) change.

As a CSM-Practicing, my view is that most of the items listed above do not diverge from "standard practice". They are very good ideas, and I commend Tobias for his focus on them. If by "practice" Tobias means that these things are not actually done enough by Scrum teams (I am pretty sure that's what he meant), well, I don't feel any of us knows a wide enough range of teams to know that for sure. Certainly we agree that they should be doing those things, as fast as the team can absorb that learning and change.

I might quibble about the comment on tasks in hours. Some teams actually prefer this. But not major in any case.

And I would typically disagree about not needing a ScrumMaster. My metaphor is...have you seen a Super Bowl team fire all coaches the next year? Or any basketball team not have a coach? Now, I can imagine specific teams and specific SMs, where we have oil and water, and better for the two to part ways. But a team that won't be coached by any SM is not likely to become a really good team. (And I sympathize with that team too, because I imagine that they are rebelling against "managers" of any sort because they once had a bad one (or three). And they see any SM as just another bad manager. Once burned, twice shy.)

Yes, the team can and should self-organize (and why was the SM ever in the way of that?). Still impediments never go away. There is always the next one. "The relentless pursuit of perfection" is, I think, a Toyota tagline. The coach serves the team in that way.