Startups and a Common Misunderstanding in Agile Software Development

I've done four Free CTO Consulting Sessions in the past month with startup founders who all had run into variations of the same problem. They didn't feel they had visibility into timelines and costs for development of their software. They couldn't plan their business. Investors and early customers were becoming worried about the ability of the founder to deliver.

In three of the cases, the founder was finding that the software teams (1 in-house, 2 outsourced) were delivering relatively well in the short-run. The teams involved didn't seem to be exhibiting many of the Symptoms of a Weak Development Team. The primary problem was that there always seemed to be a lot more that needed to be accomplished such that the big picture of what needed to get built was going very slow as compared to expectations. As one founder put it:

We keep iterating over relatively the same features and functions. We are finding and fixing bugs. Making small changes. But I'm now 4 months in on a release that was supposed to be done in 2 months. And we are not even moving yet on the the next big release that I have to have to get my next round of funding.

In the fourth case, the founder was getting ready to sign a very large contract, but they didn't feel they had much visibility into what was going to be delivered. Instead, what they had was a contract that promised Agile Software Development with Rapid Iterations and an incredibly vague list of features. My belief is that you shouldn't sign that contract. You are just setting yourself up for problems. Actually, you are setting yourself up to be in the situation of the two founders that had outsourced. They had both signed similar contracts and I'm not sure what's going to happen because clearly the outsourced developer is not delivering on the contract in terms of big picture features and functions.

In all four cases, I would claim that what's at fault is a common misunderstanding in Agile Software Development. In particular, there's a tendency among many people executing an Agile process to focus on the short-term (Sprints, Iterations) and to forget planning and other big picture aspects. There are many different Agile Software Development methodologies, but just about all of them have a strategic level element that focuses on the larger picture of the product.

Below are some pictures of Agile Development and you'll notice that each has a starting point of the big picture.

No matter what a developer implies or acts like, there is planning in their Agile methodology.

Of course, what's really at issue here is:

How much time/effort should be spent defining things that are farther away in terms of development?
How do we avoid continually iterating on a small set of product features/functions and lose progress on the bigger picture?

Level of Detail

So how deep do we need to go on features that are farther in the future? Enough to have an estimate of the scope of the item. I can hear the groans from all my fellow technical folks - we hate estimating things. So why do I say this. If you can't estimate it, then it's not defined well enough and you are just punting on getting it defined. I'm not saying the estimate has to be exact, but a reasonable range is needed.

I'm okay with splitting functions off into near-term and future. A classic example might be "reporting" as a feature item. What probably will happen is to define some early reports that will have more specific estimates. Then as it gets into the distant future (12+ months out), it can be much fuzzier.

Why do I need this? We are trying to establish the big picture over the next 6 months. And we are using them to set expectations around what's going to happen in terms of the product. If we don't force ourselves to the level of an estimate, we can't really do that and we'll have big time misunderstanding on what's going to get done.

For most early-stage startups the list of product features that are under consideration for a 6 month (or even a 12 month) period is not that big. We are likely talking about an effort of 4 hours to 2 days. In all four of the cases that sparked this post, the founder and the developer were willing to just put a single bullet item on a list (yes, "reporting" was a line item on one of them - ouch) that could have wildly different expectations and they clearly had not estimated these things. In three of the cases, these were in contracts! Of course, even for the internal development team, this is pretty much a contract with your founder.

You don't need a lot of documentation of these items. I personally like the Product Backlog type approach, but with more functional description than user stories (that can be more open to misunderstanding by developers). For example you might be capturing these first in user stories and then into a feature level spreadsheet that link back to the user stories.

You can also look at:

http://www.mitchlacey.com/intro-to-agile/scrum/the-sprint-backlog

and there are tons of examples out there. You will notice that all of them contain high-level estimates along with priorities. This level of understanding only takes a few hours of time to get through. Yes, it might be hard work, but you need to do this or you are setting yourself up for the kind of long-term misses that this post is about.

Unfortunately, there seems to be lots of confusion out there around this issue. Part of this is confusion on terminology around various Agile methodologies and terminology. But a big part of the problem is one of attitude. A great post, Joe Little starts with acknowledging that Scrum and Agile proponents often downplay upfront planning.

... drowned out by Agilists saying "why do you want to do up-front planning?"

... all we 'scrumers' hate up-front planning

Joe points to reasons why proponents of Agile may try to avoid upfront planning including that things will change, so the initial dates/budgets are quickly wrong. But Joe then goes on to point out why it's needed even with the negative attitude that Agile developers may bring:

Help the business make decisions
Team can see bigger picture and understand the tradeoffs
Helps scope down early releases
Team understands the whole project
Leads towards Re-Planning

Also, take a look at:

The bottom line here is that neither the developer nor the founder/business owner should be willing to dodge upfront planning and getting to the estimate level.

Endless Iteration

The other problem that is being experienced is that each week the teams are setting the priorities to focus on bug fixes, small changes/new features around the same basic feature set and not getting to the next set of product backlog items.

Okay, so part of this is a function of the quality of what is being built. If there are a lot of bugs and each bug fix is causing new bugs, then it could be back to a Weak Development Team. In these three cases, I would say that while I would have expected fewer bugs coming through the process with better development of test scripts, the overall symptoms were not horrible. Most of the "bugs" were edge cases that were not really thought about until after the product was pulled together.

The bigger part of this was that the business owners were defining additional features and functions that were needed now that they saw the system running. In two cases many of these were coming from customers using early releases. Some of these changes were important, but the critical question that I raised was:

What is the priority of these items vs. your product backlog items?

Many of the incremental changes and quite a few of the bug fixes were lower priority than moving on the product backlog.

Why were they stuck in Endless Iteration?

They had not accounted for the maintenance and support that comes with release. If you start with an unrealistic picture of what's going to happen as you begin to release, you are going to create a big disconnect between your initial plan and what happens in practice. As a developer, certainly as a CTO, you need to account for setting those expectations appropriately.
They had not gone through a Re-Planning effort - mostly because they really didn't do any upfront planning. If you look at Joe Little's last point about the value of upfront planning, it's setting you up for Re-Planning. In these cases, not only did they have an unrealistic picture of what was going to happen once the software was released, but they continued with their pattern of not planning. So instead of asking the priority of small changes vs. product backlog, they just sat in an endless iteration / maintenance mode.

I would also say that by starting into a process where you don't do big picture planning as you should, it shouldn't be a surprise when you are not making progress against the big picture. You've established that the big picture is not as important as small increments and the team will align with that model.