Do You Speak Agile?

3/23/2023

Assessing the Fluency Your Agile Team(s) Need to Acquire

Agile fundamentally has 'crossed the chasm.' Its early adopters have achieved sufficient momentum to ensure its entry into the mainstream of software and IT development if not product development in general. One estimate is that between 12 and 15 million people currently use Scrum daily. And yet a keynote speaker at the recent Global Scrum Gathering in Dublin claimed that Agile is failing, providing as supporting evidence a straw poll of attendees that showed only a tiny minority thought they were reaping the full benefits of agility.

Improve your operations and optimize customer value with Agile & Scrum

I have no issue with the idea that many organizations that have adopted agile are disappointed with the results so far. But the statement that Agile has failed begs two questions. First, who put a time limit on Agile's pathway? Secondly, and more importantly, what is meant by 'the full benefits'?

The Challenge of Complexity

Let's start with the indisputable fact that many organizations are either disappointed with the results they have achieved or are struggling to generalize the benefits they have seen. There is a widely held view that Agile methods are merely about executing the development of products and services more quickly than before. "Faster.Better.Cheaper" is the mantra. According to this view, nothing outside the organization's development is affected.

The reality is that Agile transformations are, by their very nature, disruptive at some level. A mindset and cultural shift often challenge the foundations on which the organization has been built. Project governance, for example, in traditional environments, assumes predictability and is usually focused on conformance to an up-front plan and the efficient utilization of resources in executing it. On the other hand, Agile methods are optimized for use in situations where levels of uncertainty and risk render master planning useless. Exploration and experimentation with frequent and rapid feedback cycles allow the best solutions to be discovered through intensive collaboration with all stakeholders. Effectiveness, not "efficiency," is the watchword.

Where this is not understood, the outdated traditional governance protocols quickly become obstacles to Agile adoption and the rapid delivery of business value that it promises. Instead, governance methods are needed based on a team's responsiveness rather than process predictability.

Financial planning can be another issue. Many companies spend a great deal of effort planning budgets annually. The Project Management Office (PMO), or its equivalent, is given a big slice of the corporate budget for IT and software development that it, in turn, has to be allocated to individual projects. Business cases are created by answering the questions "What are we going to get?", "When will we get it?" and "How much will it cost?" Answers to these questions at the beginning of the planning cycle are, at best, speculative guesses. Nobody knows. While the organization plans every year, its Agile teams are planning Sprints every two weeks or so. The mismatch between the two can surface painful tensions until these matters are resolved. Within the Agile framework, CSPO Training prepares an individual to navigate budget, priorities, and backlog.

table with hands and devices with the word agile on the table

Team Building

There are many aspects to achieving sustainability in Agile approaches, but the bedrock is its team model. "Team" is a much-abused term in the industry in general. Every manager I have ever met has referred to their "team" when they often talk about different individuals who report to them. A group of individuals is just that. Their aggregate performance comes from adding up their contributions. On the other hand, a team owns a common goal, and its members collaborate intensively to achieve it. As a result, their performance is greater than the sum of their parts.

Agile teams are self-organizing. They are autonomous. No one tells them how to achieve their goals. It's up to them to figure it out. As new information surfaces during development, they can respond quickly and take advantage for the benefit of their customers. No hand-off delays are waiting for management's permission to act. At the same time, Agile teams take responsibility for their decisions and are collectively accountable for them. It takes time, effort and investment to build teams like these. The process of growing the teams so that they improve continuously never ends.

But how much investment should an organization make in its Agile teams? What are levels of disruption tolerable? These are business decisions. They involve cost/benefit tradeoffs based on business goals. And not all organizations have made the decision to "go Agile" based on clear business goals. These are the organizations that tend to struggle. Addressing this challenge is the role of a talented PMI Agile Certified Practitioner.

Agility Fluency v 'Maturity" Models

My point is that Agile is not an end, but a means to an end: the more effective delivery of business outcomes. And these goals are highly situational. They vary from organization to organization and even between different departments in the same organization. So the 'full benefit' of Agile is not some absolute standard everyone should aspire to, but something entirely qualified by the business goals for Agile teams.

The question '" How Agile are we?'" is the wrong question. It raised the specter of 'maturity' models that are ghosts that should have been banished a long time ago. Instead of Agile 'maturity,' we should think about Agile fluency. Fluency is what your teams do when under pressure - the 'muscle memory' with which they react instinctively, without too much thinking. That kind of fluency requires deliberate, routine practice over time. And the kind of fluency your teams should aspire to is determined by the organization's goals.

An analogy might help here. Imagine you want to learn French. Depending on your goal, you would approach learning the language in a particular way. Rehearsing questions found in a phrase book would be enough to ask for directions during a visit to Paris for a weekend. You might learn from grammar books if you need to gain college credits. Should you wish to move to France permanently, you would probably immerse yourself in conversational French to socialize with your neighbors. In other words, you would choose your learning practices depending on your goal. No one would recommend using a holiday phrase book as your first step to deep fluency in a language. Instead, you would start practicing honest conversations from the get-go. The same applies to Agile development. From day one, the organization needs to determine its goals and then invest in the practices the teams need to achieve them.

