}

Do You Speak Agile?

2/20/2018

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

Agile has apparently '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. In fact, one estimate is that currently between 12 and 15 million people 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 small minority thought they were reaping the full benefits of agility.

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

I have no issue with the idea that many organizations who 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 much 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 so far, or are struggling to generalize benefits they have seen across the organization. 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. Nothing outside of development in the organization is affected, according to this view.

The reality is that Agile transformations are, by their very nature, disruptive at some level. There is a mindset and cultural shift involved that often challenges 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. Agile methods, on the other hand, 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 a hindrance to the rapid delivery of business value that it promises. Governance methods based on a team's responsiveness rather than process predictability is needed.

Financial planning can be another issue. Many companies spend a great deal of effort planning budgets on an annual basis. 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 are we going to 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 is planning on a yearly basis, its Agile teams are planning Sprints perhaps every two weeks or so. The mismatch between the two can surface painful tensions until these matters are resolved.

Team Building
There are many aspects to achieving sustainability in Agile approaches but, to my mind, the bedrock is its team model. "Team" is a much-abused term in the industry in general. I think every manager I have ever met has referred to his or her "team" when, very often, they are talking about different individuals who report to them. A group of individuals is just that. Their aggregate performance comes from adding up their individual contributions. A team, on the other hand, owns a common goal and its members collaborate intensively to achieve it. Their performance is greater than the sum of their individual 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 are able to respond quickly and take advantage for the benefit of their customers. There are no hand-off delays 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. And 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 levels of disruption are tolerable? These are business decisions. They involve cost/benefit trade-offs 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.

Agility Fluency v 'Maturity" Models
My point is that Agile is not an end in itself, 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. The 'full benefit' of Agile is not some absolute standard that everyone should aspire to, but something that is completely qualified by the business goals that are being set for Agile teams.

The question '" How Agile are we?'" is the wrong question. It raised the spectre of 'maturity' models that are ghosts that should have been banished a long time ago. Instead of Agile 'maturity', we should be thinking in terms of 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 goals of the organization.

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. If, however, you needed to gain college credits you might learn from grammar books. Should you wish to move to France permanently, you would probably immerse yourself in conversational French so that you could socialize with your neighbours. 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. You would start practising real conversations from the get-go. The same applies to Agile development. The organization needs to determine its goals, and then invest, from day one, 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. There are four fluency 'zones' in the model: Focus on Value; Deliver Value; Optimize Value; Optimize Systems. At the risk of mixing metaphors, we can think of choosing a zone like we are buying a ticket on a city bus. Depending on where you want to get to, you buy a more or less expensive ticket to the zone that includes your end destination. Different types of Agile Fluency imply different levels of investment (training, coaching, tools, etc.) and different benefits. The model gives you guidance in making these cost/benefit tradeoffs in your Agile investment plan.

Agile Fluency Diagnostics
The model is supported by the Agile Fluency Diagnostic tools. 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. The facilitator runs workshops with each of the Agile teams, 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 that management can do to help them. These guided self-assessments can be repeated on a 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 say, 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 an 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 with them. They create momentum through initial success, "engage, challenge, educate and support the middle and senior managers"(2) and seek out senior champions at executive level if needed. Depending on the level of fluency needed, this group might be a single Agile development team, or it might be a "core team" of Agile coaches driving a wider organizational transformation. They normally need external support for a while, because the challenge can otherwise be too overwhelming. The more disruptive the effort, the longer is the partnership that is needed. 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 strongly 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 very useful 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." https://blo.learningtree.com/
(2) As Dan North puts it in his blog, "In Praise of SWARMing" https://dannorth.net/2018/01/26/in-praise-of-swarming/amp/

Related Training:

Advanced Certified Scrum Master (A-CSM) Training

Alan O'Callaghan

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!

Chat With Us