Oh man, this topic is a doozy. Customers want to know how much something will cost and when it will be done without knowing what it is we are really going to end up doing. When you suggest that we will discover things and course correct, they stare at you blankly and ask if that means they are getting a discount. Customers generally don't want to have to think, and they want to shift the responsibility of designing their business model onto you, the contractor, because bless their hearts, they probably don't even have a business plan that would let them articulate their business and revenue model as it applies to the work they want you to do.
Having a consulting services based business means that your business consulting service model must be laced up and iron clad. You need to be the Delta Force that your customer is looking for. When you are a small business trying to keep all your customers happy, doing operations and support, figuring out your own revenue model that's required to support your existing client base, while at the same time figuring out how to grow your company to cover your new expenses that have emerged from your own success... it's really hard to do this. This is why most small businesses fail. An added challenge is when your business is small and there are limited numbers of partners, the partners tend to be the business development team, the sales team, the account execs, the PMs... and those roles have conflicting agendas that can make course correction in the middle of a project very hard. Sales people don't want to admit that the company's capabilities are a work in progress.
Here are some very cool articles on alternative contract models. The fixed cost, fixed scope, fixed time model ALWAYS fails without a change control officer pounding the client relentlessly, which often results in an unhappy client; on the other hand, if you don't pound them with change control, they eat into your margin, for us, typically by 50% of our margin. We desperately want to be fixed scope bucket, but varying content of bucket; we want to be fixed cost and fixed time, where we append the emerging requirements into a new bucket of cost and time.
http://www.sparkboxx.com/sparkboxx/types-of-contracts.html
http://alistair.cockburn.us/Agile+contracts
Showing posts with label story driven development. Show all posts
Showing posts with label story driven development. Show all posts
Wednesday, April 15, 2009
Monday, March 30, 2009
Agile isn't easy
I'm sure other people tranistioning to agile have had this thought. Isn't agile supposed to make my job easier? Won't I have more time to golf and relax? And yet, agile seems to be harder, and require more work and effort, than doing things business as usual. Well, guess what? Executing great work at the highest level is hard! It's harder than business as usual. But it pays dividends. You delight your customers, you have a happy, satisfied team doing valuable work.
The moment the team stops doing work against stories its committed to, the magic leaves the room, quickly and dramatically. This is your fault as the product owner or business manager, not the teams. Business inputs will constantly distract you, customers will constantly derail you, personal issues will manifest in your team's lives. The world will never cease in its efforts to derail, and that's why you have the hardest job of all as the product owner. You're the glue holding the whole thing together, keeping the world at bay.
It actually reminds me a lot of skeet shooting. Shotguns are weird weapons, and skeet shooting is quite the challenge: you're trying to hit a moving target with an explosive burst of shot. You're not sitting there at the range, lying prone, taking as much time as you need to put the bead on the bullseye. You've got at most 2-3 seconds where the clay will be close enough to the target area where your shot will hit it with any force.
The magic of the shotgun is that you don't aim down a site. You line up your vision to the sites - you put your entire upper body and vision in alignment so that you can follow the target with your eye. You no longer aim. You see the target line up, you squeeze the trigger, and pow! it explodes.
This reminds me a lot of setting the goals for a sprint. It's all mental. You have to line everything up to hit the target before shouting "pull!" and if you don't, you're guaranteed not to hit this elusive target. Go down to your local clay shooting range and try it out, you'll find it weirdly identical to leading a software team. Take your whole team as a team-building excercise. There's something interesting that happens when you fire deadly weapons together safely.
The moment the team stops doing work against stories its committed to, the magic leaves the room, quickly and dramatically. This is your fault as the product owner or business manager, not the teams. Business inputs will constantly distract you, customers will constantly derail you, personal issues will manifest in your team's lives. The world will never cease in its efforts to derail, and that's why you have the hardest job of all as the product owner. You're the glue holding the whole thing together, keeping the world at bay.
It actually reminds me a lot of skeet shooting. Shotguns are weird weapons, and skeet shooting is quite the challenge: you're trying to hit a moving target with an explosive burst of shot. You're not sitting there at the range, lying prone, taking as much time as you need to put the bead on the bullseye. You've got at most 2-3 seconds where the clay will be close enough to the target area where your shot will hit it with any force.
The magic of the shotgun is that you don't aim down a site. You line up your vision to the sites - you put your entire upper body and vision in alignment so that you can follow the target with your eye. You no longer aim. You see the target line up, you squeeze the trigger, and pow! it explodes.
This reminds me a lot of setting the goals for a sprint. It's all mental. You have to line everything up to hit the target before shouting "pull!" and if you don't, you're guaranteed not to hit this elusive target. Go down to your local clay shooting range and try it out, you'll find it weirdly identical to leading a software team. Take your whole team as a team-building excercise. There's something interesting that happens when you fire deadly weapons together safely.
Thursday, May 22, 2008
Simple Story Template
Great post on a simple story template from Mike Cohn. "As a , I want so that ". Simple constraint.
Saturday, May 17, 2008
Story Driven Development
Effective thinking about complex problems means bracketing off. SDD is one way of doing that.
Subscribe to:
Posts (Atom)