It Depends

 As part of an agile transformation, I was guiding an organization towards smaller batches enabling more frequent inspections of the organization’s progress against a ‘known good’ definition-of-done.  For complex agile projects, this approach validates that the correct collective progress is being made, and ensures issues are addressed as they are uncovered.

The organization was insistent on retaining their traditional development mindset and keeping their dependencies documented using ‘depends on’ links, effectively generating a dynamic Gantt chart.  Whenever a team issued a new dependency link, the dependency got an immediate high priority from leadership until the two teams agreed upon a path forward together.  A new dependency would disrupt the receiving team who had other critical work to complete.  Over time, the teams reverted back to on-going partial work with ever increasing dependencies on other teams.  The onslaught of dependencies disrupted teams from reaching their sprint goal, lowered their definition-of-done to maintain velocity, and undermined their predictability.

How one handles dependencies are completely different in traditional development compared to agile development. I have struggled to help leaders understand that there are two ways of delivering complex programs, that these two ways are based upon different principle sets, and that they are executed with different expectations and rituals.  

Traditional development follows a series of milestones of progressive decision making over time, for example, serial agreements to business case, product requirements, architecture & design, implementation, validation, market readiness and finally product launch decisions.  A traditional development Gantt chart maps out the program plan with dependencies within the phases showing where one team’s outcome enables another team’s work.  This is consistent with traditional development’s making a plan and executing the plan.  The use of the phases helps provide early detection that something’s amiss.  For example, if a team cannot complete all of their architecture & design decisions by the design complete date, executives know that they have an issue early in the program.

Agile development is different, first and foremost, because the product is in the continuous state of being ‘ready to ship’, or ‘done’.  To do this, means that product backlog and architecture has been constructed such that the teams can work independently and incrementally in design, development and validation.   At any point in time, all teams can operate and inspect the current ‘production’ system.  When everyone agrees that sufficient customer value has been achieved, the system is immediately released to customers.  Equally important, no one team is allowed to cause builds of the whole system to fail, validation to become stalled, or deployments to the staging environment to pause.  Even during early development, any of the aforementioned events is equal to a production outage and teams do everything to return the system to ‘production’ quality.

So, how are the interim agile development dependencies handled across teams?  Think of a traditional program’s Gantt chart as being a horizontal relationship map over time.  Now rotate the Gantt chart 90 degrees where an incremental agile program outcome is at the top and all necessary work cascades downward to stories that teams complete during the same sprint (or a few sprints).  This is called, a hierarchically structured backlog, where stories are completed to enable an epic, epics are completed to deliver a theme, where each issue type of the hierarchy is ‘done’ and inspected.  Each and all teams’ progress can be inspected and tracked.  

But using vertical dependencies, or a cross-organization hierarchically structured backlog, planning is focused on a series of inspectable, incremental, cross-team outcomes that keeps the system operational even when feature-poor.  This allows surfacing unknown risks early and uniform inspection of progress across the whole organization.  When there is a failure, the identification of the root cause and corrective action can happen quickly to enable the current incremental outcome and adjust the future outcomes.

Agile development’s known-good, production quality first over traditional development’s feature design and coding first allows leadership to have a common standard to inspect and understand progress.  Traditional development’s strict phase-driven decision making allows leadership to have a different standard to inspect and understand progress.  However, a mixture of low quality implementation and loose phase-driven decision making means pure development chaos.

Transforming Architecture

 Architecture, an architect’s role and their relationship to agile principles are seldom defined when I start an agile transformation.  There are those who believe architecture is a lofty set of future technical needs or desires.  For example, architects provide solutions to address past technical debt that will never be implemented.  There are those who believe that architects live in an ivory tower and profess designs that have no possibility of being implemented within the constraints of the -ilities (affordability, scalability, securability, sustainability, supportability, etc).  There are those who know that agile means do whatever, whenever and however they want until there is something new and urgent that needs to be done instead.  When all of these beliefs are held in an organization, architecture is dismissed.

Given this baggage, I start an agile transformation by asking, how do you define architecture and the role of architects?  As expected, I get a mixture of responses across the organization depending upon who’s answering.  Engineering managers tend to define the role subservient to their role as managers, as in technical designs that fit into their envisioned schedule and feature set. Product managers define the role as subservient to their roles balancing stakeholders and customers’ needs, as in technical designs that support the whim of sales or customers’ desires.  Support or quality leads define the role as ensuring supportability or delivering reliability.  Even the technical leads will define their own roles as being subservient to everyone else.  

When I ask, if a technical infeasibility surfaces, who raises it and resolves it?  I’m surprised by their willingness to immediately take on technical debt and paper over the infeasibility.  Or, worst yet, toss the technical issue on another team or organization, and move forward with an unrealistic, low-quality solution.

To reset the discussion, I define architecture as ‘technical decisions that we hold ourselves accountable to’.  This means that the decisions (or agreements) are technical in nature and made by engineers, technical leads and/or architects.  Architecture decisions relate to but are not management, product, quality or support decisions.  Everyone is held accountable to these decisions which means that the decisions have to be written down and tested/checked against.   If there’s a discrepancy, we either change the implementation to be consistent with the technical decision(s), or we change the technical decision(s) for everyone.  Architects, or technical leads, are responsible for cultivating, documenting and, when necessary, making these technical decisions.  Architecture and architects stand as a separate task and job role.  They are part of the collaboration between Product Management, Engineering Management and the team.

This definition avoids the pitfalls of the above baggage by centering architecture in the space of documenting and brokering technical decisions that are written down and used.  Normally, engineering managers, product managers, support, and quality don’t want to cultivate or maintain a set of technical documentation.  Equally important, most everyone will agree that given the pragmatic nature of the definition, it avoids the ivory tower and irrelevance concerns.

I can hear the screams of the agile purists, ‘working software over comprehensive documentation’!  Most agree that ‘over’ does not mean ‘instead of’.  Both working software and documentation are highly valued and important.

