The Pitfalls of Agile When Organization Fail To Understand Real Agility

I often see big organization decide to adopt Agile without the right mindset, and they fall into a common trap of mediocrity, which at best they do Iterative Waterfall and call it Agile. Of course, when you talk to them they tell you that they are really proud of their new development process and claim that they have created their own Agile Framework. After all, the have stood up Scrum teams with Scrum Masters, Product Owners and have sticky notes on the wall, they sprinting and loaded their product backlogs into an online tool … the whole enchilada. So, they are Agile, right? Wrong!

Agile software development means different things to different organizations. As it has exploded over the software development lifecycle, Agile principal and discipline often have pushed aside as organizations rushed into implementing pick and choose practices in the name of practicality.

When organizations disregard agile development values and principles, they fall into some common pitfalls. By staying true to Agile’s core philosophy, companies can better realize the true benefits of agile: high productivity, great software quality, and happy customers.

Altering standard Agile framework before the organization has thoroughly grasped an Agile mindset

Scrum, Kanban, XP, Lean and similar frameworks provide a specific guideline and set of practices tightly embedded in Agile methodology. These frameworks are designed to be flexible (to some degree) based on organizational environment, culture, and need, but not until the organization has a solid grasp of why these practices are in place. The most common mistakes organizations make when adopting agile is tinkering with these frameworks before truly understanding the implications.

One common antipattern happening at nearly most organizations adopting agile is omitting to form cross-functional teams and continue with silo and domain-centric teams or team members. This structure perpetuates an “us versus them” mentality and promotes mini waterfall approach, which usually starts with shorter release cycles and eventually falls back to the traditional way of developing and releasing product, due to the fact that it is almost impossible to complete potentially shippable product increments each iteration.

Big bang approach and scaling up before there is momentum

Agile is best to shine when small teams working highly collaboratively. Large organizations are often in a hurry to go all-in and scale up because they don’t see value at a small scale. This is entirely practical, but what most organizations miss is that agile is a tremendous paradigm shift and it takes some time to sink in throughout an organization. Scaling too quickly often means the organization at large isn’t ready for the implications of agile and isn’t prepared to cope with the changes it brings. As a result, organizations scale up without a model for success.

Dependence on Agile – Scrum ceremonies for success

Just because you do your daily stand-ups, write user stories and put them on your backlog, and conduct your Scrum meetings doesn’t mean you are doing enough to succeed. For instance, I personally see only topical value in user stories as a starting point for requirements analysis; I think most organizations need a lot more to succeed. Still, many organizations blindly latch on to popular practices without fully examining their situational needs and applying agile principles to innovate appropriate solutions.

I’ve experienced countless customer engagements where organizations espouse a Scrum practice, only to learn that it consists solely of daily stand-ups, teams that are not cross-functional, and a list of user stories. For instance, one organization asked me how to handle “defects” in Scrum. Puzzled, I dug a little deeper and discovered that they had a separate bug tracker full of defects but no one was working on them because defects were not user stories. I pointed out that the product backlog consists of everything needed to build a product, including defects. It took several sessions and training engagements before the “user story mania” subsided and this notion finally sunk in.

Failure to employ empirical forecasting

Agile approaches like Scrum control risk through frequent inspect-and-adapt points rather than relying exclusively on an extensive, upfront plan. Yet many organizations stick with “crystal-ball” predictive project management approaches, even though teams are conducting sprints and producing products incrementally. Organizations should instead translate product backlog items with relative estimates to an empirically derived prediction of schedule.

A company that produces software for supply chain management organizations had a well-formed Scrum practice, but they were not using empirical methods to forecast milestone completion, instead relying on their old waterfall-centric project management methods. When I asked what they were doing with their relative estimates, they realized their story point estimates were not being used for anything beyond sprint planning. I showed them how velocity and a simple tool like the release burn-up chart could be used to provide an empirical means for the driving duration and milestone forecasting. After a little coaching, the project management office started including empirically derived release forecasts with each release status meeting.

Neglecting distributed teams

