Common Website Mistakes 7: "Developing"​ agile

Time and time again I see companies that "develop agile", meaning the development teams use one of the agile frameworks to develop projects that are fixed-time, fixed-cost and fixed-scope. In this article, I will explain why this is not agile and how you can steer your organization to become truly agile.

What is "not agile"

Independent of which flavor you use, agile is a mindset. That makes it quite impossible to simply "instruct" agile, as many companies try to do. To make matters even worse, most of the time you hear the management say you need to be agile rather than we need to be agile. It is one of the most difficult situations to have an agile department embedded in a non-agile organization. Let me make this completely clear: Having a daily stand-up does not make you agile, nor does putting your requirements into stories or dividing your development into sprints. These are merely tools to support agile development, but organizations often utilize those tools without any of the agile benefits.

Agility means being able to move, which requires a certain degree of freedom. If your project has a defined budget (fixed cost), a hard deadline (fixed time), and immutable requirements (fixed scope), they cannot be agile - because these characteristics restrict the outcome completely. To be agile, at least one of these parameters has to be variable, and no framework or development approach can make up for this.

A glimpse at Scrum

Agile has been around for a while and there are quite some frameworks out there. One of the most prominent ones is Scrum and I want to use it as example for an agile approach. A simplified explanation of Scrum is to take a portion of the requirements - the one providing the maximum added value - and get it implemented and published in a short amount of time (a sprint). During this time frame, the remaining requirements are ignored and might even not be more than a collection of vague ideas (the backlog). Only the requirements being implemented need to be fully specified, the rest can stay vague for the time being. If you adhere to this idea, the following characteristics emerge:

• There is value added after every sprint and the implemented features are always the ones providing the highest value
• There are no more requirements specified than necessary
• Experience from published features can be fed back to specify new requirements
• You can stop developing after any sprint and still have created value

As you can see, these characteristics give you a lot of flexibility. While they minimize risk and effort, they are maximizing the value of your product in the shortest possible time. The specifics of the Scrum framework are tools to support you in adhering to the agile processes and prevent you from deviating. Now let us cross-check these characteristics with the approach of "developing agile":

• There is no added value during the whole design phase
• There might be some added value during the development phase (although stakeholders might not be willing to test or release an "incomplete" product)
• The majority of the requirements are initially specified, even when some of them are dropped later in the development phase
• Experiences from published features might lead to modifications of already specified features, generating additional effort
• When your project is stopped before the development phase, your added value is zero

All of the agile frameworks have in common that they typically yield results faster and are better suited for fast-changing environments than the waterfall approach. Unfortunately, the waterfall approach gives a false impression of safety and lower risk, hence being more appealing to management.

What you can do

When you are in a management position and want to promote an agile culture, accept that you cannot account for every possibility. Keep in mind that a specification has no inherent value until after its implementation. Encourage your business analysts to focus more on what to implement rather than how. Power and responsibility should go hand in hand, so make sure you empower the responsible people in your organization. Most important of all: trust your team or vendor with taking decisions. If you do not trust them, chances are you should not be working with them in the first place. I also recommend taking a basic course in one of the agile frameworks, since they usually do a pretty good job at explaining the philosophy and showcasing the strengths of agile development.

What do you think?

Do you agree? Did you experience situations where printing culture slowed down your publication process? Is this article helpful and would you enjoy similar content? Let me know in the comments.

Aknowledgements

Photo by Fidel Fernando on Unsplash