Do What You Say You Are Going to Do
I woke up this morning to several blogs and tweets that all basically had the same theme… estimation is bad, maturity models are bad, tools are bad, metrics are bad, measurement is bad… and that we should eliminate all of them. Eliminating this stuff requires a significant amount of trust between the customer and the team… between management and the team. Before you ask your customer or your management to eliminate estimates, maturity models, tools, metrics, and measurement… ask yourself, and your team, if you are trustworthy. Do you do what you say you are going to do when you are going to do it? Can you spin up a sprint and nail it every time?
If you can, you’ve got a good case to be trusted. If you can’t… you and your team should probably look to themselves first. It is not reasonable to ask any organization for a continuous flow of money and time, without giving them some reasonable idea of what they are going to get for their money and time.
Comments (8)
Derek Huether
I always find it interesting when people say some “thing” is bad. Things don’t have motives, people do. I’ve been told eating red meat is bad, putting salt on my food is bad, drinking coffee is bad, and the list goes on and on. I list items related to food because depending what you eat or drink, it “could” actually kill you. But, each item alone is not bad. It’s only in a given situation with a given individual can it “potentially” be harmful.
I could argue that estimation is good, maturity models are good, tools are good, and measurement is good. But, I’m not going to go so overboard with them that it chokes the life out of my project. Too much of anything can be unhealthy.
Is it just human nature to be so polar? Why do some see everything in black or white?
I think a little moderation goes a long way and everything is just a shade of gray.
Scot
I just think estimation is bad … Well not bad, just counterproductive. I much prefer to measure and gather metrics than estimate stories to arbitrary sizes of time /complexity etc. I’ve recently found that the story is a good predictor of project size. We can do X stories an iteration; let’s say that number is 10. If there are 30 stories in a proposed set of features (eg minimum releasable features) then the ‘estimate’ (prediction) is 3 iterations. To try to go through every possible permutation of the unknown with every story – that’s just an energy sapping half day meeting for the entire team. I don’t think it adds value to the customer over what we already told them (3 iterations).
Of the rest … Well metrics and measurement are essential to understanding what you’re doing as an organisation. I cant see how that can or even is desireable to do away with I don’t really know enough about the CMM style stuff to comment on it.
Vin D'Amico
I agree with Derek. ‘Things’ aren’t good or bad. It’s how we use them that makes all the difference. A tool or technique that works great for one dev team may fail miserably for another. Why? Differences in culture, training, experience, priorities, goals, etc.
Everything the team does should add value. If it doesn’t, change it or eliminate it. Strive to say what you do and do what you say.
Agile Scout
Agreed. +1 to Derek. Look, things aren’t good nor bad. It’s how you execute. If you execute with VALUE, then what’s the problem? Blanket statements about “this or this is bad” doesn’t help.
It’s funny… when I wrote this I wasn’t thinking much about the absolute value of those practices, either good or bad. I was thinking about the idea of asking to be trusted before you are trustworthy. I hear a lot of folks talk about trusting the team, and eliminating estimates and dates is about trust. Frankly, most teams don’t know how to reliably deliver software. If I were on a software development team, I’d work to become good and making and meeting commitments before I ever considered asking to be trusted. If you want to be trusted… be trustworthy.
Interesting how you guys interpreted what I wrote… it’s cool, that’s just not what was going through my mind when I wrote it.
Scot… when we were talking over Twitter, what I was trying to say was that… to me, story count as a metric is only relevant if your stories are all relatively the same size. If you have a statistically distributed group of stories all between 1 and 3… or all small… or all that take about a day or two… story count is meaningful. If the stories range in complexity between a 1 and a 13… or a small and an extra large… or that take between a day and a month… story count is meaningless.
Here is my context… I work in a lot of large companies, with complex products, some significant amount of technical debt, and dependencies out the wazoo. These guys can benefit from doing agile… they will slowly become agile if I get to help them long enough… but a blanket statement that estimating is always bad, and should always be avoided, is a non-starter for me. That’s why I kept saying ‘glad its working for you’. If that works in your context… then I really think that is great and you should run with it.
For me… I can’t say that estimating is crap. I have most teams start estimating is story points, and breaking down tasks, and estimating tasks… until I can get them to break things down into small, similarly sized user stories and we can drop tasks. If we could get everything small enough, I would agree with you and drop estimating all together… unfortunately most teams are not there and NEED estimating for any semblance of predictability… if nothing else, the estimating process forces them to work together and think through the problem.
Anyway… just my perspective. I certainly respect yours and appreciate your comment here and on Twitter.
Sridhar
I think that doing something for the sake of doing it and not because it provides value is one of the major reasons for the “bad” feeling. One project team I know was given a complex business project, where the business users provided about 700 detailed use cases. Since the team was following “Agile”, they tried to convert the use cases into stories that are of equal size and then estimate/predict the timelines. You can imagine how much wasted effort went into it (while converting into equal, bite sized stories was hard enough, trying to determine the simplest story without a very good idea of the domain was doubly hard).
One fundamental mistake I have seen teams make is to pick a methodology and try to stick 100% with it. That is where process maturity is important (to take a shot at one of the other things we were talking about). The team needs to have a toolkit, from where suitable approaches can be picked depending on the situation.
It would be great to talk more on this with you and others here.
One of first things I do with my clients is tell them is that we will break any rule of agile for the right reason. You have to understand the principles and choose the right practices. In the scenario you mentioned, I may have had some folks focus on user stories, in business value, risk order. Have some of the team build stories to learn about the system. Then let both tracks inform the next steps. I am sure there are 1000 ways to attack this… creating the entire backlog before writing any code is not one I’d choose.