Let’s step back and use Mary Poppendieck’s ‘Build Integrity In’ Tools; Perceived Integrity, and Conceptual Integrity.  Perceived Integrity is the consistency in how we present abstractions and interactions to our users.  This means that our abstractions, or user design decisions are expressed in both internal and user documentation, and are carefully cultivated and validated with our users. Equally, this means that we have explicitly decided and documented who our users, or user personas, are. Therefore, I place the decisions of user design and user personas in the realm of architects’ technical domain.   Any change in user personas has a massive impact on every aspect of the product and needs to be carefully considered and controlled.  Architects tend to understand these impacts on Perceived Integrity better than the other roles.

Turning to Conceptual Integrity as it comes more naturally to technical leaders.  Conceptual Integrity deals with the speeds, feeds, interfaces, APIs and functionality of the code itself.  As we’ve learned, APIs are contracts between components.  Neither component can change the contract without an agreement of all parties involved and a phased transition to the new agreement.  A lot of modern language and API styles have helped to ease these transitions but regardless, the contract has to be kept to keep the system operating.  When these are documented, maintained and tested against, the resulting system tends towards resilience. 

Back to the ‘working software over comprehensive documentation’ concern.  Recent innovations in validation, APIs, languages, CI/CD, tooling and UI development, have moved us towards the reality when comprehensive documentation is also working software.  As we maintain software, we can maintain architecture and our technical agreements.  With each software change, we know if we’re staying aligned with those agreements.

Another benefit of this approach, by clearly defining and using user personas, all teams can now align their user stories and outcomes to identically the user personas defined for Conceptual Integrity.  So as Product Managers, Engineering Managers and teams discuss potential user value, they have a common understanding of who they are discussing for precisely the intended outcome that is consistent with past delivered value.

During an agile transformation, it takes a while for the organization to grow accustomed to this clearly defined architecture role, responsibility and accountability.  Some organizations have created a ‘triad’ collaboration where Engineering Leadership, Architecture and Product Owners engage the team as a single voice during the team’s refinement, planning and execution.  Teams benefit because they know what’s expected of them so they can focus on creating the highest value for the customer.

TLDR

If you have been reading my postings, you have noticed that I write detailed, complex and long compositions to explain my thoughts on agile principles and transformations.  I also do this in the normal course of planning and guiding agile transformations for organizations.  I like to share the ‘conscious’ side of ‘competence’ so others can explain the ‘why’ behind the ‘how’.

Needless to say, I often get TLDR in response, as in ‘Too Long, Didn’t Read’.  I have been asked to summarize my thoughts in a summary paragraph, a short presentation, and yes, once by a boss who told me to put the important parts in the email subject line.  Somehow, there’s an expectation that if I could only shorten the concepts to bullets, the ‘aha’ would happen across the organization.  Adoption of the concepts would be self-motivated and immediate.

This leads me to ponder how a medical doctor becomes one.  Consider how the best and brightest high school students are guided to a strong ‘core’ set of biology and chemistry while getting their bachelor's degree.  In medical school, they spend their first year learning how a healthy body works, in great detail and with hands-on experience (I won’t go into detail of the hands-on experience).  Their second year is spent learning pathology, or why and how things go wrong in an unhealthy body.  They finish out their last 2 years of medical school rotating between various medical disciplines understanding the basic practices, procedures and realities while continuing to deepen their basic knowledge.  They spend years preparing for the medical exam that will determine what medical specialty that they will spend the next two to seven years being an intern after medical school.  They have board certifications to master before they are allowed to freely practice as an attending physician.

Why do they spend this much effort to learn the complexity of the human condition?  One reason is that the downside of making a mistake is so high that it can cause undue pain and suffering, even death, as well as waste time and resources on missed diagnoses.

Let’s ponder a TLDR version of medical education.  Let’s assume that we have the most excellent medical snippets from X (formerly known as Twitter), TED talks, Youtube, LinkedIn and TikTok.  Let’s assume that a really smart designer using AI figured out how to place in front of our medical students the right information in the right order, of course monitoring dwell times, actions, and answers.  Once the medical students have been exposed to the right materials long enough with sufficiently successful metrics, they are free to practice medicine.  

Would you be willing to go to such a TLDR medical doctor?  

They might be able to diagnose simple cases.  They might be able to perform simple procedures.  They might be able to, when presented with x causes y causes z, reason with the patient that x causes y causes z.  They would likely be good at a particular ‘how’.

They would likely be unable to reason the complex ‘why’.  When they are presented with unseen representations or complex, multi-causal symptoms, they will not have the context to reason possible diagnoses. 

Why?  A simple diagnosis or procedure taught without context means that that same simple procedure may not apply in all contexts.  In fact, that same simple procedure may cause harm in many other contexts.  The ‘why’ explains context and the ‘how’ explains the procedure for the right diagnosis. 

Well, what does a medical education have to do with hi-tech?  There are no life threatening development teams out there.  Right?  While this may be true, technology development does have customers, investors, stakeholders, and co-workers who are depending on leadership knowing the ‘why’ and ‘how’ of complex situations, organizations, projects and products.  Making a mistake does cause harm to these dependents.  Why would anyone simply trust a TLDR trained technology leader?  Why would anyone trust an organization that demands TLDR communications or processes?

Allow me to redefine TLDR as Tough Learning Different Reasoning.  To build the necessary context takes time and exposure.  The context explains the solutions, procedure and rituals.  This is done by humans in taking time to learn, understand and experiment with new concepts.  Watching a lot of motivational TED talks won’t suffice.  Reading a ton of summaries or email subject lines won’t help. 

Tough Learning means that one has to spend time and effort to learn and think.  Simple impressions of Learning are insufficient to master the full context.  Different Reasoning means that the underlying principles and methods are unfamiliar.  To learn them requires practice and experimentation.  Few are able to read about the new rituals and discern the new principles.  Study, effort and practice are required for mastery.  

You should ask me then, what’s a test that you can take to determine which TLDR you have been exposed to in your past.  Here is the test:  Read the Poppendiecks’ book, Lean Software Development, An Agile Toolkit.  It takes between 2 to 4 hours for a seasoned technical leader to read the whole book.  

If your response is that you don’t have the 2 to 4 hours to read the book, then you know which TLDR that you’ve been exposed to.

