Scott Woods at the Elements Penn State Web Conference 2016, presents on West Arete's experience with shipping custom software for clients. Processes such as Scrum are useful, but a prerequisite is how the teams and stakeholders approach the challenge and responsibilities of delivering on time.
31. Uncomfortable Truths
1. You can’t estimate worth a damn
2. Nobody knows precisely what you should build
3. Negotiating is futile without quantitative facts
about the future
37. Velocity only works if…
• Time boxes are consistent
• Team size stays consistent
• Points are unbiased
• Stories are written by both parties
• Stories are actually accepted by stakeholder
38.
39. Uncomfortable Truths
1. You can’t estimate worth a damn
2. Nobody knows precisely what you should build
3. Negotiating is futile without quantitative facts
about the future
4. Your job will be in trouble if “it” is not delivered
on time and on budget
40.
41.
42. Planning with Scrum
• Break everything into tiny deliverables (3/week)
• Stakeholders accept/reject each delivery
• Measure how much gets accepted each week
• See what fits in the time remaining at this pace
• Stakeholders prioritize remaining deliverables
43. Uncomfortable Truths
1. You can’t estimate worth a damn
2. Nobody knows precisely what you should build
3. Negotiating is futile without quantitative facts
about the future
4. Your job will be in trouble if “it” is not delivered on
time and on budget
5. Working overtime will ultimately kill you
I’m Scott Woods, president of West Arete. We are a custom web development company based here in State College, PA.
FracTracker maps oil and gas leasing and drilling in allegheny county,
Connects all of the relationships between the parcels.
First time the lease data has been visible.
SPOC is the software that manages the event operations for the University Police.
Flip Learning is a successful ed tech startup that provides rich interactive alternatives to textbooks for many universities.
We’re also a certified benefit corporation
Means we tend to pick projects that do good in the world
We contribute extensively to community projects and nonprofit organizations
self-contained. building software in and of own team.
who are not daily part of core team. building software for someone else
kahn bahn
Let’s talk about what makes it difficult to deliver custom projects on time.
We want to deliver on time and on budget, but we don’t want to be draconian about it. We could say “no” to everything, but then our stakeholders aren’t happy, and we don’t get good software.
A lot of times there’s an over emphasis on process. Or features. Or technology.
Step back even higher level.
Core difficulties is full awareness of what kind of endeavor we’re under taking.
Of where the complexity lies.
Of where each of our roles in the projects lie.
Stages of competence.
STRIVE for conscious incompetence!
Important part of being conscious is how do we frame the problem of software/web/mobile development.
Bad analogies.
Not like building a house or a car. Not enough patterns, too much variance.Not like ordering food.
Not like ordering a product.
Problem with these is they don’t emphasize the journey. They’re more about the destination.
My definition of adventure is “uncertain outcome”. Here’s my analogy for projects:
Custom software is like driving through the wilderness and trying to discover the best possible spot for your vacation. it could be simple or complex, and it could be the best experience ever or just plain awful. but it’s largely up to you. and it’s going to require a team.
Out-of-the box solution is like going to the Best Western (or motel 8, or ritz). Maybe good, maybe bad, but largely a predetermined outcome and a function of good logistics.
It's rough terrain, and you’ve never been here before. you can’t see very far, and you only have one lousy, very inaccurate map. you only have so much food.
This is what everyone hopes for. You may have to make some good decisions and take some risks to get there. You may compromise and play it safe by picking a spot that’s closer. There are tradeoffs in terms of whether you want to have a water view, or stay away from bugs. But it’s largely a function of your teamwork, efficiency, and navigation skills.
And if this all sounds a little too fake and idealistic, kind of like this stock photography, it is.
Unfortunately, the bar at this point for professional web projects is very high. responsive, awesome ux, great graphic design, shouldn’t take forever or cost a lot of money. convey mission of organization.
This is more of the destination your stakeholders are now shooting for. It’s 200 miles in the wilderness, and you have to get there in one day. The map is even worse than before. Now that you’re sponsored, you don’t really get to pick the site. The field is competitive. There’s a lot of money at stake too. So that journey now looks less like a hike, and more like this:
If you can imagine rally-style driving to a non-predetermined destination, then I think you have the right analogy.
Experience is so intense, you need to split responsibilities. One brain is not enough. Driver / navigator.
and crest 70
stay right over drop
stay right over jump into left 6
right 4 tightens
left 2 over crest
right 3+
They’re making mistakes all the time. Uncertainty around each corner. when everyone is a professional at this, and knows what to expect, you get focused concentration and smooth execution. but you can see where if the driver or navigator or bystanders do not have the right expectations of the experience, you wind up with a whole lot of screaming instead. because they had something else entirely in mind.
I like this analogy because Our #1 variable for evaluating clients is the quality of the collaboration. best/worst vehicle doesn’t matter as much.
You could put a world class team in a 1999 Subaru Legacy, and they’ll still kick the crap out of the slightly dysfunctional team that’s bickering in the rally car. We see teams focusing way too much on Ford vs Chevy, which does affect enjoyment, but is often not a big variable in the outcome.
On our journey today, I have a series of uncomfortable truths to reveal to you. None of them are news, but if we’re going to get to conscious incompetence, we have to confront them.
We’ve been making estimates for about 11 years as a team. Read many books on estimation.
Main thing you can learn from that experience is that your estimates are going to suck.
Yes, these are deliberately accusatory.
So what can we do? Make more of them!
Individual estimates will be very inaccurate. But when we aggregate them, the errors cancel out.
Getting the size right is key. No fewer than 3 deliveries per week. If you’re delivering 15 stories, bureaucratic waste (or big team).
Errors cancel out, but only if you can remove the bias.
Point system. How many use it?
Explain point system. Dollars. Time. Pressure.
Story: Saw a project where every estimate done by developer, in front of their boss, where points were being equated to commitment. Result — chronic underestimation. Uncertainty principle. By observing the process, you’re perturbing it. Very fickle to remove bias.
It’s true. And it’s OK. How many have been in the ones making the decision of what should be built?
Ideally, you are changing your mind as you go.
We must acknowledge up front that we don’t know what is going to come later.
We try to make our proposals as vague as possible. Sometimes only a few bullet points.
This gives the stakeholders the freedom to control their destiny. They can swap stories around, and that’s OK.
Talk about desired outcomes, not features.
Don’t say “multi-group chat room, it’ll have role playing, it’ll have threaded discussions”.
Do say “collaboration between different configurations of participants, variety of spontaneous and thoughtful interactions.”
Leave room for success.
Actually not hopeless. You can use these two to your advantage. The first with aggregation, the second with flexibility. Help steer it.
Story: we often have times where the end features are fairly drastically different than the original ideas. this is good, because it’s based on evidence. so we plan on it.
you will see situations where the development team is nervous. “this is never going to get done on time”. yet things don’t change. why?
developer gut instinct is always right. but action won’t be taken unless there’s evidence to support it. we have to get to hopelessness.
Cone of uncertainty.
As time goes on, discover what actual costs will be.
This is the passive model of observance.
Don’t like it, because red dot is fixed.
Don’t be a victim.
Instead, you want to move the dot to stay within the cone. Cone is shaped really funny!
Teamwork. Collaboration. In it together.
We must acknowledge up front that we don’t know what is going to come later.
We try to make our proposals as vague as possible. Sometimes only a few bullet points.
Measure what got accepted. average them.
since these are points, they’re relatively unbiased.
takes into account sick days, etc.
Look into future, only going to get “this far”. Need at least 4 sprints.
This one is really uncomfortable, considering points 1, 2, and 3 above it.
This is the art of diplomacy. You have to get all the other ones right.
Often what a project looks like.
Hard to plan ahead. Hard to measure. Big jumps in overall shape are new ideas/scope. Some are big surprises. When are we done?
Hard truth. scope is set in first 25% if you’re not careful.
Here is a recent project at West Arete.
Hard deadline. But lots of churn!
Getting things done is easy. Flat line is the hard part.
We need to cut 30% of what is in the backlog.
Empowered, they’re brutal.
At some point, stakeholders realize that velocity is key. Emotional attachment. Try to control it!
We need 12 points. Why was this only 11?
Fix it with overtime. Burnout.
Observe, present hard evidence. leave the stakeholders in control of the decisions.