Scrum

Response: Agile's Second Chasm

Malcolm Anderson — Tue, 22 Feb 2011 07:00:17 GMT

William Pietri over at Agile Focus has written an interesting article entitled, "Agile’s Second Chasm (and how we fell in)" in which he talks about how agile development has fallen into a common trap where large companies are now spending a lot of money hiring agile (Scrum) consultants just so that they can say they are agile, but all the while avoiding any change that is required by Scrum.

It echoes the questions that I've been asking for a while, "Can a fortune 500 company actually do agile development?" I'm starting to think that the answer is "usually not"

William ask 3 questions at the end of his article that I will answer here.

1) Have I seen agile development brought in and then preemptively customized (read: made into ScrummerFall)? Yes, Scrum is hard and disruptive. It's a spotlight on company dysfunction. In a low trust environment like most fortune 500 companies Scrum will be subverted by anyone who has ever seen "transparency" translate into someone being laid off.

2) If I had to do it all over again, would I change anything? No, this is a natural progression, but the agile principles are powerful enough, that the companies that don't adopt them will no longer be competitive and will start to fail.

3) Is this situation solvable? I think it is.

I think that one of the issues is that you often see companies implementing Scrum, but avoiding the agile engineering practices. I believe that you cannot do one without the other. Scrum keeps the ship sailing in smooth deep waters. The agile engineering practices keep the engine running smoothly and cleanly.

If you implement agile engineering practices without Scrum, you run the risk of ending up with a great running piece of software that is useful to no one.

On the other hand, implementing cargo-cult Scrum without the agile engineering practices and you end up (especially in a fortune 500 company) being steered in the right direction, but with your development practices coming to a dead halt because you have code that can not keep up with the changes in requirements.

If you are trying to do Scrum, make sure that you hire some agile engineering coaches, or else you may find your deveolpment engines grinding to a dead halt in the middle of the open ocean.

Scrum Product Owners Oath of Stewardship

Malcolm Anderson — Thu, 02 Dec 2010 05:58:34 GMT

There's an interesting discussion going on over on the Scrum Development list, dealing with technical stories verses user stories. The idea is that "Improve our continuous integration server" may not directly translate to visible functionality for a customer, so how do you handle this in Scrum. It's a conversation that pops up regularly and there are a couple of schools of thought on the subject. I'm not going to get into here.

In the midst of this discussion I jokingly (sort of) made a reference to the "Product Owners Oath of Stewardship."

right after that Alan Dayley pointed out that

Phrases seen in Scrum writings with regard to the Product Owner role: "...owns the ROI of the product..." "..represents the customer..." "...owns the Product Backlog..." and the odious "...single wringable neck..." And even the title of the role means *owner* of the product.

What part of these terms does not mean stewardship? You are pointing out that Product Owners are not getting the message, *despite* what the Scrum training and literature states. Maybe an oath would help but I don't think the message of product stewardship is lacking in Scrum.

When Alan pointed out that we imply Stewardship, but never actually use the word, it was like a gong going off in my head (or a badly aimed claymore). When talking with product owners, If we don't explicitly set an expectation of stewardship, then *none* of those terms will mean stewardship. Right now, there are teams out there that are begging to add some unit tests, begging to set up a continuous integration server, begging to try paired programming and they're getting shot down because it might slow *this* sprint down.

So what is Stewardship? Well, to cherry pick from Wikipedia "Stewardship is an ethic that embodies cooperative planning and management of environmental resources with organizations, communities and others to actively engage in the prevention of loss of habitat and facilitate its recovery in the interest of long-term sustainability " It's a little wordy, and it's specifically focused on physical environments, but for now I think it's the one I'm going to keep.

At this point, I've got to at least post version 1.0 of this thing, if nothing else because when the movie rights get sold, I don't want some kid in the audience saying, "that idiot should have blogged about right away"

So, tongue in cheek, here goes, version 1.0 of "The Product Owners Oath of Stewardship"

As a product owner, I have a responsibility to my customer to deliver the most value in the shortest time possible. I have a responsibility to show the customer working software and demonstrate new functionality every 1 to 4 weeks.

As a product owner, I am a steward to my product and therefore will listen to my team when they start to talk about refactoring and continuous integration servers. I will accept that my team is also committed to the long term sustainability of our product and weigh their suggestions accordingly.

As a product owner, I will balance the need to deliver software ASAP, and improving my teams software development environment and practices while knowing that these are not mutually exclusive activities. I will support my team in doing smart refactorings, and to allow the product backlog to suggest where improvements might be made.

Not so funny now is it?

Scrum Case Studies - A reference

