cdb619d1

MetaScrum - A Key Pattern for Transition to Enterprise Agility

Fri, 07 Nov 2025 13:58:43 GMT

By Alan O'Callaghan

One of the biggest impediments to an enterprise achieving higher levels of business agility is the underpowered Product Owner. The authority required of the Product Owner for effective product teams is often underestimated. The symptoms of this problem vary widely across organizations. There are unfortunate cases where a Business Analyst is labelled ‘Product Owner’ and given a Product Backlog to organize but has no authority over the product. A superficial resemblance to Scrum might exist in this situation, but nothing more. After all, says “For Product Owners to succeed, the entire organization must respect their decisions” (1). If the ‘Product Owner’ is not allowed to make decisions, then there are none to be respected.

A more generally seen indicator is when internal stakeholders of the product – managers of different departments in the organization – constantly try to interfere with the Product Backlog or at least badger the Product Owner to make changes. In the worst case scenarios, the Product Owners spend their entire day, day after day, swatting away internal stakeholders like they are flies. Managers have the right to raise concerns, of course, especially when market conditions change or when they are worried about how the organization is operating, but there is a danger they drain both the energy and time of the Product Owners drawing them away from their responsibilities and ultimately disrupting the flow of value to the organization’s customers.

The Underlying Issue

What throws up these symptoms is a collision between Agile product development and the legacy structures of the wider organization. As we discussed in a previous article (2) Agile development requires autonomous product teams. A good working definition of their autonomy is that, instead of being given tasks to perform, they are given problems to solve. I have always advocated this as part of my advocacy for Scrum, but this is also the definition of team autonomy that Henrik Kniberg gives in his famous ‘Spotify engineering culture’ YouTube video, and that -quite separately – Marty Cagan offers in his Product Operating Model. So, what are the problems they should be given to solve? The most important problems are those of the customers: What pains do they have that need addressing? What gains in their lives can the organization help them make? Agile product teams are charged with solving customers’ problems in a way that benefits the organization.

In traditional development a variety of different managers are given these problems to solve. Different managers might have different perspectives, depending on their departmental responsibilities or their own particular KPIs. They compete with each other for project resources from the PMO or some other financial authority in the organization. If they are granted the resources, they ask for then they fund project teams to execute their chosen solutions. When the organization moves from a project to a product focus, this legacy mindset tends to persist. It is difficult for internal stakeholders to grasp the fact that the decision-making authority has been driven down to the product teams. Managers still view the product teams as being merely ‘executing’ teams and bring their own individual and sometimes competing concerns to the Product Owners in the hope of influencing the ordering of the items in the Product Backlog.

MetaScrum

The MetaScrum pattern (3) involves the creation of a forum – the MetaScrum – in which the entire organization can align behind the Product Owners and their Product Backlogs. Attendees include all the Product Owners and the representatives of the senior management. In the best scenario, the CEO attends. The forum meets regularly with a frequency appropriate to the organization’s rhythms of activity. It is facilitated by a MetaScrum Product Owner whose job it is to lead the creation of alignment between the management, the product teams and other stakeholders.

Scrum teams can request support, funding or information in this meeting from stakeholders outside the product teams – Product Owners are, of course, embedded in the product teams in Scrum. Managers and other Product Owners can argue for changes to Product Backlogs at the regular intervals dictated by the cadence of the MetaScrum meetings, but in-between times the Backlogs are locked down.

The MetaScrum, while it makes Management concerns transparent, is not a mechanism for exerting management control over the Product Owners. On the contrary, it emphasizes the idea that the responsibility for solving customer problems belongs to the product teams, and the key role of the Product Owners embedded in them. Management’s role is, as part of corporate strategy, to identify which of the customers’ problems are the priorities to solve. Management can propose product changes through the MetaScrum but the Product Owners still own the direction of their respective products. They can shift emphasis and priority between their products, marketing initiatives and other product-related programs in response to what they learn in the forum’s meetings. The MetaScrum both sensitizes Product Owners to corporate management directives and exposes department heads and other internal stakeholders to the autonomous authority of the Product Owners.

Applications of MetaScrum

MetaScrum began at PatientKeeper nearly 25 years ago. PatientKeeper is a US company that provides healthcare applications for physicians. It was also one of the first companies to adopt Scrum enterprise-wide. A common problem PatientKeeper had to face was to frequently either delay or accelerate hospital live dates for their products due to sales contracts, development issues or generally changes in market conditions. The MetaScrum facilitated rapid changes across their product range in ways that remained consistent with their corporate strategy. The CEO attended the meetings, but rarely intervened. However, he aggressively removed organizational impediments that the MetaScrum identified – including, where necessary, changing the management.

The PatientKeeper model is not the only form the MetaScrum can take. At 3M the chief executive of one division is the MetaScrum Product Owner. The MetaScrum meets twice weekly to ensure priorities are clear and addressed. A separate leadership team focuses on the removal of organizational issues that impede the Scrum teams. Saab Defense in Sweden and Systematic in Denmark are two other companies that have adopted Scrum throughout the organization. They both have forums at the top of the management hierarchy that act as high-level MetaScrums. Steve Jobs used to raise all strategic product decisions to a meeting every two weeks at Apple – arguably also an implementation of MetaScrum.

Benefits of MetaScrum

The central idea of the MetaScrum, whatever particular form it takes, is that it is the focal point of enterprise-level change, including the change to Agile product development itself. Stakeholders may change the direction of the organization, change budget allocations between products, and remove impediments, so the people with the authority to do these things need to be present in the forum. Impediments hindering the delivery of value to the customers of any of the organization’s products are raised at the meeting and made visible. Often it is the case that individual product teams have insufficient resources or power to remove blockers but making them transparent in the MetaScrum enables the wider organization to concentrate its resources to resolve issues. A good MetaScrum Product Owner will work to resolve issues the same day if possible, but certainly as soon as possible. Managers and Product Owners can often make small changes on the spot, but if there are weightier decisions to be made then management and the Product Owners work together immediately after the MetaScrum to identify a decision pathway.

At its best, MetaScrum is a powerful force in the organization. If the Product Owners agree to a management proposal – and they retain the right to say ‘No’ if the decision falls within the realm of their authority – then that agreement stands until the next MetaScrum event. The product teams can work without interruption until the next MetaScrum because – outside of an emergency – Managers are not allowed to approach the Product Owners with new talking points. Sales force teams, HR and even the customers themselves learn very quickly that it is futile to try and alter agreements made until the next one: again, “For Product Owners to succeed, the entire organization must respect their decisions”. Over time, organizations tend to find that managers play a diminishing role in product management and that power incrementally shifts to the Product Owners. The organizational structure flattens out and the link between corporate strategy and product development becomes stronger. Enterprise agility is accelerated.

(1) Ken Schwaber and Jeff Sutherland.The Scrum Guide 2020. scrumguides.org . accessed 28/08/2025

(2) “The Self -Managing/Self-Organizing Team” by A.J. O’Callaghan

(3) Jeff Sutherland, James O. Coplien and the Scrum Patterns Group. A Scrum Book. The Spirit of the Game.pp 176-180. 2019.The Pragmatic Programmers.

First published on LinkedIn September 4th 2025

Agile Rises from the Dead - Again!

Fri, 07 Nov 2025 13:51:28 GMT

By Alan O'Callaghan

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.

The Self-Organizing/Self-Managing Team

Fri, 07 Nov 2025 13:42:52 GMT

By Alan O'Callaghan

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.

It's Product Owner not Project Owner

Thu, 06 Nov 2025 15:48:27 GMT

By Alan O'Callaghan

It’s Product Owner, not Project Owner – that one word makes all the difference. One of the most common mistakes I see when organisations adopt Scrum is that they treat the Product Owner like a kind of project manager. The language slips out easily — projects are how many companies are used to running work. But the name matters. It’s Product Owner, and that tells you a lot about what Scrum is really about.

Products, Not Projects

Let’s remind ourselves about what Product Owners are accountable for. They are responsible for maximizing the value resulting from the work of the Scrum Team and for managing the Product Backlog. Taking that last bit first, the Product Backlog lasts for the entire lifetime of the product. It is consigned to the dustbin only when the product is sunsetted. Projects are short-lived by comparison. They are transient. They have a start date, an end date, and a list of things to deliver. Project teams are broken up once the project is ended.

Products, on the other hand, live and evolve over time. They are impacted by customer feedback, market changes, and new ideas. The Product Owner should be responsible for maximizing a product’s value throughout its entire lifecycle. Since the Product Owner is embedded in the Scrum Team this implies that the team should be stable and dedicated to the product over its lifetime. They should be Product Teams, not Project Teams. When engineers and even whole teams bounce from project to project, they lose context, knowledge, and ownership. When they stay with a product, they can continuously improve it and deliver value far beyond the first release.

Why “Project Owner” Thinking Hurts

When Product Owners are treated like Project Owners, you usually see:

A focus on deadlines and the delivery of features, not value. A tagline I often use in my own practice is ‘Scrum Teams are committed to delivering value, not scope’.
Teams, and therefore their Product Owners, wash their hands of the project once the final delivery deadline has passed- which is a problem since value is usually realized a while after delivery.
Knowledge and learning is lost as teams are broken up after delivery.
Technical debt piles up as corners are cut because the goal is to “finish,” not to sustain. In other words, you might deliver something — but you don’t get the benefits of a living, breathing product that can adapt and grow.

The Real Challenge: Culture

Shifting from a project mindset to a product mindset isn’t just a terminology tweak. It’s a cultural shift. Leaders have to stop asking, “When will the project be done?” and start asking, “What value are we delivering?”. Funding models have to move from one-off budgets to continuous investment in products. Teams need stability, not constant reassignment. This is uncomfortable for organisations built on decades of project thinking. But the payoff is real: faster delivery, happier customers, and products that stay valuable over time. Bain and Company claim that product-centric organisations deliver up to 60% faster with 36% lower development costs (1). Shifting from ‘project’ to ‘product’ helped Huntingdon National Bank to achieve record double-digit growth -32% in a single year (2).

Final Thought

Scrum and product operating models are natural bedfellows. If you want Scrum to really work for you, respect the role for what it is. A Product Owner owns the product, not just the project. That one word makes all the difference.

(1) https://www.bain.com/insights/from-silos-to-speed-how-product-operating-model-is-transforming-consumer-products-companies/

(2) https://www.planview.com/resources/case-study/huntington-national-bank/

First published on LinkedIn September 15th 2025

Gathering the Evidence: Continuous Product Discovery

Thu, 06 Nov 2025 15:36:39 GMT

By Alan O'Callaghan

I love who-dunnits. If I’m resting at home in the evening watching TV, unless there’s a compelling football match to watch, I’ll probably watch crime fiction: anything from Midsomer Murders (1) to Sherlock (2). If I’m reading a novel, or listening to one on my Audible account, then the odds are it will be a murder mystery. In some stories the murderer is known at the beginning (think Columbo (3)) and the fun lies in the chase. But my favourite kinds are the ones where clues appear incrementally, there are red herrings and distractions all over the place as the evidence accumulates, and the race is on for the viewer/reader/listener to solve the murder before the fictional detective does.

Agile product development has some similarities with whodunnits. At the beginning there is not enough information to come up with a solution we can be confident in. Significant effort has to be put in to gathering evidence. Some actions will need to be taken before all the necessary information is to hand. The solution emerges over time, based on the evidence. Agile product development is driven by continuous product discovery.

Simpler Days

Twentieth century mass production was simpler. There was an upfront period of product exploration in which a potential solution was designed. Once finished, this phase was followed by a rather longer period of product exploitation in which the aim was to maximize output and, of course, sales. The difference in twenty first century production, where the rate of change keeps rising exponentially, is that the ‘exploration’ phase extends into the ‘exploitation’ phase. Product discovery continues even after product delivery starts. Potentially, it lasts until the product is sunsetted.

Managing Risks

