Things you can Check when Adopting Agile
- Share
-
- |
Read later
My Reading List
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:
- An Agile Self Evaluation provided by ThoughtWorks
- An agile readiness questionnaire on PM Gadget
- The InfoQ article Scrum hard facts: roles. artifacts. all meetings, which provides a Scrum checklist
- The InfoQ minibook an agile adoption and transformation survival guide, which includes a checklist for change agents
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
How do we measure
by
Louis Giokas
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
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
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!
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013
Hello stranger!
You need to Register an InfoQ account or Login 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