The 3 Things You Need to Do Agile Right
Teams, backlogs, and working tested product. Without these 3 Things, you’re not really doing Agile. The problem is that you can’t wave a magic wand and have these 3 Things overnight. It’s going to take some work. It’s going to require a planful approach. Because when the ideas behind Agile meet the reality of what’s going on inside large organizations, it’s going to run into some roadblocks. But that doesn’t make the need for teams, backlogs, and working tested product any less real.
Video Transcript
Approaching this systematically, there are methods to engage the organization in considering how to establish a team-based structure within the enterprise, correct? How do we manage the flow of work to provide small batches to these teams? What should we measure and control to encourage efficient flow, avoiding completing work before starting new tasks?
This concept, typically, when we engage, comes down to analyzing the business capability model, domain-driven design, product hierarchy, various organizational structures, governance approach, and metrics. We form a hypothesis for the changes needed in advance to support different teams, teams of teams, and networks of teams with interdependencies, ensuring the best chance for success.
(Musical Interlude)
Why Are You Adopting Agile?
Greetings, everyone! How’s everyone doing today? Today, I’ll discuss a recurring theme. I often talk about the significance of teams, backlogs, and working tested software. We’ll delve into tailoring Agile methodologies to suit your organization’s unique circumstances. However, I’ll focus on a comment we received on TikTok.
In that context, my team extracted a clip discussing the requirement for Scrum to involve complete cross-functional teams, equipped with a prepared backlog, capable of producing functional tested software by each sprint’s conclusion. The comment was intriguing, along the lines of, “Sure, easy for you to say, but it’s quite challenging in real-world scenarios.”
I wholeheartedly concur with that remark. However, does the challenge negate the truth? Does the difficulty involved make it any less true? Ultimately, I return to the fundamental question regarding Agile adoption—what are our objectives?
Whether it’s delivering small product increments at regular intervals, leveraging these for customer feedback, learning, and adaptation to enhance our products, or aiming for innovation by offering products customers might not even realize they want yet, the core principles hold. Even if customers know their desires, the key lies in inspecting and adapting to meet their actual needs.
Considering Agile’s essence, it’s inevitable that we must employ complete cross-functional teams—teams encapsulating the value stream within, working from a backlog containing small user stories or backlog items that embody tangible system behaviors.
If we can’t achieve functional tests in increments by each sprint’s end, what can we demonstrate to our customers? The challenge lies here. It’s like saying, “Sure, Mike, easy for you to say, but in real life, it’s genuinely difficult.”
I always consider the alternatives. So, the alternative scenario involves having ScrumMasters and product owners, yet we might merely execute Scrum mechanics, right? We could handle daily stand-ups, conduct reviews, retrospectives, track burn-down charts, and story points—various activities typical of a Scrum team.
Let’s assume we’re even implementing XP practices. We might decide to practice test-driven development, pair programming, or other software craftsmanship techniques. But fundamentally, if we lack the ability to present a working tested increment in front of a client, at the end of the day, what are we doing, right?
On Customizing Scrum to Fit Your Needs
So, what I would suggest is that most tailoring or customizations of Scrum revolve around addressing the less-than-ideal circumstances within the organization, rather than tailoring Scrum to the team’s local needs.
In essence, we accept the organization’s constraints and limitations, using Scrum to maneuver within them. Imagine, for instance, a Scrum team dedicated to a specific product, which is actually a subset of a legacy monolithic system. Let’s say this team attempts to work on a feature within a COBOL mainframe application, a system now six or seven decades old.
The scenario implies that the team engages in Scrum, constructs a controlled backlog, and operates as a complete cross-functional unit. However, technical challenges hinder regular software deployment and feedback collection due to tight architectural coupling within the monolith.
Consequently, the team’s Scrum process becomes a driving force. Effectively, their velocity remains at zero until they undertake the necessary work to extract that specific component or feature from the monolithic structure. This is how it theoretically functions—addressing impediments to Scrum implementation, in this case, the legacy monolith, which obstructs the desired delivery process we’re discussing.
The concept is to apply Scrum, which reveals your impediments. Over time, you work on removing these impediments. Essentially, leveraging Conway’s Law, we structure ourselves around what we want to hold architecturally significant—paraphrased. Subsequently, the designated team extracts and detaches from dependencies within the broader organization. However, as both I and my commenter noted, this is indeed challenging.
This is why, in most cases, though not necessarily all, we do not advise commencing with Scrum, its practices, or cultural mindset. Organizational obstacles are bound to obstruct your path, obstacles we are aware of. To execute Scrum effectively, you need the authority within the organization to proactively address these hurdles. We might acknowledge it sounds straightforward, yet it can be complicated when agency is limited.
Typically, this is the rationale behind not initiating transformations within organizations at the surface level and attempting bottom-up change. In practice, what often occurs is adopting Scrum practices, encountering immovable roadblocks, and then attempting to tailor Scrum to accommodate the enterprise’s dysfunctions, which, in essence, often deviates from true Scrum.
However, such an approach is usually ineffective. A common outcome involves redefining the purpose of Scrum. It shifts from being about delivering business value, innovating in the market, and embracing iterative learning from customers, to focusing solely on team dynamics, culture, collaboration, and workplace satisfaction.
While these aspects hold significance and are commendable goals, they alone might not warrant an entire overhaul of your company’s operations.
How to Engage the Company and Do Agile Right
Our chosen approach, therefore, is distinct. This approach drives us to create videos, deliver talks, and share content on platforms like TikTok and LinkedIn.
Why do we put forth these efforts? It’s because I wish to convey that there’s a systematic approach possible. It entails engaging the organization in developing a team-based structure within the enterprise. Furthermore, it involves orchestrating the workflow to deliver incremental batches to these teams.
So, how can we measure and control to promote a seamless flow that eliminates the tendency of completing work before initiating new tasks? Right, that concept. And so, when we engage, it frequently revolves around examining the business capability model, domain-driven design, product hierarchy, distinct organizational structures, governance strategies, and the metrics in place.
We establish a hypothesis regarding the necessary pre-emptive changes to facilitate success for different teams, teams of teams, and networks of teams, even those with interdependencies. For the TikTok viewers who find themselves on a team without the authority to enact change, that becomes their reality.
However, my intention is to have more individuals in our industry truly understand the foundational workings—complete, self-contained teams operating from well-defined backlogs, capable of generating functional tested increments biweekly. Likely, these teams function within a 3 to 6-month roadmap, all aligned with broader strategies, long-term roadmaps, connected OKRs, and KPIs.
This isn’t something that can easily be achieved from the ground up. I’m not implying that viewers of these videos can magically bring about these changes. Yet, I want them to grasp that Agile practices alone might not automatically create these conditions.
It involves making deliberate trade-offs. What slightly saddens me and proves a bit frustrating is that Agile is gradually being perceived as a methodology primarily geared towards team collaboration. There’s a risk that Agile is becoming synonymous with a set of practices, which is something I notice increasingly in the market.
The transformations we’ve been advocating for the past three decades are now being absorbed into the digital transformation realm. The idea of composable enterprises, adaptable organizations, is taking shape, evident in mature strategies around cloud migration.
Ultimately, someone else might take up the mantle of organizational redesign. This burden of change might shift to another entity. It’s becoming apparent in conferences that the concept of transformation is being relegated to a backdrop, while the emphasis is placed on adopting best practices.
This is acceptable and holds its place, but I doubt it will entirely solve the issue. Thus, it’s simple for me to verbalize, yet the implementation in practice is undeniably complex. This is precisely why we are committed to educating, communicating, and sharing insights through various platforms. This is why we assert what we do.
Yes, I address you as both a practitioner and a prospective leader. My aim is to equip you to communicate with your own leaders. I hope this resonates with leaders who may be watching and finding that Scrum isn’t effective for them. I want them to comprehend the underlying reasons because there’s a pathway forward and a systematic perspective to adopt.
I realize that I might sound repetitive week after week. Yet, this is the reality we face daily. I trust this information proves beneficial. I value the feedback you provide. My team keeps me informed about the comments, and while my responses might sometimes be a bit delayed, I’m genuinely committed to interacting with all of you.
Hence, if you have any thoughts to share or feedback to offer, we eagerly await your input. Looking forward to our next conversation. Until then, take care and goodbye.