The secret of getting ahead is getting started. – Mark Twain

There are a lot of people out there giving advice on how you can start your business. I’m not smart enough to be giving advice though so I’ll just tell you how I went about starting a startup.

The short version is Fun Panda was founded because I couldn’t find a customizable bamboo case for my iPad. The longer version is:

The Idea
Coming up with an idea is easy; implementing an idea is difficult. In fact, frustrated with my inability to get any ideas to take off, I started a company called MilliSeed with a tag line of “A million ideas; a thousand beginnings.” Will Fun Panda be different? To be honest, I don’t know, but I have learned a lot from a half a dozen failed businesses over a dozen years.

A big difference this time is it’s not just an idea. This is a frustration turned business plan. I’ve sat around with groups of brilliant people throwing concepts up on the wall. In those cases, we were trying to find a niche or create a market. In this case, the market already exists. There are large market segments for customized iPad cases and environmentally responsible product. There just wasn’t an existing solution for customizable responsible iPad cases.

The Market
The reason most of my earlier businesses failed is people didn’t want what I was selling. Sure, there was money to be made, and others with similar businesses were able to succeed where I didn’t. Maybe the ideas were too soon (search engine optimization in the late 90s, green lawn care in the mid 2000s). Maybe they were too late (baseball card inventory management long after most people stopped collecting). There are plenty of excuses, but the bottom line is that if more people were buying what I was selling those businesses would have been successful.

This time around, I have a much firmer grasp of the market and the opportunity. My living room is littered with print outs of projections, trends, and market analysis.

The Team
I learned my lesson several years ago when I partnered with a couple of guys to create grassroots organization software for political movements. I didn’t know these guys particularly well, and two months later, one of them was 1,000 miles away, not answering his phone, and holding all the vital info to run the business.

This time around, I wanted to work with friends. I interview a lot of people in my “real” job, and I’ve learned being friends with someone, even for a short period of time, will tell you more about a person than you will ever learn in an interview.

My checklist for partnering:

• A Friend
• Smart
• Gets Stuff Done
• Could stand to hang around for hours on end

There is always the possibility of going it alone, but for me, I’ve done that. You have the weight of the world on your shoulders, and when things don’t go according to plan, there’s no one there to hold you accountable, pick you up, or not allow you to quit. This time around, going it alone wasn’t an option.

The Money
Everyone I told about the customizable bamboo cases loved the idea, and when they saw the samples, the responses were amplified. This made for an odd problem – too many people wanted to invest. I followed the partner checklist above and found a couple of people who could help off-set some of the start-up costs.

This will become a new rule of thumb for me for future business ideas. If people aren’t fighting each other to invest in your business, it’s probably not a very good idea.

The Future
While I’ve made a couple of personal loans to the business, I also know where my bread is buttered. I have a great job that I love very much. I’m not going to go into debt to grow Fun Panda, but I’m also not going to be taking money out of the company. For now, invest and reinvest in the company, work hard at night and on the weekends, and see if we can’t grow this thing into something great.

In the end, no one knows exactly why anything works. Groupon was an accident.  HP turned down the personal computer idea 5 times before Steve Wozniak partnered with Steve Jobs to found Apple. For now, it’s a really fun project with a lot of potential.

If you’re looking for an iPhone or iPad case, check us out.

If you want to make an easy job seem mighty hard, just keep putting off doing it. – Olin Miller

Here’s a quick heads up. That six month project you just started – it’s going to take you seven months. If you’re clever and scheduled it for seven months – it’s going to take you eight. After spending my entire adult life sitting through one hour meetings that should have lasted 15 minutes, I am more confident than ever in Parkinson’s law.

If you’re not familiar with Parkinson, his law basically states, ‘work expands to fill the time available for completion.’ My addendum would be, “Plus 10%” – people tend to over-estimate their skills and under-estimate complexity.

Short Timeframes
If an atom, which literally means indivisible in Latin, can be divided; you can figure out how to divide your project too. Breaking a small piece off your project and setting a due date in the near future is the best way to push forward. If you can procrastinate and get it done; the timeframe isn’t short enough. This will create enough pressure to maximize productivity without limiting your ability to engage resources or be creative.

Concrete Deliverables
You’re much more likely to lose two pounds this week than your are to lose some weight. What is some weight? It’s an undefined deliverable that can be rationalized away. “I ate a bigger than usual lunch.” “I just drank a lot of water.” Wrong. You’re fat. Go for a jog. Concrete deliverables are defined and measurable. They make sure you are solving the right problem and not getting caught up in distractions.

