BT

Right Way(s) of Doing and Being Agile

by Ben Linders on Jan 10, 2013 |

Debates are being held in agile communities concerning when your are agile, and when not, and about the right way(s) to do agile. In the blog post you’re doing better than you think, Jason Little shares his view on how to deal with people who are telling you about how to do or be agile:

The agile community is quick to point out what’s wrong with what your organization is doing. You’re ‘doing scrum wrong’, you’re ‘doing’ agile, not ‘being’ agile and other bullshit like that. What about what you’re doing right?

Agile, in his opinion, is not about “doing agile” or “being agile”, but about changing behavior and making progress:

I know progress is being made because I see differences in behaviour I didn’t see months ago. I know progress is happening because people tell me stories about life a year ago vs today and how much better work is.

Jason suggests to look at things that are going right, and to take pride in them:

I don’t think organizations take enough time looking at what’s going right because at every turn some pundit is telling them they’re doing it wrong. (…) The people in the organization I’m at now should feel extremely proud of the progress they’re making (…) Keep your head up, I’m proud of all of you.

Tommy Bryntse wrote a blog post what is agile, where he takes a critical look at organizations that say that they are agile. He gives his opinion what agile is, and when you’re not agile:  

Agile is what the Agile Manifesto values. It is also the twelve principles behind the manifesto. Nothing more. (…) Being Agile is following the manifesto values and the principles behind it. If you don't, here's some news: You're not Agile!

He suggests to stop saying that you are doing agile if that is not the case, and provides a list with interpretations which can tell you that “you’re not agile”

Please stop saying you do Agile Development based on having a daily standup meeting and a board with your stories divided into tasks. (…) To be Agile you need to be able to check the list above on how you're not Agile... and if you're on the list, you're not Agile. That being said, I don't want you to stop doing the practices you're doing. They are good practices, which will help you deliver better software. Just stop saying you're doing Agile unless you really do.

In the InfoQ interview are agile teams truly agile? with Jeff Sutherland, he looks back on ten years after the agile manifesto. He shares his opinions on if you are agile or not:

(…) getting working product at the end of a sprint is challenging and impossible for about half of the Agile teams out there and as we discussed that that is so critical it’s fundamental, you’re not even Agile until you can do that.

Jeff also gives some examples of how to use scrum, and of good and bad scrum:

(…) good scrum is 10 times as fast and people have data that shows that.

The first thing [of doing Scrum well] is that they need to get to the end of the sprint with software that’s shippable. (…) The other most important thing is the backlog coming into the sprint. If it’s not in a ready state, if it’s not clear, if it’s not sized properly, if the team doesn’t understand it, they can’t estimate it, if they don’t have acceptance test.

Ken and I took Scrum and implemented it in software and we used all our software knowledge but it turns out that if the Scrum isn’t Lean it’s a bad Scrum. As soon as you start Lean-ing it out you start removing waste from the system. Scrum is all about removing impediments which is the same thing as removing waste.

In the blog post the baby and the bath water, Jim York looks at how to deal with the many practices, tools and techniques that agile has. He advices on how to decide which agile practices to use:

A basic premise of Scrum is that if what you are doing is working, keep doing it. The flip side of this premise is that if what you are doing isn’t working, change it. Scrum doesn’t prescribe which Agile practices to fit within its framework, but rather leaves those decisions up to a self-organizing team to figure out.  This “figuring things out” is the hard part of doing Scrum.

He suggest that organizations should discovers themselves what agile is, by learning what works and what doesn’t work for them:

I like to think of Scrum as an accelerated learning framework.  Each sprint is an experiment, a learning opportunity. (…) the organization learns something about the process that they used to create the product increment. The results of this learning should be seen in the changes made to improve the process going forward.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT