Thursday, October 29, 2015

Scaling Agile: LeSS

The Large Scale Scrum Framework
This is the third of six articles on approaches that try to help scaling Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The second article is about Disciplined Agile Delivery (DAD). This article will present Large Scale Scrum, or LeSS.

The creators of LeSS, Bas Vodde and Craig Larman, take a different approach to scaling Agile as DAD and SAFe do. LeSS is centered around Scrum. Scaling Scrum starts with understanding standard one-team Scrum. From that point, your organization must be able to understand and adopt LeSS, which requires examining the purpose of one-team Scrum elements and figuring out how to reach the same purpose while staying within the constraints of the standard Scrum rules.

Agile development with Scrum requires a deep organizational change to become agile. Therefore, neither Scrum nor LeSS should be considered as merely a practice. Rather, they form an organizational design framework.

The LeSS Frameworks

LeSS provides two different large-scale Scrum frameworks. Most of the scaling elements of LeSS are focused on directing the attention of all of the teams onto the whole product instead of “my part.” Global and “end-to-end” focus are perhaps the dominant problems to solve in scaling. The two frameworks – which are basically single-team Scrum scaled up – are:
- LeSS: Up to eight teams (of eight people each).
- LeSS Huge: Up to a few thousand people on one product.

LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:
- a single Product Backlog (because it’s for a product, not a team),
- one Definition of Done for all teams,
- one Potentially Shippable Product Increment at the end of each Sprint,
- one (overall) Product Owner,
- many complete, cross-functional teams (with no specialist teams),
- one Sprint.
- In LeSS all Teams are in a common Sprint to deliver a common PSPI.

The Large Scale Scrum Framework
The LeSS framework (click to enlarge)

What is so special about LeSS?

Large-Scale Scrum (LeSS) is Scrum applied to many teams working together on one product. Why LeSS? Similar to one-team Scrum. For large groups, LeSS tries to hit a sweet-spot balance between defined concrete elements and empirical process control. And just like one-team Scrum, LeSS is (1) lightweight, (2) simple to understand, and (3) difficult to master—due to essential complexity. A big part of the LeSS Practioner Course is about principles like Systems Thinking, Experiments, Lean Thinking etc, because that is the foundation of LeSS, and those need to be understood and used in order to implement LeSS succesfuly.

LeSS Principles
The LeSS Principles (click to enlarge)

Roles, Artifacts and Events

Sprint Planning Part 1 has the same maximum duration as in single-team Scrum, one hour per week of Sprint, but participation is limited to two members per team plus the one overall Product Owner. Let team representatives self-manage to decide their division of Product Backlog Items and end by identifying dependencies (perhaps with a dependency matrix) and discussing coordination.

Sprint Planning Part 2 is held independently (and usually parallel) by each Team, though sometimes a member of Team A may observe Team B’s meeting and make suggestions when there is a coordination issue between the teams.

Daily Scrum is also held independently by each Team, though a member of Team A may observe Team B’s Daily Scrum, to increase information sharing.Team representatives may hold an Open Space, Town Hall Meeting, or Scrum of Scrums several times a week to increase information sharing and coordination.

The Overall Product Backlog Refinement meeting is attended by two representatives per team and concentrates on splitting, lightweight analysis (e.g., only three examples per item if using Specification by Example), and estimation for upcoming PBIs. Use cross-team estimation to ensure a common baseline for estimation across teams.

Product Backlog Refinement: Similar to single-team Scrum, but for co-located teams, hold this at the same time in one big room with all team members present, with each team facing a separate wall with their own learning tools (whiteboards, projectors, …).

Sprint Review: Same as single-team Scrum but limited to two members per team plus the Product Owner and other stakeholders. Consider a “bazaar” or “science fair”-style phase during the middle of the Review: a large room with multiple areas, each staffed by team representatives, where the features developed by a team are shown and discussed. In parallel, stakeholders visit areas of interest and team members record their feedback. However, begin and end the Sprint Review with everyone in a common discussion to increase overall feedback and alignment.

Overall Retrospective: Maximum duration: 45 minutes per week of Sprint. Since the Team Retrospective ends the Sprint, this Joint Retrospective is held early in the first week of the subsequent Sprint. ScrumMasters and one representative of each Team meet to identify and plan improvement experiments for the overall product or organization.

How does LeSS relate to the other scaling approaches like SAFe, DAD, Nexus?

This question will be part of every article but not answered by me. I will try to find quotes from the author(s) of the framework regarding this question. In the final article, where I will compare all the frameworks, I will give my own opinion.

On the Blog of the LeSS website there are two posts dedicated to explaining the main differences between LeSS and Safe. Comparing LeSS and Safe, Part 1 and
Comparing LeSS and SAFe part 2 - Scaling Agility or Bureaucracy. Summarized it comes to the following:

SAFe and LeSS target into two different local optimums, each having a consistent set of practises, structures, skills, technology and culture. This has an analogy to species in nature. Grass-eaters and predators have different combinations of characteristics. SAFe is not aiming to reduce the Bureaucratic control enough to move the organisation away from the Traditional optimum. Instead, it tries to optimise the existing organisation by creating Lean-Agile programs. The project/program management is an old mainstream practise at this optimum. LeSS aims to reduce significantly the Bureaucratic control. It provides a mutually consistent set of practises that move the large organisation to a new Agile-optimum. 

Are there well-documented use cases of companies using LeSS?

On the LeSS website there are almost 20 case studies available. See LeSS Case Studies for the complete list. They include companies like J.P. Morgan, UBS and Nokia.

Other articles in this series:

Read more…

Monday, October 26, 2015

Product Backlog Stories ...

Last few weeks I had a few experiences around Product Backlog Items and user stories that made me write this article.

Let's start with a simple observation: many teams I have worked with and people I have met still have the notion that every Product Backlog Item should be in the form of a user story. Why? It is called Product Backlog Item for a reason, else the inventors of Scrum would have called it Product Backlog Story wouldn't they?

User stories describe end user requirements and are quite powerful in doing so. But for technical requirements or non-functional requirements like performance, security, etc they are not well suited. Of course you can "force" them into user stories but why do you want to do that when there are other means to capture these requirements far more efficient and clearer? Natural language is not always the most well suited way of defining things.

The same goes for complex user interactions like workflows and scenarios. And also user interface requirements are better visualized as described in human language. Using math for actuarial models makes far much more sense as describing it.

What I am trying to say is just use the format that is most suited for the task when creating a Product Backlog Item. That is what agile is being about.

The reason I have not used the word writing in the text above about user stories has to do with my second observation: Many people using Scrum seem to be the opinion that you just write a user story.

Even when valuable principles are considered during the writing, like the “As a … I want … so that …” notion, that reminds us that we need to consider all the users of our product, that we need to consider what they want to accomplish, and that we need to turn that into a feature that they want.

Or the “INVEST” notion from Bill Wake, that reminds us that stories should ideally be Independent, Negotiable, Valuable, Estimatable, Small, and Testable.

These are all good things for a requirements creator to think about … and they are all valuable to communicate to the developers, to help their understanding of the requirement. But a real user story consits out of the three C's: Card, Conversation and Confirmation. This formula from Ron Jeffries captures the three essential components of a user story:

- a "card" (or often a Post-It note), a physical token giving tangible and durable form to what would otherwise only be an abstraction:
- a "conversation" taking place at different time and places during a project between the various people concerned by a given feature of a product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation;
- the "confirmation", finally, the more formal the better, that the objectives the conversation revolved around have been reached.

You can write a user story in any form on a card and then create clarity by conversation between people that need to talk about it. During these conversations you can create additional documentation and add details to the card. Then you work on confirming the understanding.

That is what Product Backlog creation and refinement is all about. Not writing user stories or converting already clear requirements into user stories.

Read more…

Wednesday, October 21, 2015

Scaling Agile: DAD

The Disciplined Agile Delivery Framework
This is the second of six articles on approaches that try to help scaling Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. This article will present Disciplined Agile Delivery, or DAD. Contrary to for example Nexus or LeSS, DAD is not Scrum, it wants to be far more as that, hence this article will be much longer as the previous one
Before we can describe the current version of the DAD Framework we have to have a quick look at its history because focus and scope have changed drastically over the last few years.

DAD History

To date there have been three major release tiers of this framework:

Disciplined Agile Delivery 0.x: The framework was originally developed at IBM Rational from early 2009 to June 2012. The IBM team worked closely with business partners, including Mark Lines, and was led by Scott Ambler.

Disciplined Agile Delivery 1.x: The DAD 1.0 release occurred in June 2012 with the publication of the first DAD book, Disciplined Agile Delivery. The focus of Disciplined Agile Delivery (DAD) 1.x was to describe how agile/lean teams work from beginning to end, showing how all the activities of solution delivery (analysis, design, testing, architecture, management, programming, and so on) fit together in a cohesive, streamlined whole.

Disciplined Agile 2.0: This is the current version of the framework, initially released in August 2015. The focus is on describing a flexible, context-sensitive approach to the IT process. The scope of the framework evolved from how to be effective in delivering IT solutions to how to be effective at IT in general. As a result, the name changed from “Disciplined Agile Delivery” to “Disciplined Agile”.

Disciplined Agile 2.0
Many organizations start their agile journey by adopting Scrum because it describes a good strategy for leading agile software teams. However, Scrum is only part of what is required to deliver solutions to your stakeholders. Invariably teams need to look to other methods to fill in the process gaps that Scrum purposely ignores. When looking at other methods there is considerable overlap and conflicting terminology that can be confusing to practitioners as well as outside stakeholders.
To address these challenges the Disciplined Agile Delivery (DAD) process decision framework tries to provide a more cohesive approach to agile solution delivery. It is defined by www.disciplinedagiledelivery.com as:

Disciplined Agile 2.0 is defined as a process decision framework for Enterprise I.T. The main characteristics of this framework are that it: is a people-first, learning-oriented hybrid agile approach; has a risk-value delivery lifecycle; is goal-driven; is enterprise aware; is tactically scalable at the team level; and scalable strategically across all of IT.

What is so special about DAD?

There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD is a non-proprietary, freely available framework. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users.

It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to address the situation in which you find yourself.
The Disciplined Agile Delivery Framework

Roles

Primary roles are commonly found regardless of the level of scale. There are five primary roles:

Stakeholder: A stakeholder is someone who is materially impacted by the outcome of the solution. In this regard, the stakeholder is clearly more than an end-user: A stakeholder could be a direct user, indirect user, manager of users, senior manager, operations staff member, the “gold owner” who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, maintenance professionals potentially affected by the development and/or deployment of a software project. DAD teams will ideally work together with their stakeholders daily throughout the project.

Team Member: The role of team member focuses on producing the actual solution for stakeholders. Team members will perform testing, analysis, architecture, design, programming, planning, estimation, and many more activities as appropriate throughout the project. Note that not every team member will have every single one of these skills, at least not yet, but they will have a subset of them and they will strive to gain more skills over time. Team members are sometimes described by core agile methods as “developers” or simply as programmers. However, in DAD not every team member necessarily writes code. Team members will identify tasks, estimate tasks, “sign-up” for tasks, perform the tasks, and track their status towards completion.

Team Lead: The team lead is defined as a servant-leader to the team, creating and maintaining the conditions that allow the team to be successful. The team lead is also an agile coach, helping to keep the team focused on delivering work items and fulfilling their iteration goals and commitments that they have made to the product owner. He or she acts as a true leader, facilitating communication, empowering them to self-optimize their processes, ensuring that the team has the resources that it needs, and removes any impediments to the team (issue resolution) in a timely manner. In other words it is just a different name for the role of Scrum Master in traditional Scrum.

Product Owner: The product owner is defined as the one individual on the team who speaks as the “one voice of the customer”. He or she represents the needs and desires of the stakeholder community to the agile delivery team. As such, he or she clarifies any details regarding the solution and is also responsible for maintaining a prioritized list of work items that the team will implement to deliver the solution. While the product owner may not be able to answer all questions, it is their responsibility to track down the answer in a timely manner so that the team can stay focused on their tasks. Having a product owner working closely with the team to answer any question about work items as they are being implemented substantially reduces the need for requirements, testing, and design documentation. You will of course still have a need for deliverable documentation such as operations manuals, support manuals, and user guides to name a few. Each DAD team, or subteam in the case of large programmes organized into a team of teams, has a single product owner. A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. This includes arranging demonstrations of the solution as it evolves and communicating project status to key stakeholders.

Architecture Owner: The DAD framework explicitly includes the Agile Modeling’s role of architecture owner. The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design. The person in the role of team lead will often also be in the role of architecture owner on small teams. This isn’t always the case, particularly at scale, but it is very common for smaller agile teams. Although the architecture owner is typically the senior developer on the team – and sometimes may be known as the technical architect, software architect, or solution architect – it should be noted that this is not a hierarchical position into which other team members report. He or she is just like any other team member and is expected to sign-up and deliver work related to tasks like any other team member. Architecture owners should have a technical background and a solid understanding of the business domain.
The Disciplined Agile Delivery Framework Roles

Secondary roles are typically introduced, often on a temporary basis, to address scaling issues. There are five secondary roles:

Specialist: Although most agile team members are generalizing specialists, sometimes, particularly at scale, specialists are required. For example, on large teams or in complex domains one or more agile business analysts may join the team to help you to explore the requirements for what you’re building. On very large teams a program manager may be required to coordinate the team leads on various subteams. You will also see specialists on DAD teams when generalizing specialists aren’t available – when your organization is new to agile it may be staffed primarily with specialists who haven’t yet made the transition to generalizing specialists.

Domain Expert: The product owner represents a wide range of stakeholders, not just end users, so it isn’t reasonable to expect them to be experts in every nuance in your domain, something that is particularly true with complex domains. The product owner will sometimes bring in domain experts to work with the team, for example, a tax expert to explain the details of a requirement or the sponsoring executive to explain the vision for the project.

Technical Expert. Sometimes the team needs the help of technical experts, such as a build master to set up their build scripts, an agile database administrator to help design and test their database, a user experience (UX) expert to help design a usable interface, or a security expert to provide advice around writing a secure system. Technical experts are brought in on an as-needed, temporary basis to help the team overcome a difficult problem and to transfer their skills to one or more developers on the team. Technical experts are often working on other teams that are responsible for enterprise-level technical concerns or are simply specialists on loan to your team from other delivery teams.

Independent Tester. Although the majority of the testing is done by the people on the DAD team themselves, some DAD teams are supported by an independent test team working in parallel that validates their work throughout the lifecycle. This independent test team is typically needed for agility at scale situations within complex domains, using complex technology, or addressing regulatory compliance issues.

Integrator: For large DAD teams which have been organized into a team of subteams, the subteams are typically responsible for one or more subsystems or features. The larger the overall team, generally the larger and more complicated the system being built. In these situations, the overall team may require one or more people in the role of integrator responsible for building the entire system from its various subsystems. On smaller teams or in simpler situations the Architecture Owner is typically responsible for ensuing integration, a responsibility that is picked up by the integrator(s) for more complex environments. Integrators often work closely with the independent test team, if there is one, to perform system integration testing regularly throughout the project. This integrator role is typically only needed at scale for complex technical solutions.

Why So Many Roles?

Scrum has three roles – ScrumMaster, Product Owner, and Team Member – so why does DAD need ten? According to the authors of DAD the primary issue is one of scope. Scrum mostly focuses on leadership and change management aspects during Construction and therefore has roles which reflect this. DAD on the other hand explicitly focuses on the entire delivery lifecycle and all aspects of solution delivery, including the technical aspects that Scrum leaves out. So, with a larger scope comes more roles. For example, because DAD encompasses agile architecture issues it includes an Architecture Owner role. Scrum doesn’t address architecture so doesn’t include such a role.

Personally I disagree with this explanation but will discuss this in detail in the last post where I will compare all frameworks and will give my own opinion on all of them.

Agile Delivery Lifecycles

First, the DAD lifecycle explicitly calls out three phases:

Inception: During this phase project initiation activities occur. Although “phase” tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project. While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2013 Agile Project Initiation survey found the average agile team spends about a month in Inception whereas the most common iteration/sprint length is two weeks). So in DAD’s Inception phase some very lightweight visioning activities are planned to frame the project. It takes discipline to keep Inception short.

Construction: During this phase a DAD team will produce a potentially consumable solution on an incremental basis. They may do so via a set of iterations (Sprints in Scrum parlance) or do so via a lean, continuous flow approach (different versions of the lifecycle are discussed later). The team applies a hybrid of practices from Scrum, XP, Agile Modeling, Agile Data, and other methods to deliver the solution.

Transition: DAD recognizes that for sophisticated enterprise agile projects deploying the solution to the stakeholders is often not a trivial exercise. DAD teams, as well as the enterprise overall, will streamline their deployment processes so that over time this phase become shorters and ideally disappears from adopting continuous deployment strategies. It takes discipline to evolve Transition from a phase to an activity.

The Agile/Basic Lifecycle: Extending Scrum

The figure below presents a more detailed view of what is called the Agile/Basic DAD lifecycle which extends Scrum’s construction lifecycle. In addition to this being a more detailed view of the lifecycle, there are several interesting aspects to this lifecycle:
The Disciplined Agile Delivery Lifecycle

It’s iteration based. Like many agile methods, including both Scrum and XP, the solution is built incrementally in a time-boxed manner. These timeboxes are called iterations (what Scrum calls Sprints).

It uses non-Scrum terminology. Although the lifecycle is Scrum-based DAD chose to use non-branded terminology, in the case of this diagram the term iteration instead of Sprint. The terminology doesn’t really matter, so if you’re more comfortable with Scrum terminology use that instead.

It shows inputs from outside the delivery lifecycle. Although the overview diagram above showed only the delivery lifecycle, the detailed diagram below shows that something occurs before the project before Inception and that agile teams often get new requirements (in the form of change requests and defect reports) coming in from production. These inputs provide important context for the overall delivery lifecycle.

There is a work item list, not a product backlog. DAD has a greater scope than Scrum, and becasuse they take this greater scope into account they are the opinion you need a more robust change management approach than Scrum’s product backlog. Work items include requirements, defects, and other non-functionality oriented work such as training, vacations, and assisting other teams. All of this work needs to be prioritized somehow, not just implementation of requirements.

