The Evolution of The Scrum Guide (Part One)

A O'CALLAGHAN • June 27, 2014

How the unofficial 'Book of Knowledge' has changed

You may not have noticed, but in July 2013 Jeff Sutherland and Ken Schwaber published a new version of The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game . Don’t worry if you were unaware of this, the update was not accompanied by fanfare and so you are not alone. But as The Scrum Guide is referred to by many – myself included – as the ‘book of knowledge’ of Scrum I thought I might devote some effort in tracing the most recent changes as well as its overall evolution.

The current version of The Scrum Guide is the third since its original publication by scrum.org in February 2010 (although the original paper did not formally use the title -it was simply called Scrum – it was generally referred to by the name it acquired in the subsequent versions). The second edition appeared in October 2011, and it is this version that has just been updated. The changes between the first and second version were more obvious and perhaps more profound than those between the current edit and its predecessor but, of course, in its essentials Scrum is unchanged. In all three editions it is stressed that Scrum is a framework of roles, artifacts and events bound together by rules which is used for building and sustaining complex products. There is no such thing as the Scrum process. The framework’s role is “to surface the relative efficacy of your development practices so that you can improve upon them”. Rooted as it is in empirical process control theory, we can interpret it to say that the ‘process’ that Scrum drives out is the sum total of all the decisions that the Scrum Team(s) take to remove impediments and improve their work. The resulting process will, therefore, be different from product to product, from context to context, even for different applications of the framework in the same organization.

The fundamental idea of Scrum as a framework rather than a method or a defined process is what The Scrum Guide distilled in 2010, clearing up confusions and misconceptions which had gathered around it since its first public presentation to the software engineering community in 1995. Since then, changes to The Scrum Guide can be considered to be driven by three forces: first, a desire to strip the framework down to its bare essentials in order to define what any project (irrespective of size or context) must be doing for it to legitimately claim to be using Scrum; second, the incorporation of industry experience of using the framework; and thirdly the desire to remove ambiguities by clarifying the language.

Roles, Events and Artifacts

One of the biggest changes between the first two editions of the guide was in its description of the roles, events and artifacts of Scrum. I am not referring to mere cosmetics here: The “Team” became the “Development Team”, “timeboxes” became “events” and the spelling of “ScrumMaster” changed to “Scrum Master”, for example. Much more importantly, the original spoke of three checkpoints for inspection and adaptation( folding the Sprint Review and Sprint Planning Meeting together as instruments for inspecting “progress towards the Release Goal”), and of four “principal” artifacts that were the Product Backlog, the Sprint Backlog, the Sprint Burndown and the Release Burndown. The Release Planning Meeting was included as an optional timebox – in fact the only optional timebox alongside the mandatory Sprint Planning Meeting, Daily Scrum, Sprint Review and Sprint Retrospective.

These days I talk of Scrum consisting of the 3-4-5 ‘rule’: three roles (Product Owner, Scrum Master and Development Team), four artifacts (Product Backlog, Sprint Backlog, Definition of Done and the end-of-Sprint Increment) and five events (Sprint, Sprint Planning Meeting, Daily Scrum, Sprint Review and Sprint Retrospective) and that’s been consistent with what the Guide has said since October 2011. But you’ll notice that there is no reference in this to either a Release Goal or a Release Planning Meeting and that while the Sprint and Release Burndowns have been dropped, the Definition of Done and the Increment have been elevated to replace them in the list of artifacts. This is also consistent with the later versions of The Scrum Guide in which there is no mention of “Release Planning Meeting”, “Release Goal” or of “Burndown” of any description.

So how should we understand these changes? The most important thing to understand is that Sutherland and Schwaber are by no means deprecating release goals, release planning and Burndown or implying in any way that practitioners of Scrum should not be doing them. I reckon that maybe 9 out of 10 Scrum Teams use Burndown charts, and almost any medium to large size product lifecycle probably needs release planning meetings. The point is they are not universally required. It is entirely possible for a Team to do all the stuff that would otherwise take place in a release planning meeting in the Sprint Planning meetings if, for example, the overall work was of an appropriate size and, equally, a Scrum Team might choose ways to make the progress of a Sprint (or a Release) visible other than by showing it in Burndown charts. Remember, the Release Planning Meeting was described originally as optional, in any case. No, the point is that because you can still be using the Scrum Framework without doing these things they have been removed from the Guide. Everything that remains is mandatory.

Along the same lines we might note that the 2010 paper included fifteen tips, or tactics, that are not part of the Scrum Framework per se but were included as helpful suggestions. One of those, incidentally, referred to Product Backlog items as being “usually stated as User Stories”. This is the only reference to stories anywhere in the history of the Guide but, like all the tips, it has been removed because the use of stories is not mandated although widely used by Scrum teams. I guess the authors’ feeling was that by including the tips they somehow de-emphasized the important idea that for most issues “the users of Scrum are expected to figure out what to do.”

The Definition of Done

If all mention of Release Planning and Release Goals together with Burndown was dropped from the revision in October 2010, then the importance of the Definition of Done and the Increment of functionality were promoted. Don’t get me wrong here, there was considerable discussion of both in the original paper but it was given new prominence by including each of them in the list of artifacts from the second version onwards.

