Start with the values dang it
I’m often surprised to encounter someone experimenting with agile who has never read the agile manifesto or the principles behind the agile manifesto. This is the place to start, and if you share these values and grok the principles behind them, you can make up your own agile process completely from scratch and be perfectly successful. Or you can learn what others have tried and invest a little in a specific agileology like scrum, xp, etc and get a headstart. The point is, you should start with the values and principles. Starting with a process and never embracing the values or principles will render your agile adoption empty of true value.
Anyway, I would like to amend the agile manifesto with another value.
Team and individual productivity over consistent tools, and technologies
My first day at a bona fide startup went something like this:
Me: What kind of computer do I need?
Them: Whatever you have is cool.
Me: What OS should I run?
Them: Whatever you want. Most of us use Ubuntu. OS X works too. Winders is harder because some of the gems we use have native components that might not be available on Winders.
Me: What IDE should I use?
Them: Whatever you like most. We are all over the place: VIM, eMacs, TextMate, eclipse, NetBeans all play here. We’d prefer not paying for whatever you choose.
At first it seemed unreal that we could just use, you know, whatever. How could that work? Wouldn’t it be a mess, all of us just using whatever we wanted?
It wasn’t. The only time it was a problem was when I was not self-sufficient with the choices I had made. Specifically, I didn’t know enough about Ruby on Rails and OS X to get our app working (HEY> I KNOW THIS IS EASY! IT WAS YEARS AGO OKAY!) and everyone else was on Ubuntu. So I switched to Ubuntu until I was more experienced, then went back to OS X when I could do it without dragging people down.
Productivity over consistency is implied by the principles
I think the guys who signed the agile manifesto already shared this value. Whether they discussed including something like it and decided not to, I don’t really have a clue. But it’s certainly implied by several of the principles, the most relevant of which I’ve listed below.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Continuous attention to technical excellence and good design enhances agility.
The best architectures, requirements, and designs emerge from self-organizing teams.
Inverting this value is bad, bad, bad
It’s easy to invert these values. Consistency is very tempting for many reasons we can articulate and for reasons we may not be able to. I think humans subliminally want consistency, even when they cognitively grasp that it’s not important. But that’s a question for psychologists, not a learned-it-on-the-street developer.
Here are some of the reasons I’ve been given for valuing consistency over productivity in the past:
Cost savings from buying stuff in bulk (“Microsoft will give us a better deal if we buy 1000 licenses”)
Ease of managing employee computers (“one image to rule them all”
Network security (“we can’t protect our data assets if we don’t know exactly what is connecting to our network”)
Commoditization of employees (“if Dave gets hit by a bus I can’t jump on his projects cuz I’d have to learn HAML first”)
These might be legitimate problems that need to be addressed. I’m not saying they don’t matter. I just don’t think consistency is the answer to ANY of these problems. There are other answers that are better, such as:
Use open source tools
Provide high-tech employees some general guidelines and let them do whatever they want with their equipment
A network that doesn’t care what you are connecting with is less vulnerable than one that does
Learn a new skill
These won’t always work, but when they don’t, other answers will. The point is, don’t invert the values. Don’t sacrifice productivity of teams or individuals for consistencies sake. That is not a good tradeoff – I think you almost always lose money, and the longer you do it the bigger the loss.
Ryan Bates is the owner of Railscasts.com, an invaluable resource to the Ruby on Rails developer community. Each week or so, he publishes a screencast of about ten minutes that highlights a technique in rails that he has found useful. He also maintains a number of popular ruby gems.
About a week ago Ryan tweeted this:
Introducing RailsCasts Pro! More RailsCasts goodness for just $9 per month! t.co/0TuBJOfG
THREE DAYS LATER, he tweeted this:
Thank you all who have signed up to RailsCasts Pro. Now I will be able to work on RailsCasts full time!
That’s right. It took Ryan Bates three days to sign up enough users to replace the income of a full time job.
Ryan Bates is NOT an overnight success.
Ryan posted the first RailsCast in March of 2007. By the time he announced RailsCasts Pro he had published 285 episodes, or roughly 48 hours of content. What seems like an overnight success at first blush is really the result of 4 1/2 years of persistent effort.
Knowing how long Ryan has been working on Railscasts makes his 3-day victory all the more remarkable to me and is frankly one of the more inspiring entrepreneurial stories I’ve ever witnessed.
The secrets to Ryan’s success
I’ve been watching Railscasts for almost 4 years, and I have made a few observations about what has made Railscasts successful that should be noted by other web entrepreneurs.
Be friendly
Ryan Bates could be the meanest guy on the planet in person, but I doubt it. On the interwebs, he is always friendly, easy-going, and helpful. It is easy like Ryan, even virtually. In an age when lots of people try to gain notoriety through snarkiness, Ryan is a nice guy. Snarkiness wears on people, and while entertaining from time-to-time, eventually we are all glad when the always-snarky guys just go away.
Be valuable
Ryan’s content is awesome, focused, and editorialization-free. In ten minutes or less you can learn something that makes you better. Nobody is going to bother with FREE content that isn’t valuable, much less paid content.
Be consistent
When Railscasts started, new episodes showed up every 2-4 days. For the last couple of years, a new episode has showed up every Monday. You can count on a new episode every Monday without fail. As a result, I trust Ryan. When he says Railscasts Pro will be worth it, I BELIEVE HIM. It’s obvious he’s not going to turn into an overnight flake.
Be passionate
I’d be surprised if Ryan thought Railscasts was going to become a full time pursuit in March of 2007. He might have daydreamed it would, but it seems unlikely that making a living was the motivation behind Railscasts. Nobody would keep plugging away for 4 1/2 years the way Ryan has done for purely financial motives.
Be responsive
Go read the comments on some of the Railscasts. There are a lot of questions there. And a lot of answers. From Ryan. It’s one thing to publish content that is helpful, but Ryan takes it up a notch by following through with additional help.
Be part of your community
Railscasts is not a community. Ruby on Rails is the community, and Ryan is part of it. Not just through Railscasts, but also through the gems he maintains. It’s better to be an important part of a larger community than to build a community of which you are the epicenter. The ruby on rails world doesn’t revolve around Ryan Bates and he doesn’t want it to – by all appearances he merely wants to be a valuable contributor to that society of developers.
The fundamental truth behind the success of Railscasts Pro
There is something basic here we should all learn from. I’ve been thinking about it all weekend, and I think the best way to summarize how Railscasts Pro became an overnight success comes from my friend Mike Herrick (@mherrick66):
Do good things and good things will happen.
Thanks Ryan, for 4 1/2 years of good stuff. Keep it up – I hope you make a bazillion dollars.
Uncle Bob Martin Gets Me All Fired Up
I was perusing my twitter feed this morning and found myself reading Screaming Architecture by Uncle Bob Martin. Uncle Bob is basically making the point that architecture and frameworks are not the same thing and he uses the construction design process as a metaphor for making this point.
I found myself immediately hostile to the notion, and using Uncle Bob’s metaphor as a weapon against him. The argument went something like this:
Architects pick a number of frameworks before they ever fire up AutoCAD. First off, they know it is going to be a building, and usually what type of building it is. “It’s a house” has a framework: bedrooms, kitchen, bathroom, etc. “Building” has a framework: floors, ceiling, plumbing, electricity. The construction method is also part of the framework: stick-build, structural brick, straw bale, etc. These are all frameworks that are chosen before the architect picks up a stylus.
I was pretty fired up.
The Funny Thing Is, I Agree with Uncle Bob
The other day I lost a proposal to build a web app for a client. I had proposed a rails project to deliver some interactive content. In the end, she went another way because she realized she didn’t need a “rails” solution. She needed a solution. As she explained it to me, I found myself agreeing with her and chiding myself for pushing a framework too early.
I’m a proud believer in deferring to the last responsible moment. I often fail at it, just like anyone else, but I grok it, at least in the cognitive sense.
So why did I get all mad about “Screaming Architecture”?
It’s simple really. The construction metaphor is all wrong for software. It can be twisted and abused to argue for anything you want. I’ve seen it used to make a case for big upfront design and requirements (“You wouldn’t build a house without knowing exactly what your customer wants!”), for contract-driven-development (“You sign off on plans before you break ground, don’t you”), for specialization (“Would you use a plumber to frame your house?”), and many other concepts I consider harmful when building software.
Building software is not like building a house. Sorry people.
Building software is like building software
Years ago I witnessed a mini-rant by either Brian Marick or Michael Feathers (they were both there and I can’t remember which one of them said it). The gist of the rant was that we need to stop appealing to metaphors to make a case for building software and just deal with the realities of building software.
I didn’t get it then. I do now.
When we use metaphors to advance a concept about software development we make the conversation theological in nature rather than practical. You can’t PROVE that building software is like building a house – you can only BELIEVE it. You can’t TEST this belief, you can only PREACH it. And sadly, believing building software is like building anything not software can blind you to learning and growth when you encounter a new idea that doesn’t fit neatly into your metaphor for software development.
So, at least if you want me to listen to you, please stop using metaphors for software development. Building software is like building software.
I’m not finished yet – it’s a very long grind to read this book. That’s two in a row – I need a good book next!
Peter Hamilton weaves an intricate plot with lots of story lines. I’ve never read a book with so many story lines before in my life, and I’ve read thousands of books. It’s impressive that he thinks his stories through so thoroughly, but a book is more than its story lines, and this book is lacking in other areas, particularly pace and character development. Peter introduces you to many, many characters, but you don’t spend enough time with any of them to actually like them, just enough to get to know their irritating idiosyncrasies. As for pace, this book really drags on, and because of all the story lines it’s so long between each one that I lose track of who’s who.
On the plus side, I find the author’s description of the impact of traveling by wormholes on society to be pretty interesting. Unfortunately, you could fit that in a 1000 word essay pretty easily. Just saying.
I’ve tried introducing agile in lots of different ways, and I’ve seen it done lots of different ways. I’m not talking here about scrum vs xp or anything like that – I’m talking about the context in which an organization attempts to use agile. Here are several variations that I’ve either tried or seen, along with my opinions about their effectiveness.
Subversive Agile
The first time I tried to use agile I didn’t have anyone’s permission. I also didn’t go out of my way to give what I was doing a name – instead I just described how we were going to roll to my team without labeling it agile. When my business partner sent me a 30+ page requirements document she had written prior to even initiating the project (WaterFAIL!), I just said “Why don’t you tell me about the most important thing on that list and we’ll just start with that.” She described the #1 thing, I wrote a story, and we planned our first iteration. Only… I was the only one who knew it was an iteration.
Fortunately, we were successful, and people started to catch on. My business partner was the first person to label it – she called me up one day and ratted me out.
Her: I know what you’re doing.
Me: Um, what?
Her: I read about it in a magazine. You’re doing agile.
Long pause.
Her: I like it. I’m going to tell your department that I want all the projects I fund run this way.
Subversive agile is the second most effective means of spreading agile throughout an organization that I’ve seen because it breeds copycats that can lead to a critical mass of agilists. It also gives you time to struggle with the agile values without outside interference, which can be critical in a culture steeped in waterFAIL.
Stealth Agile
Stealth agile is just like subversive agile, except you intentionally try to disguise it as something else, usually waterFAIL. Project managers use stealth agile when they aren’t allowed to officially use agile (usually because of religious zealotry on the part of the CIO or PMO) but she doesn’t want to fail. Johanna Rothman‘s book Manage It!: Your Guide to Modern, Pragmatic Project Management
has some great pointers on how to do this well. The core feature of this approach are two sets of plans: a waterfall gantt chart for the public, and release and iteration plans for you.
Stealth agile will help your project succeed and will help your career, but unless you get outed or come clean it won’t drive agile adoption in your organization. If you are doing stealth agile, you should be looking for that perfect moment to come clean in a way that paves the way for a broader agile adoption.
Deterministic Agile
In deterministic agile, the PMO or some other group or person drives the agile adoption and they set up a comprehensive plan detailing exactly how and when agile is going to be rolled out. They analyze all the in-flight projects and decide from above which ones make sense to switch to agile and which ones don’t. They make decisions for the whole company about which practices are critical and what the standard agile deliverables are going to be. They schedule training, they find coaches, they tear down old flowcharts and replace them with new ones. In short, they get everything planned for a nice deterministic transition to agile with no surprises and no risk.
Sigh. Organizations that use this approach have completely missed the point of agile. YOU CAN’T WATERFALL YOUR WAY INTO AGILE. This approach is going to fail, primarily because no one is taking into account the time and unpredictability involved in really integrating the agile values with an organization.
Punitive Agile Punitive agile is the last phase of a waterfall project, when project leaders shed all but the essential processes and artifacts needed to finish things up. This usually means discarding requirements documents, change control processes, and gantt charts in favor of pair programming, work backlogs, and short feedback loops. Unfortunately, it also includes long hours and intense scrutiny from management, thus resulting in the “punitive” label.
Punitive agile can be a pre-cursor to real agile, if someone is smart enough to realize that they would have been better off if they worked that way all along, minus the long hours. Unfortunately, this often ends up going the other way – at the “post-mortem” meeting team members blame poor requirements, not enough time to do proper design, etc for the difficulties at the end. This naturally results in the team committing to doing more of the things that got them in trouble in the first place – spending too much time getting ready and not enough time actually building software.
Declarative Agile
This is an agile-in-name-only approach. It’s worse than deterministic agile because not only does the organization not share the agile values, they don’t really even know what agile is. They only hear what they want to hear, make a few token changes, and then tell the world that they are agile. Usually the motivation behind this approach is more about impressing customers, investors, and board members than it is about actually improving your chances of success with an agile project.
The payoff for this approach is superficial and short-lived. Worse still, it gives agile a black eye by promising improvement but not delivering any real change.
Agnostic Agile
Agnostic agile is characterized by an unwillingness to establish a preference for agile over other software development approaches. In and of itself, this isn’t a bad thing at a personal level. If you don’t have experience with agile, you probably shouldn’t just jump on the bandwagon without some gradual experimentation to see for yourself if agile will work. I’d rather work with a skeptical but willing new agilist than an inexperienced zealot – it’s easier to teach the former than the latter.
The problem is when agnosticism is institutionalized and standards for choosing which projects are agile and which are waterFAIL are set up. Often this includes the creation of a committee to make those decisions. For some reason, whenever I ask advocates of this approach which projects should be agile and which projects should be waterFAIL, the answer is always the same: small straightforward projects can be agile, but big risky projects need the risk management features of waterFAIL.
Sigh. People who advocate for this approach are being passively resistant. They are really only pretending to be agnostic because they are not confident enough to oppose agile openly. They try to relegate agile to projects they don’t care about out of political expediency in hopes that they will be able to preserve the status quo but satisfy whoever is pushing the transition to agile.
I have mixed feelings about this approach. To me, the “goodness” or “badness” of this approach depends on how agile is being driven. If it’s being driven from the bottom up by subversive agilists, this might be a major victory. Run with it, then let the successful small projects convince more people until there is critical mass to try it on a large project. If the agile transition is driven from the top it’s an different matter entirely. This sort of passive aggressive resistance should not be tolerated. Take a stand.
An Agile Agile Transition
Guess what I think the most effective way to transition to agile is? Agile! The most effective agile transitions are driven by the agile values, first and foremost. Here are the key characteristics of this type of transition.
An agile agile transition is supported from the top with the critical decisions being made at the bottom. The leaders of an organization provide permission, resources, and support for experimenting with agile, but they don’t try to dictate how it is executed or make strategic decisions about where it is applied. Instead, they make a conscious decision to trust their people and let them decide. THIS IS FREAKING HARD TO DO FOR LEADERS.
Leaders focus on removing obstacles to using agile as their teams encounter them. One of the first obstacles is usually knowledge about what agile is and how it’s supposed to work, so they provide training. The first agile training session is a great litmus test for things to come, especially if enrollment is open to anyone in the organization. The people who want to be there are your best candidates for trying agile first.
Leaders make public shows of support for agile. This happens for two reasons – to tell agile teams that they have permission and to reduce resistance by others. This shouldn’t be dramatic or come off as a marketing campaign. Instead, when leaders are asked about it they should say things like “Yes, we are trying to improve our chances for success by experimenting with agile and we expect everyone to cooperate”. Couching the transition as an experiment is important because 1) it is honest and 2) it gives people time to learn for themselves.
You eventually make it clear that agile is the preferred approach. Why eventually? Because until it is clearly successful, you don’t really know that agile is the preferred approach. Until it works, you need to remain skeptically engaged.
You don’t dictate which projects use agile and which don’t. Instead, you let the teams that want to do agile do it. Following the enthusiasm dramatically increases your odds of being successful and give the unenthusiastic time to learn, grow, and change.
Deliverables, processes, and tools are not standardized until the last responsible moment. Let teams try different things, then get back together, compare notes, and decide on a common approach.
People are given time to struggle with the agile values. If you have been immersed in waterFAIL for decades, as many organizations have, the transition to agile is going to require a lot of change. I’m not talking about pure process change – if it were that simple everyone would be doing agile successfully. Value change is very, very hard and is fraught with emotion and resistance. Leaders and coaches need to be prepared for this and available to help team members through it.
How Stetson Kennedy Killed the KKK
In the 1940′s author and human rights activist Stetson Kennedy infiltrated the Ku Klux Klan and exposed its secrets to the world (and the police). As a result of his actions the klan lost its national charter. More importantly, klan members abandoned the perverse cause in droves as a result of the humiliation Kennedy’s exposure brought, relegating the nefarious club for bigots to the butt end of jokes & mockery.
Mockery of the klan had a huge role in its downfall. I heard Stetson Kennedy talk about this almost a decade ago (he died this year) in an NPR interview. He explained how after he exposed the klan’s secrets, you could see kids play “Cops & klansmen”, where the cops always won and the klansmen always lost. It was humiliating to klan members, and most of the klan split as a result. Good riddance.
Let’s Do the Same Thing to WaterFAIL
There’s something to learn here. When rational debate fails to correct stubbornly errant behavior, mockery just might do what civility could not.
Don’t get me wrong. I’m not a mean guy. But I’m sick and tired of people in the software development industry who persist in believing that phase-based project management practices (aka ‘waterfall’) are an appropriate approach for building software. It’s not. It doesn’t work. People who believe otherwise are harming the industry, their employers, and their careers. So let’s give them some tough love and help them get off that bus.
Just Say WaterFAIL
Let’s just start calling any project that is engaged in Big Up Front Anything (requirements, design, analysis) a Waterfail project. That’s not a mis-spelling – it’s waterFAIL. Because that’s what waterfall projects do. They fail. At least 70% of the time, according to the instructor who helped my pass the PMP exam.
Say it with a smirk. Every time you get a chance.
Here’s an example of what I mean:
Joe PM: Hey Bob. What’s cooking dude?
Bob Developer: Just found out I got put on your new waterFAIL project. I’m real excited about it (Rolls eyes and walks away).
There Can Be No Doubt that waterFAIL is Misguided and Risky
Some of you are gonna get pissed off by this. I don’t care. If you believe in waterFAIL in 2011 for software projects then I feel sorry for you. Guess what? The earth is round. waterFAIL doesn’t work for software. Sorry.
The riskiness of waterFAIL is indisputable. Ironically, the best evidence for this comes from it’s greatest advocate, the Project Management Institute (PMI). They have all sorts of statistics about the failure rates of software projects and they drill them into the heads of their members who attempt the admirably difficult PMP exam (at least they require their acolytes to really understand their mythology in detail!). The cognitive dissonance lies in their failure to associate software project failure rates with their approach. Instead they try to do even more of the things that caused them to fail in the first place: they spend more time writing and analyzing requirements and less time building and testing software. That’s not gonna work, and it’s kind of insane.
Please help save the world from WaterFAIL
Just mix it in with your work conversation. You don’t have to get on a soapbox like I’ve done here. Just sneer, smirk, or roll your eyes and call out waterFAIL projects anytime you see them.
PivotalTracker is super popular for a reason – it’s totally awesome. And ever since pivotallabs started charging for subscriptions, it seems to get better on a regular basis.
We use PT with all of our software development projects at DeveloperTown as a natural complement to the agile development process we follow. We love using it, and so do our clients, once they understand 1) how to write good user stories in PT and 2) how it fits in the overall development workflow.
After informally teaching clients these things at least a dozen times, I decided to just write a little workshop to cover the subject. Based on User Stories Applied by Mike Cohn, User Stories for Business People is a one day workshop that teaches stakeholders, product owners, and subject matter experts how to write stories that an agile development team can use effectively as they iteratively build your product.
Here are some of the things we cover:
What is a user story?
The life of a user story
What makes a good user story?
How to write user acceptance tests
How to plan an iteration
Pivotal Tracker settings and other features
This class is a hands-on workshop. Students work in pairs throughout the class and computers are required. It would be pretty hard to practice using PivotalTracker without computers!
This workshop is available onsite at your location, or you can take it at DeveloperTown in Indianapolis. Send me an email at dave@techdarkside.com if you are interested in learning more.
Growth? We don’t need no stinking growth
For the past three years, I’ve largely ignored the marketing, sales, and operations side of TroopTrack. I really wasn’t trying to grow my subscriber base, increase revenues, etc for a couple of reasons:
I was concerned about application stability. I was getting lots and lots of emails from exceptional. Every one of those emails meant a user had gotten a 500 error trying to use TroopTrack.
I was concerned about my feature set. I was still getting requests for big changes from users. That bothered me because I interpreted it as meaning my feature set was not rich enough.
My conversion rate was too low. I wasn’t happy with 1 out of 8 troops that tried TroopTrack buying it. I wanted to see that get closer to 1 out of 5.
I already had a reasonably active user base that was helping me figure out what to change, what to fix, what to add. I didn’t need more customers to achieve my goals of stabilizing the app and rounding out the feature set
I was already getting enough new trial customers to tell if I was improving conversion rates.
You take all these things and growing wasn’t really my priority. The new user experience was just not good enough to warrant trying to put TroopTrack in front of even more people.
The times, they are a-changin’
TroopTrack is pretty durn stable now. I don’t get anywhere near the number of emails from exceptional I used to. Feature requests tend to be smaller and are focused on tweaking things rather than adding massive new features. My conversion rate is way up (ironically, this is partly due to me doing some non-techy stuff lately).
I am rapidly approaching what I think is a very significant milestone – in the next two weeks TroopTrack will get its 100th paying customer. Everybody pause and say “Yay!”. It took TroopTrack more than 3 years and 800 trial customers to get here – we need to figure out how to get the next 100 customers in 3 months, not 3 years, if I am going to reach my goal of 5000 paying troops before I die.
I think I can do it – I just need to figure out how. Since I’m no marketing genius, I started looking around me for people who are.
Learning from the BodyShopBids Team
I recently did a little work for bodyshopbids.com. Most of the work I did from home, but I spent a few days hanging out in their office at Lightbank while I worked on the site. It was cool to watch Brad Weissberg (President of BodyShopBids) and his team busting their butts to build their business. I saw them calling customers and body shops. I saw them talking about the cost of customer acquisition. I watched as they argued and argued about how to drive more users to make choices and commitments.
I won’t lie. It was impressive. Brad and his team act like people who really believe in their product. This makes them ballsy and persistent. They are totally awesome.
It made me think about what I was doing, and what I wasn’t doing. I realized that I had finally gotten to the point where I believed in my product’s sale-ability and that it was high time I started acting like a person who really believes in their product.
One day, as I was driving home from the Lightbank offices, it hit me.
The Epiphany
Having a product is not the same thing as having a business
So, I have a product. I think it is the best scouting software product you can get. It’s not the best it can be, but it’s better than anything I can find.
But I don’t have a business.
Not yet.
I’ve spent the last 3 years doing customer discovery, product development, and product support. I’ve even managed to make a profit for most of that time.
But for this product to become a business, it needs a CEO. A CEO who sells the product. A CEO who operationalizes the business. A CEO who creates market strategies and then drives them forward.
Interested in the position? Sorry, it’s already filled. I already hired someone.
Me. You can call me Mister Christiansen from now on, thank you very much.
I’ve got a lot to learn. I owe the gutsy guys over at BodyShopBids.com some thanks for pushing me into conscious incompetence, for encouraging me to call my customers, and for helping me see this problem as totally, 100% solvable.
It’s amazing what you can learn in just a few days watching the competent kick tail.
So thanks, Brad, Dave, and Alex.
PS. If you crash your car, go to bodyshopbids.com. They will hook you up. They gotta guy.
DeveloperTown has an interesting business model – we get paid based on the total points of user stories accepted during a billing cycle. So if our bill rate is $500 dollars per point, and you (please pretend to be a client) accepted six stories for 10 points, rejected one stories worth 3 points because it introduced a bug we didn’t catch, and deferred one story worth 2 points because we didn’t get to it, we would only bill $5000 and get to work on the two other stories. When they are finished, we would bill for the remaining $2500.
You’re probably wondering what a point is right about now. Well… it’s a totally arbitrary measurement of how difficult something is. It’s a relative estimation technique based on a reference scale of 0, 1, 2, 3, 5, and 8 points. To use the scale, you first have to establish what 3 or 5 means. For me, I usually base everything off of 3. In Ruby on Rails terms, a 3 for me is a whole new MVC stack of medium complexity. In other words, I’m creating at least one new table, a model, a controller, associated views, and tests for all of it. When we estimate stories, we compare the work requested to our reference point for a 3. If it’s harder, it would be a 5 or an 8 depending on how much harder it is. If it’s easier, it’s a 0, 1, or a 2, depending on its relative easiness.
Once we estimate a story, the customer prioritizes the story based on their understanding of its cost and value. Then we do it. If you’d like to see an example of this in action, check out my TroopTrack user stories. PivotalTracker then uses historical data about our progress to figure out roughly how long it’s going to take to complete those stories. Then we start.
Why I Like It
The Customer Gets What They Want
We don’t get paid if you don’t like our work. That gives you an appropriate amount of power to leverage in the development process. I’ll explain why it’s appropriate in the next bit. As a developer, it feels good when a customer accepts a story. It also feels good when a customer rejects a story for a good reason, because it means we have prevented a mistake from making it into the finished product. Both of these things mean a better product.
Short Feedback Loops
We accept and reject stories in two week increments. That means we are getting regular feedback on our work and course corrections are minor, not major. We might get off course occasionally, but we don’t get very far in the wrong direction before getting hauled back in. This is good for us and the customer.
Small Commitments Mean Breaking Up is Easy to Do
Some people are hard to work with. Some people refuse to change frustrating behavior. Sometimes that’s me, the developer. Sometimes it’s you, the customer. Either way, if we decide to part ways, we aren’t out all that much – two weeks at the most. That’s a relatively low risk. Breaking up is still kind of a nuclear option, but the financial consequences are limited. Because of that, talking about problems is easier. What’s the worse that can happen if I suggest a customer change their behavior and they freak out? not that bad. So, there’s little harm in asking for better behavior. Best of all, this is a two way street. The customer can ask me to do a better job too, and the nuclear option if I respond like a bratty primadonna is, well, not that nuclear.
You Don’t Get Punished for My Bad Estimation, Incompetence, or Laziness
If you’re paying me by the hour, and you ask me to do something easy and I make it really hard and it takes a long time or I have to do it over, guess what? You get to pay me to fight my way out of the corner I painted myself into. Sigh. That makes me unhappy. Also, if I’m on the clock, and someone calls me and talks to me for 30 minutes and I forget to turn off the clock, guess what? You just paid me to talk to my dad. That’s not fair. Also, if I estimate something at 5 hours and it takes 8, you pay me for 8 hours. Not cool.
The points system takes all these problems off the field, and the law of large numbers means that I can still have a predictable income as a developer. Sure, that three point story just took me longer than I thought it would, but eventually it all evens out when a 2 point story goes smoothly.
How You (the Customer) Can Screw It Up
Don’t Do Any Testing Yourself
Demos are an important part of agile software development. They are great for ‘capping’ an iteration, tweaking features, and figuring out what to do next. They are also a natural point to accept and reject stories. Demos are not, however, the whole mechanism for doing these things and if you rely entirely on demos for these things you are putting yourself in a bad position. It might still work out overall, but it will create some inefficiencies that will cost you.
The biggest problem with relying too much on demos is you aren’t touching the software. Demos are not the same thing as testing. You need to test, and you need to do it in real time. When a developer delivers a finished story to the testing environment, you need to get in there within 24 hours and test it. If you wait until the end of an iteration and only look at the feature while I demo it, you have squandered all the time that has passed since I finished the story. You could have found a problem, tweaked the interface, and got it just right BEFORE the demo. At the demo, you’re not going to find the same bugs you would have found clicking on the app yourself, and your focus is going to be primarily on the user experience. Instead, you’ll find the bugs when it gets pushed to production. More accurately, your customers will find them.
Rely on us to write and prioritize stories
Sometimes a customer will rely too much on developers to prioritize stories. This isn’t a good idea, because developers don’t tend to prioritize stories based on value. Instead, our tendency is to prioritize stories based on 1) what features are most interesting to us and 2) what is technically most appealing. Next thing you know, we built sharks with laser beams on their heads when all you needed was a bullet in Austin Powers’ face.
Don’t defer to developers. Engage! Write the stories yourself. Put some thought into them. Prioritize them yourself, and don’t let developers talk you into more than you need. Most importantly, don’t let developers convince you that you need a whole lot of infrastructure-ish sounding stuff just to do something. Most of the time it’s not true – developers are keen to optimize things prematurely. This is hard to explain, so here’s an example.
Customer Jones wants a site with videos, and he wants an admin console for managing all those videos, so he writes some stories for that. Developer Dave looks at the video stories and ask if Jones is ever going to do podcasts. Jones thinks about it and says ‘Yeah, maybe.’ Developer Dave says ‘Sweet. Can we change the stories so that we are building a generic media management system? That way, when you decide to add podcasts, you won’t need to change anything.’
Just smile condescendingly and say no. Build the stupid media management system when you need it and don’t let me talk you into anything else.
Assume you know how to write and test stories
Read User Stories Applied and write stories like that. Talk to me, Mike Kelly, or someone else who is knowledgeable about exploratory testing and ask for a two-hour exploratory testing primer.
Why does this matter? Because once you accept a story you have to pay for it. Also, once you accept a story it goes into the queue of stuff going into production. Sure, we test too, but the sad fact is it’s hard to test your own code. Real hard. Plus, we don’t come equipped with all the expectations you have about the product that can’t be expressed easily.
Marry Your Development Partner by Committing to a Large Point “Purchase”
I haven’t seen DeveloperTown do this, but I know some places will sell blocks of points, to be delivered over X months. Typically a goal is defined, a number of points (i.e. 300) is estimated, and a date is given.
Why make an unnecessary commitment like this? There’s very little benefit to you the customer as a result of contractually committing in this way, and it gives us too much leverage over you by increasing the cost of breaking up. Unless there is a pressing, important reason for a marriage like this you should shy away from it. Instead, just collaborate with us. Let us know what you think the overall schedule is, update us as things change, and insist on a more casual commitment. Don’t marry us. Date us. Things might not work out.
The Big Picture
Charging customers by the point takes a lot of risk out of outsourcing work to guys like me that simply can’t be addressed by fixed-bid or hourly consulting arrangements. Fixed bid locks you in at a time when you know the least (risky!) and hourly tends to let costs spiral out of control. Neither approach works. Just go find a PMP (Project Management Professional) and ask him how many IT projects get finished on budget (just don’t ask him how to fix the problem – he’s got the wrong answer!). When you pay me by the point, you avoid both of these problems. You know how much things will cost, and you can change direction when you need to without negotiating an entirely new contract. And, at any time, you can call it off, take your code, and go home. And guess what – because we managed the project with user stories rather than Big Up Front Requirements, the code you are going home with actually works and has value. Best of all, it creates a balance of power that reduces the risk of facing issues and fixing stuff. It’s good for the me, the developer, and it’s good for you, the customer.