If you read the book AND you can explain to yourself ‘why’ and ‘how’ for ALL of the 22 Tools apply to Scrum, S@S and/or SAFe v6 (or later), you have been exposed to the second definition of TLDR and are a well trained agilist.

If you read the book AND you can not explain to yourself ‘why’ and ‘how’ for ANY of the 22 Tools apply to Scrum, S@S and/or SAFe v6 (or later), you have fallen victim to the first definition of TLDR.  You should consider vesting time to learn the foundations and principles of agile development.

If you read the book AND you can not explain to yourself ‘why’ and ‘how’ for SOME of the 22 Tools, you have been exposed to a mixture of the TLDRs.  You have more to learn.  Focus on one of the tools and immerse yourself into building your understanding of that tool’s context.  Move to the next tool until you can explain the ‘why’ and ‘how’ for all 22 Tools.

We expect our medical doctors to be conscious competent.  Shouldn’t we expect that much of ourselves when doing agile development?

The Most Critical Step in Agile Transformations

The most enjoyable part of every agile transformation is the time spent with people during one-on-ones. They bring their realities and difficulties to the conversation. We sort out what’s going on. They allow me to share insights and provide alternatives for their consideration. They leave the discussions appreciative with ideas to consider for next steps. The best compliment that I can receive is when they thank me for allowing them time to think.

An often asked question after we’ve wrapped up a discussion is, from my perspective, what’s the most critical step in an agile transformation?  They are always surprised that my answer doesn’t appear to conform to the Agile Manifesto.  They expect something like, establish Scrum rituals.  Or, do agile training.  Or, define individual and teams’ roles and responsibilities.  Or, define the SAFe or S@S hierarchy.  Or, establish a maturity model with a clear definition of done.  And to be fair, these are important items to establish during an agile transformation, but they aren’t the most critical.

My answer is simply to establish a Learning Organization.  That is an organization that values curiosity, change, experimentation, inspections, introspection, education, teaching moments, trends, root cause analysis, improvement, and innovation.

I have found that many organizations are in an unconscious competence state where they do what they do because they have documented processes for how they do everything, but they have forgotten why they do these things, or they are in telling leadership style where they expect to ‘just tell the organization what and how to do everything’.  

The urgency of needing to fix a bad agile transformation gone wrong, to move quickly to mature agile development, and/or the onslaught of business conditions reinforces the leadership’s expectations to do what they do faster or just tell them what to do now.  There’s no time to learn.  Absolutely no time for experimentation.  If there’s any failure, there’s only time to punish.

At the core of agile thinking is empirical inspections, or the Plan, Do, Check, Act (PDCA) cycle.  The core is reinforced by Sprint Review meetings, retrospectives, burndowns, velocity and root cause analysis.  How can any of these be done without a Learning Organization?  Sadly, none can be done correctly.  Those organizations that do these rituals without reasoning, or do Scrum in name only aren’t improving, growing or learning.

When staging an agile transformation, my first act is to set up as many cross-functional, multilevel one-on-ones as possible.  The one-on-one frequency varies based upon particular needs of the individual.  They are always confidential and designed as a safe place for exploration and learning.  I always focus on root cause analysis in my questioning to help raise curiosity as to ‘why’.  I have never been disappointed by the 5 ‘whys’ questioning method that quickly guides our one-on-one to a deeper understanding of the situation and presents alternatives to consider.  I explain how PDCA, retrospectives, etc are aspects of learning and experimentation, and how those must be done to achieve improvements, albeit initially on a small scale.

What I’ve noticed is after a number of these meetings, that those involved in my one-on-ones start to set expectations with their leaders and teams for root causes, deeper reflections, incremental improvements and seeking information on concepts they don’t understand.  Learning is valued.  Time is set aside for discussions.  Experimentation is planned.  Results are inspected.  Adjustments are made.

As leaders mimic, teams start to learn and pick up on the value of Sprint Reviews and Retrospectives.  Teams become curious about ‘why’ the various rituals, metrics and roles are defined.  They become open to the role of the Scrum Master guiding the team to maturity.  This opens the door to more learning and improvements.  

A Learning Organization that only remains within a single function like engineering, can make good progress on an agile transformation, but one that does it across multiple functions can make amazing progress on agile transformation and the velocity of business value delivered.

The difficult step in a Learning Organization is to learn together across functional groups and across teams.  This means understanding that the role of leadership in an agile organization is different from what they may have grown accustomed to.  Functional leaders and their functions play important roles in agile organizations.  Setting up and enabling the role of architecture that empowers teams to act and gain velocity. Building a value chain from specification to builds to validation to deployment to enablement to sales to support.  Defining a product backlog that is built on continuous increments of capabilities that are continuously deployed.  

I liken creating a Learning Organization across functional groups to that of nurturing a human being.  When the human is a child, we nurture and educate them on the basics with an expectation that they will eventually grow and mature.  When they reach their teens, we help them understand the deeper, abstract nature of the world around them.  We can demand more from them, but they remain immature in other ways.  When they reach their twenties, we help them understand the interconnectedness and interdependence of complex systems.  We demand professionalism and perfection.  

I have found that a functional organization is well aware of their shortcomings, however, they expect and demand perfection from all of the other functions.  I have to point out that while the individuals and organizations may be highly experienced and successful, they too are in the midst of an agile transformation both within their organization and their relationship with the other organizations.  We need to realize that together we operate more like a child that needs nurturing and education together.  This is far better than demanding a child to do something that they are incapable of doing and expecting adult results.  

As we grow being a Learning Organization, we as a whole organization will become teens and adults.  As mature adults, we now understand the complexities in delivering value and continuous improvement.  We innovate. We teach.  We are consciously competent together.  

The Wonderment of All Innovation

I was talking with an Engineering Manager who said that the Product Owner (PO) and PO’s boss were concerned that the team was spending too much time reducing technical debt, improving quality and gaining velocity.  While the PO agreed on the priorities, the PO wanted more innovation delivered to customers.  On the other hand, the team was feeling that these critically important debt-reduction, quality and velocity improvements were not valuable to the business, that they were not doing anything innovative, and that management didn’t acknowledge their progress.  Net-net, no innovation means no customer features, no business value and no rewards.

Reaching for my trusty keyboard and browser, I searched for the definition of innovation and found from Wikipedia.org, “Innovation is the practical implementation of ideas that result in the introduction of new goods or services or improvement in offering goods or services”.  I pointed out that innovation is also practical improvements, confirmed by Wikipedia.org no less.  

While customers may not be blown away by some long overdue restructuring of code to improve reliability or performance, they would call support less often to complain.  While customers may not see whizzy new UX features, they would appreciate ceasing well-known, frequent UX workarounds because the UX bugs were finally fixed.  While customers cannot see that the team is becoming more efficient, they will appreciate that over time, the team is delivering more new features every quarter.  The Engineering Manager appreciated the perspective and headed back to engage the PO and team with a new perspective about innovation.

I started to realize that high technology lauds innovation of the new products, new services, and new business models.  Employee performance evaluations often have a section related to the employee’s innovation during the past year.  This implies the more impressive the innovations, the higher the performance rating.  Gaining access to the high rungs of the technical ladder requires patent grants, new products and new features in the candidate’s recent accomplishments.  Executives sponsor innovation days that allow teams and individuals to work on something innovative and new, and to break their daily monotonous routine.  

The notion of ‘1% inspiration and 99% perspiration bring new products to market’ floats into my head.  Does that mean that we personally only spent 1% of our lives innovative?  Does that mean that we, as individuals, have 1% of people who are spending most of their time being innovative?  Does that mean that we, as teams, have 1% who are spending most of their time being innovative?  Does that mean that we, as organizations, have 1% who are spending most of their time being innovative?  What if I’m in the 99 percentiles personally, individually, team-wise and organization-wise?  Am I relegated to an existence without being innovative?  Looking back at my career, I am clearly in the 99% and yet, I know that I, my teams, and my organizations have been highly innovative.

How does the above notion mesh with my experience with agile transformations where teams, leaders and organization literally rethink and refactor almost everything they do?  They refactor how the communicate strategy and set goals.  They refactor how they architect, build, validate and deliver their value.  They change their expectations of teams, individuals, management, product managers and architects.  They rethink their relationships with internal partners and external customers.  In short, they implement a pragmatic new development and delivery system that improves quality and speeds new value delivery to customers.  Using the innovation definition, it seems that those who improve both how and what they deliver to customers is worthy of being called innovative. 

So, why do high tech companies seem to value new breakthroughs or major innovations more than on-going, constant improvements by implying one is innovation and the other isn’t?

Maybe because it’s easier to recognize and reward the infrequent, yet highly valuable breakout features and products.  We cheer major accomplishments more than the on-going, constant flow of incremental improvements.  A patent is tangible, demonstratable and rare.  Having a patent wall to celebrate the achievements makes good sense.  A well-received product launch where the press and analysts’ sound bites reflect the innovative new features, is easy to reference.  Audiences like sound bites.

Whereas a constant sprint over sprint improvement of 1% in team velocity is abstract, gradual, and too small to be noticed or recognized.  Beyond the team, who cheers this accomplishment? Same is true for all the numerous on-going improvements that a Scrum team makes from retrospective to retrospective.  These small improvements are critical and yet too small to take note.

Maybe we are missing the notion of wonderment, or the state of awed admiration or respect.   I am fascinated by a child’s wonderment at the small things they encounter, the recognition of a familiar face, their first mobility, their first verbal communication that yields a result, their first success in their classroom, their first friend, and their first financial transaction (You can get candy if you give them this round shiny thing?!?!  Who knew?). 

Equally, I’m fascinated by an organization’s wonderment at small things they encounter on their agile transformation, their first meaningful standup, their first successful sprint goal being fully met, their first planning or review meeting conducted solely by the team with everyone in the correct roles, and their first incremental delivery to a high-quality definition of done.  

What if we expressed our wonderment at every improvement?  What if wonderment encourages more innovation in both small and big outcomes?  Imagine if leadership would spend time sharing their wonderment with all the innovations that their organizations including the small, incremental improvements.  

Maybe it’s too time consuming to express wonderment at all the small improvements, however, it’s easy to see the resulting trend improvements (better velocity, quality, meeting effectiveness, reduction of technical debt and efficiency) when using Scrum.  Maybe expressing wonderment for the positive trends would suffice to encourage teams to continue doing both the small and big innovations.

Dependency Management in Agile Development

By Heeman Lee, Republished with permission.

Dependencies 

Dependency is anything that must happen to complete Product Increment but cannot be done by the Scrum team alone. When an organization adopts Scrum, dependencies surface. It’s not that they didn’t exist before, but they are more exposed under Scrum practice. As you scale your Scrum teams, the dependencies scale as well. Perhaps you have adopted Scrum framework, but you are not yet fully structured to support cross-functional teams. Maybe your product or system has a strong reliance on vendors or specialists from day-one. Or it has grown to a large-scale system. Any changes require some level of dependencies. Whatever the reason is, the reality is, we created dependencies and they don’t go away easy unless we take action. 

Why dependencies exist 

There are three major reasons why software development teams struggle with dependencies: 

1. Lack of cross-functional skills in teams 

2. Overly complex architecture 

3. Component based organizational team design 

While cross-functional teams are the essence of Scrum, it might take a long time for the organization to evolve. Teams don’t become cross-functional overnight. Leaders’ support combined with team members’ willingness to learn builds cross-functional teams over time. Working through dependencies is one of the best ways to nurture teams into cross-functional teams. It’s rarely the case that you formed a perfectly cross-functional Scrum team that has no dependencies. Any Scrum team determined to relentlessly identify and resolve dependencies ends up building necessary skills to be independent. Through the process of seeing dependencies and making ruthless effort to mitigate and eliminate them, Scrum teams grow skills and structure as cross-functional, self-organizing teams. 

As Scrum teams work through dependencies, it will expose the need to simplify the architecture and reduce the number of components. It will also necessitate organizational design change as the senior leadership assists teams to find better ways to resolve dependencies. It will, in turn, make it easy to form additional cross-functional, cross-component teams. 