It includes explicit milestones. Along the bottom of the lifecycle diagram there is an indication of suggested light-weight milestones that DAD teams should strive to meet.

How does DAD relate to the other scaling approaches like SAFe, Nexus, LeSS?

This question will be part of every article but not answered by me. I will try to find quotes from the author(s) of the framework regarding this question. In the final article, where I will compare all the frameworks, I will give my own opinion. In this case it only makes sense to compare DAD with SAFe.

Two quotes from the FAQ on the DAD website:

DAD and SAFe are complementary. SAFe focuses on scaling agile approaches across an organization whereas DAD focuses on providing a solid foundation from which to scale agile approaches to address the complexities of large teams, geographic distribution, technical complexity, and other scaling factors. SAFe calls out three levels of scaling – project, program, and portfolio – although currently focuses on program and portfolio. DAD can easily fit into the project level in SAFe (SAFe current shows Scrum there, and DAD extends Scrum) and actually provides clear hooks such as enterprise awareness and a process goal-driven approach which we believe enables a much better fit to SAFe than does Scrum. An interesting observation is that both DAD and SAFe come from people with a solid background in the Unified Process (UP).
Unlike other options, DAD is not a prescriptive framework. It is a process decision framework designed to provide various strategies to facilitate better process decision making for the unique context of your situation.We don’t believe that one framework such as SAFe is best used for all scaling situations. For example, there are several ways to organize large agile teams (a single large team, several feature teams, several component teams or hybrids of these). Instead of prescribing one strategy DAD instead provides guidance to select the strategy that makes sense in a given situation. Similarly, you will evolve your strategy to reflect the geographic distribution of your team, the level of complexity that you face, the culture of team, any regulatory compliance requirements, the organizational distribution of your team (e.g. are you outsourcing some work), and other factors.

Are there well documented use cased of companies using DAD? 

On the website of the Disciplined Agile Consortium there are a number of companies listed, but only name and logo. No real use cases are described. When you have one, or know where I can find one , please contact me.

Other articles in this series:

Read more…

Monday, October 19, 2015

Scaling Agile: Nexus Framework

The Nexus Framework
This is the first of six articles on approaches that try to help to scale Agile. One of the most popular Agile methods is Scrum. Scrum is a very simple framework that describes an one iteration, one increment, one team product development effort. The framework leaves the more complex application of Scrum to the user. Many, many organizations have devised their own processes, standards, frameworks, etc. with which they apply Scrum to a wide-range of large development challenges.

But lately these scaling challenges and frameworks have become a hot topic in the agile community and multiple approaches have been created to address scaling Scrum and scaling Agile. Currently there are 5 well-known approaches that try to address these challenges each in their own way. In no particular order:

1) Nexus, by Ken Schwaber, www.scrum.org
2) DAD (Disciplined Agile Delivery), by Scott Ambler and Mark Lines, www.disciplinedagiledelivery.com
3) LeSS (Large Scale Scrum), by Craig Larman and Bas Vodde, www.less.works
4) SAFe (Scaled Agile Framework), by Dean Leffingwell, www.scaledagileframework.com
5) Scrum at Scale, by Jeff Sutherland, www.scruminc.com

Each one of them has their own focus and ideas. This series of articles will present and discuss each one of them. The final article will try to make a comparison between them and present weak/strong points, limitations etc.

The Nexus Framework

This first article will present the Nexus framework. Nexus is created by Ken Schaber and his team from Scrum.org. Nexus is a framework that is intended for developing and sustaining large software development projects.

Ken states on his blog that he has been working with people who have actually made Scrum scale for large projects and product initiatives over the last twenty years. Their smallest project experience was 3 teams, average 25 teams, and largest was 80 teams. In an answer to one of his blogposts Ken states that experiences were made at Microsoft, Intuit, Keybank, Adobe, and other organizations that do not want to be named.

Ken and his team abstracted a framework for this scaling which they named Nexus, defined as a causal link between things, such as biological nervous systems. In this case, a Nexus is 3-9 Scrum Teams that are working on a single Product Backlog to build an integrated increment that meets a goal. A Nexus+ is more than one Nexus inter-operating to build a large product, usually integrated through a product family framework, API, or such.

The core of the Nexus Framework is the development and reformulation of 40+ practices which cause the Nexus to operate predictably. They call this Scaling Professional Scrum, because they agreed that you cannot Scale amateur Scrum, represented by such bad practices as lack of integration and excessive dependencies.

The Nexus Guide that is describing those practices can be downloaded here www.scrum.org/Resources/The-Nexus-Guide. The Nexus Guide can be used next to the Scrum Guide (www.scrumguides.org) to scale Scrum and support the integrated effort of multiple software development teams.

