Have you seen those viral videos on social media showing people walking, dancing or riding their bikes on water? Somehow this pool of liquid doesn’t behave like the normal liquids we’re used to.
Like water, it has waves and ripples, it flows and splashes. But under certain conditions, it has some very unusual behaviour.
It turns out it’s not really water, but instead a liquid called Oobleck, which is a non-Newtonian liquid. As soon as you apply pressure to Oobleck, it hardens up and quickly becomes a solid able to hold up the weight of someone running across it, which is pretty amazing the first time you see or experience it!
Oobleck serves as an excellent visual image of how to treat Agile practices. The word “Agile” means the ability to move quickly and easily, and there aren’t many things that move more easily than liquid.
Agile has fluidity at its core, emphasising a flexible approach and embracing change right through the delivery process. As an Agile practitioner that continually reviews and improves your approach, you are expected to demonstrate that flexibility towards not only change, but also team practices.
Let’s look at three Agile lessons we can learn from Oobleck:
When to be fluid
In its natural state, Oobleck is like any other fluid – it flows around obstacles and is completely free to change its shape and movement. Effective Agile practitioners are like this when faced with changing requirements and with team review and improvement.
One of the founding principles of Agile, and written in the Agile Manifesto, is to “welcome changing requirements, even late in development.” It is this feature, perhaps more than any other, that sets Agile apart from more rigid processes like Waterfall.
The benefit of this approach is to provide competitive advantage for your customer by responding to changing conditions. Feature X may have been important a month ago, but feature Y is now the market differentiator for your customer to leverage their market. While these changes during delivery may be disruptive in a waterfall approach, Agile provides this flexibility to the customer.
This same fluid approach applies to how strong Agile teams review and improve themselves. They are not only open to changing their practices, one of the founding Agile principles is “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”.
If your Agile team is rigid and set in its ways, chances are it’s missing out on growth opportunities.You should never hear phrases such as “that’s just how we do things here” or “we’ve always done it this way” from an effective Agile practitioner, because they should know and be able to explain why each choice was made, and also be open to changing them. Just as Agile isn’t the answer to every delivery challenge, there is no one way to approach every Agile challenge.
Agile teams typically come together for rituals such as retrospectives where the team’s performance is discussed collectively and assessed for improvement areas. It’s in these meetings that the ability to be like the Oobleck liquid is a strength.
Feedback in retrospectives should never be made personal or be taken personally – it is there for the improvement of the team. Retrospectives are a chance to celebrate what was done well and be honest about what wasn’t great, and look for improvements.
Agile practitioners don’t hold onto practices that hold back progress – their fluid approach allows them to change for the betterment of the team.Success comes from continuous improvement together. Dr. W. Edward Deming got it right when he said “it is not necessary to change. Survival is not mandatory.“
When to start hardening up
In its liquid state, Oobleck particles are spaced out, but under pressure they respond by coming together and making the liquid a bit more viscous or thicker. Similarly, part of the “secret sauce” of Agile principles is how members of Agile teams physically come together to deliver results:
Agile principles support this by saying that “business people and developers must work together daily throughout the project.” They also says that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
A key differentiator with Agile is how the customer (business representative), developers, testers and other required talent, work collaboratively on the outcomes. In terms of coming together, this works best with collocation, where questions and answers can be handled almost instantaneously by spinning a chair around to talk. Where this isn’t possible, team members should come together as regularly as needed to communicate, while remote teams can use the great technology available to talk face-to-face wherever possible.
Your Agile team will also come together for various rituals, depending on what flavour of Agile you are following. This could include retrospectives, Sprint reviews, showcases, planning poker sessions and the ubiquitous daily stand-up.
The hardening-up approach also applies to requirements. Some purists might argue that requirements should be captured and delivered in the smallest defined unit – the user story – for maximum velocity. However, identifying the requirements individually like this doesn’t preclude coordinating the delivery of requirements grouped by common area – something that should increase overall efficiency and delivery speed. Think of it like the Oobleck molecules coming together to form more solid groups of requirements.
Taking time to identify epics and bring together the user stories can be a great time investment. This can be done with methods as simple as using blue-tac to connect stories together with string on the backlog wall.
But it’s in times of pressure where the team is facing blockers, that Agile team members will really mimic Oobleck particles, as they pull together, firm up their response and focus their efforts in an approach called “swarming”. With swarming, rather than individual team members working on independent user stories, the whole team pulls together to focus on the same problem, removing blockers so the team can make fast progress.
There is a time to be fluid and flexible, but if your team allows any and every practice to pass as “Agile”, they might soon find themselves drowning. There is also a time for Agile practitioners and their teams to come together and firm up their response to a challenge. However, there are also circumstances where, just like Oobleck, you must become temporarily rigid in your response to poor choices.
When to go solid
Knowing when it’s appropriate to stand firm on delivery practices is one of the hardest challenges Agile practitioners face – because inflexibility is a fundamental problem with the approaches that Agile seeks to challenge! As for when to give a solid response, this is best demonstrated by some examples:
One of the common misconceptions around Agile is that it’s a no-documentation methodology, which simply isn’t true. Rather, the Agile Manifesto says that Agile processes value by “working software over comprehensive documentation”.
Be rock solid on this interpretation – Agile advocates just enough documentation, no more and no less. Challenging how much documentation is being produced as part of removing waste is great, but if you find yourself in an Agile team that refuses to produce required documents and claims Agile as the reason, stand firm.
Another misconception is that Agile is all about speed of delivery over quality. Or, to put it another way, it’s inevitable that quality will have to drop in order to deliver quickly for the customer.
This is rubbish! Quality is at the heart of Agile, as is the importance of testing to validate that quality.
While scope might be variable, quality is most definitely not. If your team is compromising on quality in the name of Agile, stand solid for quality and the customer!
Expecting good solutions to “emerge” without prior planning is another Agile belief with a kernel of truth that is sometimes misused to the point of deception. Complex systems, and those with many interdependencies, are often best approached with appropriate design and architectural planning – including in Agile projects.
This appropriate amount of prior work can increase the agility of the team by streamlining effort and reducing waste. If your Agile team advocates no planning up front, but rather a discover-and-respond approach to each user story, give this a solid response also.
Finally, the customer will also be negatively impacted if non-functional considerations are being pushed to the end of delivery. Some people believe Agile is about pushing out bare-bones functionality as fast as possible, adding what they see as “technical elegance” later.
Elements of a solution, such as usability, performance and security, should be an inherent part of the emerging solution. For example, there is no point spending months developing a voting system if it is easily hacked. There would be no point developing a mobile app with 500 features but a horrid user experience. And there would be no point developing a lottery program that could only process ten tickets per hour.
Delivering these non-functional requirements that your customer deems valuable is just as important as velocity.
Be like Oobleck
Agile is sometimes misperceived as an easy, cavalier, undisciplined delivery approach – which couldn’t be further from the truth. Doing Agile properly requires immense discipline and rigour around truly understanding and following its essential principles.
The four values and 12 principles of the Agile Manifesto exist as a compass to guide your Agile journey. If in doubt about when you should be flexible in your approach, when to pull together with your team, or when to stand firm against non-Agile practices, refer to the Manifesto and Principles.
In essence, all sorts of lazy, poor and non-Agile practices can be passed off as “Agile”, when they are anything-but. The secret is in always being like Oobleck, ready to spot these non-Agile practices and rapidly change your response accordingly.