Building small but strong, functioning Scrum teams is crucial. Cross-functional, self-organizing teams will decouple dependencies. A well-built Scrum team will coordinate and communicate to identify and eliminate dependencies. They continuously expand collaboration networks and their skills to increase autonomy. 

As dependencies surface, the organization leaders must put the heavy and high-risk dependent work items to top of the Product Backlog. Make dependencies visible and tackle them first at the organization level. In turn, recursively address the product backlog items that are dependent on 3rd party teams so that they are segregated and addressed at the early phase of Scrum adoption. 

Maturing through Dependencies

Over the course of Agile journey, organizations likely see this pattern of dealing with dependencies. 

Figure 1 Progression team maturity with dependencies 

In the early stage of Agile, a team carries over sprint backlogs over multiple sprints while waiting for the other team to address dependencies. Only few people have control and permission on code changes, and most code bases are tightly coupled. Team velocity is inconsistent, and the team members are frustrated. 

As the team matures, they identify any external dependencies during backlog refinement. They split the product backlog item with external dependencies and bring the consecutive item back into the backlog to complete later time. Or teams invite guest team members to work with them to complete the story during the sprint. Team members learn from the guest member and start developing the skill. However, they still struggle with tight coupling of code base and permission/authority to review the code. 

With leaders and managers enabling the teams, they will start focusing and take time to cross-train to own more of the work for themselves, growing to become cross-functional. With that, they can resolve dependencies in their domain of work and address related complexities in architecture. In order to do that, the leaders make sure the team is given authority and permission to make changes. 

With this trend, the team gets empowered. They become more and more cross-functional. They will have people and skills needed to finish their work. They will be better at seeing the open dependencies and won’t take in the work with dependencies into sprint. At the same time, they are capable of learning new skills to resolve other complexities and dependencies. Also, they create a network of collaboration with other teams with different expertise. Team members enjoy the new challenge that comes with stories. Team’s skill expands and continues to grow as a cross-functional team. Dependencies will not scare or frustrate the team. Another benefit from this is that the code base is quite decoupled and other than critical permission and control, the teams are given authority to make changes. 

Ability to mitigate or even eliminate dependencies lies in empowering people and enabling the development flow. 

In the short term, collaboration is key. For a longer-term, more empowerment is the way. Boldly consider cross-training, opening up permissions and organizational design changes. It takes effort from everyone to see successes in the whole organization. 

With a large organization scaling Agile methodology, the first step is to identify the teams that need to coordinate and form a team of teams (Scrum of Scrums in SAFe, or MetaScrum in S@S). The Product Owners gather regularly to visualize the dependencies and honestly review and prioritize the product backlog items by the value and impact. All the dependencies must be made visible and evaluated against other demands. Make sure to involve the decision-making stakeholders so they resolve impediments and the team can focus on solutions. 

As teams mature, they should seek the way to cross-train each other to make each team as autonomous as possible. They also build skills to make the team of teams a cross-functional team as a whole. 

Eliminating Dependencies

The dependencies issue could be solved in two ways. Short-term quick fixes or fundamental long-term solutions. 

Short Term Plan 

The quick fix is to visualize the dependencies and control the work order. For example, using a specialized tool like Jira to visualize dependency maps, you can reorder product backlogs and plan dependent items for later Sprints. 

Figure 2. Jira dependencies map 

It somehow helps teams to survive and continue the development progress. However, beware; the visualization and dependency management may become a critical process and special role instead of being a pathway to eliminating dependencies. 

Long Term Plan 

The fundamental solution is to eliminate the underlying issues of dependency completely by: 

● cross-training people 

● making the architecture simpler, reducing the number of components 

● changing organizational design and forming cross-component cross-functional Scrum Teams 

The bad news is that a strong culture of “managing dependencies” will hinder the implementation of the fundamental solutions. 

The more dependencies, the less agile organization becomes. Creating additional roles and using dependencies management practices do not eliminate the fundamental dependency issues.

In order to eliminate dependencies, the role of executive leadership is crucial. No one else in the organization is uniquely positioned to make system-wide changes that can free up resources and remove constraints. They can enable flow and empower the people. Enablement focuses on the act of assisting; removing constraints, changing systems to make development flow better. Empowerment is granting of power so that individuals or teams can make autonomous decisions; clear product vision and strategy, shared common goals and having easy access to the needed resources to make decisions. 

How to enable flow? Conduct value stream mapping5to find out waste and delays in the development process. The goal is to build your organization to rational value streams and a sustainable team with decreasing external dependencies outside the value stream. To empower people, the leadership must build a culture of empowerment. In lean organization, people who add value are the center of the organization. They are empowered. Such an organization's cultural norm is empowering teams to give them autonomy. By empowering individuals and teams, you decentralize the decision-making point and lessen the constraints and dependencies. 

Developing the habit of checking for dependencies during Backlog Refinement and Sprint Planning is a great way to detect and mitigate dependencies. In addition, continuous integration (CI) powered by automated continuous testing accelerates identifying dependencies. No matter how mature the Scrum team becomes, not all dependencies are discovered through Backlog Refinement. Automated processes can greatly help detecting the hidden dependencies that can only be revealed as a product is developed. 

Strategy, Backlogs, Sprints and Scrum

Every business operates in a market and develops a business strategy to guide its way forward to capitalize on its strengths and opportunities. The challenge is how to operationalize the strategy in meaningful steps forward to achieve strategic goals as a single operating business.

A company can be focused on how to construct Scrum@Scale with a structured, hierarchical, product backlog that supports the business strategy. The business strategy is supported by a small number of Strategy outcomes. The Strategy outcomes are supported by Theme outcomes. Themes are broken down into Epics, and further into User Stories.  Scrum Teams use this backlog context to plan their sprints and create the highest customer value possible.

Scrum is focused on short sprints with small increments of customer value delivered. The focus of a Scrum-based organization tends to be on ensuring Scrum Teams are always productive. With a two-week sprint, the drum beat of unrelenting sprint planning, daily standups, sprint reviews, retrospectives and grooming under the pressure of burn-down charts and accelerating velocity, organizations often become extremely tactical and struggle to get above the fray.