In my own experience, the emphasis that Scrum gives to presenting a slice of functionality which is “potentially releasable” and the stress it places on quality is often missed by organizations who think they are implementing the framework. To be honest, due emphasis has often not been given by people who purport to be training developers in the use of Scrum. Perhaps similar observations lay behind the Guide’s authors’ choice to reframe the material around these two topics.

Even the first paper stated very clearly that all Sprints deliver an increment of the final product that is potentially releasable, and that it was the (Development) Team’s job to turn Product Backlog items into such increments in every Sprint. “More and more Sprints create additional increments” until there is sufficient value accumulated for the product to be released. There is a strong implication in the original, but only made explicit from the 2011 version onwards, that the decision about what and when to release is one made by the Product Owner.

This is, of course, what makes Scrum difficult to apply, especially at first. Not only is a slice of functionality mandated to be delivered at the end of every Sprint, but it is required that the product be “potentially shippable”, i.e., it must meet the quality standards of shippable product even if it is not going to be released yet: it must be ‘done’. The Definition of ‘Done’ is the Scrum Team’s shared understanding of what it means for work to be complete. It is essential to Transparency that such a shared understanding be in place. All of this was stated in the original document and has been maintained by the successive revisions.

There have been changes, however. The first version listed the types of things that would need to have been finished for a completely “done” increment: analysis, design, refactoring, documentation and testing that included unit, system, user and regression tests as well as non-functional requirements testing performance, stability, security, and integration. Internationalization is also included. All of this detail was been removed from the 2011 Guide. Clearly, it is context-specific so that change is perfectly in line with the general line of march of the framework’s evolution. As the 2013 version states “…this [i.e., the Definition of Done – AOC] varies significantly per Scrum Team” and later “Any one product or system should have a definition of “Done” that is standard for any work done on it.”

A more significant change, perhaps, between 2010 and 2011 was the removal of discussion of “Undone work”. In the section on “Done” the original Guide says that some Development Teams will not yet be able to put everything required for implementation and release into their Definition of Done, and must make that clear to the Product Owner. The remaining work would still need to be finished before the increment could actually be released, it pointed out. In other words there would be a level of doneness which would have to be achieved for anything that would be demonstrated at the Sprint Review, and another, higher level of doneness that would be needed to be reached before the product could be used by the customer. At least, that’s how I have always interpreted this section.

The work needed to bridge the gap between the two levels was called, in a Tip on the same page, “Undone work”, and the Tip implied that this should be accumulated in a Product Backlog item (PBI) and its effort estimated in the same way as the regular PBIs. The section on “Done” was immediately followed by another section called “Final Thoughts” which was completely devoted to how a Development Team might handle “undone work”. It recommended creating two explicit categories of work: one for “done” work and the other for “undone work”. The first category included the work governed by standards for the Sprint, the second category listed the work to be done at a later date. The Guide recommended that special Release Sprints be added to any release to complete the “undone work” and pointed out that the number of Sprints would be unpredictable to the degree that the accumulation of “undone work” was not linear.

All of that was removed from the Guide in the October 2011 revision and is absent from the current version, too. Again, the tactics listed were probably considered to be too specific to be truly universal (certainly, there are other ways of hardening releases other than adding Release Sprints at the end of the regular development Sprint cycle). It is definitely still the case that there are many Scrum Teams, perhaps a majority in some industry sectors, which are not in a position to put, at the end of every Sprint, slices of functionality that are genuinely potentially shippable at the disposal of the Product Owner. My own practice in these circumstances broadly follows the approach described in the original Guide, and I’m sure that’s true for a great many Scrum practitioners. The 2011 and 2013 versions of The Scrum Guide point out that, as Scrum Team’s mature, their Definition of Done will be expected to expand to include more stringent criteria for quality. The newest edition has added that if “done” for an increment is part of the standards, guidelines and conventions of the development organization, then all Scrum Teams must follow it as a minimum. If it is not part of an existing development standard the Development Team must define one appropriate for the product, and if there is a multiple team development for a product or a system then all the Scrum Teams working on it must mutually agree the Definition of Done.

E-Learning On Steroids

By A O'CALLAGHAN • February 26, 2024
A Case Study of the Use of AI in Learning for Agile

Mark Twain, Nancy Sinatra and the Agile Straw Man

By A O'CALLAGHAN • May 24, 2022
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.

Agile Learning and Development at Scale

By Maria O'Callaghan • May 13, 2022
An Interview with Alan O'Callaghan

Adaptive Learning

By A O'CALLAGHAN • April 20, 2022
How Can Your Organization Quickly Scale Agile Learning and Development?

What Kids Can Teach Us About Teams

By A O'CALLAGHAN • April 20, 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

Are We Nearly There Yet?

By A O'CALLAGHAN • November 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.

Measuring the Progress of Agile

By A O'CALLAGHAN • June 6, 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

Are We Done Yet?

By A O'CALLAGHAN • April 25, 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

Don’t Let Governance Threaten Your Agile Transformation

By A O'CALLAGHAN • March 24, 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/

How to Get Your Teams to Estimate Better

By A O'CALLAGHAN • March 20, 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
More Posts