Malcolm Anderson — Wed, 10 Nov 2010 16:11:59 GMT

The main point of this post is to create an easy (for me) to find list of scrum / agile case studies.

And here it is:

http://agilepainrelief.com/notesfromatooluser/2008/11/scrum-case-studies.html

There is one specific entry from British Telcom that is especially interesting for those in the telcom industry

http://www.magneticreason.com/information/articles/agiletrench.html

Fortune 500 Scrum Coaching for the developer turned Scrum Master

Malcolm Anderson — Sun, 03 Oct 2010 04:16:38 GMT

The next Scrum Gathering is coming up and they are having 6 TED style talks.

You can help make history by voting to have me present one of those talks

I can hear you saying, "Well sure, Malcolm, what can I do to help you?" I'm glad you asked.

It's really simple, click here sgnl.uservoice.com/forums/73997-bare-talks/suggestions/1105851-fortune-500-scrum-coaching and cast 3 votes for my talk "Fortune 500 Scrum Coaching for the developer turned Scrum Master."

Scrum adoption in a Fortune 500 company is very different than Scrum adoption in a smaller company.

If you came to Scrum through a project management background, there will no surprises in this talk. If, however, you came to Scrum from a developer background, get ready for some counter intuitive surprises. I'm going to talk about some realities of navigating the waters of a large company and explore a few things that I wished I had known about sooner than I did.

Why Fortune 500 timescales are paradoxical and how to take advantage of them.

Why your superior solution will always be rejected at every possible turn.

Why Agile Engineering must be avoided for as long as possible.

Scurm, the ultimate "Command and Control" framework

Malcolm Anderson — Sun, 15 Aug 2010 05:41:53 GMT

"Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity."
George Smith Patton

We talk a lot in the agile development circles about something evil and bad called "Command and Control." I've found that most people believe that the term comes from the military and that it means "massive top down planning combined with myopic micro-management."

It's true, the term does come from the military, but the concept was meant to describe the effective foundation of the military separation of responsibilities. To overly simpliy things, in the military, it's the the officers job to command (give the what), and the control (the how)is left to the enlisted personnel.

This can be illustrated by a simple mental leadership test I learned from my USMC recruiter many years ago.

You are a lieutenant who has been given the task of raising a flag pole.

You have at your disposal, a flag pole, a sergeant and 7 privates.

How do *you* get the flag pole raised?

The correct answer, of course, is, "I say to the sergeant, 'Sergeant, get this flag pole raised and report back to me when it's done.'"

I can hear you asking, "So what? What does this have to do with Scrum?"

Well, I'm glad you asked. Scrum fleshes out and leverages command and control in its original meaning. The business owner works with the product owner to determine what the business owner wants. The product owner then goes to the scrum team and asks, "Get this done, and show me demostratable progress every 2 weeks"

By using the Scrum framework (ask me why you should *never* call it a methodology) you can leverage the power that comes from separating these two responsibilities. You as the business owner can focus on the high level "whats" and the development teams can focus on a slightly lower set of "hows".

The nice thing is, that if you have the discipline to hold that separation, Scrum can scale easily.

The dangers of “No Impediments”

Malcolm Anderson — Thu, 15 Jul 2010 22:26:07 GMT

I’ve noticed that there is a disturbing tendency on some agile development team to use the phrase “no impediments” as a verbal period during a daily stand up meeting.

Have you ever heard a report out that sounded like this. “Yesterday I said I was going to finalize the business object translator and then update the 3 screens with the new color scheme. Well, I’m still working on the business object translator as it turned out to be a bigger issue than I thought, plus of course, we had that emergency meeting on the new expense reporting system. I’ll get that object translator done today. No Impediments”

Anyone want to take a shot at why the rest of the team should be taking a great deal of notice about this?

I’m going to be writing a few posts on what beliefs, behaviors and assumptions can cause this type of visibility destroying report out to happen, why it's a problem, and how you can reverse this trend and get back to a culture of visibility.

Projet Doneness and Einstein's Razor

Malcolm Anderson — Fri, 18 Jun 2010 02:55:54 GMT

I’ve started working on a series of articles about the value of having testers involved in requirements gathering. Today I was reminded of a useful tool that has provided value to me for at least 20 years. To those of you who already use this tool, I’m interested in your stories where it has made a difference for you, and to those of you who have never heard of it, I hope sharing it will make a difference in your careers.

I was reminded of it because I just finished a 3 month set of personal projects and was reviewing the success of those projects while putting together my next set of 3 month projects. During this review, I noticed that a good number of my projects did not have the level of success that I wanted. The results were good, but they could have been better. Then it hit me, I didn’t have clear enough doneness criteria. As a Scrum Practitioner, I wouldn’t think of running a sprint without reviewing the backlog with Einstein's Razor, so why wouldn’t I do the same for my own projects?