Organizations who become so focused on the urgent needs of the Scrum Teams, quickly lose sight of the business strategy and long-term customer needs. Enter the Executive MetaScrum or EMS!  The company and Scrum@Scale empowers the EMS with the duties to get above the fray and guide the Scrum organization towards fulfilling the business strategy. However nice this sounds, leaders struggle to translate strategic direction into two-week increments for the Scrum Teams.

Before jumping into more details on how strategy and Scrum work together, allow me to develop an example of a business strategy and groomed backlog for a moment.

Let’s say that the business strategy talks about switching the business to a subscription based, software-as-a-service SaaS model and shifting away from a purchased software license model. Let’s say that the EMS has groomed a roughly one-year out Strategy outcome to get 80% of purchased software license customers using a new SaaS based model. This includes monitoring, support and an update tool that automates defect queries, recommends updates, assesses the likelihood of a successful upgrade and, eventually, guides the upgrade process. This Strategy outcome is the first of other Strategy outcomes on the backlog that continues the movement of purchased software towards SaaS. But this also means that any further Strategy outcomes are, at least, over a year away.

The business grooms the Strategy outcome into the following Theme outcomes. The Theme outcomes are abbreviated here and would be expressed in:

‘As a Kubernetes clusters admin overwhelmed by the complexity of dealing with so many applications, I only have 1/100 of my cycles available for any one on-prem application to be updated and need <some customer outcome>, and I know that I’m  done when <some customer acceptance criteria>. ‘ 

For brevity, we have: A) Provide Kubernetes Admin Real-time monitoring and support information and B) Provide Kubernetes Admin update decision making insights, and C) Take over Kubernetes Admin update tasks. These are then broken down into the following Epic outcomes. Abbreviated here as: A1) SaaS set up (basic accounts, licensing access,  customer information), A2) SaaS customer connectivity (SaaS to on-prem SW  communication), A3) SaaS defect connectivity (SaaS to defect DB with correct filters), A4)  SaaS update connectivity (presents basic information to customer on updates), A5) SaaS  support chat, A6) SaaS defect search, A7) SaaS update search, A8) SaaS account resets,  A9) SaaS customer signup promotion discount, A10) SaaS customer survey, A11) SaaS  usage metrics, B12) SaaS defect notification recommendation based upon installed SW,  B13) SaaS update recommendation based upon installed SW, B14) SaaS code currency  metrics, B15) SaaS recording of on-prem SW update metrics, C16) SaaS auto-recording  of on-prem SW update failures, C17) SaaS basic risk assessment of on-prem SW upgrade,  and C18) SaaS basic ‘guided’ update of on-prem SW. Whew, that’s a lot of work to be  done isn’t it.

I’ll spare the on-going details of breaking the Epic outcomes into specific User-Stories and tasks, but you can start to image various Scrum Teams from SaaS development, on-prem SW development, IT operations and support development involved in the on-going work break down into customer story increments, sprint goals, and sprint backlogs. As this work fans out across the organization, the complexity grows. All attention from the business to the individual engineers is consumed by the details.

Not bad, right? You can see how we would go about getting the Strategy done.  Start A Theme. Do A1 then A2, A3, A4 and A5, etc. Follow with B Theme. Do B12, B13, etc. Then on to C Theme and Epics. Easy.

The sequencing of A Theme with Epics, A1, A2, etc. then B Themes and Epics, seems obvious to good planning. Doing out-of-order execution of parts of Themes and Epics seems to defy good predictive planning and good hierarchical structure. No one is that good at planning and grooming at onset, otherwise, we’d all retire at 30. Since we’re not that good at planning and grooming, expect to see a lot of out-of-order execution happening, as well as refactoring as we go. Still easy. Right? 

Well, it’s worse. Since when do we only have one Strategy outcome and three Themes? The reality is that the business has 3 to 7 Strategy outcomes and up to 50+ Themes all happening in parallel. So, the on-prem SW Scrum Teams has 2 or more other Strategies outcomes and maybe 30 Theme outcomes, as do the SaaS Scrum Teams, the IT Scrum Teams, etc. The various stories, dependencies, short-term work, longer-term work start to interact forming a complex array of customer story increments, sprint goals and sprint backlogs. Yikes!

Let’s not also forget about sales deals, revenue pressures, demanding customers, longer term architecture projects, and technical debt. These too are pressing for attention to address their needs. This adds to the near-term focus pressure and takes away from the business strategy. Does this seem real enough yet?

Strategies can be simple. They can be complex. Depending upon our abilities, the execution can be straight forward or prolonged. Depending upon our competitors, the results can be extremely rewarding, muted and/or confounded. Let’s use some games to help us illustrate these points. Consider tic-tac-toe, checkers and chess.

Tic-tac-toe also known as ‘Noughts and Crosses’ or X’s and O’s is a paper-and-pencil game for two players, X and O, who take turns marking the spaces in a 3×3 grid. The player who succeeds in placing three of their marks in a horizontal, vertical, or diagonal row is the winner.

Draughts or Checkers is a group of strategy board games played on a checkered board with 64 squares arranged in an 8x8 grid, for two players which involve diagonal moves of uniform game pieces and mandatory captures by jumping over opponent pieces.

Chess is a two-player strategy board game played on a checkered board with 64 squares arranged in an 8×8 grid. Play involves no hidden information. Each player begins with 16 pieces: one king, one queen, two rooks, two knights, two bishops, and eight pawns. Each piece type moves differently, with the most powerful being the queen and the least powerful the pawn. The objective is to checkmate the opponent's king by placing it under an inescapable threat of capture.

In tic-tac-toe, the strategy is simple. The moves are simple. When the marketplace is simple and the first mover advantage is in play, then focusing everything on the first and second moves determines the winner. There are at most 9 total moves in the game.  Moves are big decisions in the context of a game. In this case, having one Strategy outcome, a few Themes and everyone focused on one or two major outcomes is best. Very straight forward but not a typical business reality for big companies.

