...and I found something I didn't expect. The back story is that I was talking to a colleague about the merits of different jobs, and I started to talk about what kind of company I'd set up. Small group, about fifteen or so, mostly engineers, and the goal would be to let the producers produce as freely as possible. Trust the team. We could make anything. But where would the seed money come from?
My colleague said, "Have you heard of Ooga Labs? They're right down the street." I hadn't, so I asked the Internet and came across an article on SFGate from 2007 about Ooga. It mentioned "Calvinball", a game where the rules are always in flux. I'm always interested in how companies arrive at a culture, and a place that played a game based off the comic Calvin and Hobbes and features a CEO doing a head stand in the news can't be too bad a place to work, so I headed down Market St. to see what was up.
Up on the fourth floor of 703 Market St. is a sign "Ooga Labs Please use other entrance", so I did. After just a few seconds of looking totally lost someone offers to help and points me to David when I ask about Calvinball. We grab a conference room, but not before I get the chance to take in the office. But it doesn't feel like an office - there aren't cubes, there aren't high ceilings, and the desks are well decorated with everything from half drained cans of your assorted sodas to a fave figurine. While I'm looking around David informs the immediate area he's winning Calvinball, but there's no ball around and yet no one contests his winning.
The chairs are comfy in the conference room, there's a projector on the side wall and plenty of white board to collaborate on. It quickly becomes clear that Calvinball is not the core of this company. It's a game, it's fun, but it's the result of something else. David said one word about working at Ooga Labs: TRUST. I do not hear that word too often in business, and for someone to tell me his company is about trust when I just walked in off the street to ask about a game, it has to be genuine.
From what I gathered, everything good about the company stems from that trust. If you trust a person to do his job well, to make mistakes, but to do it well, he's going to love his job a lot more than the guy who has to write a detailed tech spec, and submit it for review, and have constant code reviews, and make presentations on why he should use widely accepted best practices. The trusted guy is gonna speak his mind, and his trusted colleague is going to disagree when he thinks there's a better solution, and they're going to come up with something great because they can talk. And when their trusted boss says that the priorities have shifted, his employees trust that he's got the company, not just himself in mind.
Bigger than the day-to-day, what happens because of this trust, is that they make a great product (check out GoodTree), and people go home feeling rewarded - happy. So yeah, they play Calvinball, but what they have, is the best thing a business can ask for.
Ooga Labs
Wednesday, October 22, 2008
Painful Software Scheduling
I recently read an article from "Joel On Software" (http://www.joelonsoftware.com/printerFriendly/articles/SetYourPriorities.html) in which he discusses a feature prioritization technique. At some point, he mentioned "Painless Software Scheduling" in passing, and I thought to myself, "This sounds like something I should look up."
I didn't look it up. Instead, I decided to write about my experience of the opposite. Then I'll go back and read what the painless variety is all about and see where I stand. I don't have any good reason why I should go about it this way, but here I go!
I have had the honor of experiencing iterative development for a couple of years now. I've seen user stories (features), stakeholder meetings, feature costing meetings, and all the fun stuff that you get involved in when working with such a process. The best part is how the schedule is decided. Once the features are prioritized and given a cost the schedule is made. Here's how that goes.
Manager Type: "Hey Developers, how many features can you do this iteration?"
Developers: (counts hours, subtracts meeting time, etc) "uh, thirteen features."
Manager Type: "Thirteen? Guys, we have a backlog of 247 features. 213 of which are high priority"
Developers: "Well, we can only do thirteen. That includes coding, testing, documentation, and buffer for a million unknowns."
Manager Type: "Did you guys subtract hours because of meetings?"
Developers: "uh, Yes."
Manager Type: "I'll go ahead and clear those out for you. How many can you do now?"
Developers: (counts hours) "We can do thirteen."
Manager Type: "Still? Really? Why?"
Developers: "What do you mean why? That's how much we can do. That's what we calculated."
Manager Type: "After I cleared the meetings?"
Developers: "Right. We count our hours and take 60% of everybody's time and round down to the nearest whole number."
Manager Type: "I'll go back to the stake holders to get some more details on the features, then you can give us better estimates. So be ready to re-cost the features in a couple of hours."
Notice that the schedule doesn't exist. I'll bet money that when those "detailed" features come back it'll be the same conversation because the features don't have a detailed specification and the unknowns are just too large. That's painful.
Instead of annotating the rest the process I started above, here's a summary of the rest of the story: stakeholders end up in an eight-hour meeting, which they didn't have time for. The developers end up spending two days waiting for features and defending their estimates. The manager type argued every single feature on it's merits and motivation. Now nobody in the company wants to do it again. Most people that were involved in that eight hour meeting won't be showing up to the next one.
Try to run that process a couple more times and pretty soon, sales people are selling features so they're guaranteed to make it into the next iteration (or the current one), developers are giving insanely low estimates to their manager type will get off their back, and support people stopped talking about features all together. It was just too dang painful.
I would like to point out that the schedule still doesn't exist.
I know this scheduling thing has been done before, so why is it so painful? I can think of a couple reasons. It's painful because someone is pissed-off at some point. Everyone wants features now. It's not easy to take a list of 120 features and only release the top 20 of them. It's not easy to tell someone that their feature wasn't a high enough priority to get completed. It's insanely hard to tell everyone that the developers had to drop 5 features because of some unexpected pitfall. But the point is that something gets released.
This schedule will be completed by the end of this blog, dang-it.
I've noticed that painful scheduling leads to a lack of adoption from the people that create a need to make a schedule. The people that think of the features, the developers that implement them, the people that sell them, and even the people that want to create the features have no faith in any process put forth when the results are never seen.
How do we get all these valuable people to want to suggest, implement, sell, and schedule features? My guess is that's where painless software scheduling comes into play. The challenge we face is to make it easy to get features suggested and prioritized.
Let's start with making the prioritization meeting short, remove the debating of features on there merits and just get people to understand the feature and tell you how valuable it is to them. Make sure a reasonable number of features can be prioritized in no more than two hours. If you're looking at 247 features, try to slim down that number. Combine duplicates and remove extremely vague ones. You may even find features that only apply to one or two customers. Those can go.
Then, hand that list over to the developers and let them cost the features. If the feature is too vague, break it into smaller, more cohesive ones and keep the values of each the same as the original. If there are dependencies between features, slice and dice them until those are minimized and keep the values generally the same. I don't know how you'll do it, but you're smart. You'll figure it out, just do it. Trust whatever number the developers tell you. The more you have confidence in there estimations, the more confidence they'll have in themselves. That way, they will be far less afraid to come to you to drop a feature out of the iteration because of an unseen pitfall. After all, you don't want them to crank that last one out two hours before the demo. It will be buggy and useless anyway.
Now you have a schedule. If you started with 100 features and the developers can do 20 per iteration, then you can have it released in 5 iterations. Repeat the last two paragraphs between every iteration and you'll hone in on a number of iterations it will take and your confidence in that date will get higher with each run. If you make it easy for the stakeholders and the developers, they'll adopt the process and it's not painful for them. It's a lot of work for you, but when every body else is confident in your schedule, at least it's not painful!
I didn't look it up. Instead, I decided to write about my experience of the opposite. Then I'll go back and read what the painless variety is all about and see where I stand. I don't have any good reason why I should go about it this way, but here I go!
I have had the honor of experiencing iterative development for a couple of years now. I've seen user stories (features), stakeholder meetings, feature costing meetings, and all the fun stuff that you get involved in when working with such a process. The best part is how the schedule is decided. Once the features are prioritized and given a cost the schedule is made. Here's how that goes.
Manager Type: "Hey Developers, how many features can you do this iteration?"
Developers: (counts hours, subtracts meeting time, etc) "uh, thirteen features."
Manager Type: "Thirteen? Guys, we have a backlog of 247 features. 213 of which are high priority"
Developers: "Well, we can only do thirteen. That includes coding, testing, documentation, and buffer for a million unknowns."
Manager Type: "Did you guys subtract hours because of meetings?"
Developers: "uh, Yes."
Manager Type: "I'll go ahead and clear those out for you. How many can you do now?"
Developers: (counts hours) "We can do thirteen."
Manager Type: "Still? Really? Why?"
Developers: "What do you mean why? That's how much we can do. That's what we calculated."
Manager Type: "After I cleared the meetings?"
Developers: "Right. We count our hours and take 60% of everybody's time and round down to the nearest whole number."
Manager Type: "I'll go back to the stake holders to get some more details on the features, then you can give us better estimates. So be ready to re-cost the features in a couple of hours."
Notice that the schedule doesn't exist. I'll bet money that when those "detailed" features come back it'll be the same conversation because the features don't have a detailed specification and the unknowns are just too large. That's painful.
Instead of annotating the rest the process I started above, here's a summary of the rest of the story: stakeholders end up in an eight-hour meeting, which they didn't have time for. The developers end up spending two days waiting for features and defending their estimates. The manager type argued every single feature on it's merits and motivation. Now nobody in the company wants to do it again. Most people that were involved in that eight hour meeting won't be showing up to the next one.
Try to run that process a couple more times and pretty soon, sales people are selling features so they're guaranteed to make it into the next iteration (or the current one), developers are giving insanely low estimates to their manager type will get off their back, and support people stopped talking about features all together. It was just too dang painful.
I would like to point out that the schedule still doesn't exist.
I know this scheduling thing has been done before, so why is it so painful? I can think of a couple reasons. It's painful because someone is pissed-off at some point. Everyone wants features now. It's not easy to take a list of 120 features and only release the top 20 of them. It's not easy to tell someone that their feature wasn't a high enough priority to get completed. It's insanely hard to tell everyone that the developers had to drop 5 features because of some unexpected pitfall. But the point is that something gets released.
This schedule will be completed by the end of this blog, dang-it.
I've noticed that painful scheduling leads to a lack of adoption from the people that create a need to make a schedule. The people that think of the features, the developers that implement them, the people that sell them, and even the people that want to create the features have no faith in any process put forth when the results are never seen.
How do we get all these valuable people to want to suggest, implement, sell, and schedule features? My guess is that's where painless software scheduling comes into play. The challenge we face is to make it easy to get features suggested and prioritized.
Let's start with making the prioritization meeting short, remove the debating of features on there merits and just get people to understand the feature and tell you how valuable it is to them. Make sure a reasonable number of features can be prioritized in no more than two hours. If you're looking at 247 features, try to slim down that number. Combine duplicates and remove extremely vague ones. You may even find features that only apply to one or two customers. Those can go.
Then, hand that list over to the developers and let them cost the features. If the feature is too vague, break it into smaller, more cohesive ones and keep the values of each the same as the original. If there are dependencies between features, slice and dice them until those are minimized and keep the values generally the same. I don't know how you'll do it, but you're smart. You'll figure it out, just do it. Trust whatever number the developers tell you. The more you have confidence in there estimations, the more confidence they'll have in themselves. That way, they will be far less afraid to come to you to drop a feature out of the iteration because of an unseen pitfall. After all, you don't want them to crank that last one out two hours before the demo. It will be buggy and useless anyway.
Now you have a schedule. If you started with 100 features and the developers can do 20 per iteration, then you can have it released in 5 iterations. Repeat the last two paragraphs between every iteration and you'll hone in on a number of iterations it will take and your confidence in that date will get higher with each run. If you make it easy for the stakeholders and the developers, they'll adopt the process and it's not painful for them. It's a lot of work for you, but when every body else is confident in your schedule, at least it's not painful!
Wednesday, October 15, 2008
Building a Car - The Falacy That Dev Teams Will Add on Features Mid-Sprint
You say: Build me a car
I say: Ok
You say: I want it in 2 months!
What kind of "car" do you expect me to build?
You say: Build me a car
I say: Ok
You say: I want it in 2 decades!
Now what kind of car do you expect me to build?
In the first case you probably expected an engine strapped on to four wheels and maybe some breaks. In the second case you probably expected a cutting edge car with all the safety features, smooth ride, and uses renewable resources for it's power source.
It's the same way with developers and features. Take a developer who loves his job, give him a month to do a feature he estimated would take him a week, and he'll take that whole month. Scope creep comes from everywhere, even the developer himself. "I can refactor this and optimize that, and we'll make this AJAX to it puts the burden on the client machine instead of our servers..." and next thing you know you've got a Corvette when a Taurus would have gotten the job done.
Agile says "If something goes wrong and the team isn't going to make their commitment, then it's time to cut features." And all of the product owners of the world freak out here, so we try to comfort them with this: "But if they're ahead of schedule, they can always add on features from the product backlog!" And all the product owners start to recover from their impending heart attacks. But now you realize that unless something happens to make them take another feature off the product backlog, it isn't going to happen because developers want to make the code/architecture/feature they can - adding business value is something that doesn't come naturally, preventing bugs and being on tech support calls is.
There is one mechanism that is somewhat effective in preventing internal scope creep. It's the same thing that happens when you have external sources of scope creep, the creeper has to present his creepiness to the developer, at which point the developer says "You're creepy!" and tells sales they need to bill the customer for more hours. "But Will, there's no presentation when the source is internal, I'm confused." But we can make the developer "present" I'm not talking about a stand up presentation where he can hide his work. I'm talking about my favorite tool, pair programming. Now you've got another dev, and every character you type is presented to her for review. "Why are you adding that in, we still need to build up the core functionality, quit being so creepy Will", ok, so maybe that last part was from my Google-stalking days, but you see how having an extra set of eyes keeps you honest and business minded.
I say: Ok
You say: I want it in 2 months!
What kind of "car" do you expect me to build?
You say: Build me a car
I say: Ok
You say: I want it in 2 decades!
Now what kind of car do you expect me to build?
In the first case you probably expected an engine strapped on to four wheels and maybe some breaks. In the second case you probably expected a cutting edge car with all the safety features, smooth ride, and uses renewable resources for it's power source.
It's the same way with developers and features. Take a developer who loves his job, give him a month to do a feature he estimated would take him a week, and he'll take that whole month. Scope creep comes from everywhere, even the developer himself. "I can refactor this and optimize that, and we'll make this AJAX to it puts the burden on the client machine instead of our servers..." and next thing you know you've got a Corvette when a Taurus would have gotten the job done.
Agile says "If something goes wrong and the team isn't going to make their commitment, then it's time to cut features." And all of the product owners of the world freak out here, so we try to comfort them with this: "But if they're ahead of schedule, they can always add on features from the product backlog!" And all the product owners start to recover from their impending heart attacks. But now you realize that unless something happens to make them take another feature off the product backlog, it isn't going to happen because developers want to make the code/architecture/feature they can - adding business value is something that doesn't come naturally, preventing bugs and being on tech support calls is.
There is one mechanism that is somewhat effective in preventing internal scope creep. It's the same thing that happens when you have external sources of scope creep, the creeper has to present his creepiness to the developer, at which point the developer says "You're creepy!" and tells sales they need to bill the customer for more hours. "But Will, there's no presentation when the source is internal, I'm confused." But we can make the developer "present" I'm not talking about a stand up presentation where he can hide his work. I'm talking about my favorite tool, pair programming. Now you've got another dev, and every character you type is presented to her for review. "Why are you adding that in, we still need to build up the core functionality, quit being so creepy Will", ok, so maybe that last part was from my Google-stalking days, but you see how having an extra set of eyes keeps you honest and business minded.
Subscribe to:
Posts (Atom)