James Shore and Diana Larsen's Agile Fluency Model is a simple but powerful tool that helps organizations identify what kind of fluency their Agile teams need. I like it because it is both team-based and business-goal driven. The model has four fluency 'zones': Focus on Value; Deliver Value; Optimize Value; Optimize Systems. At the risk of mixing metaphors, we can choose a zone like buying a ticket on a city bus. Then, depending on where you want to get to, you buy a more or less expensive ticket to the zone that includes your end destination. Likewise, different types of Agile fluency imply different levels of investment (training, coaching, tools, etc.) and different benefits. The model guides you in making these cost/benefit tradeoffs in your Agile investment plan.

Agile Fluency Diagnostics

The Agile Fluency Diagnostic tools support the model. First, a trained facilitator works with management to understand its goals and what achieving them would look like. These are then mapped to the appropriate fluency zone. Next, the facilitator runs workshops with each Agile team, collates the results and feeds back the curated and anonymized results to management, making recommendations for an investment plan. The idea is to provide a mirror for the teams to reflect on their progress and identify the top two or three things management can do to help them. These guided self-assessments can be repeated quarterly or six-monthly basis as part of an overall continuous improvement effort.

Depending on the target zone, it may be enough to get the teams to understand and apply the rules specific to Scrum or Kanban (Focus on Value). If delivering products or services at the maximum rate the market can absorb is needed, then a significant investment in engineering skills will be needed: test automation, continuous integration and continuous delivery (Deliver Value). Significant changes in organizational structure are likely to be needed if the teams require the ability to make excellent decisions about, for example, which products to develop (Optimize Value). Strategic business knowledge has to be embedded in the teams. A mere handful of teams have achieved Optimize for Systems fluency, and most of those have been start-ups. The reason is that achieving that kind of fluency would otherwise involve turning organizational culture on its head. The inertia and historical baggage that large organizations have to deal with might involve as much as a 10-year journey.

Most successful transformations have been driven by a small group of determined Agilists who take the time and effort to bring people along. They create momentum through initial success, "engage, challenge, educate and support the middle and senior managers," and seek out senior champions at the executive level if needed. Depending on the level of fluency needed, this group might be a single Agile development team or a "core team" of Agile coaches driving a more comprehensive organizational transformation. They usually need external support for a while because the challenge can otherwise be too overwhelming. The more disruptive the effort, the more extended the partnership that is needed. Existing ScrumMaster's can get the training to advance to a Certified Scrum Professional to master their skills as an Agile coach. Each of the fluency zones requires both knowledge and practice to achieve it.

Classroom-based learning is necessary but insufficient. Training, coaching, mentoring and consultancy may be required at different points, but the aim should be to build a permanent, sustainable internal Agile capability to the appropriate level. Learning Tree, with its unparalleled Agile curriculum, its cohort of highly experienced instructors and consultants, and its record of working with organizations to assess their specific learning needs, is firmly positioned to become your organization's trusted partner in this journey.

Conclusion

To sum up. Agile development is a means for the effective delivery of business value. Its progress can only be measured against the business goals it is being employed to achieve. For organizations feeling disappointed about what Agile has delivered for them this far, the way forward is to invest in the growth of their Agile teams. The Agile FluencyTM Model is just one tool, but a beneficial one, that can be used to identify what kind of investment is needed, what kinds of benefit to expect as a result, and what kinds of external support might be required.

Governance in Agile adoptions is discussed more fully in my blog post "Don't Let Governance Threaten Your Agile Transformation."

Lean into a more responsive development process with Agile & Scrum Training and Certification. Available In-Person, Online, or as Private Team Training!

This piece was originally posted on Feb 20, 2018, and has been refreshed with updated styling.

Written by Alan O'Callaghan

