George Dinwiddie has written an excellent blog post about Agility Versus Predictability. In this post, George challenges the idea that traditional (waterfall) software development projects are more predictable than agile projects. He also give a very clear explanation about how to do Agile Release Planning. Kelly. Photo by bb matt
Several years after I first encountered it, I still find MoSCoW one of the easiest methods for prioritization… The MoSCoW approach to prioritization originated from the DSDM methodology (Dynamic Software Development Method), which was possibly the first agile methodology (?) – even before we knew iterative development as ‘agile’. MoSCoW is a fairly simple way to sort features (or user
A while ago I wrote about a fairly simple technique explaining how to prioritise quickly and intuitively… Following this blog post, I got into an email discussion with Scott Sehlhorst from Tyner Blain. He extended the idea brilliantly, which I blogged about. His idea was to make the approach more quantitive, using business value as one dimension and size/cost as
Projects are a necessary evil 🙂 But necessary they are. Some people really feel the need to understand precisely what the project will cost and exactly long it will take. If this is the basis for investment, of course that’s a completely understandable feeling. For years, traditional waterfall projects have been sold on the false pretense that projects are predictable.
A software release may result from multiple iterations (or ‘Sprints’ in Scrum). Sprint Planning is about planning what’s included in the next iteration. Whereas Release Planning is about planning multiple Sprints, in order to predict when a release (or releases) might be delivered. Release Planning is a very simple way of doing some top-down planning. Much less complex than a
If we accept the above formula, why in non agile development methods is there so much emphasis on analysis, planning and change control? High level planning, such as a feature list (or Product Backlog in Scrum), and an outline plan based on the affordable team size; Yes. Otherwise you’ve no idea what you’re in for. But a detailed specification and
In a few entries on my blog, I have referred to Velocity and only briefly explained what it is. I think it’s about time I explain properly for those not familiar with it. Velocity is terminology from the Scrum agile methodology and is basically the same concept as Earned Value in more traditional project management methods. This is how it
One technique used by agile development teams is the idea of estimating product features using points. This has a few distinct advantages over estimating in physical units of time. 1. Estimating is very quick because it’s an intuitive estimate of a feature’s size. 2. An estimate in points indicates a feature’s size relative to another, and does not give the
I recently posted an entry on my blog about how to prioritise quickly and intuitively. I presented a 2d matrix with importance (business value) on one axis and difficulty (effort/complexity/cost/risk) on the other. It’s a simplistic approach, but then that’s what I like about it. Simple beats complicated any day! And I also like the fact it helps people like
Scrum, and other agile development methodologies, provide a framework for managing software development projects. But all too often, methodologies focus on a project environment, where the team is focused predominantly on a shared goal. Where the team is largely dedicated to the project. In reality, this is often not the case. In reality, development teams are frequently required to develop
By Kelly Waters
“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”
Kelly Waters
Emma Hopkinson-Spark
“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark
101 Ways Limited
41 Corsham Street
London
N1 6DR
United Kingdom
101 Ways Limited
No.1 Spinningfields
Quay Street
Manchester
M3 3JE
United Kingdom
101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands
If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.