Managing a Product Backlog in the face of unrelenting change involves the management of a number of risks. The most important of these is the value risk: the risk that the organization’s customers won’t buy the product or service. Either it doesn’t sufficiently address their pains, or it doesn’t offer enough significant gains to engage their interest. The continuous delivery of valuable increments, and the feedback from the customers they enable, is the most powerful tool available for managing that risk. Provided, of course, that the feedback is acted upon. In between releases, Sprint Reviews provide a forum for stakeholders and customers to collaborate with the Scrum Team about the increment they just developed. The underlying idea is that many, perhaps most, of the assumptions that we have at the beginning of the development cycle may turn out to be wrong. Incremental delivery, coupled with iterative development, provides a product team with the evidence that either validates or invalidates those assumptions.

Another risk is the usability risk. Customers might like the product’s concept and appreciate its potential for making their lives better, but if the product becomes too complicated or difficult to use they are likely to walk away from it sooner or later. Usability experiments are similarly likely to last through most of the product’s life cycle and, as with the value risk, the best evidence is the feedback from incremental product releases.

The other two big risks are feasibility and viability. Can the organization actually build the product with the resources (materials, technology, skillsets, financial etc.) available to it? And, even if the product can be built, can the organization support it in the market? For example, does the organization’s existing business model support it, or if that model needs changing, is that possible to the degree necessary?

The continuous management of these risks is the very essence of product discovery, but the feasibility risk can be raised if continuous delivery is the only way in which they are managed. Iterative development means rework, and it consumes the resource that is typically the most expensive: engineering. If engineering work gets continually discarded the cost of development may rise to the point where it outweighs the benefits. A good Product Owner will always be open to necessary reworking of the product but will want to keep it to a minimum by gathering as much evidence as possible before her team starts sprinting. The feasibility and viability risks in particular should be largely mitigated before development starts.

Discovery Techniques

The goal in product discovery should be to validate our ideas in the fastest, cheapest way possible. Different discovery techniques are available for different kinds of products, but prototyping is an approach that can be applied in most contexts. The fundamental purpose of any kind of prototype is to learn something at a much lower cost in terms of time and effort than building out a product – even an MVP. A good prototype is a powerful force for collaboration in the product team, helping its members to think more deeply about the risk(s) it is addressing.

The feasibility risk can be typically mitigated through one or more spikes – quick and dirty throwaways developed in timeboxes of no more than a day or two by a pair of Developers. Just enough of the product is created to mitigate the risk – a small percentage of the effort that might be required of an MVP – which might be a performance issue, a scalability concern, or the use of a technology or a third-party component the team has not used before.

The viability risk can be addressed through the use of a Business Model Canvas. Developed by Strategyzer.com the Business Model Canvas can be thought of as a giant canvas divided into nine panels. The central panel is for the Value Propositions. To its right are three panels to do with customers: Customer Segments, Customer Relationships and Channels. To the left are another three panels: Key Activities, Key Resources and Key Partners. Two panels below the other seven deal with Cost Structure and Revenue Streams. In a workshop stakeholders populate these panels with stickies and then collaborate to refine the visualisation of their business model. Easily accessible, the model easily reveals whether a new value proposition sits neatly within the existing business model or challenges it.

Mitigating the value risk should always be done in front of real customers. But a Product Owner doesn’t have to wait for the first release or even the first Sprint Review to begin that process. GV – formerly Google Ventures – uses what it calls Design Sprints to address key value risks before it decides to invest in companies. A Design Sprint – not to be confused with Scrum’s term for a development iteration – lasts five days in which a throwaway prototype is built and shown to a small group of five or more real customers for feedback. Famously they built a fake version of a robot for Savioke to test assumptions about how hotel guests and staff would react to an automaton that delivered room service in hotels. Only after the prototype passed this test did Savioke go into production of the real thing.

Prototypes that address the usability risk are simulations that can range in their fidelity from low (interactive wireframes, for example, that address just one dimension of the product’s usability) to high (close-to-real interfaces but which use low-fi data rather than live data). Typically, low-fi prototypes are used to identify the workflow required before development starts while hi-fi prototypes are used to build usable increments before an actual release which uses live data.

Rapid Experimentation

Different techniques are available for mitigating the various risks, but the key is to remember that whether using a prototype, a simulation or releasing an increment, the team is always performing experiments. The Product Owner uses rapid experimentation throughout the life of the product to discover the features that will maximize the value to the customer while at the same time benefitting the organization. Sister Boniface (4) is not a bad role model for a Product Owner to follow.

(1) Misomer Murders. ITV series. 1996-present day

(2) Sherlock. BBC series. 2010-11

(3) Columbo.NBC series.1971-78

(4) The Sister Boniface Mysteries. BBC studios and BritBox series. 2022-2024

First published on LinkedIn October 16th 2025

A Product Owner by Any Other Name…

Thu, 06 Nov 2025 15:29:40 GMT

By Alan O'Callaghan

There are questions that tend to haunt you throughout your professional life. One of the most asked of me as an Agile coach and trainer is “What is the difference between a Product Owner and a Product Manager?” Good question.

What is a Product Manager?

The answer depends first of all on what you think a Product Manager is. For example, in the Silicon Valley Product Group (SVPG)’s Product Operating Model there is a role called ‘Product Manager’. Their model is an abstraction of the work of highly successful product companies such as Microsoft, Netflix and Spotify. SVPG defines a product company as one in which technology, rather than serving the business, is the business. The group’s founder, Marty Cagan insists the competencies of a Product Manager are the most difficult new ones to establish. Why new? Because, despite the title being a traditional one, what is required in the Product Operating Model is a very different job, with very different skills and responsibilities. He characterises the traditional Product Manager as a roadmap administrator who essentially co-ordinates between different internal stakeholders. Solving customer problems, determining a product’s value is the province of those internal stakeholders. Key decisions are taken in committees of the stakeholders, with its meetings facilitated perhaps by the Product Manager, but she is subservient to them while trying to find common ground between them.

“Behind Every Great Product…”

In contrast to the traditional model, Cagan’s Product Operating Model requires a Product Manager to have the responsibility for evaluating opportunities, and then deciding what gets built and delivered to customers. These choices are most often reflected in a Product Backlog. To do this effectively the individual concerned needs the following:

· Deep knowledge of the customer

· Deep knowledge of the data and analytics concerning the customers’ use of the product

· Deep knowledge of the business

· Deep knowledge of the market and industry sector in which the business is competing

Cagan writes “It is my strong belief…that behind every product there is someone – usually someone behind the scenes, working tirelessly – who led the product team to combine technology and design to solve real customer problems in a way that meets the needs of the business” (1). This is the person that he calls the Product Manager. It is someone, he says, who has the competencies and the personality of a CEO, but with the key difference that she is the boss of nobody.

Accountability of a Product Owner

Well, I call her the Product Owner. The concept of the Product Owner originated in the Scrum framework. The framework has always used terms that emphasize that what is required is something very different from traditional practices and mindsets: hence ‘Scrum Master’ and ‘Product Owner’. Product Owner is not necessarily a job title, nor even a role. Crucially it is an accountability within the self-managing Scrum team. Let’s mention here that in the Product Operating Model the Product Manager is similarly embedded in an empowered Product Team.

What the Product Owner is specifically accountable for in Scrum is managing the Product Backlog and maximizing the value of the product resulting from the work of the Scrum team. These accountabilities are spelled out explicitly in The Scrum Guide. So why don’t the SVPG call this key role in their model ‘Product Owner’? Because they describe Product Owners as Backlog administrators who escalate every decision and issue to senior management. More than once, Cagan has said that this is the kind of job that is described in a Certified Scrum Product Owner (CSPO) class. When I played a video clip of Cagan saying exactly that, to a very experienced and successful Product Owner that I had originally trained he laughed and said “Well, he clearly never attended your CSPO class”. Nor a class given by Zia Malik, Matt Roadnight, Martine Devos, Nigel Bear or any of the CSTs in Scrum Alliance that I know that deliver the course.

Were it the case that a Product Owner’s accountability was restricted to managing the Product Backlog then the accusation that they are merely Backlog administrators would have some validity. I don’t doubt that there are a great many people labelled ‘Product Owner’ in their organizations who lack the leadership qualities that Scrum demands, and are basically rebadged Business Analysts. But if they are among the estimated 400,000 certificants created globally by either Scrum Alliance or scrum.org then they were not trained to be administrators.

Maximizing Value

The key issue is the Product Owner’s accountability for maximizing the value of the product. She orders the items in the Product Backlog so that the Scrum Team is always working on the most important thing to deliver that value. It is the self-managing Scrum Team that is charged with solving the hard problems the customers face, not the internal stakeholders. For them to be able to do that and stay in alignment with the wider organization their Product Owner has to have a keen understanding of the business’ strategy, develop a strong Product Vision and communicate the various market strategies the product will need over its lifetime. Each of these strategies will need an outcome-oriented roadmap providing the context for the Product Owner’s decisions on the ordering of the Product Backlog.

In reality there is a lot of overlap between the SVPG’s concept of a Product Manager and Scrum’s Product Owner. They are both very different from the traditional Product Manager. They both make use of a Product Backlog. They are both embedded in an autonomous product team. They are both accountable for delivering maximum value to the customer in a way that benefits the organisation.

The Product Operating Model is simultaneously broader and narrower than the Scrum framework. It is broader than Scrum in the sense that it addresses issues in the wider business directly. The Scrum framework leaves it up to individual organisations to work out how Scrum teams fit their particular context. The Product Operating Model is narrower than Scrum in that it applies only to technology companies while Scrum can also be applied to marketing, education and even restaurants. I love the Product Operating Model’s insistence on product teams rather than project teams (Cagan calls these feature teams). Scrum can be used on projects but customers buy products, not projects, and leveraging the investment in self-managing Scrum teams is best done by keeping them together, working on one product at a time rather than splitting them up at the end of a project. I consider continuous Product Discovery and building products through rapid experimentation – key themes in the Product Operating Model – to be essential in Scrum too.

Upskilling Product Owners

The underlying reality is that whatever you want to call them – Product Managers or Product Owners - there is a desperate shortage of people with the skill and the authority to lead product teams that can solve the hard problems that customers face. It is not about changing job titles. It is about making a serious investment in upskilling those people and equipping them with whatever they need to be effective.

(1) Marty Cagan. Inspired- How to Create Tech Products Customers Love 2nd edition p5 .2018 John Wiley.

First published on LinkedIn August 4th 2025

The Five Types of Product Owner

Thu, 06 Nov 2025 15:13:42 GMT

By Alan O'Callaghan

Don McGreal and Ralph Jocham (1) reckon there are five types of Product Owner that can be viewed in industry:

· The Scribe

· The Proxy

· The Business Representative

· The Business Sponsor

· The Entrepreneur

S cribe

The Scribe type provides the least benefit to an organization of the five. She might be charged with gathering requirements for Developers, and maybe translating them into user stories for input into JIRA or some other reporting tool. She is probably a Business Analyst (BA) who has been nominated as Product Owner, but is really nothing more than a Product Backlog administrator.

Proxy

The Proxy is a member of the Scrum team who acts as a representative of the ‘real’ Product Owner who is outside of the team and is, in their day-to-day work, focussing on activities that have nothing to do with the product development work. The proxy escalates decision-making to the ‘real’ Product Owner and causes handover delays and blockages as a result. The Scrum Team is robbed of any possibility of being truly self-managing by the fact that the Product Owner is not actually in the team.

Business Representative

The Business Representative is a big step up from the Scribe or the Proxy Product Owner, but their role as a Product Owner is a bit one-dimensional. They see themselves as the voice of the stakeholders and, fundamentally, act as a go between, shuttling to and fro between the stakeholders and the Scrum team’s developers. The Business Representative PO is like a waiter in a restaurant, bringing orders from customers at the tables to the kitchen staff who create the meal. Of course this is part of a Product Owner’s responsibility, but she is more like a Head Chef than a waiter in the restaurant metaphor. After all, waiters don’t tell the kitchen staff what is the most important part of the meal to cook next. But that’s exactly what an authoritative Product Owner does by ranking work items top to bottom in the Product Backlog.

