The Principles of Done

Phillip Cave, SolutionsIQ, http://www.solutionsiq.com/, @SolutionsIQ

Simplicity. Why do we, in general, get so hung up on getting stuff done?

There are two things that I wish everyone could experience. One of them is driving on the Autobahn in a Porsche 911 at over 200km/hour. The other is for software engineers to build and deliver product from scratch in a technology startup.

If the first wish came true, then I would not be stuck behind slow drivers in the fast lane. It is a PASSING lane people, and I mean pass within the next hundred feet, NOT mile. Pass and move over, don’t police me by thinking I should obey the speed limit (speed limits are suggestions in my mind). Thus, I love the Autobahn. Germans know how to drive.

Another wish is for all people in the software world to experience living and succeeding at a product company startup. Like driving on the Autobahn, startup companies must move. Startups must get stuff done - or they will not be around. When they finally ship, it is in hopes of being successful. My experience in a startup taught me the fine balance of what we now call a minimal viable product.

When I am coaching companies on implementing Agile, I often find myself saying, "You forgot what it was to be a startup". All companies are startups at one point in their history. Some people who started the company may still be around, but often that is not the case. Something happens along the way. People within a maturing startup look to become efficient over effective. The leadership looks to optimize in small ways but forgets to look at the larger picture. The product grows and the value stream to deliver features grows. This growth creates a dynamic of increased coordination and transaction costs. These costs appear in the guise of a lot of documentation about how to manage the coordination and transaction costs. The thinking is that we may forget what we said we wanted, so we’d better write it down, create an approval process, and create a lot of artifacts to coordinate our activities and agreements.

I am always fascinated by this growth pattern. Having experienced startup thinking and large corporate thinking, I began exploring why some patterns emerged as companies grew. Part of this pattern is found in titles, trust, and an attempt to create security.

There is work (the features we deliver to customers) and there are people to do the work. At my first startup, I managed the entire value stream as a software engineer. I did all the work. The discovery, analysis, exploring options, prototyping, UX, design, coding, testing, writing (did I leave anything out? I did that too.). So, too, did the other two engineers I worked with to architect the product from scratch. We each took responsibility for different areas of the business domain to create the product. We collaborated multiple times per day, every day, on the technical architecture and design. We made decisions in the moment, made adjustments, and got stuff done. We iterated on the product every single day to get more and more stuff done. We had no ginormous specification - we had a collection of user-based experiences. We had a business domain expert on staff with whom we collaborated daily so that we could get stuff done, every day.

Growth created specialization in a lot of companies. Instead of one person being able to do the work (e.g. implement a customer feature), we began segmenting that work. The customer still wanted the same features delivered, but how we delivered it changed.

Specialization is not likely to go away, and I am not advocating that it should. I am reminding people that with change comes managing change. How we manage that change is integral to getting stuff done as effectively as possible. (Please note that I am NOT using the word "efficiently" - there is a difference). We tried to take a manufacturing model and apply it to software engineering and product development in hopes that it would help us manage that change, thinking that has prevailed for many years.

We talk a lot about getting to done, being "done done", exit criteria, acceptance criteria, and definition of done, definition of ready, and so on. These are all good implementations of the practice of getting done.

A couple of years ago, I came across a poster at Microsoft about the "cult of done". Someone put it up to remind the team that we were there to get stuff done regardless of our specialization. Microsoft was obviously a startup at one point, and then a lot of stuff happened and new people (a lot of new people) came on board. Those new people had their own comfort levels regarding how to get stuff done, which eventually led to creating a lot of specifications about making conversations more "efficient". A lot of command-and-control-style leadership was instituted, as at many companies in the industry, to help those people feel in control of this very complex environment. Like many organizations I consult with, Microsoft forgot how to be a startup. Not in all areas, mind you, but certainly in a lot of them.

All of my work (about 6 years) at Microsoft as both a consultant and FTE was about reminding teams and leadership of what a startup feels like, how startups (and larger companies that still operate like that way) succeed, and how they have the ability to run circles around larger companies with entrenched thinking. I had supporters and those who wondered what the heck I was doing there. I was called a Principal Program Manager to boot - just a title to me.

This article is meant to help you remember how to get stuff done just as if you were in a startup … remember those days? If you have never worked at a startup, much of what you read here will be new to you but perhaps it will resonate with the way you think of the world or speak to your inner systems-thinking views. My goal is to describe my experience in hopes that it spurs creating your own, right where you are.

