As I look back at the different software delivery organizations I travelled with on the path of business agility, I started noticing some patterns in the risks that often slow down or derailed our journeys. Nine key risks stood out in my mind, but I did not have a very methodical approach towards managing them. I recently learned an approach that in hind-sight could have helped me in the past. I want to invite you to consider these risks and try out this new approach, in the hope that it helps you in the present and future.
“The quality of life is determined by the quality of questions we ask.”
– Dr. John Demartini
One of the ways a coach might help an organization is to take them on a guided enquiry to discover answers to the most meaningful questions that confront them. Perhaps one of the first set of questions we might ask ourselves and our teams in the path of Business Agility are…
QUESTION 1: What the heck is Business Agility anyway? How do we define it around here? Do we all agree? If not, where are the disconnects? Should we reconcile them to reach a common definition? How?
Here is one possible way to define Business Agility, as described in The Agility Guide…
Business Agility is an organization’s ability “to take advantage of opportunities, respond effectively and deliberately to challenges, all while controlling risk and optimizing the return on investment.”
Let’s assume that we decide as an organization, that Business Agility is important and that we create a
shared definition of what it means. Let’s also assume that we choose to use Scrum to help us stay on this path. Perhaps, the next two questions to consider might be…
QUESTION 2: What risks might slow down or de-rail our journey on the path of Business Agility?
QUESTION 3: When we inevitably have disagreements about how well we are managing these risks, is there some unbiased, objectively verifiable approach to settle differences?
This is where I think of one of my favorite TV characters from CSI Miami – Horatio Caine. Horatio Caine is famous for the one-liners he uttered as he put on his sun-glasses. It’s been a while since I watched CSI Miami, but one of his quotes that stuck in my mind is (and I might be paraphrasing here)…
“Follow the evidence, wherever it may lead.”
This is the foundation of the Evidence Based Management approach to software delivery that challenges us to use objective, verifiable data to guide an organization’s journey on the path of Business Agility. The goal is to avoid arguments based on what your gut says vs. what my gut says and shift the conversation on what the evidence says, no matter where it leads us.
So here are some ideas on the risks you might evaluate on the path of Business Agility and how you might use Evidence Based Management to manage them…
RISK #1: TEAMS LACK A SHARED AND ACCURATE UNDERSTANDING OF “WHAT” IS AGILE SOFTWARE DELIVERY WITH SCRUM
This seems like a basic, no-brainer question, but every single Agile Transformation I have helped with has been plagued with team members having completely different interpretations of what Agile Software Development is.
The foundation of Agile Software Development is Empirical Process Control. In almost every Agile Transformation I have been part of, there was no one who could explain what Empirical Process Control was. Here is one possible way of answering that question, adapted from The Scrum Guide
Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Transparency: Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
Inspection: Users must frequently inspect artifacts and progress toward a goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
Adaptation: If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
It may seem obvious to experts, but in many organizations, those trumpeting Agile often use the word to support whatever agenda they want to pursue. Often, the people throwing around the word “Agile” don’t know or don’t care about any contradictions between what they are proposing as Agile and the Agile Manifesto and Agile Principles.
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
ORIGINAL SIGNATORIES:
|
Kent Beck |
James Grenning |
Robert C. Martin |
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
So how can you use evidence to manage whether this risk is derailing or slowing down your journey?
EVIDENCE #1: One possible way to collect objective, verifiable data to manage RISK 1 is to have your team members take free, Open Assessments to gauge whether your entire team has a shared, accurate understanding of what Scrum and Agility mean.
So what do you do, if the evidence indicates that there are contradictory and inaccurate interpretations of Agility and Scrum on our teams? What steps might you take to manage this risk?
EVIDENCE BASED MANAGEMENT TECHNIQUE #1: One of the possibilities is to have your team members read and discuss the Scrum Guide and then re-take the open assessment. If the readings and conversations were effective, the team scores on this assessment should show a dramatic improvement and validate that the time invested in Agility generated ROI.
So let’s say our teams have a shared understanding of the “what” of Agile and Scrum. What might go wrong next on the path of Business Agility? One of the common risks I have observed in my Agile Transformations is blind, ritualistic adoption of Scrum, without understanding the underlying principles. Many Agile Coaches refer to this as Cargo Cult’ing. This is where team members blindly follow some Scrum practices in letter without understanding the spirit and then get dismayed when those actions do not generate the desired results. This leads us to the next Risk…
RISK #2: TEAMS LACK A SHARED AND ACCURATE UNDERSTANDING OF THE “WHY” OF AGILE SOFTWARE DELIVERY WITH SCRUM
EVIDENCE #2: One possible way of gathering objective, verifiable evidence that might indicate that this is de-railing your journey, is to have your team complete Free!!! Open Assessments and compare scores and results. Questions that the team members got wrong might open up great topics for team discussion and help understand why you might not be getting results from Agile.
EVIDENCE BASED MANAGEMENT TECHNIQUE # 2: If the team has low scores on the Free!!! Open Assessments, it may indicate problems with the foundations of Agile and Scrum in your organization. It may be time to send the team to Professional Scrum Foundations Course. Re-taking the open assessments after completing the course could provide evidence on whether the investment in training generated the desired ROI.
OK, so by now, maybe the team is now getting a consistent, accurate understanding of the what and why of Agile Software Delivery with Scrum, but they are struggling with practical application of the theory. This brings us to the next risk…
RISK #3: TEAMS LACK KNOWLEDGE AND SKILLS RELATED TO THE “HOW” OF PRACTICING AGILE SOFTWARE DELIVERY WITH SCRUM
EVIDENCE #3: Have your team take role-specific assessments to gauge the depth of their tool-kit. Developers could take the Professional Scrum Developer Assessment, Scrum Masters could take the Professional Scrum Master Level 1 Assessment and Product Owners could take the Professional Scrum Product Owner Level 1 Assessment. Low scores may indicate a gap in this area that might manifest as sub-optimal results on the path of Business Agility.
EVIDENCE BASED MANAGEMENT TECHNIQUE #3: One possible way to manage this risk is to have your team members attend role specific courses. Developers could attend the Professional Scrum Developer Course, Scrum Masters could take the Professional Scrum Master Course and Product Owners could take the Professional Scrum Product Owner Course . Re-taking assessments after the course could indicate that there has been an increase in the knowledge level that will manifest as better skills and better business value on the path of Business Agility.
Now, let’s assume that our teams have become effective in the techniques and practice of Agile Software Delivery with Scrum. However, there still appears to be something missing. We are unable to realize the kind of ROI we were hoping for. Maybe something smells bad, the morale of the team is not high and in some cases questionable decisions are being taken in different parts of the organization. Here are a couple of risks that may be at play…
RISK #4: TEAMS ARE PRACTICING AGILE SOFTWARE DELIVERY WITH SCRUM WITHOUT CONSISTENT APPLICATION OF THE SCRUM VALUES
RISK #5: TEAMS ARE PRACTICING AGILE SOFTWARE DELIVERY WITHOUT CONSISTENT ADHERENCE TO AN ETHICAL CODE OF PRACTICES
Most organizations practicing Agile Software Delivery lose sight and connection with the fundamental value that guide the effective implementation of Scrum. Here is a quick review of the Five Scrum Values…
Generating Sustainable Business Agility also requires that we adhere to an ethical code of practice. Some ideas from the Wikipedia page on Ethical Code…
A code of practice is adopted by a profession or by a governmental or non-governmental organization to regulate that profession. A code of practice may be styled as a code of professional responsibility, which will discuss difficult issues, difficult decisions that will often need to be made, and provide a clear account of what behavior is considered “ethical” or “correct” or “right” in the circumstances. In a membership context, failure to comply with a code of practice can result in expulsion from the professional organization. In its 2007 International Good Practice Guidance, Defining and Developing an Effective Code of Conduct for Organizations, the International Federation of Accountants [1] provided the following working definition: “Principles, values, standards, or rules of behavior that guide the decisions, procedures and systems of an organization in a way that (a) contributes to the welfare of its key stakeholders, and (b) respects the rights of all constituents affected by its operations.”
Ethical codes are often adopted by management, not to promote a particular moral theory, but rather because they are seen as pragmatic necessities for running an organization in a complex society in which moral concepts play an important part.
EVIDENCE #4, #5: Collecting objective, verifiable evidence might start getting tricky at this point. One possibility is to include Scrum Values and Ethics as part of every retrospective and poll the team for their thoughts on how effective we are at living the Scrum Values and adhering to an ethical code of practice. Whether the team agrees or disagrees, a skilled facilitator could surface examples that create a constructive conversation and raise the visibility and use of values and ethics on a day to day basis.
Having a confidential ethics hotline where people feel safe reporting violations can also be used as a way of collecting evidence to prove or disprove adherence to an ethical code of practice.
EVIDENCE BASED MANAGEMENT TECHNIQUE #4, #5: Low scores in retrospective discussions or surveys related to the topic of values and ethics could trigger an investment in a Coach who can provide training and coaching to cause improvements in this area. An improvement in behavior and scores in similar surveys / retrospectives after the training and coaching might indicate creation of ROI from the investment.
Another possibility is to have the Scrum Masters in the organization take the Professional Scrum Master Level 2 Assessment. This is a very demanding assessment that challenges Scrum Masters to dig deep into their thoughts about how to handle difficult situations.
Low scores on this assessment may suggest that Coaching for Scrum Masters from a Professional Scrum Trainer might help them acquire the skills needed to help the organization manage this risk. High scores after the coaching could be an indication of ROI and suggest a greater probability that Scrum Masters will help teams create a culture grounded in ethics and Scrum values.
OK, so let’s assume that now we have a technical organization that is practicing ethical, value driven Agile Software Delivery with Scrum. We may still be exposed to two inter-related risks…
RISK #6: TEAMS ARE NOT AWARE OF WHAT THE CUSTOMER WANTS
EVIDENCE #6: The evidence that might indicate that teams are delivering software that the customer does not want, are drops in revenue, reduction in product installation and usage and an increase in customer escalations.
RISK #7: TEAMS ARE NOT AWARE OF THE FORCES DRIVING THE MARKET
EVIDENCE #7: Evidence that might indicate impact of this risk could be that the team delivers technically excellent software that customers said they wanted, but it still does not translate into business success – financial measures are not healthy. This might be because customer needs have changed, competitors have come up with alternatives, or the entire industry has shifted due to tipping points or external forces.
EVIDENCE BASED MANAGEMENT TECHNIQUES #6, #7: This might be an opportunity to have the Product Owners take the Professional Scrum Product Owner Level 2 Assessment. This is a very rigorous assessment that will challenge Product Owners to dig deep into their knowledge and thinking to figure out how they might handle difficult situations.
Low scores may indicate that it would be appropriate to get your Product Owners some training and coaching from a Professional Scrum Trainer to help them raise their level of customer and market awareness. High scores after the coaching and training could indicate an ROI from the investment. They could also be a leading indicator that decisions Product Owners make to will be better aligned with customer needs and market conditions.
RISK #8: TEAMS ARE UNABLE TO RESPOND TO THE CUSTOMER AND MARKET
This risk manifests when Product Owners provide clear direction on what to deliver in alignment with customer and market needs, but the I.T. organization is unable to execute on the direction. Maybe Scrum teams have optimized at a team level, but there is sub-optimization at an organizational level.
EVIDENCE #8: Indicators of this risk might be high defect counts, high cycle time, high release stabilization cycles, low release frequency and a high amount of time and money spent on fixing defects as opposed to developing new features.
EVIDENCE BASED MANAGEMENT TECHNIQUE #8: Managing this risk might involve getting the team some coaching from a Professional Scrum Trainer on Engineering Practices and Technical Excellence so that some of the indicators mentioned above show favorable improvement.
RISK #9: THE ORGANIZATION DOES NOT CREATE ACTIONABLE WISDOM FOR SUSTAINABLE COMPETETIVE ADVANTAGE
Ultimately, Sustained Business Agility manifests in an organization’s ability to bring it all together on a consistent basis to knock the socks off the competition. If this outcome is not being generated, the organization must look at evidence to isolate the activities that are blocking the desired outcome.
EVIDENCE #9: Some indicators that might help us manage this risk are metrics like customer satisfaction, employee satisfaction and revenue per employee.
EVIDENCE BASED MANAGEMENT TECHNIQUE #9: One possible approach to optimizing the value delivered by the entire organization is to use a balanced score-card that helps avoid optimizing one indicator of value at the expense of another one. This is the foundation of the Evidence Based Management frame-work.
This frame-work has measures a balanced score-card comprising of 11 indicators of business agility and measures them periodically to observe trends of progress / regress across the organization…
These 11 metrics can be grouped into three categories and rolled-up to summarize an organization’s ability to deliver business value as follows…
The foundation of the approach is a three step approach to measure, diagnose and improve an organization’s capabilities, helping create sustainable Business Agility…
Using this approach, you can partner with a Professional Scrum Trainer and Engagement Managers to use evidence for co-relating the investment in Agility with the ROI in terms of Business Agility…
So let’s recap the nine risks that might de-rail or slow down your organizations journey on the path of Business Agility…
RISK #1: TEAMS LACK A SHARED AND ACCURATE UNDERSTANDING OF “WHAT” IS AGILE SOFTWARE DELIVERY WITH SCRUM
RISK #2: TEAMS LACK A SHARED AND ACCURATE UNDERSTANDING OF THE “WHY” OF AGILE SOFTWARE DELIVERY WITH SCRUM
RISK #3: TEAMS LACK KNOWLEDGE AND SKILLS RELATED TO THE “HOW” OF PRACTICING AGILE SOFTWARE DELIVERY WITH SCRUM
RISK #4: TEAMS ARE PRACTICING AGILE SOFTWARE DELIVERY WITH SCRUM WITHOUT CONSISTENT APPLICATION OF THE SCRUM VALUES
RISK #5: TEAMS ARE PRACTICING AGILE SOFTWARE DELIVERY WITHOUT CONSISTENT ADHERENCE TO AN ETHICAL CODE OF PRACTICES
RISK #6: TEAMS ARE NOT AWARE OF WHAT THE CUSTOMER WANTS
RISK #7: TEAMS ARE NOT AWARE OF THE FORCES DRIVING THE MARKET
RISK #8: TEAMS ARE UNABLE TO RESPOND TO THE CUSTOMER AND MARKET
RISK #9: THE ORGANIZATION DOES NOT CREATE ACTIONABLE WISDOM FOR SUSTAINABLE COMPETETIVE ADVANTAGE
Chances are that most of us would like our risk management profile to look something like this…
In all likelihood, we might be at varying levels of effectiveness at managing these risks. Maybe something like this…
The good news is that once we start surfacing these risks and start using some reasonable evidence based indicators to reflect how well we are managing them, we have power in our hands to alter the outcome.
An organization’s journey along a continuum of Business Agility that could be visualized like the triangle below. One of the important over-arching goals that inspires and guides me as I help organizations on the path of sustained Business Agility is the mission of “Improving the Profession of Software Development” – #ITPOSD, which is why I have placed it at the top of the continuum.
This article is an invitation to start a conversation with you and your teams on what you think about these risks and what evidence based techniques you might use to manage them. Let me know what do you think.