Business Sponsor

The Business Sponsor is a very common type of PO. At first glance she ticks all the boxes of a Scrum Product Owner. She will have co-created the Product Vision with key stakeholders and possibly acquired the budget. She champions the product at all levels of product planning and spearheads the drive towards delivering outcomes. The Business Sponsor PO has trust from the entire stakeholder community, and indeed the mandate to make decisions for business-related issues for the Scrum Team. But often her effectiveness is limited by her organization’s project-centred culture. She is at the mercy of a range of internal stakeholders - Department heads and other Managers -each of whom has their own solutions for the customers problems. The PO’s job is to juggle these priorities in a way that makes the most sense. But essentially, she is a Product Roadmap administrator.

Entrepreneur

It is the Entrepreneur PO who comes closes to the concept worthy of the name, Product Owner. Instead of other people in the management hierarchy dreaming up solutions for the customers, she is embedded in a Scrum Team that has been given the customers’ problems to solve themselves. They are an aligned, autonomous team that owns the business objectives the product is supposed to achieve. They are a stable team that runs the entire product development effort “from suit to nuts”. They are not merely an execution/implementation team delivering someone else’s idea of a solution. A Product Owner that has an entrepreneurial mindset, and has the authority over the product equivalent to that of a business owner is a key component of a self-managing, self-organising Scrum Team committed to delivering business value.

(1) Don McGreal and Ralph Jocham. The Professional Product Owner: Leveraging Scrum as Competitive Advantage. Addison Wesley. 2018

First published on LinkedIn October 25th 2025

The North Star isn't a Destination - but it lights the way

Thu, 06 Nov 2025 15:07:57 GMT

by Alan O'Callaghan

Although not explicitly mentioned in The Scrum Guide, Product Vision is an enormously powerful tool in the hands of a Product Owner. It provides a bridge between a product’s strategy and the business strategy of the wider organization. It is crucial in enabling the autonomy of the Scrum team by ensuring its business alignment, and its use tends to highlight problems in the way an organization develops its products and services. It opens up opportunities for the business to take actions that improve its ability to satisfy its customers. The need to upskill its Product Owners is often one of them. The Product Vision is a kind of North Star. It lights the way and, in doing so, often reveals things lurking – previously unseen – in the shadows.

Business Strategy

Let’s sort out some terminology first. In product management the same words can mean different things to different people. So, what do I mean by ‘business strategy’. Roger L. Martin (1) claims that an effective business strategy answers the following questions:

What is our winning aspiration? What is the fundamental purpose of the business – why do we exist, beyond just making money?

Where will we play? Which markets, geographies, customer segments and distribution channels will we focus on?

How will we win? What is our unique approach to create superior value for customers and deliver a sustainable advantage over competitors – and which ones will we deliberately not pursue?

What capabilities and systems must be in place? What critical competencies, resources or ways of working must we build or acquire to deliver our winning way?

What management systems are required? What structures, measures, incentives, and governance are needed to support the strategy and ensure continuous adaptation?

Answering those questions takes an organization beyond the vague aspirations embodied in, say, a mission statement to make clear, hard choices. Mission statements and business strategy are - quite properly - devised, owned and communicated by the organization’s senior management. But the sad fact is that most companies avoid the kind of brutal prioritization that Martin is implying.

Instead of stating clearly which of their customers’ pains they should address with their products, internal stakeholders come up with business cases for individual projects, use them to compete for a share of funding (often on an annual basis) and, if they are successful, hand their ‘solutions’ over to project teams for execution. This approach is commonly called the peanut butter strategy (2). Resources are spread too thinly across the development organization and over too many products and services. The peanut butter strategy is in fact the absence of business strategy. Instead of the senior management deciding which areas of customer need they should prioritize, the financial arm is ranking proposed solutions identified by various department managers. Decisions are made on the promised Return on Investment (ROI) contained in their separate business cases.

Product Vision

A Product Vision is a stable, aspirational goal that describes the kind of product that is needed to meet some aspect of a business strategy. My favourite example of a Product Vision was the one for the iPod. Apple released the iPod in November 2001 after 8 ½ months of rapid experimentation and development. The vision Steve Jobs gave to his senior engineers was for a device that could fit in his pocket, hold at least 1000 tunes and would be easy enough for his mother to use.

In 1997 Apple was 90 days from being bankrupt. Dell’s CEO commented at the time that if he were in charge he’d “shut it down and give the money back to the shareholders”. Then Steve Jobs returned. He killed 70% of the products Apple was shipping in his first year. He slimmed the company’s portfolio down to just two desktops and two laptops for consumers and computer professionals. He diverted a large part of the R&D department’s budget into marketing and launched the “Think Different” campaign that proclaimed that Apple is for passionate people who want to make the world better.” The campaign advertised the core values of Apple rather than any individual products, but the vision he had for the iPod fitted right into the new strategy. Apple wasn’t just saved from bankruptcy it was turned into the richest technology company in the world by Jobs’ strategy.

Product Visions usually get elaborated in an envisioning workshop, facilitated by the Product Owner, that involves a diverse group of stakeholders as well as some engineers. Its job is to boil down potential features to the most important ones. Creating a list of potential features is easy. Boiling them down to the three or four critical ones for a product’s success is much harder. In the absence of a business strategy, it gets extremely difficult. Different stakeholders champion their own pet features in competition with each other. The Product Vision says “This is the kind of product we need to do…” To do what? In the absence of a business strategy the question is almost unanswerable. Peanut butter, anybody?

Towards a Product Model

Fractious envisioning workshops are often symptoms of a bigger, underlying problem: the organization as a whole has an insufficient focus on its customers’ priorities. The senior management is the body to redress that. But the issue is exacerbated when the organization’s focus is on projects rather than products. Customers buy products and services, not projects. The most successful businesses place problem-solving in the hands of product teams, not internal stakeholders. A team, led by the Product Owner embedded in it, is given a customers’ problem to solve by management. The product team is empowered to figure out the best solution. In these circumstances, the Product Vision has a clear link to the business strategy (which is based on the superset of customer problems the company has focused on), while at the same time providing a value compass to the development effort itself. Individual feature requests can be compared to the Product Vision and judged as to whether they contribute to it or take the product off at a tangent. In the latter case, the Product Owner should reject the request out of hand. Product strategies to implement the Product Vision; to gain market-fit, or to or maintain market share, and the roadmaps associated with these strategies provide the context for the ordering of the Product Backlog, helping the Product Owner to maximize the value resulting from the work of the Scrum Team.

Empowering Product Owners

All this implies a change in the position of Product Owners relative to the rest of the organization. In project-centric companies a Product Owner is, at best, a roadmap manager, arbitrating amongst the different stakeholders who each want their project’s features to rank highest in the Product Backlog. A genuine Product Owner is described by the name on the tin. She owns the product. To do that she will need to know the business strategy; have a deep understanding of the customers’ needs and how her product might serve them; drive product strategy and elaborate outcome-driven roadmaps. This is not just an upping of her authority; it demands that her skillset be raised to new levels. The choice for organizations is to invest in their Product Owners or eat peanut butter for the foreseeable future.

(1) A.G. Lafley and Roger L. Martin. Playing to Win: How Strategy Really Works. Harvard Business Review Press. 2013

(2) See, for example, Marty Cagan with Lea Hickman, Christian Ididdi, Chris Jones and Jon Moore. Transformed: Moving to the Product Operating Model. Wiley. 2024

First published on LinkedIn October 6th 2025

Meaning is in the Eye of the Beholder - MVP

Thu, 06 Nov 2025 15:00:26 GMT

by Alan O'Callaghan

The worlds of business and product development are awash with acronyms. While they can be useful shorthand for complicated concepts, they have a tendency to degrade over time and the understanding of what they mean gets fuzzy. Meaning, like beauty, is then in the eye of the beholder. ‘MVP’ is one of those acronyms which seems to have attracted both beautiful and ugly meanings to itself.

MVP stands for Minimal Viable Product and was popularised by Eric Ries in his book The Lean Startup. A Build-Measure-Learn feedback loop is at the heart of his Lean Startup model. He explains “The MVP is that version of the product that enables a full turn of the Build-Measure-Loop with a minimum amount of effort and the least amount of development time.” (1) The very fact that it is a minimum product tells us that not all of its planned features will be included in the MVP. Even essential features might be left out. Often people focus on the ‘Build’ part of the loop and use it as an excuse to release a product that has too little functionality to be considered either valuable by customers or viable by the business. Some engineers even use ‘MVP’ as an argument for cutting corners on quality assurance:” It’s only an MVP. We can build in the quality later in the full product”. They appear to be practising development agility because they are delivering incrementally – and we definitely favour small increments in Agile product development – but where’s the value if no-one wants to use it, and who wants to use a shoddy product?

Product-Market Fit

MVPs are not about reducing the product’s development effort. In fact the use of an MVP increases the effort required because its impact has to be measured. An MVP is essentially an experiment. It is testing the emerging product to see if it is likely to deliver the value proposition embedded in the Product Vision.

MVPs are usually targeted at product-market fit. Product-market fit means having a product that can satisfy a market. By definition, that means building a product that creates significant customer value. In turn, that requires meeting real customer needs in a better way than any competitor products.

The Product Owner has an essential role to play here. She has first to identify who the real customers are, and secondly decide which of their needs are underserved, and in what way. This is the thinking that should underpin the selection of the feature set for the MVP. Those features which address the customers’ top pains or offers them the most benefit should be prioritized. Brainstorming a list of features is easy. Deciding which four or five are the most important is really hard. And it is really critical. Of course, at first these are just hypotheses. It is the release of the MVP to the market, and the feedback from customers that will tell us whether it’s moving in the right direction to achieve the Product Vision. Increments that are demonstrated internally and are not placed in front of real customers should never be called MVPs. Quantitative measurements can tell us how many customers have bought the product, how the end-users interact with it and such like. Qualitative feedback is needed to tell us why they use it in a particular way. MVPs give us data that can lead to a go/no go decision about whether or not to build a solution and grow it in the market.

Pivot

The nature of a hypothesis is that it could be proved right or wrong. If our assumptions are wrong, we will need to pivot. The worth of an MVP is that it can tell us sooner that is time to change direction, saving money and effort in the process. Startups that use MVPs in this way are capital-efficient and are more likely to survive but, clearly, more established organizations can also use an MVP to validate assumptions about new products or innovative features.

MVP tests

Given what I’ve just said, I suppose that there can only be one MVP in a product’s lifecycle. I’ve witnessed many a lively debate about whether there can be one or many. And I’ve usually stayed outside of them unless one of the ugly meanings I mentioned before is raised. For sure, the Product Owner will be prioritizing features and work packages throughout the product’s development, but deciding which few are the key ones to deliver on the Product Vision seems to distinguish the MVP from increments that are delivered later.

Having said that, similar thinking can be used at various points during development to test key assumptions and get new learning. Dan Olsen calls these ‘MVP tests’ (2) and I like this idea. Faced with an unknown or a particular risk, the Product Owner will work with the engineers in the Agile Product Team to identify which features are needed, in a prototype perhaps, to uncover a new learning point or address the risk.

Four Product Risks

There are four kinds of risk that the team, under the guidance of the Product Owner needs to bear in mind all the while:

Value . This is the risk that nobody will want to buy or use the product- that it is essentially not fit-for-purpose. While this is the risk that MVPs usually address most, it will still need to be revisited even if the MVP validates initial assumptions.

Usability . If the customers can’t work out how to use the product, they will eventually walk away from it and it will have no value. Prototypes can be built rapidly and cheaply to test which kind of interactions the customers prefer before the product team commits to any particular solution.

Feasibility . Can the engineers build the solution with the resources available? This includes technology, skillsets, budget and time. Ruthless prioritisation by the Product Owner is key here too. If the product team is always working on the most important items then it is likely they will deliver customer value even if budget and time constraints prevent them from delivering full scope. Spikes might be needed to address technology or skillset-based risks.