As you read, please keep in mind that in all things we need a goal or target. Startups succeed, just as many companies do, because they understand reaching a goal and target. Where they differ is that the culture of a startup more easily adjusts to learning. Getting to done does not mean that we don’t think about where we are going - we actually do. It means we create goals based on the information we have today, and then adjust those goals as necessary when we receive new information. Would a startup take four months to determine its goals? Probably not. So with this thought, please read on.

These principles of being done reflect my experiences during my 24-year career in the software industry, startups and otherwise. My inspiration comes from a very simple list in a blog post entitled The Cult of Done Manifesto by Bre Pettis and Kio Stark [1], to which I have added my thoughts.

1. There are three states of being: Not knowing, action, and completion

I will only take a moment to discuss the "not knowing" state. Your sole purpose when faced with "not knowing" is to start knowing, quickly. It fascinates me when people batch up work into ginormous requirements documents and treat all of those requirements as the same. Instead they should start working on what they absolutely know needs doing. Then they can figure out what they don’t know by creating short experiments to begin knowing. If a team is faced with considerable risk due to a lack of knowing, that team should start work on experimenting to gain knowledge. If you don’t know something that you really ought to know, then start to know it! That is the action part. Writing documentation is not action. Well, technically you are in motion as you type, but what are you getting done? A lot of words. How does that help the customer? Does the customer pay you to write a spec or deliver software? Yeah, yeah, you can argue that writing the spec helps me get to done and I will tell you that is a bunch of crap. Yes, you need to know what the feature is, what done means for the feature, what in initial look and feel may be, but that does not have to be in a 500-page spec - it just needs to be a notation somewhere. That somewhere could be a white board or a list of stories in a spreadsheet or jotted down in a collection of features and stories in the cloud. I wrote multi-million dollar software without a 500-page spec, so don’t tell me you need it. We had a white board and conducted A LOT of experimentation with design and writing code. Actually doing something is action. Discovering something cannot be accomplished by writing a specification. You can’t get to done until you start, so start building or start learning what to build by creating experiments that deliver information. In both of those cases, begin creating something so you can get to done.

2. Accept that everything is a draft. It helps to get to done.

Too often I have heard the words, "But we might have to throw it away if we don’t get it right," to which I reply "…and … <pause for effect> how do you know it is wrong or right until you get feedback? You can’t get feedback on what the thing should do until you actually start to build it. So guess what? You will have ‘throw-away’ work because you are going to learn later what to keep and what not to keep. So quit your whining and get it done."

A favorite movie of mine is Disney’s The Kid. Bruce Willis is an "image consultant", and one of my favorite lines comes at the moment he tells a political figure to stop her whining. "Somebody call the waaaaaaambulance," he says. I say that internally much of the time. Instead of focusing on what can’t be done, focus on what can be done. Some of my most fun I’ve had in architecting software products has been in discovering and saying out loud, "Well, that was complete crap! Next option?" A startup-thinking organization of people focuses on what can be done and then experiments to validate those assertions.

3. There is no editing stage.

Well, there actually is. It is when you are typing and you hit the backspace and retype. Other than that, build in small increments, validate in small increments, get feedback in small increments, deliver in small increments … get the idea? Small feedback cycles are much more conducive to achieving success. The longer you edit, the longer it takes to get to done.

Editing (other than the excellent people helping me edit this article, mind you J) is an excuse to postpone being done. I was once on a project at Microsoft that entailed building out a business scorecard. The new manager had just come from another area of the company and was what I call an entrenched thinker - stuck doing things the only way he knew how to, in big batches. Despite his many years in the industry, he had no other experience. When he observed the quick/iterative process I had implemented and the empowerment to start and do something that came along with it, he commented about how cool it was to see a working model within a few weeks instead of months. The interesting thing about this guy was that he could not let go of the old big-batch thinking model, so my functional specification was woefully behind what the team was actually accomplishing. I met with the team every day to discuss options and then build them. They did not wait for me to produce a "how to build" document when the thing was already in the process of being built. This is how it should be. I left as soon as my stock vested and moved on to helping companies that actually want to learn how to build things instead of edit things. Sigh. I recognize it is a comfort-factor thing. There are people in the world who want to control everything and are afraid to try anything new, and then there are companies like Apple and certain divisions within Microsoft (like Xbox) that just do stuff and get it done. In those places, editing does not exist, only getting stuff done.

4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t, and do it.

Give yourself permission to start. Give yourself permission to experiment. Give your intuition some credit. Give yourself permission to explore what you don’t know and play so that you discover what you don’t know, and then get on to the other stuff you don’t know by experimenting.

Hell, there was plenty I didn’t know when I was starting out, but I was one of those people who loved to play around with stuff. I am a natural "What does that do?" and "Where does that road go?" kinda guy. I was never a "fake it ‘til you make it" person - I’m an "I don’t know, but let’s find out!" person.

Once I was on a short gig as a software engineer and the person who was responsible for indoctrinating me into the culture and technology stack was impatient. He just wanted me to follow his script step by step without explaining anything and without letting me experiment and learn by experimenting. I left there as quickly as possible. I call those kinda people lifers. They plant themselves at a conservative-thinking culture and retire. Not exactly disruptive, but not disruptive enough (or at all). Disruptions get us to new places - pretending that we know what we are doing and just doing it is what gets us there. They create innovation and transform old/crappy ways and products into new/better products and services and ways of doing stuff and getting it done.

You know how to start something, right? So pretend you know what you are doing and just start, which leads to…

5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.

When I coach teams, I tell them that if they spend more than a week trying to figure something out they are wasting their time and the time of the business. Figure stuff out by doing stuff in small experiments: Build and experiment. If you allow other stuff to get in the way, then the thing you were working on must not have been that interesting or important. Move on to a variant of the thing so that you actually get some value created, which really is the purpose of done … value creation.

I "love coach" friends to look at what people value by observing where they spend their time and money. If it is not spent on you, then it is time to find someone else that does spend time and money on you. It is the same with software products: Spend the most time and money on the stuff that matters most and get it done. Be nice to the feature you don’t like by just dumping it.

Procrastination may occur anywhere in the value stream and is best described for management as the cost of delay. In lean organizations, this metric is measured throughout the production process to objectively track the cost associated with making or not making decisions - delayed decisions create overhead and missed-opportunity costs.

When management and executives ask me what they should measure as they adopt Agile ways of delivering software, I tell them to quantify cycle time and the associated costs of delay. The idea of banishing procrastination is to minimize the costs of delay - delay of requirements, delay of estimates, delay of decisions, delay of coding, delay of testing, delay of implementing, and so on.

Delay means we are not done. Not being done costs money. So get done.

6. The point of being done is not to finish but to get other things done.

The point is to create value. The faster we can get one thing done, the faster we can get "done done" with other stuff. I coach teams on a pet phrase: "Stop Starting and Start Finishing". If you have too many things in process, then nothing is getting done. And if nothing is getting done, it means you are just procrastinating and we now know that procrastinating has a cost associated with it.

During my 24 years in the software industry, I have never had stuff I could not deliver. Well, except for that time at what is now Verizon Wireless and after our second merger during the days of cellular company buyouts and consolidations. I was essentially day trading while looking for my next job - just sitting on my ass as my position was being outsourced to a company in India. And that is when I went to my first startup, fed up with large corporations. It was there that I learned how to truly deliver software products. I am super-grateful for my time at my first startup. It taught me one thing well: You might look busy, but guess what? You are not providing value until you get stuff done, and you are not effective until you can move on to get more stuff done … so get it done. Once one thing is finished, it means we have the capacity and availability to get other things finished. And getting finished with the first release meant that we could get more customers to buy our product and get the next million-dollar contract. The more we finished, the more we had to do and the more customers we had.

7. Once you’re done, you can throw it away.

Sure, you take pride in creating stuff. I certainly did when I was creating solutions, especially at that first startup. But once created, then what? You move on to the next. At some point, the stuff you created will need to be changed. Or it will get thrown away because requirements have changed.

Products evolve. Evolution means we will improve it, at least we should. It means that the old stuff we are holding onto is stinky and moldy. Let it go. The world changes. So should our software. We can get so emotional about it. Let economics like cost of delay guide your decisions.

Consulting in many industries and companies over the years, I have often seen this inability to move on or move quickly enough through delivery cycles. Once a feature is done, it is on the fast track to obsolescence. You are not going to get it perfect, so stop pretending you should. You are going to throw it away and build the next version at some point, which leads to …

8. Laugh at perfection. It’s boring and keeps you from being done.

It means let the thing go, validate it, move on. Revisit it later when you have more information or have to adjust to something learned. This does not mean you abdicate quality!!! A saying I like is "The perfect is the enemy of the good." Perfection slows us down and causes us to second-guess and create blame. Perfection holds us back from making progress, from getting it in the hands of customers in order to validate what we created.

