Blog Post

Are We Nearly There Yet?

A O'CALLAGHAN • Nov 13, 2017

How can you assess the progress of your Agility in your organization?

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.

I have no issue with the idea that many organizations who have adopted agile are disappointed with the results so far. We’ll come back to that a little later. 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’?

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’ 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 really 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. And the kind of fluency your teams should aspire to is determined by the goals of the organization.

An analogy might help here. I’m learning French. I need to be fluent enough to be able to converse and socialize with my neighbours in Nouvelle Aquitaine where I have a home. That is a completely different type of fluency from what someone would need for a weekend trip to Paris. Yet another kind of fluency would be needed for someone wanting to, say, teach a technical training course to French-speaking students.

James Shore and Diana Larsen’s Agile FluencyTM Model is a simple but powerful tool that helps organizations identify what kind of fluency their Agile teams need. There are four fluency ‘zones’ in the model: Focus on Value ; Deliver Value ; Optimize Value ; and 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 FluencyTM Diagnostics

The model is supported by the Agile FluencyTM 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.

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, and what kinds of benefit to expect as a result.



By A O'CALLAGHAN 26 Feb, 2024
A Case Study of the Use of AI in Learning for Agile
By A O'CALLAGHAN 24 May, 2022
The body content of your post goes here. To edit this text, click on it and delete this default text and start typing your own or paste your own from a different source.
By Maria O'Callaghan 13 May, 2022
An Interview with Alan O'Callaghan
By A O'CALLAGHAN 20 Apr, 2022
How Can Your Organization Quickly Scale Agile Learning and Development?
By A O'CALLAGHAN 20 Apr, 2022
With the huge rise in interest in Business Agility since the start of the pandemic, does this mean the puzzle of Agile product development has been solved? In my coaching and training for Agile product development I have always emphasized the importance of the team model. When I’m consulting with organizations wanting to increase their levels of Business Agility I find myself constantly arguing that the most important thing is to continue to invest in team development. “Surely, that’s a given?” you might think. Well, part of the problem is that ‘team’ is a term that is routinely abused in industry. Almost every manager I’ve ever spoken to has spoken about “my team”. What they are referring to is the collection of people who report to them. Often these people don’t know each other. Their only connection is they have the same manager. But how can people who don’t even know each other, and never meet, possibly constitute a team? The ‘No Hopers’ Team sports provide rich insights into what makes a team. Let me take you over a quarter of a century in time to tell you a story of one of the most important lessons I learned. The father of one of my young teenage son’s friends decided to set up a football team. His son, like mine, loved the game but because of their fitness, size, skill-level or other reason they never got to play in eleven-a-side games. Their schools only focussed on the best players and the most physically developed -one of the challenges for under-13s is the different physical sizes of boys of the same age. This team was formed to give these kids that opportunity. It acted like a magnet for all the ‘no-hopers’ in the area, and the team got affiliated to the local amateur club. Unfortunately, the guy who set the team up got cancer and died part way through the first season and I had to take over to keep things going. It was a tough task. All the boys dreamed of scoring the winning goal in an FA Cup final at Wembley and so all wanted to be strikers. But a team needs a goalkeeper, defenders and midfielders as well as attackers. Convincing them individually and collectively to put the team first took a lot of training, coaching and soft persuasion. The match results were not good. At the beginning the boys got hammered in every game, often conceding a double-digit number of goals and, more than halfway through the season, had not scored a single one. County Cup Humiliation- Or Was It? And then we got drawn in the County Cup against a team that was four divisions higher than our team, were the cup holders and league leaders. You’ve seen Hollywood films like this, haven’t you? No-hopers come up against the champions. They’re down at half-time but the coach gives them an inspirational talk and they go out and – against all odds- they win the game. OK, that didn’t quite happen. In fact, with just a minute to go the boys were losing 40-0. That’s not a typo. FORTY nil. Now, under-13 games are only 35 minutes each way. They had conceded a goal in less than every 2 minutes on average. On the touchline I just wanted the final whistle to blow so that the boys’ humiliation would end. I was desperately trying to think of ways to pick them up afterwards so that they wouldn’t lose their love of football. The Importance of Common Purpose And then something astonishing happened. With the last kick of the game, the boys scored. They went crazy. You would have thought they had just won the cup, not lost 40-1. And then the opponents’ coach did something remarkable. He lined his team up and got them to shake the hands of every one of the lads they had so comprehensively thumped. And then I heard him say. “Remember that. You won the game. But they were the better team. You got arrogant and started playing as individuals after about five minutes. They were a team right to the end. You need to learn from them.” I was dumbstruck. It took me a while to realize that my feelings towards the end of the game were driven by targets (concerning the results of games) I had imposed on the boys. But as the cup game approached – one they knew they couldn’t possibly win – they set themselves a different target. To score a goal. And working as a team that’s what they achieved. Katzenbach and Smith (1) define what they call a ‘real team’ as “a small number of people with complementary skills committed to a common purpose, performance goals and approach for which they hold themselves mutually accountable”. The common purpose the boys committed to wasn’t the one I set for them. It was one they set themselves, but their wild celebrations at the end of the game showed their commitment. Looking back now there a few patterns that they demonstrated. Small successes (from Fearless Change(2) and Evolving Vision (from More Fearless Change (3)). They also showed the power of One Step at a Time (in A Scrum Book (4)) because in the games that followed they still lost most of them but never again by a double-digit score, they did score more goals and, by the end of the season, had even won two matches. The minimum requirement for any kind of team, beit a sports team or an Agile team, is that they have a common goal that they have taken ownership of. It becomes the focus of their ongoing collaboration on a journey of improvement that is never-ending. A real team shares its successes and its failures, and becomes stronger in doing so. In retrospect I got taught a powerful life lesson by a bunch of pre-pubescent kids, and I’ve taken it into everything I do professionally. And guess what? The teams I work with today in product development keep teaching me new ones. Whatever else is happening in your organization’s onward journey to Business Agility, do not underestimate the importance of teams. This post is based on a story I told originally at the Fearless Change Campfire, a remote event organized by Mary Lynn Manns and Linda Rising on October 6 th -7th 2021. The campfire will be lit again in 2022. I recommend it! AOC References (1) Jon R. Katzenbach and Douglas K. Smith. 1993. The Wisdom of Teams: Creating the High Performance Organization. Harvard Business School Press (2) Mary Lynn Manns and Linda Rising. 2005. Fearless Change: Patterns for Introducing New Ideas Addison Wesley (3) Mary Lynn Manns and Linda Rising. 2015. More Fearless Change: Strategies for Making Your Ideas Happen. Addison Wesley (4) Jeff Sutherland, James O. Coplien and the Scrum Patterns Group. 2019. A Scrum Book: The Spirit of the Game. Pragmatic Programmers
By A O'CALLAGHAN 06 Jun, 2017
The eleventh State of Agile survey has just been published by VersionOne. These reports are invaluable in helping agile practitioners understand where their practices, problems and challenges fit the context of the wider world. As with all VersionOne’s previous reports, the eleventh survey paints a picture of the onward march of agile. Its progress is rarely in a straight line, however, and this latest survey has revealed a very interesting contradiction. Increased Focus on Business Value? When respondents were asked how the success of agile initiatives were measured, the second ranked answer after “on-time delivery” was “business value.” In the previous report, “business value” was the fourth-ranked answer. This time, some 46 percent of respondents chose it ahead of “customer/user satisfaction” (44 percent), “product quality” (42percent) and “product scope” (40 percent). No other answer was given by more than a quarter of respondents. Read more at https://www.frontrowagile.com/blog/posts/110-measuring-the-progress-of-agile
By A O'CALLAGHAN 25 Apr, 2017
The definition of done (DoD) is one of the most important and least-understood elements of the Scrum Framework. It is specifically called out in “ The Scrum Guide ” in what is probably its biggest section, and yet, I’ve seen so-called ‘definitions’ of Scrum that fail to mention it at all. In this post, we’ll be talking about why, exactly, the DoD is so important. DoD Explained So, what is the definition of done? Fundamentally, it is the Scrum team’s agreement about the standard of quality that it will apply across the product. This concept is closely related to that of the Potentially Shippable Increment that must be created at the end of each and every sprint. The two words in that phrase that the DoD concerns are “potentially” and “increment." While all agile approaches – Scrum included – aspire to “deliver early and deliver often,” this does not mean that a product must be handed over to the customer at the end of every sprint. Whether enough useful value has been accumulated to warrant a product’s release is a business decision, and one that is the product owner’s responsibility to make. Read more at https://www.frontrowagile.com/blog/posts/106-are-we-done-yet
By A O'CALLAGHAN 24 Mar, 2017
Governance seems to be one of those frightening words that threatens to stop an Agile transformation effort dead in its tracks. I’ve been hearing it whispered, and even screamed once or twice, quite a lot recently. There’s no big surprise here. As the big corporations and Government agencies get increasingly fascinated by frameworks like Scrum, they are mandating their IT departments to “Go agile” and then, sooner or later…governance! Types of Governance There is operational governance represented in the defined processes that organizations and teams are expected to follow when software is in production. There is project management governance, perhaps dictated by PRINCE2 or similar, while the product is in development. PRINCE, by the way, is an acronym standing for ‘PRojects In a Controlled Environment’. Project management governance is often a subset of a wider IT governance. According to the TOGAF version 9.1 , IT governance supposedly provides the framework and structure that links IT resources and information to enterprise goals and strategies. “IT governance institutionalizes best practices for planning, acquiring, implementing and monitoring IT performance…” Standards like COBIT, which stands for Control OBjectives for Information and related Technology, might be in place. And then, of course, there is a range of issues to do with compliance to the requirements of external regulators in all public bodies, as well as commercial institutions in sectors such as insurance and banking. So, is this a case of an irresistible force (Agile) meeting an unmovable object (governance)? Published on 23/3/17 on Learning Tree page. Read more at http://blog.learningtree.com/uk/governance-threaten-agile-transformation/
By A O'CALLAGHAN 20 Mar, 2017
“We need to get better at estimating,” an experienced member of a Scrum development team once told me. “Management is getting concerned that we keep coming up short on our commitment.” “Really?” I responded. “What have you been committing to?” “Thirty story points” she said. “We get there about 50% of the time. In a couple of recent sprints, we’ve even exceeded thirty points, but the last sprint marked the third time this quarter that we fell short of our target.” “Why was your forecast off target, do you think?” I asked. “Well, things come out of left field occasionally. You know, stuff that couldn’t be anticipated in sprint planning,” she answered. “So, why are you estimating effort if you can’t predict what will happen in the sprint?” I said. Now, at this point I want to make clear that I am not one of those who say that development teams should not estimate effort. For me, the ability to estimate independently is an important part of the autonomy of teams. What I was trying to do in this particular conversation was to get the team member to consider why teams estimate in the first place, and what “commitment” means in that context. It is not just a matter of those doing the work being the only ones who are able to estimate effort, which I believe to be true. I recently participated in a large multi-team project of effort being estimated by a centralized systems analysis unit. In that project, the development teams were involved in estimating, but it was the systems analysts’ forecast that was being communicated to the customer. The result was massively inflated customer expectations, and retrospection revealed that the teams’ estimates were about four to five times larger—and thus far more accurate--than those of the analysts. Read more at https://www.frontrowagile.com/blog/posts/99-how-to-get-your-teams-to-estimate-better
By A O'CALLAGHAN 01 Mar, 2017
“Ready? Steady! Go!”. That phrase echoes from my youth. I used to twitch waiting for the starter to shout that phrase at the beginning of the 800m races I ran, representing my school. It was also the title of a ground-breaking pop music show which caused me to fall in love with Dusty Springfield, Sandy Shaw and every other female singer who appeared (I was a very impressionable teenager). It resonates today for me in Scrum. When Development teams pull Product Backlog Items (PBIs), or user stories, from the Product Backlog into a Sprint they need to be ready to hit the ground running immediately after the Sprint Planning meeting. For that to happen the PBIs must be in a state that allows them to do that. Read more at http://blog.learningtree.com/uk/what-does-mean-be-ready-scrum/
More Posts
Share by: