Westerly Consulting

Homehome.html
Due DiligenceDue_Diligence.html
ProductProduct.html
Management AdvisoryManagement_Advisory.html
BlogBlog.html
AboutAbout.html
Contact UsContact_Us.html
 

Features not Projects

Increase your flexibility by eliminating projects

Fred Engel

Westerly Consulting

www.westerlyconsulting.com


A client and I were discussing the fact that the transformation to Agile Development had not provided the needed business flexibility. The engineers in the company had moved to Agile Development almost two years earlier and the software being delivered was better, but the lack of flexibility was creating friction in the executive ranks.  The problem is that while the engineers are using Agile methodology the rest of the company is still stuck in a big batch big release mindset. In Lean, the planning process is a continuous flow of small items whose priority is decided upon just in time for the next small release cycle. If the business is to achieve the needed flexibility, the business leaders need to change the planning process. The business needs to think in terms of small pieces that are continuously prioritized rather than big projects that are decided upon once every six or 12 months.

Project thinking is really just a habit not a necessary reality when building products. Planning processes tend to focus on projects not on flow of features. It takes a lot of time to construct a project that commits development for the coming long cycle. Committing to deliver a project’s worth of value in 6, 12, or even 18 months in the future is an expensive planning effort in its own right. If the business is to achieve greater flexibility, the project structure needs to be changed or eliminated. Lean methodologies in development have taught us that a continuous flow of small items (i.e. features) provides much more benefit to the organization than large batch projects.

In the old model you make all of the decisions that you can upfront, set the engineers loose, and then manage the process. In the new Lean model you break things up in a small pieces, prioritize them when the engineers free-up, and release things more frequently. We are used to thinking about software development as being very lumpy, delivering something once maybe twice a year and no more. If we can change our thinking, we can gain greater business flexibility.

The auto industry went through this transition many years ago and is now at the point where every car in the assembly line can be different. The methodologies used by the auto industry to change its “batch” production are the same methodologies that we used to change the software “project” mentality.

Large projects are the source of many of the problems we see in product development. The detailed requirements, detailed designs, and detailed plans each create inefficiencies and problems in their own right.  While they are intuitive and familiar, they do not work.  Lean methodology includes planning, but only uses plans as a guide.

Lean methodologies show that a continuous flow of small items improves the operation of the organization along almost every dimension one can measure. It is more efficient, reduces errors, encourages improvement, provides greater flexibility, reduces waste, and increases profitability and revenue.

How does the organization move to such a new model? For large organizations with multiple products and multiple product teams, monthly releases are not an achievable option in the early stages of Lean conversion. It takes many years of effort and investment to create development organizations capable of continuous automated testing, integration, and delivery. For these large organizations having releases that are scheduled on some larger time horizon (e.g. quarterly or semiannually) is a necessity.

The good news is that increased flexibility can occur in these environments as well. There are two changes that can make this work. First, the release cycle is fixed in time (e.g. six months, 12 months, 18 months). Second, the decisions of what goes into a release are made continuously throughout the release cycle. If the decisions are made on a continuous basis, the business can change its priority at any time without disruption.

The biggest change comes in the decision process that defines what goes into a release. Rather than thinking about the release as a single project, the business leaders need to think of the release as a continuous flow of decisions about the content of the release. It may seem like a lot more work to deal with a continuous flow of decisions. But if business priorities change then new priorities need to be established. There are many subtleties that can minimize the overhead of making “feature” decisions, but the reality is that more granular continuous decisions are unavoidable if business flexibility is desired.

The definition of feature is not precise, and will probably change over time as the organization refines its use of the methodology. If we begin with the desire for business flexibility and think about what that means it will lead us to the definition of feature. Business leaders want to be able to raise the priority of some item so that it gets delivered more quickly. For the most part, these items will be of similar size, roughly speaking. That is a reasonable starting point for the definition of feature. A feature is that item that the business leaders need to re-prioritize in order to have the desired flexibility. Clearly, this is a vague definition. It’s a guideline and it needs to be small enough to fit into a discrete/small number of sprint(s) of a team while at the same time be large enough to be visible and meaningful to the business leader making the request. It can have more than one size definition.

What is being suggested is that the release content decision-makers make decisions at the feature level in a manner so that every Sprint has the highest priority business delivery. Instead of making these decisions once or twice a year event, these decisions are actively worked in an ongoing manner forever. The release date is fixed but its content is not.  If the Sprint length is a month, then these decisions need to be made monthly.

I expect some resistance to this concept. People are used to thinking in terms of fully loaded projects. After all, isn’t a project just an accumulation of features (we include technical debt in this definition)? Isn’t a project an upfront decision process that itemizes the features that can fit into a project? The fact is that these decisions are usually wrong at some level because the project rarely gets delivered on time with the quality and features desired? We should stop pretending that the old methodology really works.

It can also be quite tedious to have to make a lot of detailed decisions. For many business leaders, this level of detail is an unwelcome dive into the day-to-day operation of the organization. But how else will the business leaders be able to adjust the changing priorities if they do not make the tradeoff of what it is that is important? Somebody in the organization needs to be able to speak for the business priority and make the trade-offs. Generally, this is not a low-level person.

The habit many organizations have is to say to the development teams “I want the new features as well as the already committed features”. Many development organizations say “yes” when they should be saying “no” in that situation. Usually, they do not feel empowered to say “no”. If the business leader thinks a new feature should be bubbled up to the top, that same business leader has the duty and responsibility to say to the development team what it is that they should take off the list. The business leader who does not do this is causing the low-level people to make a high-level business priority decision.

It is a zero-sum game! There are only so many days of development and the business leaders need to accept the responsibility of taking things off the plate when they add things to the plate. Far too often the process breaks down because nobody is willing to take the responsibility of eliminating something from the list.

Yes, a project is making the same kinds of decisions upfront that we’re calling for it to be continuous. That is exactly the point. You can make these decisions at the time they are needed and you will have greater business accuracy. If you make the decisions continuously you will adjust what you do based on the delivery of the teams and the current business climate. If you make your decisions continuously you will have higher-quality with the lower cost. If you make your decisions continuously you’ll have much more informed decisions because you will have the knowledge of all the previous decisions and their outcomes.

To be explicit about something that we merely passed on, the release itself should have a fixed date. Whatever is ready when the release starts to engage is what is shipped in that release. Therefore, the exact content of the release is uncertain. The high-priority items, in all likelihood, will be in the release. The lower priority items may or may not make it into the release. In this way, the overhead of creating release can be managed while adding the flexibility of the content that relates. The only thing that this does not achieve, that other Lean processes do achieve, is early delivery.

For many, not committing to all the features in a release upfront is heresy. How can you measure people if you don’t get a commitment upfront and see what it is that they delivered against that commitment? How do you know that the organization will not avoid its responsibilities if it hasn’t committed upfront all the features in the release? How do you know the people won’t slack off if you don’t overload them?

Unfortunately, these questions come out of line of thinking that ignores the realities that it has dealt with all along. Releases are often late, buggy, and do not have all of the features that people want. Overloading people is like overloading a highway, it creates a mess. Far too often, the items in the release are not exactly what the customer wanted or capabilities that no one will make use of. The old model does not deliver to the expectations set at the beginning of the release. It is time to change the model and Lean provides the guidance.