Perfection causes startups to go out of business. Adapting to learning causes startups to succeed. We learn by doing and exploring quickly. Perfection keeps us from learning more and learning faster. Perfection keeps us from learning what we should not do as well as what we should do. We are so busy trying to get something perfect that we delay learning, we delay releasing, and we delay succeeding.

Don’t "perfect" yourself right out of business. Get something done, learn from it, and build the "good enough" version and release it. Again, this does not mean that it is buggy software. It means that I don’t have to dwell on it or satisfy every customer, which is an interesting dysfunction I have seen in some of the companies I have consulted with over the years.

We can be so perfect at satisfying every customer that it creates dysfunctional decision making not based on what is best for the company. If I have a whiny customer that demands more than is economically feasible or if people in my own company subvert a sustainable sane pace to product delivery and do an end run around standard practices, this creates delay.

Just because a customer wants something does not mean we should build it to the detriment of the product or the teams building it. If it costs me more to have a customer then the value I am receiving, then it is time to think of replacing that customer with one that is more reasonable to work with. Instead of trying to create the perfect product for every client, create the best-quality product that meets most of the needs of most customers. Perfection costs more than the value you are getting out of it … in economics, they call that diminishing returns.

When you stop focusing on the perfect, you end up managing the work-in-process to stop starting things and focus on finishing things. Getting to done means focusing on the right activity at the right time to deliver and be done.

9. People without dirty hands are wrong. Doing something makes you right.

In lean thinking we are urged to "go to the gemba", which means go to the people doing the work because they know best how to change HOW we work. Design is not development. Get your hands dirty by doing something.

I do this every day in my career as an Agile management consultant. I am asked to go to the gemba when I "assess" a team. My version of an assessment is a little study and a lot of answering the "how do we?" questions - "How do we… re-estimate work, use story points vs. hours, create a portfolio budget with Agile, estimate large projects, change our organization design…?" I learn a lot about an organization, its teams, and its leadership by answering these questions.

Do something and get your hands dirty, whether you are a C-level exec, a manager, a developer, a tester, a program manager, or any other team member responsible for delivering products to market or supporting the business in your IT shop.

As an executive, your number one responsibility is to own the system in which your teams deliver products and create a culture of improving that system. As a manager or supervisor, your number one responsibility is to incrementally improve that system. Get your hands dirty.

When managers ask me what they’re supposed to do in an Agile world, I tell them that middle management has the super-important role of creating the best possible system for development, a duty that should not be taken lightly. Apply lean principles to help the team succeed by getting your hands dirty. Improve the HOW of how teams deliver.

If you are a developer of products and you are not testing, you are not getting your hands dirty. Your number one job is to deliver quality product, not pass it off to someone called a tester. You should not even need a tester. You build it, you test it. Get your hands dirty and get it done. Working with large systems, I may have testers in my environment that focus on testing the system interfaces and larger integrations, so their hands are dirty all the time.

If you are a tester - either a manual tester or a software development engineer in test (SDET) -your number one job is consulting with teams about how to build quality into the system. Your hands are dirty all the time with some of the crap you are handed from developers who should be doing some of their own validation. You may be busy, but are you effective? Stop the line. Create a quality mindset by showing teams how to build quality as they go instead of inspecting it at the end.

The point is: take responsibility and get your hands dirty by getting quality stuff done. Quality environment, quality delivery system, quality code, and quality product.

10. Failure counts as done. So do mistakes.

Getting done means we learned something. Something either worked, or did not work, or worked in a way we didn’t expect. Failure means we can now move on to the next thing, which will either work or not work. [2] It is okay to fail as long as we learn from it - what to do as well as what not to do.

A saying I like from my time in lean operations at a health insurance company is "fail forward fast". It means that sometimes failure happens and it is just fine, and it is better to find out sooner rather than later. This is because it helps us get to the done we want to arrive at. Riddle me this … if you are going to fail (and you sometimes will), would you rather fail quickly or slowly? Me, I want to do so quickly and learn what works. We fear failure in general. I believe this is because we may have been victim to management that punished failure instead of fostering an environment of learning. This leads to dysfunctional political posturing, CYA actions, and a legalistic "document everything up front" behavior in the belief this will mitigate failure. Here is a thought … what if we embraced learning and mitigating failure by finding mistakes quickly? This is just one of management’s responsibilities in a Lean culture: Create a learning environment and help teams find and correct mistakes quickly.

This speaks to an attitude of starting. Instead of being afraid to fail, which leads to not starting, just start already. Not starting is unacceptable failure. Trying something - learning from it and failing - helps me get other stuff that does not fail done.

