Has it ever happened to you to be in a development team and feel that the “Agile” process resembles more of a show?. With ceremonies, sprints, dailies, monthlies, but in practice, they are just empty words without adding value to the development process? Well, perhaps you might find yourself in what’s called Agile Theatre. Here are some points that can help you identify if you are in a team that practices Agile in name only.
Deadlines
We all know that software is a business, and contracts always lurk behind. The issue is whether these contracts are impeding your agile responsiveness. For instance, if a contract is set for X months and a requirement comes in, it must be delivered by a specific date no matter what.
If changes or problems arise during development, a “buffer” is often estimated to deal with them. But what if the changes that emerge while delivering interim versions to the client are much larger than expected? Should the estimation change? Should there be renegotiation?. If the dates remain fixed even when the scope has significantly shifted, and these changes aren’t evaluated, it’s not truly Agile.
Initial estimates are meant to provide a rough outline of the development cost, but unexpected issues can arise. Delivering a product early to gauge and understand user needs helps identify problems sooner rather than later. However, not addressing changes in scope results in delivering a product that doesn’t meet expectations or, at best, a product riddled with bugs and design issues that hinder its lifespan.
Team Effectiveness Measured by Completed Tasks per Sprint
Understanding how many tasks a team can handle is useful for setting goals. However, relying solely on this metric doesn’t offer a genuine development perspective. In Agile, the focus is on delivering value. The key is how valuable a feature is to the user. You can complete 100 tasks creating new software features, but if users don’t use any of them, what’s the point? Agile can involve delivering features, adjusting them based on user feedback, and ending up with fewer features but much greater value.
If your team’s effectiveness is solely measured by completed tasks rather than the value those tasks bring, it’s a sign of Agile Theatre.
Unused Features Aren’t Removed
Agile isn’t about predicting in advance which features users want; it’s about discovering them as quickly as possible using substantiated metrics. Often, projects have features that go unused, yet nobody wants to remove them “just in case.” Having unused or minimally relevant features complicates projects with more code and potential test failures. If the team experiences high turnover, nobody may know why those features exist or why they’re not removed. Agile distinguishes between what users find important and what’s not.
Lack of Impact Indicators for Features
This scenario is common: The Project Leader opens a meeting with the team.
Project Leader: “We’ve been told by that we need to implement this feature.”
Dev: “Why? What purpose does it serve?”
Project Leader: “I don’t know, we just have to do it because it was requested.”
Time passes, the feature is developed and delivered, and if any value was added, it remains unknown.
One of the effects of this lack of measurement is that the backlog becomes something static that hardly changes, and this is because tasks are not reevaluated based on what has already been developed and delivered.
Agile requires measuring whether a feature has a positive impact, based on specific metrics. Without such metrics, you might lose sight of features that users truly value.
Lack of Focus
What happens when a team is responsible for multiple projects simultaneously?. Often, the round-robin allocation of developers’ attention leads to a situation where they can’t truly focus on any project, or in the worst cases, they can’t focus on any project due to spreading themselves too thin.
The company and the type of software being developed determine this situation. If this occurs, it’s important to communicate when you can’t dedicate the necessary time.
Ineffective Status Control Meetings
Here, I’ll focus more on the Scrum methodology. On one hand, there are Daily meetings, where devs share their progress and any issues. The purpose is for the team to share what’s being done, creating a comprehensive view and sharing knowledge for smoother day-to-day development.
If a Daily turns into a meeting involving a large number of people (let’s say 20), and what person 1 says isn’t relevant to person 2 due to lack of dependencies or relevance, it becomes a mere status check, adding little value beyond the team leader. A Daily that doesn’t convey how the team is progressing toward the sprint goal or doesn’t contribute to modifying or adding items to the backlog for the next sprint isn’t being used effectively.
Scrum also includes end-of-sprint meetings for evaluating the team’s progress, reinforcing positives, and addressing issues. If these meetings don’t exist or are used solely to showcase how money is being invested without focusing on process improvement, it’s not Agile. If actionable points arise but are never followed through, the purpose of the meeting is lost.
Conclusions
Agile Theatre isn’t always a deliberate act; often, it arises during the process of transitioning and learning this work methodology. That’s why it’s crucial to remain vigilant about these points and take action to improve.
Be First to Comment