Organizations composed of individuals or teams who are separated by many time zones are now the norm. Aside from the obvious cross-training on practices, organizations often forget that each geographical location has its own culture. The process of spreading the agile philosophy and achieving a real paradigm shift across distributed teams is something that must be considered for each geographical location, independent of successes achieved at any one site.

A major independent software vendor in the process of forming agile project teams for select customers fell into this trap. Over the course of several years, they did a phenomenal job of infusing agile culture into their US-based development center. However, their India-based teams were not included in this cultural shift. In fact, things were happening the same way in India, with a heavy focus on CMMI and ISO compliance standards. Needless to say, the collaboration between the two centers was difficult, being that the two groups had vastly differing ideals and norms. Now, they are explicitly working to bring a uniform culture across geographies.

The Path to Enterprise Agility

Agility is a tremendous paradigm shift in our thinking and behavior. It cannot be rushed or pushed on an organization. It cannot be effective if the underlying philosophy is largely an afterthought. Pragmatism is an intelligent pathway, but it often precludes the consideration of lofty ideals—something essential in enterprise agile transformations.

The Minimum Viable Product vs. The Minimal Marketable Product

The minimum viable product (MVP) is a powerful concept that allows you to test your ideas. It is not to be confused with the minimal marketable product (MMP), the product with the smallest feature set that still addresses the user needs and creates the right user experience. The MVP helps you acquire the relevant knowledge and address key risks; the MMP reduces time-to-market and enables you to launch your product faster. This post discusses both concepts, and it shows how you can use the minimum viable product to create a minimal marketable one.

The Minimum Viable Product

The minimum viable product (MVP) is a learning vehicle. It allows you to test an idea by exposing an early version of your product to the target users and customers, to collect the relevant data, and to learn from it. For instance, to test the viability of using ads as the major revenue source, you could release an early product increment with fake ads, and measure if and how often people click on them.

As a lack of knowledge, uncertainty, and risk are closely related, you can view the MVP as a risk reduction tool. In the example above, the MVP addresses the risk of developing a product that is not economically viable.

Since the MVP is about learning, it’s no surprise that it plays a key part in Lean Startup’s build-measure-learn cycle, as the following picture shows:

The MVP is called minimum, as you should spend as little time and effort to create it. But this does not mean that it has to be quick and dirty. How long it takes to create an MVP and how feature-rich it should be depends on your product and market. But try to keep the feature set as small as possible to accelerate learning, and to avoid wasting time and money–your idea may turn out to be wrong!

While the MVP should facilitate validated learning, I find it perfectly OK to work with MVPs such as paper prototypes that do not generate quantitative data, as long as they help to test the idea and to acquire the relevant knowledge.

The Minimal Marketable Product

The minimal marketable product (MMP) is a different type of product. It is based on the idea that less is more. The MMP describes the product with the smallest possible feature set that addresses the user needs, creates the desired user experience, and can hence be marketed and sold successfully. The MMP is a tool to reduce time-to-market: It can be launched more quickly than a fat, feature-rich one.

Creating a product with just the right amount of features sounds like common sense. Why would we create more features than necessary? Sadly, I have seen many projects develop over-engineered products with lots of shiny features that provided little value to the users, but cluttered the product and increased the maintenance cost. And it’s not just the others: I am constantly tempted to add just another cool feature to a product, or to write a few extra lines in a blog post. Using the concept of an MMP helps me focus on what really matters, and remove unnecessary features (and lines).

A great example of an MMP is Apple’s original iPhone launched in 2007. I know that the first iPhone was a complex product, and that many people worked incredibly hard on it. But I find it amazing how many features the phone did not provide compared to its competitors: no copy-and-paste, no Outlook integration, and no voice recognition, to name just a few. Nevertheless the phone was still a staggering success. How come?

The key to creating a successful MMP is to “develop the product for the few, not the many,” as Steve Blank puts it, and to focus on those features that make a real difference to the users. To discover the right features, the MVP is a fantastic tool.

Combining the Two Concepts

To combine the two concepts, develop one or more MVPs to test your ideas and to acquire the relevant knowledge. Then use your new insights to create and launch the MMP – a product with just the right features and a great user experience, as the following picture shows:

Note that a minimal marketable product differs from a viable one: It is complete enough to be ready for general release, as indicated by the gift wrapping in the picture above. What’s more, launch preparation activities have to take place for an MMP, for instance, creating advertising campaigns, or gaining certification. Some of your MVPs are likely to be throwaway prototypes that only serve to acquire the necessary knowledge; others are reusable product increments that morph into a marketable product.

Three Common Misunderstandings Of Self-Organized Teams

“Self-organization” can be a very loaded term, and when there is not a discussion within organizations around what this means, teams will typically create their own convenient meaning for it. In some organizations where the culture has a lot of directivity by management teams, I sometimes even see the term “self-organized teams” become weaponized in different ways.

What is self-organization?

To set a baseline, let me describe to you my own high-level interpretation of a self-organizing team. When I use this term with clients, I usually mean:

• A team that has a certain level of decision-making authority. This level may change and evolve over time, but there is a clear sandbox defined where teams can make decisions.
•  A team that is working toward meeting their emerging vision.
• A team that takes ownership of how they work and continuously evolves through having a continuous improvement mindset. In other words, where they are today is not where they will be six months from now.

I could add more to this because we could involve different facets of self-management in this as well, but this definition is sufficient for the purpose of this article.

“The team has to decide everything.”

This is the softest weaponized form that I hear around self-organized teams. I typically hear this from team leaders who are uncomfortable bringing leadership and guidance to their teams in certain situations.

One of the places I often see this relates to process. Imagine for a moment you are leading your team in a change initiative. What is the container or structure that you would like the team to use? Should they do a plan-do-check-act cycle? What does that cycle look like?

As the leader of the initiative, should you propose a structure or let the team struggle to create one? Should you even propose having a structure? Should you just assume one will emerge? What is the best approach?

The answer depends a lot on the maturity of the team and their capability. If it is a brand-new initiative, the team may appreciate the guidance to help them better work together and may be frustrated and angry when it is not there. Proposing something upfront can actually set the tone for the team culture.

The other key decision factor is the capacity of the team to make decisions together. There is some learning needed to become a team, and it can be useful for the leader to provide an initial structure.

“The team made this decision, I cannot change it.”

The is the subtle difference between this perspective and the previous one is that this one typically comes from the manager of a self-organized team.

There is a myth or, rather, a belief out there that when a team is self-organized, the manager needs to completely disappear, do nothing and say nothing. The team gets to decide everything and even make bad business decisions.

The truth of the matter is these teams operate in the context of a business, and in this context, there are some accountabilities that need to remain with managers, general managers, and executives.

There needs to be clarity for the teams; there needs to be a sandbox within which self-organization is possible. When the team wants to make decisions that are outside that sandbox, it is the role of their manager to point it out to the team and bring them back into the sandbox.

“We are a self-organized team, you cannot tell us what to do!”

This is the stronger weaponized use of the term “self-organized team.” This one happens when someone (or everyone) on the team is pushing back against a perceived authority figure.

I often see this kind of pushback when teams reach what I lovingly refer to as the “rebelling teenager phase.” You know, that phase where they feel because they are self-organized, they can make whatever decision they want.

If I stick with the teenager metaphor, it is the time where they are learning to stand up for themselves and express their opinions. During this time, they have a strong belief that they no longer need the authority figures, although whenever it seems convenient you hear them express they still do.

The challenge here is teaching the teams they can self-organize — but within a certain sandbox. There are some things they may decide and other things they cannot. Making sure where you are delegating decisional authority is key.

Conclusion

Fostering self-organized teams can be very easy or incredibly hard depending on the organizational culture and how long people have been in the organization.

As a leader, it is important to work with your teams to help them align on what self-organization actually means and support the team in finding their way back to this agreement.

As a leader, it is also important for you to align your actions and decisions to support your teams in their journey toward self-organization. If the teams start noticing you are asking them for one thing and acting in the opposite way, you will quickly lose credibility.

What does the term self-organization mean in your organization? What can you do to better foster the self-organization of your teams?