2024 -
I recently had an enlightening conversation with a knowledgeable colleague about Dual Track development in an agile context. I argued that not applying Dual Track development within a Scrum Team is, in fact, an anti-pattern.
Let's examine Dual Track development! This approach segregates work into two parallel tracks: Discovery and Delivery. It enables a team to concurrently discover user needs, validate hypotheses, and design solutions (Discovery track), while also developing, testing, and deploying code (Delivery track). The primary benefits of this methodology include accelerated feedback loops, enhanced risk management, and more efficient prioritization of features. Essentially, the work done in the discovery phase directly informs and feeds into the subsequent sprint's delivery efforts.
I observe implementations of Dual Track development where one team does the discovery and another team does the delivery. I think this is a misconception; Dual Track is actually a single track with discovery and delivery work entangled in the same iteration. Why is this important? If one team does the discovery and another team does the delivery, there is significant risk that information is lost in the transition between the teams, and we miss the opportunity to remain agile and lose focus on adaptations.
How does this apply to Scrum? A key aspect of the Scrum Team’s role is to understand the product's users and determine their significant needs. These needs are then translated into hypotheses, which detail how these needs might be fulfilled, the expected outcomes, and impact. The Scrum Team then devises strategies to validate these hypotheses with actual end-users, aiming to keep the feedback cycle as short as possible. It’s not uncommon for a Scrum Team to conduct several discovery and delivery cycles within a single sprint. This underscores the importance of the Scrum Team being cross-functional and self-managing, enabling them to swiftly adapt without being hindered by dependencies.
From my experience, if your Scrum Team is not merging discovery and delivery efforts within the same sprint, there exists a significant opportunity for the team to learn and evolve, thereby enhancing their capacity to generate impactful outcomes.
For educational purposes, however, I find the Dual Track development concept excellent for explaining what happens in great Scrum Teams.
We also dwelve on hypothesis validation in our podcast episode 7.
Recently, I had the opportunity to attend an exceptional lecture featuring Bent Flyvbjerg, the author of 'How Big Things Get Done,' hosted by Morten Münster. Bent has spent decades assembling an impressive database comprising approximately 26,000 meticulously documented projects. Astonishingly, when this wealth of data is extrapolated, it reveals that a staggering 99.5% of all projects are over budget, over time, or under benefits.
Professor Bent Flyvbjerg highlights that IT projects often face significant delays, with the average project being approximately 50% delayed and the most delayed 18% of projects experiencing an average delay of 455%. This suggests a favor for more frequent high-level forecasting, avoiding the burden of extensive planning that does not yield more accurate results.
While this revelation is undeniably disheartening, what strikes me the most from the lecture is the scarcity of detailed data regarding whether these projects actually achieve the intended benefits. It's astonishing that despite the vast amount of information available, there's a profound lack of insight into whether these initiatives successfully deliver the promised advantages. This realization is both astonishing and concerning: we anticipate going over budget or extending timelines, yet we lack clarity on whether the envisioned benefits are ever realized.
Looking ahead to 2024, it's imperative that we begin measuring the value hypothesis of our features and product backlog items. This strategic shift will enable us to adapt our approach, ensuring that we create the intended value or adjust it based on what we learn.
SCRUM IS TOO STRICT AND TRADITIONAL PROJECT MANAGEMENT IS USELESS.
EVERYONE CAN BENEFIT FROM USING AGILE PRACTICES
Recently, I have been reflecting on the landscape of product development methodologies, ranging from traditional to agile approaches. At the core, I believe that, regardless of the chosen approach, the goal remains the same: to create outstanding products that delight our customers.
Over the years, I've had the privilege of fostering environments that truly embraced Scrum in self-managing settings. Seeing how empowered people collaborate and create more value together than they could individually, and how they engage in collective continuous learning, has been truly magical. Likewise, I've navigated more traditional environments, discovering significant value in integrating them with agile practices in "Projagiles" or "Scrumjects."
Even though I believe that a focused use of the Scrum framework can lead to delivering value sooner and promote continuous learning, I still see value in combining more traditional project management methods with agile practices in organizations with a less pronounced appetite for agile thinking. It is, however, important to adjust our goals and understand that we cannot expect to reap the same benefits as when fully embracing the Scrum Framework and self-management.
WHEN IS IT SCRUM, AND WHEN IS IT SOMETHING ELSE?
I don't agree with the argument that Scrum is too strict or lacks flexibility. Scrum, as outlined in the Scrum Guide, is distinct and should not be confused with other sets of agile practices; doing so dilutes its significance in our discourse. Don't misunderstand; I fully support experimenting with various practices, including agile ones, to identify what best suits our specific context. However, for clarity in our discussions, if we deviate from Scrum, we should refer to our approach differently. Imagine the confusion and potential chaos if you attended a football match only to discover that the game was being played with rugby rules. Both include a ball, but they are not the same.
A friend of the house once posed an intriguing question: What do you call your agile practices when you're unable to adhere to the Scrum framework entirely? After careful thought, I concluded that the answer should be tied to your objectives for adopting agile. If your aspiration is to align with the Scrum Guide, then it's Scrum. Otherwise, you should feel encouraged to be as inventive as necessary in naming the unique blend of agile practices you've adopted.
So, let’s refrain from battling over what is best, but instead collaborate on finding the best solution for our specific context. Let me know what you think?
Let’s be courageous together!
Founder, Jakob Jensen
Is it hard to get the collaboration going in your Scrum Team or getting your Scrum Team to move beyond individual here and now thinking and doing?
Consider using this retrospective pattern inspired by the theory of Bento-ism (BEyond Near Term Orientation.) by Yancey Stickler. A philosophy for decision making that encourages people to think beyond immediate desires and consider a broader perspective including future selves, others, and the collective good.
I have however found it very useful for sparking a conversation about moving from Now Me thinking into Future Us thinking, taking Now Us and Future Me perspectives into consideration.
A retrospective around the concept of Bentoism can lead to profound insights and actionable steps for a Scrum Team.
Here’s my step-by-step guide to facilitate such a retrospective:
By incorporating Bentoism into your retrospective, you encourage a holistic view of work and its impact, fostering a more thoughtful and balanced approach to team and individual development.
I have only used it a few times, so reach out to me and share your experiences or if you have any questions?
I have recently engaged with several companies facing challenges in realising value through Agile methods. After in-depth discussions with these organisations, ranging from small to large entities employing both scalable and non-scalable Agile approaches, I've identified three critical areas that seem to require more attention, especially when compared to the successful Agile organisations I've collaborated with:
1. Lack of a clear target for their Agile journey and a defined responsibility for pursuing this goal. (Have they clearly outlined their desired destination, the sub-goals that can bring them closer to it, and are they revisiting this frequently enough?)
2. Shortage of experienced and motivated Scrum Masters. (Hiring Agile Coaches cannot fully compensate for an imbalance between experienced and inexperienced Scrum Masters, which can lead to challenges.)
3. Insufficient emphasis on technical excellence.
While all these aspects are essential, I'd like to emphasise the importance of technical excellence, which appears to be lacking in many cases. This doesn't imply that individual developers lack technical excellence, but it can be challenging to foster collaboration in this regard. Provocatively, I'd argue that without a certain level of technical excellence enabling one-click releases, organisations might find it challenging to derive value from Agile methodologies - Bum 😁.
In my role as a Scrum Master and Agile Coach, I've assisted numerous companies in navigating the often complex transition from multi-step, manual release processes to streamlined one-click releases. Common questions that arise include addressing existing technical debt, maintaining testing, and ensuring ongoing development activities. Some of these challenges can be eased with the application of AI, but that's a separate discussion. My experience suggests that once organisations have successfully implemented a one-click release process and all its components, they rarely wish to revert. Subsequently, these companies have become better equipped to respond to evolving business needs.
Here are three pieces of advice for rebooting the Agile mindset within your teams:
1. Establish a clear goal for enhancing your Agile practices over the next 3-6 months. Communicate this goal regularly and be prepared to adjust it based on new insights.
2. Ensure that at least 1 in 5 Scrum Masters is a highly experienced professional who has witnessed the capabilities of an exceptional Scrum Team.
3. Prioritise technical excellence, which often involves implementing test automation.
When experimenting with delivering value sooner, a question soon creeps up: 'How will we know if we deliver value?' In this newsletter, you will learn why it is important, and that it might not only be relevant for measuring feature value. This subject is also covered in the Danish podcast 'Noget for Noget,' Episode 7, I am co-hosting.
Most teams I know of today are very good at establishing more hypotheses, but less so at proving the hypothesis. We are often convinced that the features on our product backlog create value in terms of reaching our goals, however we rarely develop the instruments that will allow us to know.
What is a hypothesis? A hypothesis is like a scientific hunch—it's an educated guess or a proposed explanation for a phenomenon. Researchers use hypotheses to guide their experiments and investigations. It's like saying, "I think this might be true, and here's how I'm going to test it." If the evidence supports the hypothesis, it can become a theory or contribute to our understanding of a subject.
Translating this to the features on our product backlog; we identify a user need, a phenomenon, and our educated guess is that the feature will address the need, hoping it will create value for the user. So, the feature implementation works as an experiment to address the user need. However, rarely do I see companies test if the value is actually realised. This means that we never close the loop to determine if a given feature realises the value we had a hunch it would. On a practical level, this is the reason we build products with thousands of features, of which only 20% are used. Additionally, as we are not measuring the value of our features, we end up never decommissioning features that are no longer used, making our product unnecessarily complex.
So, how to get started on measuring value:
Define the hypothesis for addressing the identified user need in one or more product backlog items.
Establish a baseline for metrics that will allow you to prove that the feature is providing increased value.
Build the increment, including the minimum version of the feature (Customer delight should still be in focus).
Put the feature in the hands of customers and start proving the hypothesis by monitoring the metrics.
Continuously evaluate if the metrics you have defined are true measures of value. Otherwise, find new and better metrics.
Keep monitoring the value the feature provides, and if it declines towards zero value for the customers, consider decommissioning the feature, making your product easier to maintain.
Is it easy? Not at all. Does it bring value? It has for me, as it helps focus on the 20% of the features that bring value to customers and helps you deliver value sooner!
It is not only feature value that is worth measuring - how about agility? “How do we actually know we are agile?” If we do not set up some metrics that make sense for us to determine if we are becoming more agile, then it is hard to say?!
In this paragraph you can write a description of your business, your personal interests, your professional skills - or really whatever you prefer to use this text box for.
