Agile Learning and Development at Scale

A Case Study of the Use of AI in Learning for Agile

In 1897 Mark Twain famously complained that reports of his death were exaggerated. A hundred and twenty five years later the reports of the death of Agile similarly abound, and are just as far off the mark. In fact, according to the Business Agility Institute, Business agility – defined by the BAI as “…a set of organizational capabilities, behaviors, and ways of working that affords your business the freedom, flexibility, and resilience to achieve its purpose. No matter what the future brings.” – has increased globally in a very significant way since the start of the pandemic. Other respected authorities, McKinsey, for example, have noted a rush towards Agile ways of working as a consequence of organizations finding flaws and dysfunctions in their existing structures, cultures and processes that hinder their ability to respond to unanticipated change. One wellspring of the rumours of the death of Agile has actually been from well-known Agilists such as Dave Thomas who were actually pointing out that big consultancies have jumped on the Agile bandwagon and corrupted its meaning and intent. Way too many organizations have swallowed the snake oil that suggests Agility is about adopting a few practices in the product development area to become “faster, better, cheaper” while changing nothing else. Agile has always been about responsiveness to change while delivering products that delight customers: “faster, better, cheaper” are second order effects of lowering the cost of change. These are not obituaries, but passionate warnings about the need to defend the values and principles of Agile. A Post-Agile World? A different, but insidious and dangerous perspective comes from those who contrast Business Agility with Agile product development. To the extent that the term “Business Agility” focuses on the need for organizational-wide cultural and structural change, it reflects a welcome shift in an understanding of the challenges businesses face in every sector of the world economy. On the other hand, these are not new problems. The pandemic, supply chain disruption, the ‘Great Resignation’ and even the war in Ukraine have only exacerbated and revealed more clearly the need equip organizations to respond to change and to innovate more quickly. Changing the world of work has always been at the heart of genuine Agile thinking and practice. Yet we are welcomed to the ‘Post-Agile World’ by the authors of one acclaimed book. An Agile Straw Man The book concerned, by Fin Goulding and Haydn Shaughnessy is called Flow . First off, it’s a good book. I recommend it. It is full of interesting ideas to promote cultural change throughout a business. I love their concept of extreme visualization, of work as a learning model, of the need to co-create processes and so on. I see these as valuable additions to our understanding of Agile. But they do not. At one point in the book, they post a table that compares Flow with Lean Startup and with Agile. Agile is summarized in eight bullet points. But their ‘Agile’ is a straw man – easy to knock over because it’s not the real deal. Let’s look at those eight bullet points: “A structure for software programming”. While it is true that Agile took off in software development, it didn’t start there, and it won’t finish there. Most commentators trace Agile thought and practice back to the Shewhart cycle first promoted in 1929. Today, Saab build fighter aircraft, Tesla make autonomous cars, GKS develop pharmaceuticals and the EduScrum movement is transforming education using Agile approaches. “An a priori project-planning method”. I’m not sure where that one came from. One of the four values of the Agile Manifesto is about valuing “responding to change over following a plan.” Agile planning is data-driven. We plan on what we know rather than speculate. But in a complex world we don’t have all the information up front and some of that will change in any case. Scrum, for example has a planning event at the beginning of every iteration precisely because a priori planning doesn’t work. “Risk reduction”. Quite true. But as the authors contrast this with ‘Management of uncertainty’ in their own framework I think they have misrepresented ‘risk reduction’ in Agile as meaning ‘risk avoidance’. In reality, risk is identified and promoted in importance so that it can be dealt with early in Agile development. “Fixed process”. Just a second while I pick myself up from the floor. I’ve spent 25 years explaining to those I have coached or trained in Agile that ‘the process’ is merely the sum total of all the decisions a self-organizing team makes. As such it is adaptive and will be different for each and every team. Predefined processes are a death march in the face of uncertainty and risk. They are anathema to Agile. “Emphasis on avoiding big failures”. Again, I see here an attempt to draw Agile as a conservative risk-aversive approach compared to Flow. Once again, this is a nonsense. Agilists have always advocated “fail fast; embed the learning” as the only way to succeed in a volatile, uncertain, complex, and ambiguous world. ‘Big failures’ are avoided by the emergent behaviour of running safe-to-fail experiments that either validate assumptions or prove them wrong. Agile teams are empowered to take whatever actions the results of such experiments suggest to them. “More supervisory roles”. What are they then? A Scrum Master for example is a servant leader – the very opposite of a supervisory role. A Product Owner has some independent authority but is a peer member of a Scrum team. There is no rank amongst a Scrum team’s developers. As the eleventh Principle Behind the Agile Manifesto says, “The best architectures, requirements, and designs emerge from self-organizing teams” (emphasis added). Self-organization is defined as order which arises through frequent, local interactions rather than being directed externally. You need a peculiar form of mental gymnastics – standing on your head and turning your insides out maybe - to translate that into the idea that Agile requires more supervisory roles “Fulfills the plan”. See the discussion on ‘a priori planning’ above. Finally: “Execution method”. No! To be truly self-organizing, Agile teams have to take ownership of business goals and objectives. The very reason for having a Product Owner in a Scrum team, for example, is so that her business domain knowledge and experience is available to the team as a whole. A Scrum team’s purpose is to deliver business value. That makes it a genuine business unit, not just an execution/implementation unit. How the team achieves its goals and objectives is entirely up to the team itself. Agile Teams vs Business Agility In their blatant mischaracterization of Agile, Goulding and Shaughnessy have taken the caricature of Agile dreamed up by the “faster, better, cheaper” school of thought and put it on steroids. I suppose when you launch any new product you’ll feel the need to differentiate it from ‘competitors’, but in this case the authors of Flow are in danger of undermining the drive towards Business Agility. Many organizations need to heed the words of Nancy Sinatra: ”You keep saming when you oughta be changing”(These Boots Are Made for Walking). The question is what to change? And more specifically, what to change next? Some people like to think of the recent history of Agile as consisting of three waves: first, team Agile (single team product development); second, scaled Agile (multi-team product development) and third, Business Agility. Karim Harbott in his book, The 6 Enablers of Business Agility, describes it that way. That’s fine and good, provided you don’t think that in this so-called third wave the need to invest in Agile teams is somehow in the past. Karim doesn’t think that by the way. In general, it is clear that organizational and cultural change require leadership. But successful transformations cannot be purely top down, and often do not start that way. My friend Jim Coplien often says of empowerment that power is never given, it is always taken. Most Agile transformation drives to date have been bottom-up. Development teams sit in the heart of the value stream of the organization. The products or services they create are what deliver value to the customer. No-one is in a better position to see how existing hierarchies, processes and compliance demands get in the way. No-one is in a better position to understand which impediments and dysfunctions are the most important to remove next. It is not as if, in the so-called ‘first wave’, the vision of empowered self-organizing teams was universally achieved (even in many companies who thought they had adopted Agile). If anything, the influence of frameworks like Safe and DAD in the so-called ‘second wave’ took us all a step backwards. Scrum Masters and Agile coaches will continue to have to fight to increase the space within which self-organizing teams can operate. The measurement of success with Business Agility can only be the value delivered to customers. Business Agility cannot be achieved without continuous investment in self-organizing Agile development teams. Let no-one tell you anything different.

How Can Your Organization Quickly Scale Agile Learning and Development?

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

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.

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

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

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/

“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