In checkers, there are more pieces, and the game board is bigger. However, movements are restricted, and capabilities must be earned. Checkers requires strategy and initiative refinements throughout the game. Strategy can be bold at the beginning until the opponent’s moves take effect. Moves are small and incremental, much like a sprint.  Strategies are brought about by a series of incremental moves. Checkers is like a complex business market because players have strategy and potentially one or more outcomes they are trying to bring about. However, it can also be unlike a complex business market as products have infinite flexibility in how they are brought about and operate in the marketplace.

Are you noticing the pattern? The game board, opponent, strategy, play outcomes, pieces and moves are akin to a market, competitors, strategy, Strategy outcomes, Theme outcomes, and sprints delivering incremental customer value, respectively. 

Let’s keep this pattern in mind as we look at chess. Chess is like checkers, except there are various capabilities of six game piece types. Pawns are numerous but are restricted to forward movement, one space at a time. The queen is most powerful as she can move any number of spaces in any direction per move. The other pieces have capabilities in between these two. The game strategy must take the game pieces capabilities into account and engage them smartly. Constant monitoring and adjustments are made to strategy and outcomes as the other player’s make their moves. Moving a piece to a desired location may take moves of other pieces before the desired piece can even move, during which time, the opponent is also making moves. This complexity is more like a business market and competitors. While we want to deliver certain outcomes, we’re inhibited and/or enabled by our capabilities, we must keep certain pieces on the board viable as we develop the next plays for other pieces, yet to be engaged in the game. We may be focusing on one area of the game board while our competitor is focused on another. While moves are technically visible, the strategy is invisible and constantly being re-evaluated. Every play, every sprint, seems minor but is important for the strategy of the long game.

Like all analogies, the chess game isn’t a perfect comparison to a real business strategy or market, but it illustrates well the value of constant re-evaluation of strategy and the cost/necessity of strategic change. It also demonstrates well how minor moves can upset an opponents’ strategy and/or outcomes. The most important lesson here is that chess provides a well-known, learning framework to explain how strategy relates to Strategy Outcomes to Themes Outcomes to Epics Outcomes to Stories (completed incrementally with each sprint), can build into a powerful market force.

Back to our earlier example, where our Strategy outcome is ‘to get 80% of purchased software license customers using a new SaaS based model, within a year’. Let’s call our Strategy S6 outcome as the following:  A monitoring, support and update tool that automates defect queries, recommends updates, assesses the likelihood of a successful upgrade and eventually, guides the upgrade process

Adding complexity, let’s say that we have 5 other Strategy outcomes, S1 to S5. For ease, each Strategy outcome relates to a specific software offering that we already have (S1 to S5) or will have (in the case of S6). There’s no need to specify the S1 to S5 Themes and/or Epics outcomes in detail here, except to note that they have similar complexity of Themes, Epics, etc. as S6 has.

If we continue with the chess analogy, our marketplace is the chess board, and our major competitor is our opponent. We and our opponent have our products and/or offerings in the marketplace and are investing in them. The changes in the products reflect the piece moves.

Imagine that we have our offerings reflected by our Strategy outcomes that we eventually want to achieve over the course of the year (the game period). S1 to S6 outcomes are positioning of our six key pieces in the marketplace by year end. This means capability in position to take action for the coming year. (I’m using a year as a game play horizon for this post.) 

Now, we must move our offerings to their associated Strategy outcomes through a series of moves based upon our capabilities, in the given period. While our business will worry about each Strategy outcome, for the purposes of this paper, we are going to let S1 to S5 randomly impact our ability to get S6 in position by year end (the Strategy outcome).  Remember, we will also have impacts to our S6 outcome caused by our competitors moves. 

The last part of the setup are the moves. A move is taken at the end of a two-week sprint with every Scrum Team creating Definition of Done-Production Ready (DoD-PR) increments. This completeness of increments is critical to the game because partial moves or the inability to move a piece when needed, would undermine the game.  Equally, because we’re doing mature Scrum, each offering is ready to be moved at any moment in time. We are always in production-ready quality at the end of each sprint cycle for all offerings. 

The point of small increments being DoD-PR at the end of each sprint for all offerings cannot be stressed enough here. Having work-in-progress (WIP) preventing us moving forward on the strategy, would be akin to moving a chess piece back and forth on the game board because that’s the only move available. Consider the cost of these wasted moves during the game.

Let’s look at how we’ll bring about our Strategy S6 outcome during the year using two week sprints or moves. 

Remember our S6 Outcome is: ‘80% of purchased software license customers using a new SaaS based monitoring, support and update tool that automates defect queries, recommends updates, assesses the likelihood of a successful upgrade and, eventually, guides the upgrade process.’

S6 THEMES are: 

A) Provide Kubernetes Admin Real-time monitoring and support information

B) Provide Kubernetes Admin update decision making insights

C) Take over Kubernetes Admin update tasks

S6 EPICS are: 

A1) SaaS set up (basic accounts, licensing access, customer information)

A2) SaaS customer connectivity (SaaS to on-prem SW communication)

A3) SaaS defect connectivity (SaaS to defect DB with correct filters)

A4) SaaS update connectivity (presents basic information to customer on updates)

A5) SaaS support chat

A6) SaaS defect search

A7) SaaS update search

A8) SaaS account resets

A9) SaaS customer signup promotion discount

A10) SaaS customer survey

A11) SaaS usage metrics, 

B12) SaaS defect notification recommendation based upon installed SW

B13) SaaS update recommendation based upon installed SW

B14) SaaS code currency metrics

B15) SaaS recording of on-prem SW update metrics

C16) SaaS auto-recording of on-prem SW update failures

C17) SaaS basic risk assessment of on-prem SW upgrade

C18) SaaS basic ‘guided’ update of on-prem SW.

For simplicity, I have clocked the S1 to S6 position changes for each sprint or move. One could imagine any one of these taking more/less time, and you see the pattern laid out to bring about the Strategy outcomes.

