I have seen people grow because of agile, who were not so present before. Agile, properly done, gives you one thing: A big bunch of people who take over responsibility for your company. And this alone gives me an environment were I love working in.

Upper management often ignores Scrum/Agile or has problems, mostly with the up-front-aspect.

““What managers need to know about agile”

Just take any agile book or agile text, it’s usually written for managers.

I think you won’t get far telling developers “everything is going to be fine”, like you seem to be doing and then let managers, or even worse, external consultants do the work. The way I see it agile is development centric. I think you’ll get a lot further with developer driven agile adoption with management buy in than management driven agile adoption with some developer buy in.

Maybe you should write a blog post with “What managers need to know about agile” instead.

Your typing errors fit the original post, really.

Nice post! At our company, agile/scrum was introduced by developers. Those of us on the management side had to play catch-up, which we did. I’m a big fan of agile/scrum, and I just recently blogged about the benefits of agile from a management perspective. I’d be interested in your take.

http://softwareresults.blogspot.com/2010/02/achieving-higher-productivity.html

Regards,
Dave Moran

I was yesterday at my old employer (the biggest real estate portal in Germany) who migrated 150 people to Scrum. After a survey nearly noone wants to go back to waterfall. There are problems in Scrum, but the alternatives (in the domain of websites) are far worse, and include budget overruns, frantic movement of developers to the currently most important project, crunch time crunch time crunch time, missed deadlines.

“Stephan, I couldn’t tell from your post, but are you speaking from first hand experience of actually being part of a real life implementation of these techniques or are you just parroting what you’ve learned about the practices”

My agile/Scrum story is this:

Started playing with XP when the first XP book was published, then done consulting work on agile (XP), then became an CSM and did Scrum with a group of students for dev projects, then moved to IS24 and introduced Scrum with some others, became ScrumMaster there and converted a team, moved to brands4friends as head of development and introduced Scrum. In all 3 usages over the last 5 years most of the stakeholders have been happy (some not, as they lost power, influence, control or other things). Not sure what you make of this experience, I lack years of agile as a developer, but talked to several dozens over the last years (those on my teams and others).

However I’ve heard horror story after horror story from actual developers in companies that have tried to adopt Scrum or other Agile techniques and failed in a most spectacular way.

It seems like it’s a very fragile thing and could easily do far more harm than good.

From the success stories I have read, they almost always caveat that they only adopted some of the practices because they found that some just didn’t work well.

Stephan, I couldn’t tell from your post, but are you speaking from first hand experience of actually being part of a real life implementation of these techniques or are you just parroting what you’ve learned about the practices?

It all sounds good, and as a developer it’s easy to read things like this and get excited about it. But it smells a bit like fish oil to me.

You can’t over-emphasize this: Agile is about working, high quality code.

Pretty much everything in Agile either is there to achieve that, or can only work if you do achieve that.

And this is the reason, by the way, why SCRUM so often fails without some good best practices on the technical side.

“Which, by the way, is why SCRUM without some good best practices on the technical side so often fails.”

I agree.

Pretty much everything in Agile either is there to achieve that, or can only work if you have do achieve it.

Which, by the way, is why SCRUM without some good best practices on the technical side so often fails.

Having a sprint actually puts more pressure on the developers to develop something to show. However making it a team effort enables developers to get help and provide help for anyone who needs it.

Thanks for this helpful summary for developers coming into agile.

The agile community deserves pats on the back for making developers happier (by humane treatment) and enabling developers to become remarkably efficient at delivering software (by giving them the tools to release confidently). As a developer, I can attest to both being a revelation that made me happier and less cynical about my work.

Developers coming into agile can look forward to becoming quite good at Delivery.
It’s worth mentioning that the area of agile that’s poised for evolution is what post-agilists Jeff Patton and David Hussman call Discovery. Discovery is something we’re not so good at yet.

Discovery is understanding what represent value to your users. I believe we’ll also see the merging of the agile and the Interaction Design or User Experience communities (e.g., see Alan Cooper’s work)

Agilists have relied much too long on a largely clueless proxy to our users known by various names including “Product Owner”, or the more nebulous “The Business”. From practice, many developers have come to realize that these well-meaning folks set our priorities based on notions and whims rather than customer data or direct investor return. None of us, developers included, have spent enough time considering what our user community or our bank-rollers value about our software.

Our community claims to measure something we call velocity, when it’s really just speed. The direction component in velocity is lacking.

“If you don’t know where you are going, it’s easy to iteratively not get there.”
~David Hussman, Nov 3rd, 2009 from TweetDeck

For those coming in green to Agile, you’re going to like it. Be prepared to have fun becoming more efficient, more accountable, and more collegial & collaborative.

None of the books or blogs will tell you that you also must prepare for focusing on what represents value to users and investors in the product you’re growing. And ways to *verify* customer/user value. If we’re delivery junk, who cares how fast we can delivery it?

Cheers,
Bob