Scaling Agile: Scrum at Scale

This is the fifth of six articles on approaches that try to help to scale Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The following articles are about Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS) and Scaled Agile Framework (SAFe). This article will present the Scrum at Scale framework.

The creator of Scrum at Scale is Jeff Sutherland, the co-creator of Scrum. Jeff's reasoning is that part of the key to Scrum's success is that it allows for context-driven solutions and processes – which is why no two Scrum implementations are identical. So why does the conversation about scaling Scrum focus on finding a prescriptive, one-size fit all solution? The conversation should instead be about how to scale the underlying principles of the Scrum framework that have enabled it to be so adaptable.

The Scrum at Scale framework is his first move in that direction. It is a minimal extension of the core Scrum framework that keeps the modular structure at the core of the Scrum framework and allows you to scale a Scrum implementation tailored to the unique needs of your company.

There are four major reasons why Jeff thinks modularity is important:

1. Modularity allows versatility. Scrum has been successful in a wide variety of product and project contexts. It’s been used for everything from traditional software development to designing a new granola bar or designing complex integrated defense systems. No single prescriptive approach could work in all of those different contexts. You need something that is modular to adapt to the specific strategic context of your company.

2. Scrum is modular. At its roots, Scrum is inherently modular. For example the Retrospective ceremony within Scrum doesn’t tell you exactly how you have to implement the retro, it just says that at the end of it, you need to have a plan for improving the team process, puts some bounds around how long that meeting should take, and gives guidance on who should attend that meeting. It leaves the actual practices for how to do that to the team that is actually conducting the retrospective. And as a result, we’ve seen a proliferation of different practices that are successful in lots of different contexts.

3. Deploying incrementally is easier. If you have a modular context and you define all of the interconnections between modules ahead of time (namely what the goal of the module is, what the input to the module is, and what the output of the module is) then it doesn’t matter what happens inside that black box as long as it meets those constraints it still satisfies the goal of the module. That means you don’t need to have an entire solution delivered in one “big bang” at the very beginning of your scaling. It frees you to iteratively use Scrum to incrementally develop the modules that are most important to you and after several iterations have a fully-fledged scaled Scrum.

4. Modularity supports a pattern library. A library of what people have tried in the past, and in what context, is a great way to accelerate the speed with which you can try new scaling experiments. As an agile community, we can quickly build, distill, and capture knowledge so that we can improve the state of the art by borrowing patterns and practices that have been used by other companies in a similar context to ours, and then contribute incremental learnings back to that library. It’s a powerful concept that allows us to crowdsource the development of scaling Scrum.

Context is important

- How important is the speed of delivery?
- How important is innovation?
- How important is team empowerment?
- Where are teams located?
- How complex and/or tightly integrated is the product?
- What is the driving timeframe for becoming agile?
- How severe are the repercussions of a product defect?

Answers to these questions define context, and context is very important when trying to scale scrum. But too often it is neglected in discussions of scaling approach. DAD states the same. There is no one size fits all, and context determines the most suitable approach.

The different modules

The whole framework is described in the picture below.

I will give a short description of the goals each module below:

1. Team Level Scrum Process: Maximize the flow of completed and quality tested work; try to increase velocity a little each sprint; operate in a way that is sustainable and enriching for the team in the long run

2. Strategic Vision: Clearly align the entire organization along a shared path forward; compellingly articulate why the organization exists; describe what the organization will and won’t do to leverage key assets in support of its mission; update and fine-tune vision continuously based on feedback to outmaneuver the competition

3. Backlog Prioritization: Identify a clear ordering for products, features, and services to be delivered by the organization; reflect value creation, risk mitigation and internal dependencies in ordering of the backlog

4. Backlog Decomposition and Refinement: Break complex projects and products into manageable independent functional elements that can be completed by one team in one sprint; capture and distil emerging requirements and customer feedback; ensure all backlog items are truly “Ready” when they reach sprint backlog; parse backlog to individual teams

5. Release Planning: Forecast delivery of key features and capabilities; communicate snapshot of delivery expectations to stakeholders; inform updated prioritization, as needed, based on stakeholder input

6. Release Management: Deliver a consistent flow of valuable finished product to customers; integrate the work of different teams into one seamless product; ensure high quality of the customer experience; capture and communicate feedback on product, process, and schedule

7. Feedback: Understand how customers actually use and interact with the product; define improvements to existing functionality; distil actionable changes in direction from the noise of all responses; capture ideas for new features and functionality not previously identified; update progress towards product/project completion to refine release planning and stakeholder alignment

8. Continuous Improvement and Impediment Removal: Identify impediments that slow teams down and reframe them as opportunities to get faster; maintain a safe and structured environment for prioritizing and removing impediments, and then verifying the resulting improvement;; ensure visibility at the right level(s) in the organization to effect change

9. Cross-Team Coordination: Coordinate similar processes across multiple related teams; manage cross-team dependencies to ensure they don’t become impediments; maintain alignment of team norms and guidelines for consistent output

10. Metrics and Transparency: Provide all decision makers including team members with appropriate context to make good decisions; shorten feedback cycles as much as possible to avoid over-correction; accomplish all of this with a minimal additional effort by teams, stakeholders or leadership.

For each module, you can decide how to implement this best and then start the adapt and improve cycles that form the core of any Scrum implementation.

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

This question is part of every one of my Scaling Scrum articles 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. Unfortunately, I could not find any quotes except for a few outdated spoken ones of Alex Brown.

Are there well-documented use cases of companies using Scrum at Scale?

Since Scrum at Scale is not really a method but more a help and guidance on choosing your own approach for scaling there is no real clear use case. Scrum Inc is consulting companies whilst using the Scrum at Scale approach, so there are people and companies using this approach, but these cases are not documented and available to the public. When you have one or know where I can find one, please contact me.

Other articles in this series:

1. Scaling Agile: Nexus Framework

2. Scaling Agile: DAD 

3. Scaling Agile: LeSS

4. Scaling Agile: SAFe

5. Scaling Agile: Scrum at Scale

6. Scaling Agile: Conclusion

Read more…

Scaling Agile: SAFe

This is the fourth of six articles on approaches that try to help to scale 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) and the third about Large Scale Scrum (LeSS). This article will present the Scaled Agile Framework, or SAFe.

The creator of SAFe, Dean Leffingwell, tries to provide a receipe for adopting Agile at enterprise scale. So not just scaling Scrum, it is all about the Enterprise. SAFe provides guidance on architecture, integration, funding, governance and roles at scale. SAFe, as many enterprises, loves three letter acronyms like DBT, ART, RTE, PSI, NFR, RMT and I&A. I will try do give a short and understandable overview of SAFe, but I have to admit that this is not so easy to do. The whole framework is described in a single poster.

The Scaled Agile Framework (click to enlarge)

What is so special about SAFe?

There are three levels in SAFe:

1 Team
2 Program
3 Portfolio

Team Level

SAFe uses Scrum with XP engineering practices at team level. Define/Build/Test (DBT) teams deliver working, fully tested software every two weeks. This is called one iteration. There are five to nine members in each team.

Program Level

SAFe defines an Agile Release Train (ART). As iteration is to team, train is to program. The ART (or train) is the primary vehicle for value delivery at the program level. It delivers a value stream for the organization. Between 5 and 10 teams work together on a train. They synchronize their release boundaries and their iteration boundaries. Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI). A demo and inspect and adapt sessions are held. Planning begins for the next PSI. PSIs provide a steady cadence for the development cycle. They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.

New program level roles are defined
- System Team
- Product Manager
- System Architect
- Release Train Engineer (RTE)
- UX and Shared Resources (e.g., security, DBA)
- Release Management Team

