Stuck in a rut? Can’t seem to ship?
Try delivering something of value every week.
Doing this will require you and your team to do certain things.
You have to break big problems down into smaller ones
A week is a relatively short period of time. You can’t possibly do everything in a week!
To get anything done in a week, you have to break big, scary, complex problems down into smaller, simpler, more manageable ones.
At first this can appear daunting.
But once you crack it, you will find the big problems aren’t as bad as you thought; and that you can deliver a lot of value in one week’s time.
You are forced to focus on things that are valuable to your customer
How do you know what’s valuable to your customer? You ask.
When you look at a software project through your customer’s eyes, it’s easy to see how little of what is traditionally offered has little or no value.
Sure you need documentation. Sure you need plans.
But they are only in support of one thing—working software.
By delivering something of value every week, you are forced to get lean and ignore anything that doesn’t add value.
As a result, you travel lighter and only take what you need.
You have to make sure that what you are delivering works
Delivering something of value every week implies that what you deliver had better work.
That means testing—lots of it, early and often.
Testing isn’t something you be slough off till the end of the project.
It’s not something you can delegate.
The buck stops with you.
When you deliver something of value every week, testing will become a part of your daily life.
You are forced to get feedback
How do you know whether you’ve hit the target if you don’t regularly engage and ask your customer how you are doing?
Feedback is the flashlight that cuts through the fog and keeps you on the road as you’re barreling down the highway at a 100 miles per hour.
Without it, your customer loses the ability to steer. And you end up taking a lot of wrong turns.
You have to adapt
Stuff happens on projects. Things change.
What is really important one week can be de-scoped the next.
If you create a plan and follow it blindly, you won’t be able to react to the curve balls.
That’s why when reality messes with your plan, you change your plan – not reality.
You have to be accountable
When you promise to deliver something of value every week, you become accountable.
That means owning quality.
Owning the schedule.
Setting expectations.
And spending the money as if it were your own.
Because, at the end of the day, it is you, your team, and the expectations you set, that will determine whether your project succeeds or fails.
You can’t delegate this. Nor would you want to.
Warning! Not everyone likes working this way
Delivering something of value every week is not for the faint of heart.
It puts the spotlight on you like never before.
There is no place to hide.
Every week you sit down with your customer, and show them how you’ve spent their money.
Some people don’t like this level of visibility.
They don’t want it.
But for a team struggling for direction, and not knowing where to begin, it’s an awfully good place to start.
So if you find yourself in a bit of a rut, or your team is struggling to get something out the door, hit the pause button. Take a step back. Ask yourself what it would take to deliver something of value every week.
Then trust your instincts, and do what needs to be done.
zackatoustra
Jun 03, 2009 @ 11:49:07
Every week?
Does this principle apply when you’re on a relatively “big” project (20 developers)?
I’m not quite sure that our “project leader”(yeah, i know : if we were really agile, we wouldn’t have a PL) is able of scheduling sets of tasks that fit into one week.
Actually, we’re struggling because we have to deliver a “stable” version every 4 weeks!
So, is the week THE unity of time? Can it be changed to month, or “couple of weeks”?
Or, am I missing something?
JR
Jun 03, 2009 @ 12:37:05
No, you are correct. The week doesn’t matter.
It could be one, two, three, or four (though I don’t recommend going beyond four).
The idea behind this is just show people that you don’t have to disappear for two months before delivering something of value to your customer.
You can build product feature by feature.
And that you can do a lot in a week.
Top Posts « WordPress.com
Jun 05, 2009 @ 00:23:25
Flow » Blog Archive » Daily Digest for June 5th - The zeitgeist daily
Jun 05, 2009 @ 05:28:16
arpit
Jun 06, 2009 @ 05:54:03
Isn’t this the whole point of Scrum and agile development? Where we work we go with 3 week dev schedules with a demo at the end of week 3. A week may be too constrained
JR
Jun 06, 2009 @ 20:42:29
@arpit
Yes – this is indeed the what agile is all about.
Three weeks is a fine iteration length. I know many projects that start there.
I also know many projects that get away with weekly iterations too, and have had great success with that.
It’s what ever works for you and your team.
On your next project try two weeks and see what happens.
Links Roundup 07/02/09 | Marketing.fm - Eric Friedman
Jul 02, 2009 @ 14:05:43
Ian Fuller
Nov 17, 2010 @ 16:52:20
Hi JR,
Is there anything in Agile about dealing with issues? What happens if on the day before a weekly delivery one of the developers hits a coding bug that he can’t get past?
Cheers,
Ian
JR
Nov 19, 2010 @ 13:54:37
Good question Ian. Things like this happen on projects—all the time.
If the team is finding they are producing a lot of bugs at the end of each iteration, maybe they need to slow down, tighten up their testing practices, and see if they can just produce better quality from the start. In other words—go slower.
If the odd bug pops up, most teams will try to squash it on the spot. If it’s really big, you can create a story and track it like any other story.
You can also reserve 10-20% of each iteration for general bug fixing and large scale refactoring if that helps to.
Let me know if that answers your question. Good luck!
Ian Fuller
Nov 19, 2010 @ 14:21:53
Thanks JR. I think the word ‘bug’ might have been misleading. I guess what I’m referring to is a roadblock of some sort. Maybe a third party library doesn’t work as expected, or the a hardware interface doesn’t function correctly. When something like this occurs and you can’t make a delivery how best do you move on?
JR
Nov 20, 2010 @ 16:24:42
@Ian Gotcha. Aglie doesn’t have any magic bullet for dealing with issues.
I mean it suggests you do certain things to minimize the chance of issues from coming up in the first place (XP practices). But it’s more an acceptance that there this is inherent complexity and uncertainty in software delivery, and that dealing with ‘unexpected issues’ comes with the job.
Agile handles this by working opening, transparently, and closely with the customer from day one. One team.
By working hard and delivering something of value every week, trust is earned. Then when issues do come up, there’s enough trust that our customers work with us (instead of against us) through the inevitable issues as they come up.