I once dated someone who told me she made a mistake when it came to lying to me. That was not a mistake, it was a failure. A mistake is spilling your coffee. Mistakes are made when we don’t know any better or we are clumsy (or caffeine deprived). Failure takes purpose. So be purposeful in your failures. Meaning, run experiments. You may not be sure if the experiment will work, but it definitely won’t work if you don’t try it.

Try it, you’ll like it.

11. Destruction is a variant of done.

Some things should be destroyed, like old dilapidated buildings and zombies, and old crappy code … and zombies (cuz they just keep coming at you). Think of the mythical phoenix. Its destruction makes room for the next iteration or version. If you don’t need it, destroying it creates less complexity. If you need to improve it, start killing it off and replacing it with the next version. It’s okay to let go of bad investments and code that just is not allowing us to get stuff done as effectively as we want to.

My first startup did this. We destroyed the old platform and started a new one. (Thinking about it now, we should have called that project Phoenix! Sigh, missed opportunity.) The project was birthed because the old crappy architecture was not going to work at the enterprise level.

I am working with a customer that has what we call a legacy code base. I’m talking legacy. Old COBOL mixed with new Java (which isn’t so new no more) and CICS and … and … and. Yeah, you get the picture. I can navigate these waters because I started off in the tech industry as a COBOL programmer and migrated to object languages to end the coding phase of my career. My advice to this customer is to start destroying the legacy stuff and replacing it with not-so-legacy stuff (let’s face it - in one to three years, the new stuff will be legacy as well).

Destruction means we are done. In this case we want to be done really badly.

12. If you have an idea and publish it on the Internet, it counts as a ghost of done.

But ghosts have no real substance. This is exactly like a ginormous requirements document - it has no substance and it is a ghost of done. Done is taking what you wrote about in the requirements document and actually giving it life. Done = Life, and ain’t life grand?!

Alternatively, if someone picks up your idea that you published on the Web and then creates something (like the thought leader behind Tesla, Elon Musk, publishing his short and succinct idea for a high-speed train called the Hyperloop), then you contributed to done but you didn’t get it done. Since an idea is a ghost of done, why spend a lot of time trying to communicate it in a ginormous document when you can write it down as a placeholder, in a short sentence or two, which elicits real conversation that can lead to done?

I once wrote multi-million dollar selling software with two other people using a whiteboard for architecting and having A LOT of conversation. I snicker at documentation jockeys (heh heh). What a waste of time to think that putting a conversation into a document is a good idea. Publish a little, just enough to have a conversation. Thus I love one-pagers or story cards or small feature-driven documents. (I am speaking to documentation to deliver products, not documentation for the end user.) We do not need heavy documentation to tell us how to write code. We need a little documentation to communicate intent, what done means, and our decisions. But we need a lot of talking.

Write small and talk a lot, but mostly just get it done.

13. Done is the engine of more.

Finally being done with turning this blog series into an article means I can get to the other blog posts I want to write and customer work and improving our engagement model and and and …. Yeah you get the idea. Done = get more stuff done.

A story I like to tell is about working with a group at Microsoft. One of the PMs I collaborated with had a team that was faced with an ever-changing environment and specialty-based team members. During a standup, it was brought to the team’s attention that a story was blocked because the specialty team member was busy setting up his test environment. The team asked if he had to be the one to set up the environment. The answer was no, he did not have to be the one to set up his test environment and that, in fact, another team member could accomplish that task while he unblocked the team by working on the story.

Was it efficient for him to set up his own environment? Probably. Was it effective? Absolutely not. That story was about focusing on the work and not the team member, and reaching the most effective way in which to complete the work.

Getting done in one area helped the team get done, which created a team focus on done. Sounds like a well-run engine to me.

<this space left intentionally blank> … well, with the exception of actually containing the words "this space left intentionally blank" because then it is not really blank, is it?!  You are now done with your choice to read this article, now go get other stuff done. And may the force of done be with you … gesundheit!

References

1. The Cult of Done Manifesto by Bre Pettis and Kio Stark,
http://www.brepettis.com/blog/2009/3/3/the-cult-of-done-manifesto.html

2. Scott Adams' Secret of Success: Failure,
http://online.wsj.com/news/articles/SB10001424052702304626104579121813075903866

---

Agile and Scrum Articles

Agile Scrum Sprint Length: What is Right for You?

5 Tips for Getting Software Testing Done in the Scrum Sprint

Understanding the Scrum Burndown Chart

Agile and Scrum Resources

Scrum Expert

Agile Videos and Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Spring 2014 issue of Methods & Tools