Continuously moving forward (short timeframes) and in the right direction (concrete deliverables) makes big projects small and over time will make small paychecks big.

"Where ignorance is bliss, tis folly to be wise." – Thomas Gray

I’m starting to feel for Atlas. Sure, he was condemned to bear the heavens upon his shoulders, and I’m just trying to manage an IT workload. But the crushing feeling of no end in sight has to make us brothers in arms.

I’m quickly learning, there is no silver bullet in project management. Putting processes in place does not fix problems; it exposes them. If there is more work than workers, you’re going to fall behind. If you’re working on projects that are not fun to work on, there are no methodologies to fix boring.
However, leaving the lights off and ignoring the cockroaches running across the floor is not an option. Managers have to deal with the infestation. That is what we get paid to do.

Implementing Lean processes have exposed problems in our organizational structure and weaknesses in dealing with departments throughout our company. It would have been easy to blame the new system, and solve the problem by just getting rid of it. We could have just flipping the lights back off, but once you’ve seen the cockroaches, it’s tough to go back to business as usual.

It’s always hard to convince someone to implement anything that might lead to more work. Something that will make visible problems that no one even knew were problems.

There will be more stress and you’ll get some scars, but in the end, if you stick to your processes, your company will be better for it. And in times when we’re all trying to do more with less, you owe it to your team to deal with some stress if it can gain you some efficiency.

“One thing completed is worth ten things on hold.” – Dianna Booher

Most of our jobs entail delivering some sort of a widget to a customer. Ideally, we would be able to work on one task at a time. Finish it, then move on to the next task. Unfortunately, very few of us feel we have the luxury to work in this manner.

In our world, we have any number of distractions from bug reports to feature requests that compete for our time. Too often, what gets lost in this mix of pleasing the customer is actually returning value to the customer. It seems obvious, but a customer cannot begin to see value until the product is delivered. Take the following example:

Using single piece flow, you are delivering this set of features 8 days sooner:
Feature 1: 3.2 Days Sooner
Feature 2: 2.4 Days Sooner
Feature 3: 1.6 Days Sooner
Feature 4: 0.8 Days Sooner
Feature 5: Delivered at the same time.

Not only are you delivering your most important feature (presumably the one delivering the most value) three days sooner, you are not delivering any feature later. Overall, the Single Piece Flow yields a 32% increase on a company’s ROI. – if you’re interested in the math, feel free to shoot me an email.

An easy shot to take at the above methodology would be to criticize the efficiency in the hypothetical. Obviously, no shop is 100% efficient. In fact, most research points to a shop running anywhere north of 80% as pretty streamlined. That being said, there would be common waste among both project management techniques. In a single piece flow environment however, you are not nearly as exposed to four wastes that Lean methodologies warn against: Partially Done Work, Task Switching, Waiting, and Motion.

Depending on who you read, with three switches every day the multi-tasking team is losing an additional 10-25% of their efficiency.

Even using the most conservative numbers – 80% efficiency with multi-tasking only costing 10% – you’ll realize over 28% better numbers running tasks through one at a time. The math is pretty easy. If you can increase your company’s top line sales by getting billable features to customers quicker or reduce your costs by having less developers deliver the same work you’ll be in a much better position than you are today.

It’s simple: no product, no value. The quicker the product is delivered, the quicker value can be realized. Like Tom Demarco said, “There are a million ways to lose a work day, but not even a single way to get one back.”

“When you’re finished changing, you’re finished.” – Ben Franklin

Lean software development was actually my introduction to agile through the Poppendiecks’ book, but Ray came in and has refocused our teams on what it means to actually run a lean software shop.

So, as I often do, I dove headfirst into studying.  I read anything I could get my hands on even remotely related to the Toyota Production Systems (TPS) and quickly realized that while TPS concepts have been around since the 1930s (and lean principles much longer than that), lean software development is very much in the early stages of application.  There is really no consensus in the community as to how to run a project, but James Shore wrote a really good article that contained a sketch for a Kanban Planning Board. Below, I’ve modified it to incorporate a non time-boxed retrospective concept that was discussed on the Kanban Development Group and added a couple of team motivation concepts.

At the top of the board is the overall goal of the current project. Having this so prominent should help the developers not get so involved with the trees (Minimal Marketable Features) that they lose sight of the forest (the project).

