From the excellent Ron Jeffries, we have “Refactoring – Not on the Backlog!“
From the excellent Ron Jeffries, we have “Refactoring – Not on the Backlog!“
You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation. This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques. The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved. There are three fundamental principles of Agile estimation:
Principle One: Collaborative
Agile estimation methods are collaborative. This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort. Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates. Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.
Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem. Teamwork and groupwork are based on this concept. This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.
The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person. This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort. This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders. Another way of stating this principle is that no individual can be punished for a bad estimate.
Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated. This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.
Principle Two: Relative Estimation
Imagine you are shown a glass bottle with some water in it. You can see the water sloshing around. Someone asks you, “how much water is in the bottle?” You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.” Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity. In both cases, you are doing a relative estimate of the amount of water in the bottle. You are comparing the amount of water to a known quantity.
Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?” If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum. You have no basis for comparison. You might take a wild guess, but it is just that. Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is. But those cases are, again, relying on our inherent ability to see relative differences.
So instead of ignoring this capacity, in Agile estimation techniques, we leverage it. When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work. The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units. For example, it is common to use “points” when estimating the effort for Product Backlog Items.
When doing relative estimates it is very important to ensure we are comparing “apples to apples”. Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done! If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.
This last point is subtle, but important. If you have already done something, you know much more about it. If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it. By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.
It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).
Principle Three: Fast
In Agile estimation we don’t care (!!!) about accuracy nor about precision of estimates. Whoa! Why is that? Because estimation is waste. You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building. Therefore, both Agile and Lean concur: do your utmost to eliminate that waste. There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)
In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast! Really fast!!! Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.
There are really only two modestly good reasons for doing estimation in an Agile project or product:
As a business stakeholder, one can do a simple mental exercise. Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?” Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results. If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).
Bonus Principle: We Suck at Estimating
Most people doing estimation in traditional project management try to measure in units like person-days or dollars. There is no doubt that these units are useful if you can get good estimates. However, most of the people doing estimation are fundamentally and irredeemably bad at it. How do I know? Because they are not wealthy… and have thereby proven that they cannot predict the future. If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth. Given that, it is fruitless and wasteful to try to get better at estimating. Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now. Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.
One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses. We are delivering some of them ourselves, but we are also bring in outside experts for others.
Here is the course list at a high level:
- a 1-day “Advanced ScrumMaster” course
- a 1-day “Advanced Product Owner” course
- a 1-day “Managing for Success” course
- a 1-day “Enterprise Agile” course
- a 2-day “Agile Engineering Practices” course
- a 2-day “Agile Coach Training” course
Our schedule for these events will be finalized in the next few weeks. If you are interested in any of these courses, please pre-register here. Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.
I’ve been working for the past year on building the Scrum Team Assessment (yes, you can still go get it for your team ). I’ve been doing all the work on it personally and it has been great fun. The best part of it has been that I’m back into coding. And, with that, of course I have had to take my own advice about Test-Driven Development and the other Agile Engineering Practices. But it hasn’t been easy!
I’m using PHP for the web front end, and Python with OpenERP for the back end. My testing tools include Selenium for Acceptance Testing and PHPUnit for unit testing. And… nothing yet for the Python back-end. This is still a sore point with me. Normally, I would find the back end TDD process easier… but OpenERP has been a HORRIBLE BEAST to use as a development platform. Well, I might exaggerate a bit on that, because it is really just the complete lack of well-written API documentation and sample code. Which is funny, because there are tons of open-source extensions for OpenERP written. Anyway, I don’t want to complain about it too much, because in many other ways it is a fantastic platform and I wouldn’t easily switch it for anything else at this point.
Back to testing. Last week, a client using the Scrum Team Assessment found a bug… and it was one of those ones that I know made them consider not using the tool anymore. Fortunately, our contact there has the patience of a Redwood, and is helping us through the process of fixing the system. How did the bug happen?
Because I didn’t do _enough_ TDD. I skimped. I took shortcuts. I didn’t use it for every single line of code written.
The question for me now, is “why”? Fortunately, the answer is simple to find… but solving it is not as easy as I would like. I didn’t follow my own advice because I was learning about too many things at the same time. Here’s what I was learning all at once over a three week period in December when I was doing the real heads-down development work:
Like I said, FUN! But, a bit overwhelming for someone who hasn’t done any significant development work since 2006-ish. As well, because of learning about so many things, I also didn’t have a good setup for my development, testing and production environments. Now I have to clean up. Finally, I also forgot about another important Agile Engineering practice that is used when you have lots of intense learning: the Architectural Spike.
I have to make sure that I take all that I’ve learned and create a truly good dev and test environment (because that was a huge hinderance to my work with both Selenium and PHPUnit). And I have to take the time to learn to do the testing in Python (I would love suggestions on a good unit test framework)… and go back over that code, even though most of it is simply declarative of data structures, and make sure it is well-covered by unit tests. Ideally, I might even consider throwing some code away and starting from scratch. One possibility I’ve considered is to get rid of PHP entirely and build the whole system with Python (I’d love some thoughts on that too!)
Why am I doing all this? Well, I really think that the Scrum Team Assessment is an awesome tool for teams that maybe can’t afford a full-time coach. It certainly isn’t a complete replacement, but I’ve poured my knowledge and experience into it in the hopes that it can help a bunch of people out there do Scrum better… and more importantly, create great teams that produce awesome business results and where people love to come to work every day.
All PBIs completed by the team should be “potentially shippable” increments of complete value. In order to do this, they must touch all the layers and components of the product so that the functionality produced is truly complete, not just a prototype… a “slice” through the system. In other words, all of the work that is required for shipping product needs to be completed on all individual PBIs. Creating slices through our system allows the Scrum team to deliver value each and every Sprint and also allows for the Product Owner to change direction to a new feature if it is more valuable for a future Sprint. What happens if we don’t create and complete PBIs that are slices through the system? We risk falling into a pattern of not having a potentially shippable product each Sprint, and, even worse, we may regress into a waterfall type process that produces nothing of value to the customer until the end of the project.
Dave Nicolette has written a fascinating rant called “All evidence is anecdotal” in reference to research about software engineering.
Isráfíl Consulting Services is pleased to announce our upcoming:
Software Developers, Technical Architects and Lead Developers for teams that currently use or are intending to use Agile methods such as Scrum, Extreme Programming or OpenAgile will benefit from attending this course.
After completing this course you will:
Register!: http://www.israfil.net/publictraining/registerCourse Details: http://www.israfil.net/publictraining/coursesClass Schedules: http://www.israfil.net/publictraining/scheduleFor more information, please e-mail us at: firstname.lastname@example.org
Thanks to Christian Gruber of Geek in a Suite for pointing me to this fascinating use of agile on writing projects: Agile Guidance Engineering.