What Developers Need to Know About Agile

How about
9. You get more feedback. ??? Having a tighter feedback loop is IMO one of the main features of agile.

Stephan,

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

I enjoy the meetings of Scrum. Unlike other meetings, they are up to the point with the progress and issues and have specific outcomes that help in the progress of the project.

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.

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

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.

I meant “code”, obviously. :-)

Wow, I’m aghast at how many typing errors there were! Let me redo it:

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.

Agile Development has great marketing lines. Countless people go on and on about how agile is great for XYZ if you just enact policy A, B and C.

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.

Stephan,

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

@Daniel Sobral

Your typing errors fit the original post, really.

@stephan: When thinking about what I’ve heard from developer friends, you are right that most of the time it’s because upper management didn’t truly embrace it.

The premise of this article : “Agile is mostly driven by managment and consultants, seldom bottom up by developers.” doesn’t fit with my experience at all. Most developers I know are trying to migrate to more agile ways of doing things and it’s usually management that doesn’t understand how to handle and facilitate this. In my experience management often has trouble letting go of the security big design up front seems to give them, they want to have a clear understanding of what is going to be done when. I’ve seen several cases where practices like TDD and pair programming were actively discouraged by management because of perceived ‘inefficiency’.

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.

Here’s another thing that developers need to know about Agile, it’s designed with a “team of outstanding developers in mind”. E.g. everyone on the team has to be a very bright developer, slackers are not permitted and can be easily caught. This, of course, will put a huge stress on the developers at the beginning of the adoption phase. Agile has its limitations, and these limitations greatly affect developers and their perception of Agile.

I clearly love agile. Agile belongs to a set of modern company organization tools that has something to do … yeah with brightness.

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.

[...] What Developers Need to Know About Agile (codemonkeyism.com) [...]