What’s so special about Nexus?

Nexus is defined as an extension of Scrum, an exoskeleton. Single team Scrum artifacts are integrated in Nexus artifacts (Nexus Sprint Backlog, Integrated Increment). Events for managing the integration through identifying and resolving dependencies drive existing Scrum events, such as the Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Retrospective and where appropriate replace them (Nexus Sprint Review). Rather than relying on serendipity, integration responsibility is formally embedded in a new role, the Nexus Integration Team.

Roles, Artifacts and Events

As displayed in the following graphic, Nexus consists of:

Roles: A new role, the Nexus Integration Team, exists to coordinate, coach, and supervise the application of Nexus and the operation of Scrum so the best outcomes are derived. The Nexus Integration Team consists of a Product Owner, a Scrum Master, and Nexus Integration Team Members.

Artifacts: All Scrum Teams use the same, single Product Backlog. As the Product Backlog items are refined and made ready, indicators of which team will do the work inside a Sprint are made visual. A new artifact, the Nexus Sprint Backlog, exists to assist with transparency during the Sprint. All Scrum Teams maintain their individual Sprint Backlogs.

Events: Events are appended to, placed around, or replace (in the case of the Sprint Review) regular Scrum events to augment them. As modified, they serve both the overall effort of all Scrum Teams in the Nexus, and each individual team.

The Nexus Framework
The Nexus Framework (click to enlarge)

Nexus+ provides an architectural platform for consistently integrating the work of multiple Scrum teams into a consistent, quality whole.

How does Nexus relates to the other scaling approaches like SAFe, DAD, LeSS?

This question will be part of every article but not answered by me. I will try to find quotes from the author(s) of the framework regarding this question. In the final article, where I will compare all the frameworks, I will give my own opinion.

Ken Schwaber in an InfoQ Interview:
Nexus is different both in scope, approach, and cost. Nexus only addresses scaling software development, starting with a Product Backlog, budget, goal, and scope. Nexus also is only a framework within which an organizations unique approach to software development operates. Nexus does not guarantee success and is not formulaic. The people doing the software development do so to be successful in the most appropriate manner available. Individuals and interactions over processes and tools.

Are there well-documented use cases of companies using Nexus?

According to Ken in an interview on InfoQ it is being used worldwide. They are gathering, editing, and will publish examples and case studies on their website, www.scrum.org, as soon as they are ready. At the moment of writing no such use case has been published.

Other articles in this series:

Read more…

Sunday, October 18, 2015

Estimating with Wideband Delphi and Monte Carlo Simulation

Estimating with Wideband Delphi and Monte Carlo Simulation
During the LeSS training in Berlin last week with Craig Larman he mentioned the best estimating method he knows for any big software project. Wideband Delphi with Monte Carlo Simulation. I agree with him on this one hundred percent.

This article will explain what Wideband Delphi and Monte Carlo Simulation is (Part 1 & 2), how you can use them together for Scrum Project Estimations (Part 3), and gives you a tool that I build in Excel to guide you through the Wideband Delphi estimation and run the Monte Carlo Simulations easily yourself (Part 4).

I named this tool the Oracle Planning & Estimation Toolkit. This because the Wideband Delphi method was named after the greek oracle and the last 6 letters of Monte Carlo contain the word oracle as well.

Part 1: Wideband Delphi Method

Barry Boehm and John A. Farquhar originated the Wideband variant of the Delphi method in the 1970s. They called it "wideband" because, compared to the existing delphi method, the new method involved greater interaction and more communication between those participating. The method was popularized by Boehm's book Software Engineering Economics (1981). Boehm's original steps from this book were:

Step 1 Coordinator presents each expert with a specification and an estimation form.

Step 2 Coordinator calls a group meeting in which the experts discuss estimation issues with the coordinator and each other.

Step 3 Experts fill out forms anonymously.

Step 4 Coordinator prepares and distributes a summary of the estimates

Step 5 Coordinator calls a group meeting, specifically focusing on having the experts discuss points where their estimates vary widely

Step 6 Experts fill out forms, again anonymously, and steps 4 to 6 are iterated for as many rounds as appropriate.

A variant of Wideband Delphi was developed by Neil Potter and Mary Sakry of The Process Group. In this process, a project manager selects a moderator and an estimation team with three to seven members. The Delphi process consists of two meetings run by the moderator. The first meeting is the kickoff meeting, during which the estimation team creates a work breakdown structure (WBS) and discusses assumptions. After the meeting, each team member creates an effort estimate for each task. The second meeting is the estimation session, in which the team revises the estimates as a group and achieves consensus. After the estimation session, the project manager summarizes the results and reviews them with the team, at which point they are ready to be used as the basis for planning the project.