Strategy	Position	Moves
S6	1st	Get A1, A2 done by the SaaS and IT Scrum Teams
	2nd	Include SaaS A) in all S1 to S5 offerings’ licenses and drive volunteer customers to sign-up
	3rd	Get A3, A4 and A8 done
	4th	Get A6, A9 and A10 done, include SaaS A) discount if customers sign up account to use defect DB tool, incremental discount for update usage, and a final discount for automated updates.
	5th	(and next position for S1) Get A6 done for offering S1
	6th	(and next positions for S2 and S3) Get A6 done for offerings S2 and S3
	7th	Get A5 done, drive usage as high as possible by offering support discount for customer defect queries
	8th	(and next positions for S4 and S5) Get A6 done for offerings S4 and S5
	9th	Get A11 and B13 done.
	10th	(and next position for S1) Get B13 and B12 done for S1.
	11th	(and next position for S2 and S3) Get B13 and B12 done for S2 and S3
	12th	(and next position for S4 and S5) Get B13 and B12 done for S4 and S5
	13th	Get A14 and B15 done
	14th	(and next position for S1) Get B15 done for S1
	15th	(and next position for S2 and S3) Get B15 done for S2 and S3
	16th	(and next position for S4 and S5) Get B15 done for S4 and S5, get B13 and C16 done
	17th	(and next position for S1) Get B13 and C16 done for S1
	18th	(and next position for S2 and S3) Get B13 and C16 done for S2 and S3
	19th	(and next position for S4 and S5) Get B13 and C16 done for S4 and S5, get C17 done
	20th	(and next position for S1) Get C17 and C18 done for S1
	21st	(and next position for S2 and S3) Get C17 and C18 done for S2 and S3
	22nd	(and next position for S4 and S5) Get C17 and C18 done for S4 and S5

 

Did you keep track of all the moves and complexity in the 22 sprints? Pretty difficult but if you do tick off the Themes and Epics, you see that by year end, S6 is in good shape to fulfill the outcome.

Now, try to imagine a situation anywhere above where we are unable to deliver our next move. Having work partially complete (WIP) does this. Then imagine the accumulation of this WIP preventing other pieces from moving. See how much more complex the sequencing becomes. Therefore DoD-PR and small increments must be reached and maintained across the Strategies and Scrum Teams.

Now let’s see how much you were following.

Did you notice that A7 was not implemented? As we laid out the steps, the plan was modified to no longer allow the customers the ability to query for updates (the feature usage was expected to be short lived, and the feature wouldn’t drive any incremental customers to sign up). Not doing A7 is not a failure, rather, it is a saving. Doing something unnecessary is a form of waste. Seeking these refinements during the year means retiring Strategy outcomes faster. 

Did you notice that measurement of the Strategy outcome A11, was not completed until the 9th move? While critical to management and/or the outcome, it was deemed less valuable until enough of the SaaS offering was completed with the S1 to S5 offerings’ work was integrated before work on measures was taken on. If necessary, the A11 work could have been moved out in time as needed.

Equally, you can imagine that as we started to work this plan, that the competitor of the S2 offering makes a change, putting pressure on the business to bring our S2 offering to market sooner, even to the point of delaying other offerings to the following year.

Also, you could imagine that while we’re clocking away incrementally, that S5 work is always highly problematic due to its extreme complexity. The plan could be re-worked to move all S5 work to beyond the S6 outcome period to isolate this risk. We could even go further by deciding to stop all work on S5, effectively, sacrificing S5 to the market forces in order to ensure S1 to S4 and S6 outcomes.

Next, imagine that the other Strategy outcomes have an equally detailed sequence of moves, internal difficulties and competitors moves to consider. You can see why as we’re engaging the marketplace competitor, we must continuously reconsider the moves, reconsider the ordering, and/or reconsider the Strategy outcomes.

What makes this all possible is that the ordering is thought through and written down, moves are small production increments, and when change is needed, the context and impacts are readily understood. The changes can be communicated with the rationale across all Scrum Teams consistently, so everyone knows the state of play.

Equally, you can see why the Executive MetaScrum (EMS) review of strategy and Strategy outcomes is both constant and on-going. 

The EMS role is to reconsider with each sprint, the validity of keeping Strategy outcomes unchanged and the Theme outcome priorities. This does not mean changes with each sprint. The EMS must even be open to retirement of a Strategy when there is sufficient progress made, and the business needs another Strategy outcome started. 

The metametaScrums’ reviewing Strategy outcome fulfillment is equally engaging for their level of work. Same for the metaScrums at the Epics and User-Story level. You can see why each Scrum Team reaching production-ready for each User-Story within a sprint helps the business’ flexibility. Equally, incremental progress of Epics aids the understanding of progress on Themes, which aids the understanding of progress on Strategies so each level of metaScrums make the right decisions on retirement, changes and on bring forward new outcomes.

While in our example, we set the Strategy S6 outcome to be ‘80% adoption’, you could see that goal raising or lowering during the year, based upon strategy and/or other Strategy outcome changes. Additionally, had we hit 90% adoption with just Themes A and B, we might have delayed the work on Theme C and moved out the associated discounts to help profit margins in the current year. 

This raises the point that often Strategy outcomes are ‘gray’ because of the time horizon (a year out) and unknown nature of the game play during the year. While 80% is concrete, the EMS retains the ability to adjust the goal and/or outcomes as the year plays out. 

Does this mean that Annual Planning cycles are meaningless to the business?  Annual Plans remain critical to set annual goals and align various functions like Sales to reduce on-going thrashing and churn. Annual Plans do change, albeit infrequently, as the year progresses, and new understanding of reality happens. You can imagine that while Annual Plans may change infrequently, that Strategy outcome changes might occur a bit more frequently, that Theme outcome changes might occur much more frequently and that Epic outcome changes happen very frequently. The key is constructing a systematic and meaningful way of assessing, controlling and communicating the changes. 

Finally, let’s head back to tic-tac-toe and checkers. While these games are simpler and the strategies to win are easier to master, there is less flexibility to tolerate mistakes or to overcome obstacles as they materialize. The challenge of chess is its flexibility is derived by its complexity to bring about the outcome. Chess requires a deeper comprehension of the game, the pieces, the strategy and each move. Winning in a multi-billion dollar marketplace requires a similar deep comprehension. 

Every move must count!