I can hear a few of you asking "What's Einstein's Razor?"

I'm glad you asked. I was once told that Einstein told an audience, "If you can't explain what you do to a relatively bright six year old, you probably don't understand it yourself."

This quote had an impact on me, especially early in my career as a solo developer. At the time, I was mostly doing end to end software development. I found that I saved myself a lot of pain and trouble by turning that quote around to “If you can't explain your project's doneness criteria in such a way that a relatively bright six year old can't competently determine your projects success or failure, then you have not broken it down to a fine enough level.” There are more negatives in that quote than I’m happy with, but it still gives me tons of value to this day.

In your opinion, in your current projects, could a 6 year old competently pass or fail your next sprint? What risks are you running if your answer is “No” ?

The only metric with any value

Malcolm Anderson — Mon, 19 Apr 2010 17:20:08 GMT

There's a lot of talk in the Scrum world about metrics. What's the velocity? How big is a story point? How many story points is that team producing per man hour?

People are sadly missing the whole point. Take your measurements up a level or two. When you get down to it, the only metric that makes any difference, is ROI.

The problem is that often times, the developers work in a dark hole, far removed from the realities of how exactly they get paid. A bigger problem is that mid-level managers tend to be further removed from the realities of ROI. A lot of times mid-level managers get tasked with tracking their teams "productivity" using things like, "lines of code", or "completeness of the productivity reports."

Monetize your projects and then track your velocity against business value (real dollars).

When your development teams can say, "Last year, our team cost the business 2 million dollars and we know that because of our efforts, the company saved 2 million dollars in waste and increased revenues by another 4 million dollars." At that point you have just moved your development team from a cost center, to a profit center. You might have to give them a raise, but they have demonstrated that they have earned it.

Scrum won't help the nosey CEO

Malcolm Anderson — Wed, 09 Sep 2009 16:02:03 GMT

I've seen it come up in discussion groups time after time, the management wants to measure productivity in their development team and developers just want to be left alone to code. Recently some one asked:

> Maybe it's also time for a frank discussion of "What does the CEO
> *really* need" for visibility? Is it really metrics that do not make
> any sense (and costs a lot to collect)?

No, it's time that we turn this question on it's head, because it's not "What does the CEO *really* need" for visibility?. The CEO's job is to maximize profits for the shareholders, anything else is a dereliction of their duties, he or she really *does* need visibility.

The question is, how can we turn the development team into a profit center? This is an ongoing issue in the corporate world where IT typically falls under the CFO rather than the CEO.

We as development staff have to remember, CEO's care about raising profits, CFO,s care about cutting costs. We as development staff have trained CxO's that software is unpredictable and mysterious, so naturally, they apply dilbert-esq techniques to it hoping to fix it.

Maybe it's time for a frank discussion of "What can we do to help the CEO with his or her goals of increasing company profits?"

Scrum is not going to help the CEO, at least not directly, but if you have an agile coach helping developers to start taking the profit question seriously then scrum could provide a fast road to moving software development out of the shadows and into the strategy sessions where it belongs in an information age.

Joining the let's-find-out club

Malcolm Anderson — Tue, 01 Sep 2009 11:42:06 GMT

Joining the let’s-find-out club

When it comes to a new idea, a mentor once told me that my feelings and past experiences are lousy tools for evaluating that new idea.

What he said was something to the effect of, “You need to join the let’s-find-out club. Will that idea work? I don’t know, let’s find out”

At the same time, if you are using someone’s already successful system and that system has worked for others, but not for you, just maybe, you’re not really following their system.

And don’t say, “but we’re different here.” No you’re not, you’re just unwilling (or in some corporate settings, not allowed) to make the changes dictated by the successful system.

I once heard a trainer explain

If I told you to dial (555) 123 – 4567, give my friend on the other end your name & address, and he’ll send you a check for $100, don’t come back to me and say,

“I tried your system, and it didn’t work, I didn’t dial the number in the order you gave me, but I dialed all the numbers”

“I tried your system, and it didn’t work, I didn’t use the number 4 because I don’t like to press the number 4, so I just replaced it with two 2’s.”

“I tried your system, and it didn’t work, I put in the first 6 digits and didn’t get any result, so I didn’t bother to finish implementing your system you fraud.”

Laugh, but I have watched people, at great expense, implement their version of other peoples systems and then complain that not only did the original system not work, but that the people explaining the system were unyielding zealots who didn’t understand how things worked in the real world.