Step 1 Choose the team: The project manager selects the estimation team and a moderator. The team should consist of 3 to 7 project team members. The team should include representatives from every engineering group that will be involved in the development of the work product being estimated.

Step 2 Kickoff meeting: The moderator prepares the team and leads a discussion to brainstorm assumptions, generate a WBS and decide on the units of estimation.

Step 3 Individual preparation: After the kickoff meeting, each team member individually generates the initial estimates for each task in the WBS, documenting any changes to the WBS and missing assumptions.

Step 4 Estimation session: The moderator leads the team through a series of iterative steps to gain consensus on the estimates. At the start of the iteration, the moderator charts the estimates on the whiteboard so the estimators can see the range of estimates. The team resolves issues and revises estimates without revealing specific numbers. The cycle repeats until either no estimator wants to change his or her estimate or the estimators agree that the range is acceptable.

Step 5 Assemble tasks: The project manager works with the team to collect the estimates from the team members at the end of the meeting and compiles the final task list, estimates and assumptions.

Step 6 Review results: The project manager reviews the final task list with the estimation team.

You see that this process fits perfectly for any Scrum Team or Teams. The "project manager" is the Product Owner, the "moderator" the Scrum Master and the "team" the Scrum team(s) or representatives of these teams. The "WBS" is the Product Backlog. This is not practicable nor useful for a Sprint Planning, but at the start of a new project this is extremely helpful to get an idea bout size of the whole product and bigger epics/stories.

Part 2: Monte Carlo Simulation

Monte Carlo simulation, or probability simulation, is a technique used to understand the impact of risk and uncertainty in financial, project management, cost, and other forecasting models.

Uncertainty in Forecasting Models

When you develop a forecasting model – any model that plans ahead for the future – you make certain assumptions. These might be assumptions about the investment return on a portfolio, the cost of a construction project, or how long it will take to complete a certain task. Because these are projections into the future, the best you can do is estimate the expected value.

You can't know with certainty what the actual value will be, but based on historical data, or expertise in the field, or past experience, you can draw an estimate. While this estimate is useful for developing a model, it contains some inherent uncertainty and risk, because it's an estimate of an unknown value.

Estimating Ranges of Values

In some cases, it's possible to estimate a range of values. In a software development project, you might estimate the time it will take to complete a particular Product Backlog Item; based on some expert knowledge, you can also estimate the absolute maximum time it might take, in the worst possible case, and the absolute minimum time, in the best possible case. The same could be done for IT infrastructure costs.

By using a range of possible values, instead of a single guess, you can create a more realistic picture of what might happen in the future. When a model is based on ranges of estimates, the output of the model will also be a range.

This is different from a normal project estimation model, in which you start with some fixed estimates – say the time it will take to complete each of the Product Backlog Items of a project – and end up with another value – the total estimated time for the project. If the same model were based on ranges of estimates for each of the Product Backlog Items of the project, the result would be a range of times it might take to complete the project. When each part has a minimum and maximum estimate, we can use those values to estimate the total minimum and maximum time for the project.

How it works

When you have a range of values as a result, you are beginning to understand the risk and uncertainty in the estimation. The key feature of a Monte Carlo simulation is that it can tell you – based on how you create the ranges of estimates – how likely the resulting outcomes are.

In a Monte Carlo simulation, a random value is selected for each of the tasks, based on the range of estimates. The model is calculated based on this random value. The result of the model is recorded, and the process is repeated. A typical Monte Carlo simulation calculates the model hundreds or thousands of times, each time using different randomly-selected values. When the simulation is complete, we have a large number of results from the model, each based on random input values. These results are used to describe the likelihood, or probability, of reaching various results in the model.

Part 3: Combine the two methods for a Scrum project estimation 

With a few small adaptions to the Wideband Delphi process it
- fits perfectly in a (large scale) Scrum setup.
- we generate the input we need for a Monte Carlo Simulation.

The steps for the whole process would look like this

Step 1 Choose the team: The Product Owner, the Scrum Team and a Scrum Master form the group for the next steps, but only the Scrum Team will estimate. The Scrum Master is the moderator. The Scrum team should consist of 3 to 8 team members. On a large scale project or product group where multiple Scrum Teams follow the same goal each Scrum team will select an X number of representatives so that the total number of people is not bigger as 10. This is the maximum in my opinion to handle the following process effectively.

Step 2 Kickoff meeting: The Scrum Master prepares the team and moderates a discussion to brainstorm assumptions based on the initial Product Backlog items and decide on the units of estimation. I prefer to estimate in number of Sprints but you can also estimate in days, months or story points. Note that 4 week sprints is almost the same as estimating in months.