In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles. If they have deep domain expertise, they are likely to fill the Product Manager role. If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.

SAFe makes a distinction between content (what the system does) and design (how the system does it). There is separate “authority” for content and design. The Product Manager (Program Manager) has content authority at the program level. She defines and prioritizes the program backlog. SAFe defines an artifact hierarchy of Epics – Features – User Stories. The program backlog is a prioritized list of features. Features can originate at the Program level, or they can derive from Epics defined at the Portfolio level. Features decompose to User Stories which flow to Team-level backlogs. Features are prioritized based on Don Reinersten’s Weighted Shortest Job First (WSJF) economic decision framework.

The System Architect has design authority at the program level. He collaborates day to day with the teams, ensuring that non-functional requirements (NFRs) are met. He works with the enterprise architect at the portfolio level to ensure that there is sufficient architectural runway to support upcoming user and business needs.

The UX Designer(s) provides UI design, UX guidelines and design elements for the teams. In a similar manner, shared specialists provide services such as security, performance and database administration across the teams.

The Release Train Engineer (RTE) is the Uber-ScrumMaster. The Release Management Team is a cross-functional team - with representation from marketing, dev, quality, ops and deployment – that approves frequent releases of quality solutions to customers.

Portfolio Level

PPM has a central role in Strategy, Investment Funding, Program Management and Governance. Investment Themes drive budget allocations. Themes are done as part of the budgeting process with a lifespan of 6-12 months. Portfolio philosophy is a centralized strategy with local execution.

Epics define large development initiatives that encapsulate the new development necessary to realize the benefits of investment themes. There are business epics (customer-facing) and architectural epics (technology solutions). Business and architectural epics are managed in parallel Kanban systems. Objective metrics support IT governance and continuous improvement.

Enterprise architecture is part of SAFe. The concept of Intentional Architecture provides a set of planned initiatives to enhance solution design, performance, security and usability.

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

On the SAFe website there are almost 20 case studies available. See SAFe Case Studies for the complete list. They include companies like John Deere and Intel.

Other articles in this series:

1. Scaling Agile: Nexus Framework

2. Scaling Agile: DAD 

3. Scaling Agile: LeSS

4. Scaling Agile: SAFe

5. Scaling Agile: Scrum at Scale

6. Scaling Agile: Conclusion

Read more…

Scaling Agile: LeSS

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

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:

1. Scaling Agile: Nexus Framework

2. Scaling Agile: DAD 

3. Scaling Agile: LeSS

4. Scaling Agile: SAFe

5. Scaling Agile: Scrum at Scale

6. Scaling Agile: Conclusion

Read more…

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…

Scaling Agile: DAD

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.

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.

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:

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:

1. Scaling Agile: Nexus Framework

2. Scaling Agile: DAD 

3. Scaling Agile: LeSS

4. Scaling Agile: SAFe

5. Scaling Agile: Scrum at Scale

6. Scaling Agile: Conclusion

Read more…

