@SCALE

The Benefits of Revisiting the Basics of Agile

As someone who has been trying to master the guitar for quite a few years, I always try to challenge myself with learning more complex songs. Sometimes, I’ll get hooked on something extra complicated, and will find myself practicing it over and over until it seems like all the notes blend together. That’s when I know it’s time to take a step back and take a moment for a pause to clear my head.

A teacher of mine let me in on a trick to help with this: set aside the difficult piece, and spend a few minutes playing a simple song that uses just a few basic chords, something really hard to get wrong. What I found is that this accomplishes a couple of things:

It reminds me that I can play guitar, I shouldn’t be discouraged, and boosts my confidence.

Working on something simple allows me to work out more complex problems in my background thinking. I almost always come up with a way around what’s blocking my progress.

As I plucked away at another tricky song the a few evenings ago, I realized that many of our customers who were well into their transformation journeys could be having a similar experience with complexity while working at scale. From lean portfolio management to innovation canvases to the introduction of value engineering, the landscape of agile at scale is constantly changing. We take a lot of pride on staying up to date and contemporary with all the latest concepts of agile at scale, ensuring that we bring them into the AgileCraft platform in an intuitive and connected way.

That being said, you can’t write a song without knowing how to strum all the chords on a guitar. And, we know that scaling agile to the enterprise can seem overwhelming. This is why we ensure that the benefits of agile are solidly represented in our product and the way in which we approach helping our customers achieve excellence at scale. One way to do this is to get back to agile basics, because every now and then, revisiting a familiar concept can spark a new idea. Regardless of whether you have started your journey scaling agile to your enterprise or are just starting to think about it, knowing and periodically revisiting the basics is just as important for those who are new to agile as it is to the seasoned veteran.

Our team works on some massive scaled agile implementations, and sometimes the scope of what we’re helping our customers pull off is a little mind boggling. We’re talking huge, Fortune 500 companies with thousands of users, all striving to run scaled agile programs using many frameworks – SAFe, Scrum@Scale, DaD, LeSS, and hybrids of their own invention. What I’ve noticed is that in the face of this complexity, it’s easy to forget some of the basics and make some easily avoidable mistakes. Here are a few pieces of basic advice which we like to use to remind our customers and community of the benefits of agile when the complicated stuff trips us up.

Agile teams and key stakeholders need to work together every sprint to ensure the product is delivering continuous value. At the end of each sprint, the goal is to present a product to the product owner and business owners to gain feedback so they can decide whether to pivot or persevere along the current product path. It’s easy to neglect this agile practice with a lot of excuses because it takes away time from developing software – all that demo prep takes so long! At the end of the day, the agile team needs the demo as much as the stakeholders so that they know for sure they are developing software that will deliver value to the customer.

Don’t forget to actually improve when practicing continuous improvement. An agile team’s focus is on consistent communication and short feedback loops, which gives them the opportunity to fix problems and try new ways of doing things to deliver value, faster. Retrospectives have to be actioned and agile team members need to hold themselves accountable for contributing toward desired outcomes. The daily scrum, or standup, is critical here, so teams are communicating, and Scrum Masters are removing impediments.

Agile product management and teams embrace changing requirements as more is discovered about value delivered. All agile frameworks – from scrum and Kanban at the team level to SAFe and LeSS at scale - allow for changing requirements over time. With agile product management, the roadmap gives the greater team a starting point, then it will change as the greater team inspects and adapts the product roadmap to market requirements, workflow improvements and work capacities.

User stories vs. use cases: the difference between outcomes and system behavior. User stories are meant to actually tell a story to elicit conversations that will help the developer understand what outcomes the end user is actually meant to experience. A use case describes the way a system should behave when the user performs a set of actions. A user story traditionally takes the format of “As a <user definition>, I want to <do something>, so that <result>”, can really help figure out how to imagine the feature. When it comes to user stories vs. use cases, opt to tell the story instead of defining flat requirements.

Agile testing is a critical part of the inspect and adapt principle. Testers and developers need to pair closely to create real-time, instant feedback loops on product delivered to continue to drive value – it’s not a “throw it over the fence” relationship. When planning sprints, doing sizing exercises, or getting ready for demos, agile testing is a critical part of the value delivery stream.

The Scrum Master works as a servant leader to the team. Scrum Masters are not project managers. Their focus is to help facilitate sprint and program planning at the team level and identify dependencies across the program, as well as helping remove impediments and obstacles from the team’s path. The team itself is empowered to determine how they work, and the Scrum Master is there to ensure they are able to achieve their objectives.

Agile vs. Scrum vs. Kanban is not really an argument we need to have. People tend to get these terms tangled up, so let’s clarify: there’s no agile vs. scrum, and there’s no agile vs. Kanban. Think of agile as the umbrella term under which frameworks like scrum and Kanban peacefully coexist, and one isn’t better than the other. The same goes for SAFe vs. Scrum@Scale vs. LeSS etc. … it’s not a competition for framework dominance. It just depends on the individual team situation and what framework suits their particular situation better.

I could go on and on, but instead I’ll just point you over to the new eBook just published by AgileCraft, the Agile Primer: Back to Basics. There, our team has assembled a handy reference guide of articles written by our stellar team that can keep you calm in the face of the complex and ongoing practice of scaling agile. Now, back to that song I’ve been practicing. I wish the dog would stop howling at me… I think he’s trying to tell me something!