As mentioned in a previous post on the value of Scrum certifications, I became a Certified Scrum Product Owner (CSPO) in May 2011, some thirteen years after I first engaged with Scrum. The reasons as to the delay in gaining certification were outlined in the previous article. But why CSPO certification? Why not Certified ScrumMaster (CSM)? CSM is, by far, the most popular entry certification available from the Scrum Alliance. This might be because, if you have only a nodding acquaintance with Scrum then it’s the one new role that you will almost certainly have come across. The Product Owner role is also the newest one in Scrum. The ScrumMaster and Development Team member roles have always been there. To be honest, if I had applied for certification in the early years of the Scrum Alliance then I, too, would probably have opted for CSM. ScrumMaster was the role I played first when using Scrum, and is still the one I’ve played most in Scrum Teams I’ve been involved with. I have since added CSM to my CSPO and Certified Scrum Professional qualifications, by the way – so it is not because I have underrated the ScrumMaster role in any way. So why was CSPO certification my first choice? My main reason for becoming a CSPO was that I had realized in the interim, when Agile entered the mainstream, that for Scrum to be sustainable over time the Product Owner role is probably the most important one to get right. Is the CSPO the “One Wringable Neck”? As far back as 2007 in his book The Enterprise and Scrum, Ken Schwaber had written about the Product Owner having the “one wringable neck” in the Scrum Team. I don’t think for one moment that he was suggesting that the Scrum Team as a whole was not collectively responsible for the success of their product. A team wins together and loses together, as any team sports coach worth his or her salt will tell you. Schwaber was, however, trying to draw attention to the special responsibilities of the Product Owner within the Scrum team. Let’s list them briefly. Product Owner Responsibilities • is responsible for the Return on Investment (ROI) and the Total Cost of Ownership (TCO) of the product • has the job of ensuring the value of the delivered product is at maximum • must optimize the value of the work performed by the Development Team • manages the Product Backlog, and orders the items within it to-to-bottom • must make the contents of the Product Backlog available, and in a way that they can easily understand • makes decisions about when to release increments of the product to the customers • is the only person who cancel a Sprint Strategic Significance of the CSPO Taken together, these responsibilities add up to some very serious strategic implications. The Scrum Guide puts it this way “For the Product Owner to succeed, the entire organization must respect his or her decisions….No one is allowed to tell the Development Team to work from a different set of requirements (other than those represented in the Product Backlog – AOC), and the Development Team isn’t allowed to act on what anyone else says”. Think about it. The Product Owner is the person who tells the Development Team what to do. It is through her management of the Product Backlog that she does this, in the main. The Product Owner spends a lot of time and effort working with the customers and other stakeholders to understand the relative value of the different requirements represented in the Product Backlog, and orders them accordingly. Of course, business value is not the only driver. Technical dependencies between different items – or stories if that is how the Product Backlog Items are represented – must be taken into account, too. Another factor to be considered is what the system will look like at the Sprint Review. A good Product Owner will always try to have the Team present a small and skinny version of the evolving system at the demo, and this might cause some lower value items to be promoted higher in the list than they might otherwise be. Other roles, including ones outside the Scrum Team such as managers and customers, will of course have input, but the decisions about ranking the Product Backlog Items are in the end those of the Product Owner and the Product Owner alone. The importance of is that at the Sprint Planning meeting, the Product Owner will agree with the Development Team on a Sprint Goal – the target value to be achieved by the end of the iteration – and the Development Team will “snap off” from the top of the Backlog the number of items it forecasts it can develop in the timebox that will meet that goal. A Combination of Traditional Roles So clearly the Product Owner is a role that not only has something of the traditional Product Manager about it, but also a bit of Project Manager stuff, too. She or he cannot tell the Development Team how to do their work, nor can the Product Owner dictate how much work the developers should do (only the Development Team itself can do this in Scrum), but every time she reorders the Product Backlog she is telling them what needs to be done, because it is the top-ordered items that will be worked on next. And non-one else, no-one but no-one, can tell the Development Team to do anything differently. Now add to this the fact that the Product Owner is acting as a proxy for the customer during the Sprint, making herself available to the rest of the Team as needed, and you can see that the role sits right at the centre of the communication pathways and collaborative actions that have to happen for the product to succeed. Maybe to say the Product Owner is the one wringable neck isn’t quite right. A better way of putting it might be that if any team or organization fails to grasp the importance of this role, if they don’t get it right, or if they make the wrong personalities Product Owners, then everyone’s neck is on the chopping block! CSPO Certification Revisited If certification is justified at all – and I believe it is – then certification of Product Owners is critical, not just for individuals who want to embellish their CVs, but more importantly, but for their employers whose organization’s future is, perhaps, being put on the line by their adopting Agile. One issue is that, like the CSM qualification, CSPO can only be gained by attending a certification course delivered by a Scrum Alliance Certified Scrum Trainer (CST). Except that the CST must themselves hold a CSPO certification – and only a minority of this relatively elite group are also CSPOs. It is hard to find appropriate courses. Fortunately, Learning Tree has teamed up with CSTs to provide exactly that service. Course 1814 Certified Scrum Product Owner is taking enrolments now. If you are a practising Product Owner who is not yet certified you should register for this 2-day course as soon as possible to get certified. If you are a Scrum Team member in another role, or are outside Scrum Teams but are impacted by their work in any way, then alert your Management to this opportunity to get your organisation’s Product Owners qualified. And don’t forget there are now nearly thirty Agile courses in the Learning Tree catalog to support the skills development of all your Agile professionals. This includes courses that provide CSM Certification, SAFe Agilist Certification, APMG’s Agile PM Practitioner Certification and prep you for PMI’s Agile Certified Practitioner (PMI-ACP) exam. We look forward to seeing you on course with us soon!