Step 3 Individual preparation: After the kickoff meeting, each Scrum Team member individually generates the initial estimates for Product Backlog items, documenting any changes to the necessary tasks and missing assumptions.

Step 4 Estimation session: The Scrum Master leads the team through a series of iterative steps to gain consensus on the estimates. At the start of the iteration, the Scrum Master adds the estimates to Oracle Planning & Estimation Toolkit so the group can see the range of estimates. For each Product Backlog Item we will need the following three estimations:

- Best Case Estimate
- Most Likely Estimate
- Worst Case Estimate

The Oracle Planning & Estimation Toolkit creates these three values automatically based on the single estimations of the Scrum team member. The lowest estimation is the Best Case Estimate, the highest estimation is the Worst Case Estimate and the average off all estimations is the Most Likely Estimate. Note that the average is not always good estimation of the most likely estimation, but it serves us well to start the discussion.

The Scrum Team see the three estimates on the screen and will discuss and update primarily the Most Likely Estimate. But also the Best Case and Worst Case Estimates can be changed. this mosten happens when underlying assumptions change, or the item was not clear to everybody. Updates will be entered directly in the Oracle Planning & Estimation Toolkit for everybody to see, The cycle repeats until either no one wants to change the Most Likely Estimate or the Scrum team agrees that the range is covering difference on the most likely outcome. Note that the Product Owner needs to be available during the whole meeting for answering questions and clarifications.

Step 5 Run Monte Carlo Simulation: The Scrum Master runs the Monte Carlo Simulation with a beta-PERT Distribution and the Oracle Planning & Estimation Toolkit will produce and analysis of the results.

Step 6 Review results: The Scrum Master reviews the final Product Backlog, their estimations and uncertainties (i.e. Risks) with the Scrum Team and Product owner.

As you can see the process is very straight forward and will need only two meetings.

Part 4 Oracle Planning & Estimation Toolkit

At the hand of an example I will explain the the Oracle Planning & Estimation Toolkit.  Consider a simple Product Backlog like the one for the tool itself. This Product Backlog contains 8 "large" items. Remind that we are at the beginning of the project and the items are so big that they will not fit into one Sprint. It is about project estimating, not Sprint estimating.


Let's further assume that these items must be completed in sequence and cannot be done in parallel. Based on the prioritization of the Product Owner the row order is of course flexible. How long will the project take to complete? During the Kickoff meeting, we will discuss all Items and will change, split or delete them until we agree on a common understanding. This is of course only possible when the Product Owner is in the room. After this is done all Team members will prepare themselves for the Estimation meeting. It is up to the team to agree on the date of the next meeting.

During the Estimation meeting, we will start with the Wideband Delphi Input Screen (click to enlarge).


The first Team Member will give their estimations in public without commenting them. The estimations in this example are in number of 1 week Sprints. 


Then the second Team Member


And so on


After all estimations are putted into the screen we will go the Wideband Delphi Estimation Screen which will look like this.


It consists out of 5 sections. The white section is the Product Backlog. The greens section contains the values of the Wideband Delphi Input Screen but are rounded to whole numbers.


The red section is where we continue our meeting. This where we will change the estimations as described in Step 4 of our method until we reach consensus.


The focus will be on reaching consensus on the Most Likely Duration, but the Best Case and Worst Case can be changed as well. As soon as changes are made the model will recalculate the values in the orange and the grey section. The orange section contains a random value between 0 and 1 and the PERT Value coming from the input (Probability, Min, ML, Max).


The grey section contains the Three-Point Estimate that is used often when using PERT but no Monte Carlo simulation.


After a consensus is reached the Scrum Master will run the Monte Carlo simulation by running the Macro RunSimulations(). The Toolkit will ask for the desired number of iterations. Typically 1000 is a good number. The results of the simulation can be found in the sheet "Montecarlo Simulation Results". They will look like this (but then 1000 rows instead of 10).


These results can then be visualized and analyzed by using the Data Toolpak from Excel. You can compute Average, Standard Deviation, Variance, etc. But the most helpful tool is the Histogram combined with the Cumulative Percentage curve.


This diagram will tell you that based on the current 6 expert opinions the probability to be done in 29 sprints is above 80%. At the same time, it tells us that the probability of finishing in 26 sprints is not even 30%. This kind of analysis will help us combining our expert input with risk simulation and will give us this way a better feeling for the estimations itself.

Currently, the Oracle Planning & Estimation Toolkit is in Beta and contains only the functionality described in this post.

When you are interested in the Oracle Planning & Estimation Toolkit and want to receive a copy just contact me.

Read more…