Agile vs frAgile: Handle Your Scrum with Care
Your standard citizen today is an avid, savvy, and therefore extremely demanding consumer of technology. Wearables, smartphones and social media dominate their lives and purchases. This has created the perfect storm for fluid Agile methods like the Scrum framework to take over the IT world because it now demands the speed that heavier and more mechanical waterfall approaches are not capable of delivering.
Agile has became the reference approach for modern product development in the last few decades. However, we still see a lot of misinterpretation and abuse of its core values. This is so common that there is a name for it. The experienced Agile community likes to call this unwanted byproduct frAgile. If you don’t handle it with care, it is sure to shatter your product and loudly crash your entire team.
The Unbearable Lightness of Being frAgile
Agile is all about being lightweight, nimble and flexible—that’s why it can quickly adapt to change. However, frAgile arises when the attempt to adopt Agile is clumsily undertaken. It’s like trying to run in a track meet with your shoelaces untied.
With this in mind, I’m going to walk you through a few examples of how Agile can indeed become frail, and how all of them are inevitably linked to frAgile anti-patterns. And I mean walk, because you have to learn how to walk before you can (speed) run.
On Your Mark...Get Set...Scrum
Before we get there, I must first explain how I got to a point where I am able to quickly identify this phenomenon. I have been in two quite distinct scrum environments. First, as a product owner for a software house that built a widespread B2C product from scratch; later on, as an engagement manager at OutSystems.
At OutSystems, I’m helping deliver one of our largest digital transformation initiatives. As a result, I now have a set of common and proven core best practices that are key for setting anyone up to have the smoothest demo weeks. Ever.
Without further ado, here are 4 hints that what you thought was Agile might actually have become frAgile. And, of course, my focus is a specific Agile practice: Scrum.
1. Your Team Consistently Fails to Meet the Plan, Carrying Work Over to the Next Sprint
Working software over comprehensive documentation: Teams often become so obsessed with the “working software” part of this core Agile value that they neglect user stories, which are vital. Team members then are discussing and agreeing on the sprint’s scope while the sprint is already running—or walking because we’re not putting ourselves in anyone’s untied shoes—instead of using this time for speedy and objective development work.
Adding to this, these late definition activities normally linger on and have little-to-no support from business stakeholders.
The previous estimates you used for your sprint planning will have no basis in reality; your team will work daily through the unknown until the Day of Reckoning comes: the sprint demo.
Without taking the time to develop all originally “planned” user stories, predictability becomes an issue. The business feels they’re not getting what they expected and that they never know what sprint velocity to expect. This is the most recurrent and harmful frAgile anti-pattern I’ve seen around.
The point is that this Agile core value is not an excuse to overlook the value of collaborative and well-defined user stories, which you should do ahead of the sprint’s start so they can be used as a basis for proper planning. Yes, you should not be compiling the mile-long technical or functional specs document of old. But good user stories in no way resemble these behemoths. Instead, these straight-to-the-point descriptions of a feature capture the perspective of whoever wants a feature or capability (it’s Scrum, so that’s probably a customer) so you can plan what needs to be done.
2. Your Product’s Technical Debt is Untamable But Your Team Works Around the Clock
Constant in-sprint changes and new stuff keep popping up. Your development team is continuously restarting its work and working against the clock because they need to make sure that their delivery meets expectations at the end of the sprint. Does this ring a bell?
If you allow this dynamic to go on for too long, it becomes the norm. On one hand it actually relieves business stakeholders from committing to a fairly defined and stable sprint scope—which can be addictive. On the other hand, the development team will keep piling up the most gruesome technical debt known to man. Add to it a huge list of defects, thanks to the fact that they don’t have the necessary stability to nurture their code base, and you’ll be set for disaster.
Responding to change over following a plan: Since Agile is mostly about embracing change and Scrum allows for requirements volatility, it kind of feels like you are doing what you are supposed to do. Well… not really, I have to tell you! Even though you should have a healthy degree of flexibility while you are developing, the change that you should welcome and embrace is not one that impacts your sprints, day in and day out. Bigger change should be introduced from sprint to sprint, ideally driven by end user feedback.
3. Your [Product Owner/Team Captain/Senior Developer] Is Gone and Now the Rest of the Team Trembles at the Sight of Its Next Release
Think about one of those big or complex projects that live off unstructured processes for managing requirements, for instance. Now, imagine one or two key members leave your team. Given the job rotation that is the norm these days in the IT world, this is not uncommon, right?
When your local heroes are gone, none of the standing team members will have the same version of what the team should deliver. No one will be able to describe the existing system behavior with complete accuracy, either.
Testers won’t be able to perform their role satisfactorily because they won’t have proper requirements to test the software against. The go-to person isn’t around anymore, so your team won’t be willing or able to determine how sound the product will be for its next release.
Before long, delivery will stall, deadlines will pass unmet and quality standards will be a dream, not reality.
Individuals and interactions over processes and tools: The trick here, as with all other Agile values, is to find the right balance. In this case, having neglected how the work to be done is documented and managed has led your team to a very delicate position after the loss of a key player. Be sure to carefully and thoroughly assess what may indeed be deadweight holding your team back versus what actually provides the necessary support for the fast-paced of world-class engineering.
4. Your Project Is Near Completion and You Just Realized that Your Customer Doesn’t Really Get Agile
There are too many organizations out there that still can’t grasp what this Agile thing is all about. They tend to appreciate the flexibility the Agile methodology provides, but, upon closer inspection, you will notice those at the top of their hierarchy still have a waterfall mindset. They talk a good game by throwing around terms like sprint, scrum and iterative, but they don’t really know what they are or do.
In this kind of setup, agreeing on the scope of delivery will put you in delicate situations. Plans tend to change quickly—and this is one of the main reasons IT chooses Agile — but the contract’s feature list usually does not.
It’s not uncommon for the commercial relationship to then deteriorate. Your customer may decide to litigate, stop paying its bills… the works. All due to a lack of organic adoption of the Agile values and principles.
Customer collaboration over contract negotiation: Make sure that you assess how Agile your customer’s organization really is in its multiple hierarchical levels.
Set very clear communication flow from day 0, because establishing the Agile ins and outs is an absolute must. Plan for ongoing coaching to be part of your day job, as well. If a feature list needs to be met, make sure that any necessary changes to the scope you agree on are duly managed internally in your customer’s “home.”
Main Takeaways
To round it all up, here are the key takeaways for avoiding frAgility in a scrum environment:
More to Come for Agile and Scrum
There is more that can be said in regards to Agile vs. frAgile. The selections for this article pertain to the most recurrent and hazardous pitfalls. No form of Agile is one-size-fits-all. Nevertheless, there are clear indicators, common to any context, that will signal if you are doing it right. End users are happy. The quality of what is delivered is spot on and the project team is healthy and eager.
This article is the first in a series that describes multiple best practices for Agile and Scrum. Some are already industry standards, which will pretty much just be pinpointed in the orchestration of our proposed method, while others derive directly from experience. All in all, we will be providing you with recipes to cater to key aspects of the two most important activities that you have, as either a product owner or engagement manager: Knowing what to build and how to document it, so that you can then properly manage your backlog for true agile development. Stay tuned! In the meantime, check out what Andy Hunt, a co-author of the Agile Manifesto, says about enterprise software and Agile in this podcast.