Viability . A given solution might be very attractive to customers, but can the organization support it in the marketplace? The potential issues range from whether the business can make a sufficient profit, to whether its existing business model needs adaptation.

An initial MVP might begin to answer some of these questions, but the reality is that the Product Owner will repeatedly have to ask, “Which subset of features do we need in the next increment to address this risk?”. Continuous product discovery and rapid experimentation will be needed throughout the product lifecycle to maximize customer value in the face of change, and in a way that benefits the business.

Questions for You

· What is the understanding that your organization has of ‘MVP’?

· How do your teams address risk?

· How do you measure a release’s impact?

(1) Eric Ries. The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. p.77. Portfolio Penguin. 2011

(2) Dan Olsen. The Lean Product Playbook. How to Innovate with Minimal Viable Products and Rapid Customer Feedback. Wiley. 2015

First published on LinkedIn September 22nd 2025

E-Learning On Steroids

Mon, 26 Feb 2024 16:16:11 GMT

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

An issue for organisations seeking greater Business Agility is how to scale the learning required to get staff on board with Agile product development. The training of Product Owners, Scrum Masters and the like in either physical or virtual classrooms is a must, as is their coaching and mentoring, but may be prohibitively expensive to extend to the whole organisation, depending on its size. But without sufficient understanding, people in the wider organisation may well turn into resisters of the change. E-learning on proprietary Learning Management Systems (LMS) is the go-to response, especially for big organisations, but success is limited as one-size-fits-all online courses fail to engage learners . Often they are forced to wade through material that bores them rigid because they feel they already know a lot of what is being presented.

Personalised E-learning

In May of last year Emerald Hill Limited launched what we believe to be the world’s first Adaptive Learning course for Agile development: Scrum Fundamentals (1). The course content, including quizzes and surveys, are all created by humans. It is in the presentation of that content that AI algorithms kick in . The learning is ‘adaptive’ because the learners’ understanding of the subject is being continually probed, and the platform ensures that they are only presented with content they do not yet fully understand. The result is a highly personalised, engaging experience that quickly leads learners to 100% competency. We’ve deployed the Scrum Fundamentals course to four different companies since then. One of them, an organisation undergoing a digital transformation enabled by Scrum and other Agile approaches, was enthusiastic enough to install the course on its LMS for a rollout to over 100 staff as a trial. The results are in. They are staggering.

Full Proficiency in Less Than Half the Time

The entire cohort has achieved 100% competency in their understanding of terminology and meaning of Scrum as defined in The Scrum Guide . (2) The platform continually probes the learner with quizzes and questions, returning to topics until they demonstrate full understanding. Learners typically take the course in bite-size chunks at their own pace. End-to-end, there is 2 hours and 45 minutes of material. In the trial, the mean time to achieving proficiency was 1 hour and 19 minutes of engagement with the course. That’s 100% competency in less than 48% of the time! The minimum time taken to progress through the course to a successful completion was 25 minutes. The differences in completion times between the different learners partly reflected their varying experience and degrees of understanding of Scrum before starting the course. Only a tiny number needed to see all of the content.

The Power of AI

The platform we use is Area9 Lyceum’s Rhapsode ^TM (3). Area9 is a Danish company that has been developing AI algorithms for adaptive learning for more than twenty-five years - originally to help train doctors in the medical profession – and has helped more than 30 million learners worldwide. Our Scrum Fundamentals course is, we believe, the first to use the technology in the Agile space. Adaptive learning delivers a very close approximation to the personalisation of one-to-one training. Essentially, the platform flips the traditional training model. Instead of presenting information and then assessing it, probes are seeded throughout the course to identify what the learner already knows; what they don’t know; and, crucially, what they think they know but really don’t . Training content is then selected by the platform for presentation depending on the data from the probes. There were one hundred and forty seven probes covering the five modules and eighty five learning objectives of the Scrum Fundamentals trial. The client company requested that we include a module about how they scale their Agile teams. In the public version of the course, there are four modules, 68 learning objectives and 114 probes.

Capturing Learner Data

Corporate learning and development (L&D) seeks meaningful return on investment (ROI) measures which go beyond the transactional data of the number of people taking a course or its completion rates. Metacognition , or the process of thinking about one’s own thinking and learning , plays a crucial role in adaptive learning. Data points gathered from learners’ individual responses can be measured to provide a high-level feel for how challenging a course is and whether the learners had high or low misconceptions prior to starting it. Rhapsode generates information automatically which allows the client to assess improvements in proficiency, competence and confidence.

We can demonstrate, for example, that there was a 91% improvement in understanding of Scrum across the trial cohort taken as a whole. The company concerned has invested in developing an understanding of Agile amongst its staff for a number of years, so it was no big surprise to find that across all the topics 52.6% of the material was understood and the trial group were confident in that knowledge. In fact, there was a small amount of content (4.6%) where they knew more than they thought they did. The big gains were in the areas where they realised that they didn’t know material (12.8% of it) and where they had important misconceptions about it. This last category included no less than 30.7% of the course content. As a general rule, a figure of less than 10% in this category (called ‘unconscious incompetence’) is considered low and anything above 30% is considered very high. However, there are good reasons to expect high levels of unconscious incompetence when the topic is the Scrum framework . It has evolved considerably since first being made public in 1995 and the current version of The Scrum Guide 'is the sixth update. The bottom line is that the trial revealed that for all its prior investment in both instructor-led and e-learning in Scrum, there is a huge amount of misconception that needs to be addressed. But it also showed that the Scrum Fundamentals course had, with a laser-like focus, fixed that issue in the trial cohort – and in record time.

We can also see from the data collected where in the course individuals struggled and where they achieved mastery more easily. The client’s LMS quite rightly protects the identity of those individuals from Emerald Hill and from Area9. Their single sign-on system generates a unique ID number for enrolees, but the client company can, of course, identify those individuals itself and follow up with more focussed learning and development if needed. From our point of view as trainers, we have been able to use aggregate data at a fine level of detail (for example, how long it took on average to answer a question or complete a quiz) to identify places where we can improve the course . Changes are automatically updated and are made available not only to new learners, but also to those who have already completed the course. Once enrolled a learner can access the materials for a refresh at any time .

Benefits of Adaptive Learning for Agile

Adaptive learning – like Agile product development itself - is geared for an age of accelerating, often seismic change. Skills gaps come and go, and companies have to fill them with new hires and/or the reskilling of existing staff. Compared to last generation e-learning it cuts training time in half and creates higher proficiency at lower cost . The personalisation of material means no-one is left behind . Adaptive Learning is scalable, personalized learning.

From the learner’s perspective, boredom is largely eliminated and their engagement is intensified. Retention and reinforcement of key ideas are vastly improved.

Adaptive learning is especially strong in targeting ‘unconscious incompetence’ or what the learner thinks they know but really don’t . One immediate payoff in the Scrum Fundamentals course is a common vocabulary across the cohort that is taken straight into workplace practice. Confusion about terminology and what the Scrum framework is, and what it isn’t, is eliminated.

Learners have used our course in different ways:

· As a standalone course increasing their knowledge of Scrum and agile practice

· As a preparation for in-class training (for our Certified Scrum Master and Certified Scrum Product Owner courses, for example)

· As a tool for revision in preparation for taking Scrum Alliance’s Certified ScrumMaster (CSM) or scrum.org’s Professional Scrum Master (PSM) examinations.

Based on the extraordinary success of these trials we, at Emerald Hill, will be expanding our portfiolio of Adaptive Learning courses for Agile product development and Business Agility. Keep an eye out for new announcements in the near future.

To learn more, contact maria@emerald-hill.co.uk

(1) https://www.emerald-hill.co.uk/adaptive-learning22909ce1

(2) https://scrumguides.org/scrum-guide.html

(3) https://area9lyceum.com

Mark Twain, Nancy Sinatra and the Agile Straw Man

0017404279 (A O'CALLAGHAN) — Tue, 24 May 2022 13:57:56 GMT

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

Fri, 13 May 2022 08:00:20 GMT

An Interview with Alan O'Callaghan

Q: You have championed instructor-led training, mentoring and coaching for Agile

development for nearly a quarter of a century. But your company, Emerald Hill Limited,

has just released an Adaptive Learning course on Scrum Fundamentals. Is this a change of

heart?

AOC: Not at all. Context is 95% of the issue with Agile training. Every team is working in its own context, and experiences changes which are specific to it, so the personalised intervention of experienced coaches, mentors and trainers is critical to success.

Q: So why have you chosen now to release what is essentially an e-learning course?

AOC: The world of work is experiencing seismic change. Across the business landscape, autonomous cars, robotics, artificial intelligence (AI), the internet of things and other advanced technologies demands reskilling for the technology-enabled workplace. The COVID-19 pandemic has acted as a forcing function, exposing dysfunctions and flaws in the structure, processes and culture of organizations. As a result many are urgently switching to Agile for the first time, or looking to speed up their acquisition of Business Agility.

On top that there is the Great Resignation. I read the other day that 46% of workers in the Netherlands, for example, plan to change jobs in the next 18 months. It’s not a Dutch phenomenon. This reshuffle of the workforce is happening globally, and placing greater demands on the L&D functions in organisations whose staff – or at least a large part of them – might now be working remotely.

How do you scale learning and development in that situation, and how do you ensure Return on Investment in training when the labour market is so mobile? Learning that can acquired at a pace determined by the learner, content that be accessed at any time, any place, on any device is an essential part of the toolkit for upskilling at scale.

Q: But how does that fit with Agile training given what you’ve said about the specificity of

the issues organisations, teams and individuals face?

AOC: There are some invariants. The Scrum framework, for example, is composed of essentially two building blocks: a rigorous, time-boxed inspect-and-adapt cycle designed to surface new information during product development, and a self-organising Scrum team authorised to take action on that information. The rules of Scrum – the roles, the events and the artifacts- are mandatory in any situation if you are claiming to be using Scrum. They are what complexity scientists might call ‘enabling constraints’. They provide a lightweight structure which maximises the decision-making authority of the Scrum teams so that they can respond quickly and appropriately to the specific challenges they face.

The rules are the rules are the rules. They can be delivered through technologies such as Adaptive Learning. An organisation using Scrum can quickly scale that kind of training so that everyone in the organisation is Scrum-aware and is using the same vocabulary with a consistent meaning. New hires can be quickly onboarded and Graduate Training Schemes enriched. And, to be frank, it’s a lot cheaper to do it that way.

It is the application of the rules, not the rules themselves, which is where coaching and instructor-led training becomes important. Adaptive Learning does not substitute for or lessen the need for that kind of intervention. It complements it. But from the learning organisation’s point of view, personal interventions are relatively expensive so companies want to concentrate those resources where they are most needed: the training of ScrumMasters and Product Owners and the coaching of Agile teams, for instance. The additional benefit for the coach and the trainer is that they can leave the ‘basics’ if you like to Adaptive Learning or other kinds of e-learning and concentrate their efforts on the more interesting and challenging stuff they need to get across.

Q: You’ve mentioned Adaptive Learning a few times now. How does it work?

AOC: You can think of Adaptive Learning as a kind of personalised e-learning on steroids. We’ve partnered with Area9 Lyceum which is the global leader in Adaptive Learning and use their cloud-based platform, Area9 Rhapsode TM . A registered learner can sign in at any time, from any place on any device.

You start by assessing your level of understanding anywhere from ‘novice’ to ‘expert’ and the platform will start by presenting you with selected content based on that assessment. Broadly speaking, if you are an expert you’ll get mainly probes – questions in various formats- before you are presented with any training content. Novices will see content first and their understanding gets tested later. There are multiple probes for each learning objective. After each one you answer you will be asked for your level of confidence in your response. Using the latest AI algorithms the program adapts according to your progress, only presenting you with the material that you do not yet understand. And it does so repeatedly, in different ways, until you demonstrate mastery. You are more likely to be

engaged as a learner because you won’t be bored by being presented with stuff you already know. Research shows that with this technology you can achieve 100% comprehension in half the time it would take using last-gen e-learning, and that the effort required to retain what you have learned is 90% less.

Q: I know Emerald Hill Limited tested this technology for two years before committing to

it. What impressed you most about Adaptive Learning?

AOC: That’s easy. Every Agile instructor, coach, trainer or mentor who has been doing the job for more than five minutes is aware that there are tsunamis of myth and misinformation that constantly threaten to drown the essential ideas of Agile development. Some of it is even peddled by big name consultants. You know what I mean: “Agile is about working faster, harder by adopting practice X or practice Y”; “ScrumMasters are kinds of Project Managers”; “Product Owners are not Scrum Team members”. That kind of rubbish. They become major obstacles to success when learners hold those myths and believe them to be right. Psychologists call this “unconscious incompetence”. It’s the gap between what you think you know about a subject, and what you actually know. Area9’s data shows that learners in any subject are typically 15%-40% unconsciously incompetent. It’s probably a higher figure for professionals learning Agile ways! Area9 Rhapsode TM targets this really effectively. Each learner gives herself an assessment of her confidence in her answer to each probe. That input is combined with other data about the learner’s interaction with the system -for example how long it took to provide an answer- and analysed in real time to determine what content should be presented next. Area9 refer to their biological model that mimics the way viruses behave in nature, evolving moment-by-moment using trial-and- error as their environment changes. Agilists call this “inspect and adapt”. It’s a perfect fit.

Q: So tell us about the Scrum Fundamentals course…

AOC: It’s composed of four modules: Scrum Theory, Scrum Roles, Scrum Artifacts and Scrum Events and covers all of the learning objectives set out in Scrum Alliance’s Scrum Foundations certificate. There are 49 fine-grained learning objectives and well over a hundred probes associated with them which means learners can take the course in very small chunks at their own pace. Individuals can sign up for the course for £100 +VAT. Group discounts are available for 4 people or more.

Q: Does the Scrum Fundamentals course lead to any recognised certifications?

AOC: On completion you receive a certificate of completion from Emerald Hill. Optionally – and at no extra cost – you can acquire Scrum Alliance’s Scrum Foundations certificate by attending an online session with me, booked through Emerald Hill Limited. Since the learning objectives form part of the wider objectives of Scrum Alliance certification courses you also get a voucher for a discount on either a Certified Scrum Master (CSM) or a Certified

Scrum Product Owner (CSPO) course delivered by Emerald Hill to be taken within 6 months of completion of the Adaptive Learning course.

Q: How long does it take to complete the course?

AOC: No individual is the same as another and Adaptive Learning is, as we’ve said, highly personalized. Not only will learners engage with the course at their own pace, but how much material they are presented with will differ according to the platform’s assessment of their understanding. However, there is about two and a half hours of content. Understanding is constantly probed throughout and refreshed until 100% comprehension is achieved.

Q; Finally, How can an organisation take best advantage of Adaptive Learning for Agile

Development?

AOC: Organisations can purchase credits for multiple seats for any Emerald Hill Adaptive Learning course. We’ve got new titles in the pipeline to do with User Stories, Story Mapping, Kanban and so on, plus some management-focused courses on Business Agility. Alternatively our content can be integrated into an organization’s Learning Management System (LMS) via Area9 Rhapsode TM and “white labelled” under license so that is presented in the colour scheme, style and logo of the host company. Depending on the pricing agreement unlimited numbers can access unlimited courses. Any updates to Emerald Hill content would be immediately available to all learners. Integration and white labelling is an economic solution to scaling that supports onboarding of new hires as well. Anyone wanting to explore the possibilities should contact maria@emerald-hill.co.uk to learn more.

Follow Emerald Hill Limited at https://www.LinkedIn.com/company/emerald-hill-limited/

Alan O’Callaghan is a Certified Scrum Trainer (CST) and Principal Product Owner at Emerald

Hill Limited. He is also a member of the Scrum Patterns Group, the Agile Fluency® project and

the Business Agility Institute. He is a contributory author to two influential books on Agile: A

Scrum Book: The Spirit of the Game by Jeff Sutherland, James O. Coplien and the Scrum

Patterns Group, and 97 Things Every Scrum Practitioner Should Know, edited by Gunther

Verheyen.

Follow Alan at https://www.LinkedIn.com/in/alanjocallaghan/

Adaptive Learning

0017404279 (A O'CALLAGHAN) — Wed, 20 Apr 2022 13:36:14 GMT

How Can Your Organization Quickly Scale Agile Learning and Development?

Since the start of the pandemic the urgency of Agile transformations has never been more clear. Unpredictable market dynamics and supply chain disruptions have moved ‘Agile’ from being a possible option to an urgent imperative. The Business Agility Institute measured a 15% increase globally in Business agility within the first few months of the COVID-19 emergency and it has accelerated since. The change is not confined to software engineering and IT. Heavy manufacturing, pharmaceuticals and support functions like HR and legal are seeing surges in the adoption of Agile. Just one big player in any given sector moving to increase their Business Agility causes a domino effect it would seem. No-one wants to be left behind. As W. Edwards Deming once said, “It is not necessary to change. Survival is not mandatory”.

Paradigm Shift

You have heard Agile being described as a ‘paradigm shift’, but what does that mean? Well, the BAI describes Business Agility 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.” The emphasis is in the original statement (1). Agile product development has never been primarily about faster implementation and execution of existing processes. These act as comfort zones – bubbles that need to be burst if an organization is to become fluid enough to respond to unanticipated changes. The paradigm shift will, for sure, be concretized in new and evolving practices but these are manifestations of changes in behaviour, in individual and collective mindsets, in organizational culture and organizational structure – at the centre of which is the concept of the self-organizing team. In combination these factors constitute a perfect storm that is fundamentally disruptive to traditional ways of working. Such a shift is not achievable without significant investments in training, mentoring and coaching.

Scaling Learning at Speed

A problem for any large organization that now sees itself as being behind the curve is how to do this quickly. A global brand in telecommunications, say, might have upwards of 30,000 engineers; an international bank maybe has 140,000 employees. The problems they have in scaling learning and development are just magnifications that many mid-size companies and even small organizations face. The well-established certification programmes, Scrum Alliance’s Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) for example, are too expensive to put an entire workforce through even with the generous discounts that are available for private group delivery. On the other hand, traditional e-learning is a poor substitute especially for those important roles in an Agile team. And training, though necessary, is insufficient on its own. To create new flexible work patterns and habits – to truly embrace change – requires coaching. There are currently 10,000 unfilled vacancies for Agile coaches in the USA alone. Scrum Alliance has set itself the target of having 5000 certified Agile coaches by the end of 2025 and for 50% of all advertised vacancies to be for certified coaches by that date. They have also partnered with the International Consortium for Agile (ICAgile) and the BAI to fast-track the professionalisation of Agile coaching.

The Promise of Adaptive Learning

So clearly any Learning and Development strategy for increased Business Agility will require coaching as well as training. And we should add mentoring to the mix. Mentoring is the direct transfer of experience from those who have used Agile at the coalface to the new folks. Incentivizing the early cohorts who have benefitted from training and/or coaching to downstream their experience to the wider organization is also important.

But – back to the training issue. How do you economically train significant numbers of professionals to kick-start the transformation? And how do you support new hires who join after the initial wave of learning and development? How do you ensure sufficient time is devoted to knowledge acquisition without negatively impacting on in flight product development or support projects? E-learning’s attractiveness lies in that it can be delivered in bite-size chunks, on demand. Its downside is that it tends to be a one-size fits all approach which can demotivate staff who can feel patronized if forced to go through material they all ready fully understand, and its impact on individual learners is difficult to assess.

Enter adaptive learning. What is adaptive learning? Well, you could consider it as personalized e-learning on steroids. Like last-gen e-learning the material can be digested at the learner’s own pace and, if needed, in their own time. But more importantly, it uses AI algorithms to decide what material needs to be presented. Learners self-assess their current knowledge on a scale between novice and expert, and then the platform probes their understanding. Each exercise requires students to assess consciously how sure they are of the answer they have given. AI then determines what material is presented based on the responses to the probes. Studies suggest that Adaptive Learning reduces the time for first-time learning by 50% compared to traditional E-learning, and that there is 90% less retention effort involved on behalf of the learner. Because the system constantly probes and reassesses understanding, 100% proficiency can be achieved and progress towards it audited.

Emerald Hill Partners with Area9 Lyceum

Emerald Hill has partnered with the Area9 Lyceum, a Danish company that is the market leader in Adaptive Learning to provide a series of Agile courses, the first of which will be launched in May. Adaptive Learning provides a perfect complement to our existing Scrum certification classes. Instructor-led, role-based training remain essential, especially for prospective ScrumMasters and Product Owners. Every Agile team, in every organization faces unique challenges in its own particular context. In-class or remote instructor-led courses (typically 2 days in length) equip professionals best to deal with these issues. But there are also some invariants in Agile training: the rules of the Scrum framework – the events, artifacts and roles within a Scrum team) are mandatory if you are ‘doing Scrum’, independent of context. It is in these areas where we believe adaptive learning can provide massive value to our clients.

Adaptive learning can help create widespread ‘Agile awareness’ quickly at scale; provide a steppingstone to the richer, instructor-led programmes and establish a common vocabulary across an organization no matter how big it is, or how widely it is distributed geographically. Adaptive learning is part of Agile’s future without a doubt.

(1) Business Agility Institute. “What is Business Agility?”. http://www.businessagility.institute

What Kids Can Teach Us About Teams

