Not long ago I wrote about the short-falls of scrum planning. And not too long before that I wrote how traditional constraint based planning doesn’t work when estimating software projects. Both outline the reasoning and motivation for how we estimate at Planet Argon, and why.
Assuming you haven’t read the articles linked above—I’ll summarize them both.
1.) There are no physical constraints in software.
Things like fit, form, function in manufacturing; or the physical and legal constraints of a building lot in construction simply do not exist in the world of software. Instead—because we cannot plan without constraints —we must invent them. Agile or waterfall, all software planning works this way.
2.) The problem however, is that instead of creating application constraints, we constrain ourselves to features.
Scrum planning promotes the practice of organizing a project into sizable bits of features and functions. The index card says, “we need a way to do ‘x’?”
Why?
Why do you need to do ‘x’? Let’s back up and ask, what’s the sole purpose of this app? Is the function written on the note card and stuck to the whiteboard going to help the app achieve your purpose? Probably not.
WE START WITH A GUESS
When asked for a quote, we make one up. We gather a few heads in our conference room and find a median between everyone’s guess. Then we provide our shopper with the agreed number and tell them it’s accurate within +/-50-75%. Sounds terrible, right?
We do this for a number of reasons. First, we’re not a garage of coders. We’re a strategic partner. We won’t execute an RFP ‘to a tee’. Instead, we’ll question every line within. We ask why—and that scares a lot of people. We guess on our first engagement because we have every intention of rewriting your requirements with you to make your project better.
The guesstimate simply sets both party’s expectations in line and provides the go-ahead to start with ITER-ZERO.
ITER-ZERO: WE REWRITE YOUR RFP, TOGETHER
The purpose of ITER-ZERO is to collaborate on the problem at hand.
- What issue does your project aim to solve?
- What’s your project’s motto?
- What are your goals?
- What’s your app’s purpose?
Notice that we don’t ask about features or functions. We’re creating application constraints. These constraints will guide what solutions (features/functions) we use to achieve each goal of the app. If you want feature creep, create a list of features from index cards and tape them to a white board. If you want a well designed application that matches simplicity with utility—then you’ll need to dig a little deeper and ask why … a lot.
WE RE-GUESS
With your application more clearly defined, we’re put in a position where we can estimate. And the best part? The deliverables from ITER-ZERO can be used anywhere, not just at Planet Argon. Our client has paid for and completed the first step of their journey at any studio—and put anyone in a position where they can better estimate their project.
Our next step is to prepare an estimate that outlines what we think it will take to design the app; and a rough idea of what it will cost to develop it. A lot more goes into the estimate this round than the first—but it’s still a rough estimate. Design is not quantifiable, but instead a collaborative, iterative process. ITER-ZERO defined your project; but getting that definition on screen in a way that meets everyone’s expectations is always an unknown.
The difference between this estimate and the first is not only accuracy, but (more importantly) certainty. While the first round is +/-50% accurate; it’s usually around 25% certain. This round we’re up around +/-25% accurate—but 90% certain. That’s a huge improvement.
WE ESTIMATE… FOR REAL THIS TIME
We work in iterations—blocks of work that flow through our D^5 process. Once the first iteration is through design, we create a project plan and definitive estimate. Because we refused to plan using features and before we were able to collaborate with our clients, we’re able to construct a very realistic—and very accurate—project plan.
And unlike those studios that use scrum—we won’t bail when the reserved ‘sprint’ expires.
Our entire team, and our clients are involved all the way through the design process. Scrum requires flexibility because of the lack of heavy planning and thinking. Scrum is very much a ‘do’ work process—a sprinter. We’re more methodical than that—like a long distance runner that needs to consider her breakfast the day of a big run.
Our collaborative planning and estimating processes means changes in development are rare. We both know what to expect and what it will take to finish a project.
CLOSING
In summary—if you ask us for an estimate and our competition, you won’t be getting two apples to compare. No, ours is more of a basket—with an invitation to work with you to find the fruit to put inside.