BT

Things you can Check when Adopting Agile

by Ben Linders on Jan 03, 2013 |

 An agile checklist can be helpful when adopting agile in an organization. From the blog post a corporate agile 10-point checklist by Elena Yatzeck:

(..) I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.

Her checklist covers various things which can be considered when implementing agile. Some of the things on her checklist are:

Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.

Auditing.  If this is working correctly, you should always know what is going on, because you are there for it in person during the release planning phase, and you can see the plan and execution to plan in the project dashboards for your work streams.

The last item on the checklist from Elena discusses what it takes to use agile, and how to deal with advices:

Beware of Zealots.  (…)  Any time you see the words “it’s just not agile if…” you should beware.  Agile offers a lot of opportunities, but to benefit, you need to start with common sense, experience of human nature, technical expertise, and a lot of pragmatism.  You should never accept advice unless the person giving it to you can tell you why it would benefit you to do so.

In the blog post do scrummasters need agile checklists?, Alan Dayley discusses the pro’s and con’s of agile checklists:

There’s a constant debate in agile circles about checklists. Should we create them and follow them strictly or shouldn’t we?  They’re recognized as helpful by some and called evil by others.

Alan goes into the benefits and dangers of agile checklists. He concludes that checklist can be valuable, and suggests to use them as agile thoughtlists:

I see checklists as a tool for thinking about your process. Sure, they’re a reminder to do things you may not yet have as habit, and yes, they can be helpful to new teams or individuals new to agile processes. However, we need to think about the value each check item brings to the customer and product.

If you use them, include thought, every time, with every step. And don’t be afraid to change them as needed! Heck, even drop them completely if they’re slowing you down.No matter where you lie on debate over using agile checklists, maybe the solution to the endless battle is to simply refer to them as agile thoughtlists. A reminder in and of itself to always think through whatever it is that you’re tasked with.

There are several other agile checklists available, similar to the corporate agile 10-point checklist by Elena Yatzeck, that can help you to assess your agile implementation. Some examples are:

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

How do we measure by Louis Giokas

It is fine to have a checklist, but who is giving you that checklist? What is their experience and success? I ask this becuase we have very little real statistical data regarding the differences between agile and other types of development. I also ask it because I have seen other such trends in business that are really not backed up by data that turned out to be false (indeed one was a real hoax). The hoax was Business Process Re-engineering (BPR). I worked at a software company whose consulting are was caught up in this "movement". During this a guy came work with us who had worked for the authors of the book that defined BPR. He related that the primary author told him it was all unsupported. Over time, organizations found they were not reaping any benefits. The hoax died. Now I do not expect there is such a situation here, but the truth is, when I have tried to look for real evidence of improved efficiency or quality, I do not find it. Either the projects are too small or, most often, the mass of statictics and measurements used on agile projects are not available for the previous methodologies. This does not invalidate agile, and I am not trying to do that. What I am interested in is the real impact, with some scientific backing.

I also saw something on this site that really threw me. In general, it was an observation that user stories may not be a useful or optimal way to design the software. Over 20 years ago I worked in a large software engineering shop and one of our new employees was working on his masters. He was looking at HMI devices. The question was asked, which device, or menu system, do you think you will be more efficient at. They were then measured at real tasks. There was no correlation between the user's preference and their actual performance. Asking users is not the way to go. Rapid prototyping and measurement are required to come up with statistically significant decisions.

What we really need is to bring back the science and engineering aspects of software development to this question. The agile manifesto was a response to a problem. It is not necessarily an optimal solution.

Re: How do we measure by Ben Linders

Louis, thanks for your reaction. I recognize your worries, there is very limited data on the results of agile. One news item that was published a few months ago on InfoQ, Evidence of Success of Agile Projects, mentions the results of some studies on the effects of agile software development.

I'm interested in any other studies on agile, there is a need for evidence. If you know studies on agile that have been published, please share them with me!

Re: How do we measure by Elena Yatzeck

Ben, thanks for posting the "evidence of success" link. I hadn't seen it. I really like Michael Mah's work.

I would add in answer to Louis's question that my checklist assumes (but does not discuss) that a business case has been made to try agile, based on a quantified and sketched out expectation for how some particular agile practices will provide improved quality, speed to market, faster risk identification and mitigation, transparency in general, team morale (and reduced turnover), and/or customer satisfaction.

Of course I agree that lots of people do jump into agile just because it sounds cool. For that type of person, the checklist would not be helpful, and might even be harmful, because to me, that person is lost in the first place, and who knows what will happen!

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

3 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