Along the left hand side, you have the current MMF that the team is working on as well as the backlog. The order of this backlog can be changed at any time by the stakeholders (Corey Ladas has a great article on usingperpetual multi-vote to schedule this queue).

In the middle, are the development tasks that are required to satisfy the current MMF as well as Work In Progress (WIP) and an area for Done tasks. James left off the second two areas, but project management is about managing people as much as it is managing projects. People like to mow their lawns because once it is done there is a psychological boost to look over and see what you’ve just  accomplished. In the same way, a “Done” area allows  the developers to see the grass they’ve mowed during the current MMF. In an environment where the team is local, you could do away with the WIP area as the developers would have the cards at their desk, and in a situation where a software based board was being used there could be a current MMF progress bar instead of the done area.

On the right hand side, there is an Urgent  box that allows for an MMF to skip the backlog and focus the developers on an emergency situation, and there is a retrospective queue. Rather than time-boxing retrospectives, this queue allows the retrospective to fit more naturally into a pull system.

While this board is my take on improving what I’ve seen out there, I have high hopes that Kaizen Conference will help us as a community move to a more standardized approach to managing projects in a lean, efficient way.

One of the most contentious and discussed topics on our team was how to actually run an agile project. After a lot of good debate and maybe a few bad arguments, here is a wire frame of how we run agile software projects.

1. Create a backlog for the project.
   1. Get with stakeholders and ask them what they are looking for in the software.
   2. Write high level user stories with the stakeholders. Format like:
      As a (role) I need (something).
2. Discuss user stories with the development team and assign story points to each card.
   1. Story points are assigned to each story using planning poker.
   2. The numbering system used for story points will be a subset of Fibonacci numbers (1, 2, 3, 5, and 8). These points will be assigned where user stories are relative to each other. A story assigned a 2 is twice as complicated as a 1 and 2/3s as complicated as a 3.
3. At the beginning of each one week iteration, user stories are selected by the development team until the total number of story points equal the team’s velocity.
   1. The stories are detailed out further to add “so that (benefit)” to the story where the card now reads: As a (role) I need (something) so that (benefit).
   2. With this additional information, at any developer’s request, the user story can be assigned a new story point value via planning poker.
   3. All cards with a Fibonacci number of 5, or 8 are broken down into multiple user stories until there is nothing with a value assigned to it that is greater than a 1, 2, or 3.
   4. Add acceptance criteria to each card.
   5. The numbers are added up again, and if the number is less than the velocity of the team, additional user stories are added. If the number is greater than the velocity of the team, user stories are taken away.
4. The cards for an iteration are placed on a board and developers grab one when they begin to work on it.
5. Once complete, the developer places the card on the “Complete” board and grabs the next available card.
6. At the end of each one week iteration, a retrospective is held to discuss lessons learned, any new cards added to the project, and any changes to the team’s velocity. The team will show working software to stakeholders and users when applicable for feedback and sign off.
7. Any new stories that were added to the project are assigned a story point value and added to the backlog board.
8. Plan the next week’s iteration (restart at Step 3).

• Acceptance Criteria – Measurable terms of what must be done for a user story to be acceptable to the stakeholders.
• Backlog – Sometimes called a Product Backlog, the Backlog is a collection of user stories and tasks the development team will work on at some point in the future. Initially, this list consists of all obvious functionality, and it is allowed to grow and change as more is learned about the software.
• Iteration – Sometimes called a Sprint, an iteration is a fixed, specific length of time resulting in a small but complete piece of working software. Multiple iterations combined create a fully integrated product.
• Planning Poker – Planning Poker is a consensus-based estimation technique for estimating. Using this methodology, individual user stories are presented for estimation, and after a period of discussion, each developer chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story being discussed. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again. The method has been popularized by Mike Cohn in his book Agile Estimating and Planning, and studies have credited it with less optimistic and more accurate estimations than other methods (K. Molokken-Ostvold and N.C. Haugen)
• Retrospective – A meeting where a development team looks back on the previous iteration so that they can learn from their experience and apply this learning to future projects.
• Stakeholders – Customer representatives from the business who are actively engaged in the project. They prioritize user stories and give real-time feedback throughout iterations.
• Story Points – A measure of magnitude of a paticular user story, and it\’s size relative to the size of other user stories. Story points enable effort to be estimated without trying to estimate how long it will take.
• User Stories – A very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.