Scaling Agile: 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 (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:

1. Scaling Agile: Nexus Framework

2. Scaling Agile: DAD 

3. Scaling Agile: LeSS

4. Scaling Agile: SAFe

5. Scaling Agile: Scrum at Scale

6. Scaling Agile: Conclusion

Read more…

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…

Budgeting a Scrum Project

A few weeks ago, I took the training for "Agile Estimating and Planning" with Mike Cohn on FrontRowAgile.com. The training was very good and I think it's an excellent start for all estimation and planning-related questions. But even after this training, it is still unclear for many on how to make the leap from estimations and planning to a sound budget. This article will create the bridge between estimations and planning and a sound budget. Although my focus is on budgeting for larger companies, because that is my experience, I am sure that it can be useful for smaller companies as well.

Who is creating and managing the budget?

Projects are funded in company-specific ways. Usually, a project sponsor gets funding from a steering committee or the CFO. In other cases, a project may be funded out of a specific department's budget. In all cases, there is ultimately a budgetary authority that authorizes predefined or ongoing spend for a project. Any well-run company has a budget process. This process includes the delegation of formal authority to someone in the organization to manage that budget.

On projects that use the Scrum framework, that person should be the product owner. In Scrum, the product owner is responsible for prioritizing the deliverables. By extension, this makes the product owner responsible for the allocation of resources for the project and for creating the initial budget.

Cost per iteration, per team?

The two fundamental features of Scrum projects are that they will have a stable team setup and iterations with a fixed duration -- for example, two-week sprints. When you have these two pieces of information, you can compute the costs per iteration. Sounds simple, but the approach has a few challenges.

Let’s start with the team composition. We will assume what is typical for projects in larger companies, which is a mix of internal employees and external contractors and consultants. For each team member, we will need a few pieces of information.

Role: Product owner, ScrumMaster, team member (business analyst, software engineer, tester)

Daily rate: Most larger companies will have a fixed daily rate for internal employees. Based on their level, they will sometimes be different, but typically there is one rate for all employees that includes all costs. External employees will have a daily rate specified in their contract and, when relevant, you should add VAT to this rate to get the real cash-out costs. When you have not yet fixed the rates of the external employees, you will have to estimate them. I prefer to take a range and create a low-cost and a high-cost projection of one iteration.

Allocated time on project: In an ideal world, the team members are working full time on this project, but this is often not the case. We will have to determine the percentage of their time that they will be working on this project.

Burn rate per sprint: This is the cost that this team member will incur per iteration, under the assumption that he or she will work the agreed allocated time on the project. I always assume 20 working days per month for budgeting. In this example, it's ten days per two-week sprint. I know that people who are allocated 100 percent on the project will not work 260 days a year. Typically this will be around 220 days a year (Switzerland and other countries will have fewer or more days off).

Internal/external: For computing the cash-out in your budget, you will need to identify which costs are internal and which are external.

Example of internal and external costs for a team:

Role	Daily rate	Allocated time on project	Internal / external	Burn rate per 2-week sprint
Product owner	1000	50%	I	5.000
ScrumMaster	1400	100%	E	14.000
Business analyst	1200	100%	E	12.000
Software engineer 1	1000	100%	I	10.000
Software engineer 2	1000	100%	I	10.000
Software engineer 3	1200	100%	E	12.000
Tester 1	1000	100%	I	10.000
Tester 2	1100	50%	E	5.500
Total				78.500
Total internal				35.000
Total external				43.500

When you are budgeting a larger project with multiple Scrum teams, you just do this exercise for each team. I budget them separately, which means I will have a line in my budget for each team and do not have a total cost per iteration. This is because not each team will have the same number of iterations.

When your project includes a project management office (PMO) resources, such as a chief product owner or a program manager, you can do two things: create a separate team for them and do exactly the same exercise as above, or add each one of those resources for a certain percentage to an existing Scrum team. I have seen both, but I prefer the first one and call the team "Program Management." This way, it is very clear that they are managing and not building, and you prevent long discussions regarding team percentages.

One other team that I have added to some budgets is the Initiation team. Before everything is in place for a larger project (including a final budget approval), a small team starts the initiation and elicitation of the project. And yes, I let this team work in sprints as well. Why?

1. Management is not willing to commit to starting the project without having a view of the total scope and cost.
2. A business case is required to make a decision whether to go ahead with the project at all.
3. Multiple stakeholders must agree on the scope of the deliverables for the project before it is sanctioned.

Example of internal and external costs for multiple teams:

Team	Total costs per 2-week sprint	External costs per 2-week sprint	Internal costs per 2-week sprint
Initiation	20.000		20.000
Overhead	24.000	14.000	10.000
Team A	78.500	43.500	35.000
Team B	56.000	16.000	40.000
Team C	94.000	74.000	20.000

After I have the cost per sprint, per team (including the overhead team, as shown in the example), I can start the next step.

How many sprints per team?

There are thousands of articles and videos on Agile estimating and planning, so I will not address how you can do this here. What we will need from each team for our budget is the number of sprints that are planned. This can be done by estimating the product backlog and dividing it by the team's (estimated) velocity. You will not even have to do this for some projects because the time is fixed, and you know the maximum number of sprints up front. The overhead team has always the same number of sprints as the team with the largest number of sprints.

When we have this information, we can compute the total project budget for each team. When the project runs over multiple calendar years, you will have to split the numbers by year. This means that you count the sprints per calendar year for each team.

Example of total project budget for each team:

Team	# sprints 2015	# sprints 2016	Costs 2015	Costs 2016	Total costs
Initiation	2		40.000	0	40.000
Overhead	12	18	288.000	432.000	720.000
Team A	12	12	942.000	942.000	1.884.000
Team B	8	18	448.000	1.008.000	1.456.000
Team C	10	8	940.000	752.000	1.692.000
Total			2.658.000	3.134.000	5.792.000

Are there any additional costs?

This answer will be "Yes" for almost every project. Additional costs are incurred through local hardware and software for the software engineers and testers as well as the infrastructure for the final project. Development environment, test environment, user acceptance testing environment, and production environment will cost money to buy, set up, and maintain. I do not allocate these costs to a team when it is not forced by accounting. I will add a line for hardware, a line for software, and a line for setup costs (typically an external IT provider or internal IT costs). Other possible costs are travel (for example, one team is at a different location), workshops, and training. Again, these are project costs and not team costs.

How about contingency?

Most companies I have worked for have an obligated percentage of contingency on top of the total budget, or parts of the budget, that typically range from 10 percent to 15 percent. Be careful here, because although you have more money, it is hard to add members to an existing Scrum team. Therefore, this is only usable for running an additional number of sprints.

How reliable is the budget?

Unfortunately, serious, realistic planning is impossible at the start of a software project. This is true for conventional and Scrum projects and does not reflect the team or service provider’s capabilities. It is due to the nature of complex IT projects.

But unlike in Waterfall projects with detailed requirements specification, Scrum embraces this impossibility, so the initial estimates in Scrum are not fixed. They become more realistic over time. As soon as the project starts, the requirements and general conditions become clearer with every passing sprint. And by using proven estimation methods and gained experience, the team becomes better at telling how much a desired feature will affect the budget. After just a few iterations (which is very early in the course of a bigger project) the project sponsor has reliable and valid information about the required budget.

Besides creating a more reliable budget by design as part of the Scrum process, Scrum projects guarantee transparent budget control on the way. Cost explosions, which might need to be accepted in a Waterfall project if you want to actually see your software in the end, can be avoided with Scrum. The project sponsor will still receive a high-quality software product, albeit with fewer features than initially planned.

Possible reactions to a total budget that ends up greater than planned

What happens if after a few sprints the estimates are much higher than the initial estimates? Does the project sponsor lose all control over the budget in Scrum projects? The opposite is actually true. The project sponsor always has options due to the new, incoming information about the total budget. This is one of the main advantages of Scrum. Early on in the project, the project sponsor has functional software containing the most prioritized functions and offering the greatest benefit. In this case, the project sponsor has four options:

1. If meeting all requirements is expected to cost more than budgeted, the project sponsor can abort the project at an early stage. A basic version of the project is generally released after just a few iterations.

2. The project sponsor can let the project run until the planned budget is consumed and then suspend or terminate the project. In any case, they will have functional software that contains the most important functions.

3. The project sponsor has the option of changing the project scope by postponing or omitting less important functions.

4. The project sponsor can increase the budget.

Scrum allows the project sponsor full budget control and thus full flexibility while reducing the risk of cost explosions because of big-bang implementations.

This article appeared first on ScrumAlliance.org

Read more…