0017404279 (A O'CALLAGHAN) — Wed, 20 Apr 2022 13:36:08 GMT

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?

Mon, 13 Nov 2017 11:06:32 GMT

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

Tue, 06 Jun 2017 13:54:00 GMT

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?

0017404279 (A O'CALLAGHAN) — Tue, 25 Apr 2017 00:00:00 GMT

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.

Don’t Let Governance Threaten Your Agile Transformation

0017404279 (A O'CALLAGHAN) — Fri, 24 Mar 2017 15:13:18 GMT

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.

How to Get Your Teams to Estimate Better

0017404279 (A O'CALLAGHAN) — Mon, 20 Mar 2017 13:52:23 GMT

“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.

What Does it Mean to be “Ready”?

0017404279 (A O'CALLAGHAN) — Wed, 01 Mar 2017 00:00:00 GMT

“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.

Is Kanban Always a "Pull" System?

0017404279 (A O'CALLAGHAN) — Tue, 21 Feb 2017 00:00:00 GMT

The pushmi-pullyu (pronounced “push me-pull you”) is a fictional creature in “ The Story of Doctor Dolittle ,” which is described as a cross between a gazelle and a unicorn.

Recently, I was talking with a fellow software professional about some issues he was having implementing Kanban, and the pushmi-pullyu came to mind. Allow me to explain why.

Kanban’s Popularity

Kanban is the most popular agile approach after Scrum, according to the most recently published State of Agile Survey . Scrum is, of course, massively dominant.

Only 5 percent of respondents described their teams as Kanban teams, while three-quarters used either Scrum, a Scrum hybrid or Scrumban. However, when asked what techniques they used, nearly four in every 10 teams said that they use Kanban boards.

This is might be an exaggerated figure since, in my experience, many people confuse Kanban boards with Scrum boards. They look similar, but have very different purposes.

While a Kanban board maps a value stream for the lifetime of the product, a Scrum board is a visualization of a sprint backlog, and is reset at the beginning of every new sprint.

Additionally, the Scrum board is owned by a single Scrum development team, while Kanban is agnostic about who owns the board. These differences turned out to be at the heart of the issue that my colleague raised with me.

How Do You Do JIT Requirements?

0017404279 (A O'CALLAGHAN) — Thu, 16 Feb 2017 00:00:00 GMT

“What is the difference between an up-front requirements document and a fish?” said Gollum, hoping to catch the Hobbit out with his riddle. But Bilbo Baggins, though a Halfling, was an experienced Agilist. He knew the answer. “A fish rots from the head down, “ he said, “but a requirements documents rots from the bottom up”. “Curses!”, screamed Gollum, “You cheats us”. But Bilbo wasn’t cheating. He was just drawing on experience.

Detailing all of the requirements out up front is a colossal waste of effort in the development of software products. The average churn after the document has been signed off is said to be about 35%, although most software professionals when I ask them to give an estimate, tend to give me a much higher figure . In any case the point is, that by the time the requirement is reached, there’s a good chance it will have either significantly changed or disappeared completely from the To-Do list. The effort spent in eliciting needs, analysing them and documenting the system requirements that meets those needs has been wasted. That in turn entails a cost: the salaries of the professionals involved for a start. And now at least part of that effort and cost has to be spent again in understanding the new situation.

Eating in the Scrum Café

0017404279 (A O'CALLAGHAN) — Mon, 13 Feb 2017 12:16:12 GMT

(The Role of the Product Owner)

(Originally posted 2014)

I have recently been reading The 7th Annual State of Agile Survey (1). It has some interesting statistics. Not surprisingly, Scrum is still the dominant approach in Agile projects by a country mile. 54% of respondents use Scrum and another 11% use a Scrum/XP hybrid. The named approach with the highest reported penetration after that is Scrumban with just 7% of 'the market'. The results concerning the role of the Product Owner were much more concerning, only 51% of respondents reported that they have a dedicated Product Owner and, most worryingly of all, Product Owners are listed at the bottom of those who are most knowledgeable about Agile in their companies (only 1% of respondents chose the Product Owner).

These figures just don't add up. The Product Owner function is one of the three key roles in Scrum. You cannot truly be using the Scrum framework if there is no Product Owner in your Scrum Team, and you certainly will not be as high performing as you can be if the Product Owner does not understand Agile (let alone Scrum). So what's the problem?

Ensuring the Value of the Product

Perhaps a clue to at least part of the explanation can be found in a comment made to me recently, "The Product Owner is a kind of a waiter, yes?". For the commentator - at a client's site - the customer raises requirements just like the customer in a cafe or a restaurant. The development team, like the kitchen staff, create the solution. The Product Owner is, like the waiter, a go-between who informs the kitchen (development team) of the order and then delivers the meal (product) to the customer's table. If that was all the Product Owner had to do then there might be a good reason for either having no-one in the job at all, or rebadging some existing function (a Business Analyst, perhaps) without developing in them any special skills or knowledge about Agile.

But in Scrum, the Product Owner is responsible for the Return on Investment (ROI) in the product, and the Total Cost of its Ownership (TCO). She has to ensure the value of the product to the customer, and the value of the work done by the development team. This is a heavy responsibility: Ken Schwaber once described the Product Owner as "the one wringable neck" in the Scrum Team (2).

For sure, when the customer is not directly accessible by the developers, the Product Owner acts as a customer proxy, but to play even that aspect of the role properly requires the Product Owner to be proactive in creating an intensive collaboration with the customer to understand their Business Value Model. This is so that the relative value of the different features being requested can be understood and communicated to the developers.

Ordering Product Backlog Items vs ‘Prioritising’ Them

Many organisations understand that at least, but there is an even deeper aspect to the role of the Product Owner that has not been grasped so well. When Schwaber and Jeff Sutherland revised The Scrum Guide in October 2011 (3) they removed the references to 'prioritisation' in relation to Product Backlog Items (PBIs) and the Product Owner's responsibility for them. In too many projects this had been interpreted as the Product Owner categorising PBIs by value ('High, Medium, Low or using MoSCoW rules or something similar) and then leaving it up to the Development Team to decide what the build order of the PBIs should be in any given iteration or release. The Guide now talks about the Product Owner's responsibility for ordering the PBIs in the Product Backlog 'top to bottom'.

What is the significance of this change? Of course, the Product Owner is still seeking to get higher valued features delivered earlier than lower value ones. This typically will involve some categorisation of PBIs by value. But the Product Owner also has to take on, amongst other things, the push back from the Development Team about technical dependencies between those features, and from other stakeholders, such as System Architects, who might be pointing out some architectural issues, especially in legacy systems. Another consideration is that what the customer will expect to be seeing in any Sprint Review is not a collection of discrete "done" elements, but a small and skinny version of the product as a whole to which more 'flesh' can be added in later iterations. Any one of these concerns could lead to lower value features being bundled together with higher value ones in any given Sprint Goal.

Intense Collaboration

The point is that the intense collaboration that goes on between the customer and the Product Owner is married with an equally intense collaboration between the Product Owner and the Development Team. The Product Owner is right at the centre of some of the key relationships that make the whole thing work. It is a hugely demanding role, and one which is strategically important to the success of any Scrum-driven project.

The intensity of the collaborations does not diminish, by the way, as the project progresses. The Product Backlog is not ordered top-to-bottom once and then left alone. The weight of any of the factors that led to the initial decisions can change, and other unforeseen ones emerge, as the Scrum Team surfaces new information through the development process itself. The ordering of the Product Backlog is therefore being constantly revisited, and constantly changed as the Team, and the project's stakeholders, learn more. But remember, only the Product Owner has the authority to make those changes to the Product Backlog.

The Importance of the Product Owner

If you think about it, the ordering of the Product Backlog in Scrum is the equivalent of the 'critical path' in traditional, plan-driven management of software projects. Project Managers in those projects spend time and effort sequencing activities in such a way that the dependencies between them lead to the shortest possible sequence - the critical path. This in turn determines the ordering of the work by the developers and the scheduling of other resources. In Scrum the Development Team is cross-functional, self-organising and self-managing. No-one can tell it how to do its work. The need for managing sequences based on different activities carried out by different specialists in those activities is gone. Instead the developers self-organise around the order of the PBIs in the Product Backlog by carving out a Sprint Goal from the top that is within their capacity for development in a single Sprint. And the Product Owner 'owns' the Product Backlog. That's why the Product Owner role is so important.

It is also the Product Owner who determines when enough value has accumulated in the product for it to be released, and the Product Owner who, alone in a Scrum Team, has the authority to cancel a Sprint for whatever reason. In addition, of course, it is the Product Owner who forms an agreement about the quality standards of the project with the developers in the shape of the Definition of Done

Now, what waiter tells the kitchen when there's enough of a meal on the plate for it to be served? Or negotiates with the chef and the cooks about the quality standards of the food? In what restaurant does the waiter dictate the order in which the food items will be created?

We will talk more about the role of the Product Owner and the Product Backlog in future articles, but hopefully even in this short space we have established that the Product Owner function is one that deserves respect and attention. Product Owners in Agile teams need the authority and responsibility to do the job properly, and that means their skills have to be developed - through training, coaching, mentoring and experience - to the appropriate level. Organisations that ignore or neglect the role of the Product Owner are just storing up problems for themselves in the future.

Alan

Emerald Hill Limited

www.emerald-hill.co.uk

References:

(1) 7th Annual State of Agile Development Survey. VersionOne. www.versionone.com . 2013

(2) Schwaber,K. The Enterprise and Scrum. Microsoft Press. 2007

(3) Schwaber K., and J. Sutherland. The Scrum Guide. www.scrum.org . October, 2011

Scrum Guide Update – Scrum’s Five Values

0017404279 (A O'CALLAGHAN) — Thu, 09 Feb 2017 00:00:00 GMT

You might not have noticed, but The Scrum Guide was updated recently (July 2016) for the first time in three years. The changes aren’t big in terms of word count, but they are significant. So I decided I needed to update my own description (1, 2) of the Guide’s evolution.

Cumulative Flow Diagrams

Let’s deal with the smallest change first. Cumulative Flow diagrams (CFDs) have been added to the list of example ‘information radiators’ that a Scrum team might use to track its progress towards its Sprint Goal. CFDs are associated popularly with Kanban – though I think they started life in Feature Driven Development – so it might be a bit of a surprise to some to see them mentioned alongside burndown charts and task boards. Don’t worry though, it is just that – a mention. You don’t have to use any specific charts or diagrams to use Scrum, so there’s nothing fundamental being indicated here.

Scrum Values

The big change is a paragraph that reintroduces the five values of Scrum. They’ve been around since 2002 at least when they were described in a book by Ken Schwaber and Mike Beedle (3). They’ve never really gone away. Although they have not previously been mentioned in The Scrum Guide they have always been included in the curriculum for the Scrum Alliance’s Certified Scrum Master and Certified Scrum Product Owner courses, for example.

How Does Santa Do It? The North Pole’s Secret Organisational Recipe Explained

0017404279 (A O'CALLAGHAN) — Thu, 22 Dec 2016 00:00:00 GMT

My grandson, Finnlay, aged nearly 3, wants to know how Santa manages to make and deliver all the toys to all the children in all the world for Christmas. The answer “Christmas Magic” may be beginning to wear thin.

So here’s my new version. Santa does a lot of work through the rest of the year, long before we get to Christmas. He gathers all the information about which boys and girls are being naughty and which ones are being nice, for a start. Then he has to find out where they live, the size of their chimneys, and what toys they would like. Based on this information he has a list – which, of course, changes a lot as new information is discovered or older information goes out of date. The most important deliveries (to the children who have been most good) go to the top of the list. Santa wants to guarantee that the good kids (“Like you, Finn”, I say, fingers crossed behind my back) get their presents on time.

The Product Owner's Role in Team Building

0017404279 (A O'CALLAGHAN) — Thu, 27 Oct 2016 00:00:00 GMT

Self-organising, self-managing teams are at the heart of Scrum. Everyone knows that. Most people are clear that, as an agile coach, the Scrum Master bears the main responsibility for growing the team.

Less understood is the idea that everyone in a Scrum team has a role in team building if it is to be successful. Geoff Watts has written about how collaborative behaviour is a skill that has to be acquired individually by members of the development team.

But what about the product owner—what can she contribute?

Let’s segue into the world of team sports for clues to an answer. Jose Mourinho is possibly the most successful club coach currently in world soccer.

He has been a head coach since only 2002, and has spent two of the intervening years on gardening leave, yet his teams have already won an astonishing 24 titles in four different countries: Portugal, England, Italy and Spain. He has coached two sides, Porto and Inter Milan, to be European Champions.

What is it that he knows about team building that we don’t?

Just-in-Time Scaling Agile

0017404279 (A O'CALLAGHAN) — Wed, 20 Jan 2016 00:00:00 GMT

Scale the mindset before you scale the product development

Scaling Agile is a hot topic. Adverts for courses on SAFe (Scaled Agile Framework) and LeSS (Large Scale Scrum) seem to be everywhere. Then there is DAD (Disciplined Agile Development – from IBM) and Enterprise Scrum and a few more approaches just emerging. The first advanced certifications announced by ScrumAlliance are concerned with scaling Scrum.

On first thought there is a kind of inevitability about this. Agile has been steadily advancing into mainstream software development since about 2008, and the slower moving large organizations such as global banks, international manufacturers and service providers, and even Government organizations, having had a taste are now preparing to eat their Agile lunch. The knee-jerk reaction is: let’s scale our Agile operations, especially for those big projects we always have. But, even though I am a SAFe Program Consultant (SPC) myself, I have a sneaking suspicion that many scaling efforts are misguided, and generate more waste than business value.

A Restaurant Analogy

Let me begin by introducing a restaurant analogy. Recently for the birthday celebration of an extended family member, my wife and I, together with a mob of relatives and friends, ate at a chain eatery in Coventry, England near where we live. It is one of those places where you pay a single price and then eat as much as you like from an enormous buffet. Indian, Chinese and Italian specialties are included. There are also a grill, a roast meats station, and a dessert counter. Each station has its own specialist crew of kitchen staff. They make sure that there is a constant supply of food items to keep the counters fully stocked.

One of the attractions of this restaurant is that it is cheap, so I’m guessing there is a major pressure on keeping costs low. Why then, do they employ so many in the kitchen? The answer is because all of the different food items are needed both all at once and continuously. Now compare this to a much more up-market Indian restaurant that, as a couple, we more regularly favour with our custom. It has a small kitchen and a correspondingly small kitchen staff. True, its throughput of customers is not the same as the Coventry one, but it is usually packed, and it has many more menu items than the big eatery. In either place we might eat a starter, a main and a dessert, but in our Indian restaurant the chef is cooking to-order and can start on the mains even while we are eating our starter. The other place has to have all the potential elements of the meal on offer at the same time.

The World is Becoming Scrummier

0017404279 (A O'CALLAGHAN) — Wed, 06 Jan 2016 00:00:00 GMT

The State of Scrum

Hot on the heels of my response to Michael O. Church’s tirade against Scrum comes the State of Scrum report: the results of a survey conducted by the Scrum Alliance. There’s bad news for Mr. Church who looked forward to the early death of Agile and Scrum. Use of Scrum is growing exponentially, and developers love it. The world is getting Scrummier in all sorts of ways.

Scrum Alliance

Scrum Alliance is the largest single network of Agilists in the world and now has a membership in excess of 400,000. That’s a jump of 150,000 in just a few months. Nearly 5,000 people responded to their survey from 108 different countries, though three-quarters were from the US and Europe. 77% of those who answered work in software engineering or IT related jobs, although only 29% of the companies they work for are in the IT sector. Other industries prominently represented were Finance, Heathcare, Government, Telecommunications, Insurance and Education. The headlines of the survey results are that Scrum is growing, expanding beyond its use in IT, and is delivering success to customers and to the business. As a parting shot to Michael O. Church who insisted that Scrum was “terrible” for developers, let me point to the answers to the question about whether Scrum has improved the quality of the team’s work life: 87% responded that it had, 10% were unsure, and 4% said no. So, there you have it, Church is the champion of a tiny minority: Mr. four per cent

Read more at http://blog.learningtree.com/uk/world-becoming-scrummier/

Why Ranting that "Scrum is Terrible" is a Straw Man Argument

0017404279 (A O'CALLAGHAN) — Fri, 31 Jul 2015 00:00:00 GMT

A Reply to Michael O. Church

My good friend and colleague at Learning Tree, Doug Rehnstrom, sent me a link last month to a blog post by Michael O. Church entitled “Why ‘Agile’ and especially Scrum are Terrible” . My first reaction to it was that it was an entertaining if misguided rant, but in retrospect Michael says some important things. He talks of companies that have been “killed” by Scrum, and complains about what he calls the “humiliating transparency” required of programmers who he claims are treated as “interchangeable, commoditized components” by Agile. He makes the claim that Agile…”has engineers still quite clearly below everyone else: the ‘product owners’ and ‘scrum masters’ outrank ‘team members’, who are the lowest of the low.” Technical debt piles up in Agile organizations, he tells us, and is not addressed, and wraps all this up as a conspiracy theory in which Agile/Scrum “eradicates even the possibility of work that’s acceptable for a mid-career or senior engineer”, part of an age-discrimination culture aimed at “chasing out our elders”. As a 60-year old who has been a software engineer for most of my working life, and has been using Scrum for seventeen years, and who is yet to be chased out of the industry, I would like to respond.

Should I Pursue Certified Scrum Product Owner (CSPO) Certification?

0017404279 (A O'CALLAGHAN) — Fri, 10 Jul 2015 00:00:00 GMT

Why you should invest in your Product Owners

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.

Using Scrum? Get Certified

0017404279 (A O'CALLAGHAN) — Sat, 30 May 2015 00:00:00 GMT

The Case for ScrumAlliance Certification

It is always amusing for a speaker of UK English to hear an American professional declare that they are certified. To be certified in the UK means that a Doctor or a social worker has committed you to a centre for the treatment for mental illness. The Oxford English Dictionary term for professional qualifications is ‘certificated’. Scrum certification is a hot topic, and will increasingly become so, as Agile development becomes more and more mainstream. So, if you are a practitioner of Scrum, should you be certificated, or should you be certified for even asking the question?

The Scrum Alliance

I’ve been practising Scrum formally since 1998. I say formally because I’d been working for a while previously on organizational patterns with Jim Coplien. Organizational patterns form one of the roots of Scrum and, arguably, an article Jim wrote in Dr. Dobbs Journal twenty years ago was the first one on Scrum’s principles. It was Martine Devos who introduced me to Scrum as we know it today at the 1998 OOPSLA convention. There were no Scrum professional qualifications in those days. Certified ScrumMaster (CSM) appeared for the first time with the founding of the Scrum Alliance in 2007. CSM was introduced in order to give organizations seeking Capability Maturity Model (CMM) level 3 accreditation the evidence they needed to show that they trained people in their chosen process.

When Scrum certifications came out I wasn’t interested, frankly. I was working for an organization (a British University) that wasn’t interested in CMM. I had been practising Scrum for nearly a decade and neither I nor my employers were particularly excited by the thought of paying a thousand dollars or so for me to go on a Scrum Alliance validated training course in order to learn about what I already knew.

CSM, CSPO and CSP Certifications

That was then. This is now. I became a Certified Scrum Product Owner (CSPO) in May 2011 after attending a training course delivered by my good friend, Martine Devos. It kind of closed the circle to have the woman who introduced me to Scrum train me for CSPO. CSM and CSPO are the two ‘entry level’ Scrum certifications offered by Scrum Alliance and attending a training course delivered by a Scrum Alliance Certified Scrum Trainer (CST) is still the only way to get either of them. Less than 5 months later I became a Certified Scrum Professional (CSP), a qualification that acknowledges my experience in using Scrum in practice. I have maintained those qualifications ever since, as well as adding others (Project Management Institute Certified Agile Practitioner (PMI-ACP), Professional ScrumMaster and SAFe Program Consultant)

So, what happened? Did I go mad sometime between 2007 and 2011?

Scaling Agile: Is it The Next Big Thing?

0017404279 (A O'CALLAGHAN) — Mon, 30 Mar 2015 00:00:00 GMT

“What’s the next big thing in Agile?” is a question I’ve been asked a lot over the years. Answering used to make me a feel a little awkward. It was almost as though the questioner is treating Agile as a fashion, one that includes many fads. My usual answer has been, “Whatever your team decides to make it” reflecting my deeply-held conviction that Agile in general, and Scrum in particular, is fundamentally about self-managing teams. More recently though the tone of the question has been different, and has reflected the fact that there are people now with real track records in applying Agile approaches to software development, and they have a real thirst for more learning. So, when the question was asked of me for the umpteenth time recently, I found myself answering “The next big thing is scaling Agile”.

What Does It Mean to Scale Agile?

Scaling Agile usually involves two things: developing products that require more resources than one small development team can supply, and making organizational changes to accommodate the approach. Let’s be clear, Scrum and eXtreme Programming (XP) both started with enterprise applications. There have always been big projects that have used Agile, albeit a small minority of them, but now the software development community has reached a stage – or at least is rapidly approaching it- when the use of Agile for big projects will be the norm.

Dr. Who, the TARDIS and Scrum

0017404279 (A O'CALLAGHAN) — Fri, 12 Dec 2014 00:00:00 GMT

Why Scrum is bigger on the inside than it appears on the outside

The BBC’s Dr. Who is one of the most popular TV science fiction series world-wide. I recently took advantage of a trip to a client’s site in Cardiff Bay to visit the Dr. Who Ex perience there, and found myself drawing analogies between aspects of the series and Agile development. I’ve been a fan since I watched the very first Dr.Who episode in November 1963. What hooked me in that first broadcast was the moment when William Hartnell, the actor who played the first Doctor (the incumbent, Peter Capaldi is the twelfth) revealed to his first companions, Ian Chesterton (played by William Russell) and Barabara Wright (Jacqueline Hill), that the Tardis is bigger on the inside than it is on the outside. Tardis stands for Time And Relative Dimensions in Space and is The Doctor’s time-travelling spaceship. Bigger on the inside than it appears on the outside? Scrum is like that. Let me explain.

Bigger on the Inside

The Scrum framework is a very simple set of rules, easy to memorize and easy to understand. Elsewhere I’ve referred to it as the 3-4-5 rule (1): three roles (Scrum Master, Product Owner and Development Team); four artifacts (Product Backlog, Definition of Done, Sprint Backlog and the increment of Potentially Shippable Product) and five Events (the Sprint, the Sprint Planning Meeting, the Daily Scrum, the Sprint Review and the Sprint Retrospective). There are rules governing the interrelationship of these essential elements, of course, and these are spelled out in The Scrum Guide (2).

Where Do BAs Live in the Agile Ecosystem?

0017404279 (A O'CALLAGHAN) — Wed, 05 Nov 2014 00:00:00 GMT

Business Analysis and its place in Scrum

“Where do Business Analysts live in the Agile ecosystem?”, or some variant of this question, is probably the one I am most often asked in my consultancy engagements. It pops up at different times in different places in different Agile adoption initiatives. But almost invariably it will be asked.

Why? Well for a start, the Agile model is supposedly business value-driven. Traditionally, this is the province of Business Analysts. Yet, as a recent book has noted, in the early days at least there seemed to be only two roles: the programmer and the customer (1). In Scrum there are only three roles: the Scrum Master, the Product Owner and the Development Team. Where, oh where then, does the Business Analyst fit in? This is an especially sharp question if BA is your job title, of course, but it is also one of general importance.

The Product Owner Myth

Perhaps we should start with the guess that many people make at the beginning: “The Product Owner is a Business Analyst”. If this means the Product Owner is someone who – at some level – performs business analysis as an activity, I have no objection. The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. That responsibility cannot be executed without a pretty deep understanding of the customers “business model”. But if they are referring to the Business Analyst as a job description then I begin to worry. It is often a clue that the Product Owner role has been misunderstood, and/or that the there is some idea that the Development Team should be getting requirements from someone other than the customer (i.e., by some intermediate professional).

Collapsed Scrum

0017404279 (A O'CALLAGHAN) — Mon, 03 Nov 2014 00:00:00 GMT

Saving a Scrum initiative

There is nothing more dangerous in the game of Rugby Union than the collapsed scrum. Think of it. Eight hunking great forwards (many sporting flattened noses and cauliflower ears that advertise their experience of scrums) on one team collide, head on, with an equal number of monstrously-sized opponents from the other team in an attempt to get control of the ball. If the initial engagement is not carefully synchronized by the referee then the scrum can collapse, potentially causing serious injury to one or more of the participants.

Collapsed Scrum is bad news in Agile product development too. Thankfully it is rarely Scrum team members who get injured. But the product is certainly at risk, and perhaps even the agile adoption initiative. Its immediate consequence is the failure to deliver the results expected.

Nature of the Problem

What causes collapsed Scrum? As in the game of Rugby it is often the initial set up which triggers the problem. Either through misinterpretation of the rules, or an unwillingness to follow them, the Scrum team is created without the appropriate roles, responsibilities or events needed to properly implement the fast feedback cycles and inspect-and-adapt behaviors that drive success.

Scrum: Going Wider and Deeper

0017404279 (A O'CALLAGHAN) — Wed, 09 Jul 2014 00:00:00 GMT

Scrum advances at pace

Despite the occasional claim that “Agile is dead!” and announcements of Scrum being past its selling date, all the available evidence is that it is gathering ground: going wider and deeper. I have had the considerable pleasure of attending two events recently, both hosted by the Scrum Alliance. Whatever criticisms might be levelled at the Scrum Alliance, there is no doubt that Scrum’s dominance in the Agile community is in large part due to its efforts. The first of the two events was the Scrum Gathering at New Orleans from May 4th to May 7th. Evidence that Scrum’s reach is getting wider was provided by the fact that it was the largest global Scrum Gathering to date. 550 people attended, and 300 of those (myself included) were attending their first Scrum Gathering. That the Scrum community is diving deeper was demonstrated by the Scrum Coaching Retreat Europe, which took place in Teddington, London between June 9th and 11th, attended by 80 people – a quarter from outside the UK – wanting to understand better how to coach organizations in their adoption and implementation of Scrum.

Scrum at the Crossroads?

Linking the two events was the sense that Scrum – and Agile in the broad sense too – are at the crossroads. Part of Scrum’s past includes what might be called ‘Bad Scrum’. Bad Scrum takes many forms. ‘WaterScrum’ or ‘ScrumFall’ are when development activities that appear Scrum-like are either preceded by, or succeeded by practices that are decidedly linear and sequential, and the whole workflow is dominated by master-planning. In these situations we can confidently predict a number of things.

Targetting Your Investment in Agile

0017404279 (A O'CALLAGHAN) — Tue, 01 Jul 2014 00:00:00 GMT

The Agile Fluency Model Explained

I recently had the great privilege of attending a two-day Product Owners’ Survival Camp in London, organized by Gojko Adjic, Dave Evans, Christian Hassa and Chris Matts. Other camps are planned around Europe – if you get the chance I highly recommend it. Contact Neuri Consulting (1) for more information.

Over lunch on the first day I was talking to Christian Hassa about the issues many of Emerald Hill’s clients were facing – especially those I described as taking their “second wind” in Agile – and he asked me if I had seen James Shore and Diana Larsen’s Agile Fluency Model (2). I hadn’t. But I have now, and what an eye-opener it is!

Fluency

First, let’s park one possible misconception. What James and Diana have presented is not (another!) “Agile Maturity Model”. The point is not to badge Agile teams with one level of maturity – or indeed immaturity - or another, but to provide a guide to teams and organizations about where are with the Agile approach, where they want to be, and what are the trade-offs of costs and benefits that have to be considered in meeting their targets. For consultants like ourselves, and for training organizations, it helps focus our efforts with our clients in helping them overcome any impediments they are facing. If you browse the Emerald Hill website (3) you’ll see that we are already reorganising our services and marketing them along the lines of the Agile Fluency Model.

Fluency is measured by what teams do when under pressure. It’s what their “muscle memory” is. Fluency is not gained by merely knowing certain techniques, but by practising them intensively over time.

As you can see from the figure below, the Model uses a star system that goes from 1-star rising to 4-stars. James Shore has described a 1-star Team as one that is using the fundamentals of Agile. From the perspective of Scrum that would mean that the mandatory rules of Scrum are in place and are being operated. Then again, it might be that Kanban is being used, for example, if the team is not a Scrum Team. The test of whether a team is at least at the 1-star level is whether they have changed team culture to the point that they are business value-driven in their process, and can change direction when needed. It typically takes a team from between 2-6 months of practicing their chosen Agile approach to become a 1-star team.

1-Star and 2-Star Teams: Changing the Team

Sustainability in Agile requires 2-star Teams. Big investment in skills is needed for teams to be 2-star teams. Test-Driven Development, Acceptance-Test Driven Development and Continuous Integration are typical practices. The common theme is that these are the kinds of skills that eliminate the drag of technical debt, allowing the team to be truly responsive to change. 2-star teams typically identify impediments, dysfunctions and issues early, and are quick to remove them. They are characterised by an ability to ship on “market cadence” – i.e., to deliver value as soon as the market is ready to accept it: the ability to ship at will.

The model’s authors point out that many organizations will be satisfied at achieving 2-stars. Shore has since commented that most large, bureaucratic organizations – the kind that have heavyweight managerial cultures and IT that is predominantly legacy – will probably be unable to go further (4). But even getting to 2-star demands a price. The kind of intensive skills training required, together with the task of eliminating the previously accumulated technical debt will almost certainly cause a drop in the team’s productivity while they are upskilling. How fast they can become a 2-star team depends on the existing level of technical debt, but it can take a further 3 months to two years of training, mentoring and, above all, intensive practice before the necessary muscle memory is acquired.

3-Star and 4-Star Teams: Changing the Organization

Shore describes 3-stars as the level of “ Agile’s promise ”. In a rather damning aside he has stated that Agile promises 3-stars, but more often than not, has delivered only 1-star teams (4). 3-star teams are characterized by the level of business domain expertise that is embedded in the team itself. They deliver higher value than other Agile teams and make better, business value-driven decisions about the product. In retrospect many of the practices we were discussing at the Product Owners’ Survival Camp are of the kind that would be routine for 3-star teams. Chris Matts’ Feature Injection (5) is an approach that helps teams “hunt the real value”, for example, while Gojko Adzic’s Impact Mapping (6) allows the team to test assumptions in the business case for the product by shaping and releasing Minimal Viable Products that can provide quantifiable feedback with concrete business metrics. Such teams are equipped to be vastly more responsive to changing market conditions and business priorities than 1-star or 2-star teams.

Only about 1 in 20 Agile teams are thought to be at this level (45% of teams are 1-star and 35% are 2-star), and it might take a team an additional 1 year to 5 years to reach it (if indeed that is the target it has set itself). The issue is that structural changes in the wider organization are needed for this to happen, and this always engenders some level of resistance. How quickly a team might move to 3-stars depends on how willing the organization is to remove the impediments in its way, as much as it does on the team establishing new practices as part of its daily routine. Most of the teams currently at this level are in relatively small, entrepreneurial organizations.

If 3-star is the (largely unfulfilled) promise of Agile then 4-star is largely aspirational . It represents a potential future for the Agile Model and there are only a handful of teams at this level right now. 4-star teams are peer-decision makers with the entire organization as to how to deliver business value. You might say that they are applying “Agile Enterprise Architecture” in full partnership with everyone else in the wider organization. Most of the teams at this level are in small, single Team organizations, although Shore (4) has suggested that Semco, the Brazilian manufacturers; the US games company Valve; G.L. Gore, the makers of GoreTex and GitHub are potential hosts of 4-star teams. Nevertheless, there is not enough experience in the industry yet to say how a team might get from 3-star to 4-star or how long it might take.

Most 3-star teams will not even aspire to the 4-star level and this is the beauty of the Agile Fluency Model. It is not promoting an “OK, better, best” scale that managements will use to whip their software development teams with. Perhaps 15% of Agile teams are not even 1-star teams yet (maybe they have just started their Agile journey) and they should certainly seek improvement. But, beyond that, every level is the right level for some teams. My guess is that most will aspire to at least 2-stars, and the Model shows what the investment focus should be, and what the costs that will likely need to be paid to get there. It also demonstrates very clearly, that 3-star and 4-star teams cannot be grown without significant structural and cultural change in the wider organization which in turn often implies a change in management’s mind-set – even if it was management which initiated Agile adoption in the first place.

References

(1) Neuri Consulting LLP. www.neuri.co.uk

(2) J. Shore and D.Larsen. 2012 “Your Path Through Agile Fluency”. www.martinfowler.com

(3) www.emerald-hill.co.uk

(4) J. Shore. 2013. “Your Path to Agile Fluency” NDC Conference presentation. www.vimeo.com/68327316

(5) C. Matts and G. Adzic 2011 “Feature Injection: 3 Steps to Success” www.infoq/feature-injection-success

(6) G. Adzic. 2013. Impact Mapping. Making a Big Impact with Software Products and Projects. Provoking Thoughts Limited

Evolution of The Scrum Guide (Part Two)

0017404279 (A O'CALLAGHAN) — Sat, 28 Jun 2014 00:00:00 GMT

Changes to the July 2013 Edition

In the first part of this article we discussed the changes in the list of principle artifacts and events (timeboxes) that have taken place between the first publishing of The Scrum Guide in February 2010 and its current version, published in July 2013. We also discussed how the Definition of Done has evolved. In this second part we will be discussing issues that might be grouped under the heading “Sprint Goal”.

What is the Sprint Goal?

Let’s start with the basics. Products are built iteratively in Scrum. Each iteration, called a Sprint, creates an increment of product, starting with the most valuable and, often, the riskiest. Successive Sprints create additional increments which must be fully integrated with the previous ones. Each increment is a potentially shippable slice of the entire product. When the accumulated increments contain sufficient usability and value, the product is released by the Product Owner.

It is the Development Team’s responsibility to turn Product Backlog items into increments of functionality. The Sprint Goal is, in essence, the Scrum Team’s projection of what it expects to achieve by the end of the Sprint, given the information and available resources that it knows about at the time of the Sprint Planning meeting.

All versions of the Guide referred to the Sprint Goal within the section on the Product Backlog, but the two most recent versions then call it out separately in its own paragraph. All versions discuss the Sprint Goal having just stressed that only the Development Team can assess how much work, and therefore which Product Backlog Items (PBIs) can be done in the upcoming Sprint. It is after the Development Team forecasts which PBIs it will deliver in the iteration that the Scrum Team crafts a Sprint Goal. As the 2011 version says “The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the increment”. The latest (2013) version says the same thing, almost exactly. The earlier version is subtly different. It speaks of the Sprint Goal as a “statement”, not just an “objective” suggesting it should made explicit rather than implicit in the set of PBIs selected by the Development Team. It also states that the Sprint Goal is a subset of the release goal, while the 2011 refers to it being a milestone in the “larger purpose of the product roadmap”. The Sprint Goal can be both of things, of course, but – as we discussed in Part One of this article – the evolution of the Guide is in the direction of stripping out everything that is not mandatory in the Framework. Neither release goals nor product roadmaps are universally required by Scrum Teams, so all such references have gone from the 2013 version.

Coherency

Some curious language has entered into current version concerning the Sprint Goal, however. “The selected Product Backlog Items deliver one coherent function, which can be the Sprint Goal”, it says. That’s fine. That seems to me to be entirely consistent with the idea of the Goal providing guidance as to how the top-ordered PBIs (the ones to be worked on in the Sprint) fit together, and that notion has been around as long as The Scrum Guide itself. But what about the sentence that follows? “The Sprint Goal can be any coherence that causes the Development Team to work together rather than on separate initiatives.” That seems to me to be open to misinterpretation. I think that the authors are trying to address the situation that occurs when there is not a simple, single functional description that acts as an umbrella for all the PBIs that have been selected for the Sprint. This often happens with back-end, shared legacy systems which are being upgraded, for example. I’m pretty sure about what it is not saying. It is not saying that you can have a target which is non-functional. It is not saying, for example, that a coherent design in UML would make a suitable Sprint Goal. The need for potentially shippable increments of functionality at the end of every Sprint is not being overridden.

I must admit, I rather miss the clarifying example that was given in the original Guide: “…the goal for the above Sprint could also be: ‘Automate the client account modification functionality through a secure, recoverable transaction, middleware capability’. As the Team works it keeps this goal in mind.”

Wriggle Room

The 2010 document used the example to show that one of the aspects of the Sprint Goal (one often ignored in my experience) is to give the Development Team wriggle room regarding the functionality. As it works it implements the functionality and technology needed to implement the goal, but if it senses that it has overcommitted in terms of the selected PBIs it can negotiate a lower scope that stays within the general spirit of the Sprint Goal even with less functionality. Both the subsequent versions make the same point, but possibly less effectively. We might also mention here that the later versions dropped the term “commitment” when referring to the Team’s crafting of the Sprint Goal. Too many practitioners had interpreted this as some kind of contract, so that any Team that did not deliver all the PBIs selected were deemed to have failed. That was never the intention in Scrum. When a Scrum Team “committed” it was saying, given what we know now we think we can achieve this goal and we are going to “go for it”. But every Sprint turns up new information and new learning. The commitment to the Sprint Goal was never intended as a guarantee that it would be achieved. Such guarantees are impossible to give.

So, as we said at the top, the Sprint Goal is a projection of what the Scrum Team hopes to achieve by the end of the Sprint but not a guarantee. It is best framed in such a way as to give a coherent focus to the Development Team’s work, makes clear why the PBIs they are working on are needed, and at the same time provides a backdrop for any renegotiation of scope that might be needed mid-Sprint. Beyond that, whether the Team uses it as a subset of a release goal or a milestone in a product roadmap, or anything else is up to the Team to figure out. That’s the essence of self-management. That’s the essence of Scrum.

The Evolution of The Scrum Guide (Part One)

0017404279 (A O'CALLAGHAN) — Fri, 27 Jun 2014 00:00:00 GMT

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.