Episode 4 - 23 Sep 2015
In Episode 2 we talked about the importance of business objectives: how it’s more important to satisfy real business goals than to craft beautiful code.
Then in Episode 3, we talked the importance of code itself: how we can’t know for sure that our business objectives are sound without first writing some code.
In this video, we're going to look at the third pillar of the "Development That Pays" model: the people that make the whole thing work.
As you'll see, the quality/quantity/profitability of the software produced depends to an extent on how well individuals do their jobs...
... and to a surprising extent on the way they work together.
Enjoy the video.
Hi this is Gary
Welcome back to Development That Pays.
In Episode 2 we talked about the importance of business objectives: how it’s more important to satisfy real business goals than to craft beautiful code.
Then in episode 3, we talked the importance of code itself: how we can’t know for sure that our business objectives are sound without first writing some code.
Unfortunately - or fortunately, depending upon your viewpoint, we don’t have a business objectives picking machine and we don’t have a code generating machine.
If we did, we could plug them in and watch super-profitable software pop out of the other side.
No, we’ve going to need some people. So let me introduce you to a couple of friends of mine: Business Bob and Development Dave
Business Bob is the product owner.
In our walls and ladders model, Bob has responsibility for picking walls.
Development Dave is the Lead Developer.
Dave has responsibility for stacking boxes… building ladders… and building staircases.
Roughly speaking, Bob decides what to build… and Dave (together with his dev team) builds it.
The quality - and profitability - of the software that Bob and Dave produce… depends on how well they do their individual jobs.
It also depends - to a surprisingly large extent - on how well they work TOGETHER.
It’s been my experience that the Bobs and Daves of this world don’t work well together, at least not as well as they might. To illustrate this, let’s look at what happens when they DON'T work together.
Bob has an idea for a new feature - "Feature X”. He’s spec’ed it out in detail, and hands it over to Dave Dave and his team set to work. After 4 long weeks, it’s complete and it goes live.
Only then does Bob see the awful truth. Feature X is a failure. Dave, as you can imagine, is furious. A month’s work down the drain.
It’s not a happy ending.
Let’s play out this story again.
Bob has an idea for a new feature - "Feature X”. Dave comes up with a “minimal” version of X - let’s call it “little x” It takes just 2 days for Dave and his team to get "little x" live.
Bob can see straight away that “little x” isn’t really working. So he suggests a change. Dave doesn’t have a problem making the change: after all, “little" x only took a couple of days to build
The next day, “little y” is live. The initial results are promising. Dave has an idea for an improvement. Bob likes the sound of it. It’s live the next day.
And so it goes on, with Bob and Dave working together to refine the feature, one small step at a time. Bringing this story to very happy ending.
Okay - we don’t need Bob and Dave to fall madly in love. But I hope you get the point.
Talk to you next time.
Watch "Agile Software Dev = Business + Code + PEOPLE" on YouTube.