Stuck in the past: Are you running your Agile team still as Waterfall?

05/14/2019 by Tudor Tofan

Nowadays, one of the most used buzzwords in the IT industry and not only, is Agile. Everyone’s using it one way or another. The traditional roles are getting revamped by adding “Agile” in front of them (e.g. Agile Project Manager, Agile Business Analyst) and there are also new roles, such as Scrum Master or Product Owner. Since you’re reading these words, it seems that you’re already, at least, taking Agile into consideration. But is it really Agile what you’re adopting? Or is it just cherry picking from what the Agile approach is promoting, with very limited results in the end?

In my experience, if you really want to help your team embrace Agile, you should focus in 3 directions:

  • Practices and processes
  • Values and principles (mindset)
  • Technical excellence

Still, before deep diving into each of the aforementioned topics, I would like to raise awareness about one more critical aspect in this whole equation, which is THE TEAM. When transitioning from the classical command and control mindset, to an Agile one, this is often overlooked.

So, you want to go Agile. You aim to build a working tested increment every 2-4 weeks. To achieve that, you pick individuals with all the needed skills and bring them all together, physically or virtually. Are they really a team? Can they work like a Roman phalanx from the beginning? Not really. That’s why you should really invest some time into team building. You need to help the team members navigate the Forming stage (Tuckman’s stages of group development), so that they build alignment, trust and a shared vision. A very useful activity that I’ve tested is Personal Maps, which is really helpful in creating and exploring more personal connections. Also The Team Canvas, a workshop comprised of smaller activities, facilitates conversations about purpose, goals, working agreements, strengths & weaknesses etc. If you’re a Scrum Master or Agile PM for such a team, your leadership style should be a bit more directive than usual and focused on teaching.

1) Practices & processes – The bricks and mortar of the Agile approach

This is where the vast majority of the teams start their Agile journey. By far, the most popular framework is Scrum, being used by more than 50% of Agile teams. But there’s a catch to it. Scrum by itself is not enough, since it has only a minimal set of roles, events, artifacts and rules. Since it is a framework, not a methodology, it also has many intentional gaps left in order to avoid becoming too prescriptive. Basically, the Scrum Guide describes the “WHAT?”, but it leaves the “HOW?” up to you. Think of Scrum like the structural frame of a house. It acts like a backbone and can contribute to the success of the house, but it doesn’t guarantee it.

It is up to you and your team to fill in those gaps with different practices, tailored for your specific needs. For example, Scrum does not say anything about User Stories, it says only about Product Backlog Items (PBI). Many teams are using the concept of User Stories, borrowed from XP, to organize their Product Backlogs, while others are using different approaches such as “given, when, then” etc.

Also, don’t forget that Scrum’s core mechanism is “inspect & adapt”. I’ve seen many teams implementing an army-style Scrum, based on someone’s recipe, who has seen it working in another team. Needless to say, they were failing gloriously, since each team is unique and needs to find its own flavor, by constantly inspecting their way of working, and adapting it in order to improve it.

On a larger level, the same applies with the Spotify Model. It is a unique approach, which has worked for Spotify, based on their organization, on their market, on their context. Many companies have tried to copy it and failed.

2) Values and principles – Why are we doing this?

There’s also a tendency to forget the “Why?”, or worse, just to add Agile terminology on top of the existing processes. I’ve seen a lot of teams saying that they’re “doing” Agile, just because some senior manager wanted so, lacking the basic understanding about the values and principles behind it. This means that they’re doing things mechanically, not thinking about collaboration with the customer, rapid feedback from the market, or continuous improvement. For them, Agile is seen as the destination (“We want to do Agile”), instead of being the journey. This setup is so common that it even has a name, being called Cargo Cult Agile or, targeted more specifically on Scrum, Zombie Scrum.

But there are also teams that are doing the “WHAT”, that also know the “WHY”, but still have problems in reaping the benefits of Agility. The most probable cause could be the frictions between the team’s Agile mindset and the organization’s command and control one.

For example, I’ve worked with Agile teams that were supposed to deliver fixed scope, fixed time projects. Even though the team was aiming for an MVP in 3 months, to gain rapid & real feedback from the actual customers, the senior management just wanted the whole USS Enterprise in one year. Fast forward 4 sprints later, there was a real problem with the lack of stakeholders in the Sprint Review.

Besides implementing frameworks, Agile also needs a change of mindset in running the whole organization. Things like going from project teams to product teams, going from upfront budgeting to a more venture capitalist style one (“I’ll give you 50k and 3 months, bring me an MVP”), going from fixed scope to building what the customer really needs.

Of course, it is easier said than done. The problem is that these changes don’t occur overnight and it takes a handful of passionate promoters, patience and resilience. Executive sponsorship is also crucial and things are usually a lot easier if at least one top manager is onboard. Usually, the preferred approach is to start small, in a controlled environment, and then adapt continuously while spreading in other parts of the org. There have also been exceptions, with big bang approaches (ING Netherlands), but it’s risky and it takes a lot of guts.

3) Technical excellence – Agile Meets Technology

One of the changes that Agile promotes is iterative and incremental development. It’s like building a modular product, comprised of validated bits & pieces which bring value to the customer. Scrum goes a bit further and talks about “potentially shippable product increment”. The concept is really powerful and is essential to the goal of having a short time to market, but it often poses technical challenges to the teams going Agile.

First you have to think about the design and architecture of your product in a manner that will accommodate this way of development. Such architecture will also help when dealing with potential changes resulted from the customer/market feedback. Very popular among the Agile technical community is the Microservices Architecture style.

Achieving a product increment each sprint means that for a piece of functionality, the team has to do a bit of everything, every iteration. This means speed, but it doesn’t mean that you should sacrifice quality. To achieve this, Agile teams focus on automating stuff as much as possible, so they’re no strangers of concepts like automated testing (unit, regression, GUI, acceptance, etc), continuous integration or continuous delivery. They also aim to build it right from the first time, so they sometimes work in pairs (pair programming) or in groups (mob programming).

Could you imagine delivering an increment in 2 weeks, when all your regression testing is done manually? I guess it’s possible after 2-3 iterations, but once you advance it will be harder and harder, next to impossible.

Then, it’s all for nothing if you have working tested software every 2 weeks but it takes an additional 2 weeks for it to get to the customers. After all, it’s the end result that matters, so Agile teams also focus on releasing the increment as fast as possible, through Continuous Deployment.

As a Scrum Master it’s really important to have these technical practices on your radar. You should be able to explain the benefits and to identify the right person who can help you (since some of them also involve some investments).


Rounding up, all these 3 areas are like a tripod. If you’re not thinking about all of them, the whole thing collapses and you will not get the full benefits of real Agile.

What do you think? Do you still consider your team as Agile? What about your organization?

Tudor is a freelance Agile Practitioner from Romania. In the past 5 years he has worked with multiple teams and organizations, guiding them to embrace Agility in a fun and friendly manner.
Connect with Tudor Tofan on LinkedIn

- Share with your friends or followers.