Our experience is that there has been a great deal of improvement in projects over the last decade. To be more specific, we’ve seen the agile movement make an impact on how projects deliver business value.
The focus of this book, when it comes to processes and frameworks, is on agile methods like Scrum and XP. The reason is simply that agile fits nicely with the concept of ALM.
This chapter looks at how you can use Scrum as an agile project-management model to deliver software. We cover the Scrum process in-depth, including how you in practice can use Scrum and agile practices such as agile estimation and planning in combination with an ALM tool. This chapter gives you insight into why agile and ALM are a good match.
This chapter also shows you some other agile processes that are popular. Scrum in itself is a great framework, but some projects and organizations need another process to help run their projects.
The Scrum Framework
Next is one of our favorite development models: Scrum. With all the attention Scrum has been getting in recent years, you may be misled into believing it’s a fairly new model. The truth is that the Scrum approach, although not called Scrum at the time, was first presented as “the rugby approach” in 1986. In the January-February 1986 issue of the Harvard Business Review, Hirotaka Takeuchi and Ikujiro Nonaka described this approach for the first time.1 In the article, they argued that small cross-functional teams produced the best results from a historical viewpoint.
It wasn’t until 1990, however, that the rugby approach was referred to as Scrum. In 1990, Peter DeGrace and Leslie Hulet Stahl2 highlighted this term from Takeuchi’s and Nonaka’s original article. The term comes from rugby originally (see Figure 3-1), where it means the quick, safe, and fair restart of a rugby game after a minor infringement or stoppage.3 This is also the source of the following quotation:
Figure 3-1. A real scrum!
A scrum is formed in the field when eight players from each team, bound together in three rows for each team, close up with their opponents so that the heads of the front rows are interlocked. This creates a tunnel into which a scrum-halt throws in the ball so that front-row players can compete for possession by hooking the ball with either of their feet”
Keep this definition in mind as we describe the development version of Scrum.
Ken Schwaber started using Scrum at his company in the early 1990s. But to be fair, Jeff Sutherland was the first to call it Scrum.4 Schwaber and Sutherland teamed up and presented this approach publicly in 1996 at Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) in Austin, Texas. They collaborated to use their experience and industry best practices to refine the model until it achieved its present look. Schwaber described the model in Agile Software Development with Scrum in 2001.5
Let’s continue bay looking at empirical process control and see what that means in software development.
Empirical Process Control
What is this model, or framework, all about? First, let’s define two ways to solve problems. We touched on the issues with projects in Chapter 1. When you have an issue that is similar time after time (like road construction, for example, or implementing a standard system), you pretty much know what to expect from the various tasks at hand. You can then easily use a process—the Waterfall model, perhaps—that produces acceptable-quality output over and over again.6 This approach is called defined process control.
When it comes to a more complex problem, however, like building a software system, you saw earlier that the traditional models don’t work. You then must use something called empirical process control, according to Schwaber.7 Empirical process control has three legs to stand on:
Transparency
Inspection
Adaptation
“Transparency means that the aspects of the process that affect the outcome must be visible to those controlling the process.”8 This means to be able to approve the outcome, you must agree on the criteria for the outcome. Two people can’t say they’re “done” with a task unless they both agree on what the criteria for “done” are.
The next leg is inspection. The process must be inspected as frequently as necessary to find unacceptable variances in it. Because any inspection may lead to a need to make changes to the process itself, you also need to revise the inspections to fit the new process. To accomplish this, you need skilled inspectors who know what they’re inspecting.
The last leg is adaptation. An inspection may lead to a change in the process: this is one example of an adaptation. Another is that you must adapt the material being processed as a result of an inspection. All adaptations must be made as quickly as possible to minimize deviation later.
Schwaber reuses the example of code review when he discusses empirical process control. “The code is reviewed against coding standards and industry best practices. Everyone involved in the review fully and mutually understands these standards and best practices. The code review occurs whenever someone feels that a section of code is complete. The most experienced developers review the code, and their comments and suggestions lead to the developer adjusting his or her code.”9 Simple, isn’t it? We could not have said it better ourselves.
Complexity in Projects
What makes a software development process so complex? We discussed this a little previously, but let’s dive deeper here. In theory, building a software system may seem pretty straightforward. You write code that logically instructs the CPU to control the computer. How hard can it be? Alas, it isn’t that simple, we’re afraid. The people writing the code are complex machines in themselves. They have different backgrounds, IQs, EQs, views, attitudes, and so on. Their personal lives also add to their complexity.
The requirements may also be complex and have a tendency to change over time. According to Schwaber, a large percentage of the requirements gathered at the beginning of a software project change during the project. And 60% of the features you build are rarely or never used in the end. Many times in our projects, several people at the customer site are responsible for the requirements. Often they have diverging agendas as to why and what to build. Often the stakeholders have a hard time expressing what they really want. Only when they see a first prototype of the system do they fully begin to see the possibilities of the software, and only then can they begin to understand what they want.
Rarely is it the case that just one computer is involved in a system, either. Generally there is interaction among several machines. You may have a web farm for your GUI, a cluster for your application tier, a backend SQL server, some external web services, and often a legacy system, all needing to integrate to solve the needs of the new system.
When complex things interact—as people, requirements, and technology do in a software project—the level of complexity increases greatly. So it’s safe to say that we don’t have any simple software problems anymore. They’re all complex. Schwaber realizes this as well. Figure 3-2 shows his complexity-assessment graph.
Figure 3-2. Schwaber’s complexity graph
The projects in the anarchy area are chaotic and unworkable. To get them to their finish lines, you probably need to resolve serious issues before starting them.
What Scrum tries to do is address this inherent complexity by implementing inspection, adaptation, and visibility, as you previously saw in the section “Empirical Process Control.” Scrum does so by having simple practices and rules.
What Scrum Is
Scrum is a powerful, iterative, and incremental process. Many are fooled by its perceived simplicity, but it takes time to master. Figure 3-3 shows the skeleton of the Scrum model, to which we attach the rules and practices. In Scrum, you do development in time-boxed intervals called iterations. An iteration is usually between two and four weeks. Each iteration consists of daily inspections. Such an inspection—or daily Scrum, as it’s called—is performed by the team once every day at a preset time.
Figure 3-3. The Scrum skeleton
During these inspections , team members evaluate each other’s work and the activities performed since the last inspection. If necessary adjustments (adaptations) are found, they’re implemented as quickly as possible. The iterations also conclude with inspections, when more adaptations can be made. This cycle repeats until it’s no longer funded.
All the requirements that are known at the beginning of the project are gathered in the product backlog, which is one of the artifacts of Scrum. We come back to this shortly. The project team reviews the backlog and selects which requirements should be included in the first iteration, or sprint, as it’s called in Scrum. These selected requirements are added to the sprint backlog, where they’re broken down into more detailed items (tasks). Later in the chapter, in Figure 3-9, you can see how many teams visualize their work in a sprint using a Scrum board. This can be electronic, as in the figure, or it can be a whiteboard with sticky notes. The board shows the tasks that have been found for each backlog item and where in the development process each task is currently located (development, test, and so on).
The team then makes its best effort to turn the sprint backlog into a shippable increment of the final product. The team is self-managing, which means members collectively decide who does what and what the best way is to solve problems.
The increment is presented to the stakeholder(s) at the end of the sprint so they can inspect it and make any adaptations necessary to the project. The sprint is most often 30 days, although as mentioned earlier, we often see sprints that last two to four weeks. It depends on the sprint backlog items. When I took his Scrum master certification, Ken Schwaber related that he once had a one-week sprint in a project. The reason was that the team malfunctioned, and this way he could more easily catch the reason and adjust the process so the project ran more smoothly.
The stakeholders’ adaptations and feedback are put into the product backlog and prioritized again. Then the team starts the process over and selects the backlog items they think they can finish during the next sprint. These are put into the sprint backlog for the next sprint and broken down into more manageable items. And so it continues, until the stakeholders think they have received the business value they want and funding stops.
If you look again at the three legs of empirical process control, you can see that Scrum covers them nicely. Transparency is implemented by letting the team and stakeholders agree on the expected outcome of the project and of each iteration. Inspection occurs daily and also at the end of each sprint. Adaptations are the direct result of these inspections and a necessary thing in Scrum.
Roles in Scrum
Scrum incorporates different roles. In other models, there are usually many more roles defined in a very strict way, but Scrum has only these three roles:
The product owner
The team
The Scrum master
The Product Owner
Let’s start with the product owner. This person is responsible to those funding the project to deliver a product or a system that gives the best return on investment (ROI) he or she can get from the project. The product owner must acquire the initial funding for the project and make sure it’s funded through its lifespan. The product owner represents everyone with a stake in the project and its result. At the beginning of a project, the product owner gathers the initial requirements and puts them into the product backlog. It’s the product owner who ultimately decides which requirements have the highest priority based on ROI or business value (for example) and decides into which sprint they should go. During the project, the product owner inspects the project and prioritizes the product backlog and sprint backlogs so that the stakeholders’ needs are met.
The Team
The team is responsible for development. There are no specific roles on the team. Because the team is cross-functional and self-organizing, it’s the members’ responsibility to make sure they have the competencies and staff required for solving the problems. It isn’t the Scrum master who decides who does what and when, as a project manager would do in a traditional approach. These are some of the reasons behind this approach, as taught by Ken Schwaber in his Scrum master course:
People are most productive when they manage themselves.
People take their commitment more seriously than other people’s commitment for them (like when a project manager commits that a person should accomplish something).
People always do the best they can.
Under pressure to work harder, developers automatically and increasingly reduce quality.
The team should consist of seven people plus or minus two for optimal results. An optimal physical team consists of 2.5 logical teams. A logical team consists of one programmer, one tester, a half-time analyst/designer, and a half-time technical writer. The team decides which items in the backlog it can manage for each sprint based on the prioritized backlog.
This thinking is a giant leap from traditional project management and takes some getting used to. Some people don’t accept it and find it impossible to work this way.
The Scrum Master
The Scrum masteris responsible for the Scrum process and has to make sure everybody on the team, the product owner, and anyone else involved in the project know and understand the process. The Scrum master makes sure everyone follows the rules and practices of the Scrum process. But the Scrum master doesn’t manage the team—the team is, as you saw, self-managing.
If a conflict occurs in the team, the Scrum master should be the “oil” that helps the team work out its problems smoothly. It’s also the Scrum master’s responsibility to protect the team from the outside world so members can work in peace and quiet during the sprint, focused on delivering business value. The following are the Scrum master’s responsibilities, again according to Ken Schwaber’s course material:
Removing the barriers between development and the customer so the customer directly drives development
Teaching the stakeholders how to maximize ROI and meet their objectives through Scrum
Improving the lives of the development team by facilitating creativity and empowerment
Improving the productivity of the development team in any way possible
Improving the engineering practices and tools so each increment of functionality is potentially shippable
The Scrum Process
Now that you know the basics of Scrum, it’s time to take a look at what happens during a Scrum project. The product owner, after arranging initial funding for the project, puts together the product backlog by gathering functional as well as non-functional requirements . The focus is on turning the product backlog into functionality, and it’s prioritized so the requirements giving the greatest business value or having the highest risk come first. Remember that this approach is a value-up paradigm where you set business value first.
Note
Value up measures value delivered at each point in time and treats the inputs as variable flows rather than as a fixed stock. If you want to learn more about this, see Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer (Addison Wesley, 2006).
Then the product backlog is divided into suggested releases (if necessary), which should be possible to implement immediately. This means when a release is finished, you should be able to put it into production at once so you can start getting the business value as quickly as possible. You don’t have to wait until the entire project is done to begin getting return on your stakeholders’ investments.
Because the Scrum process is adaptive, this is just the starting point. The product backlog and the priorities change during the project as business requirements change and also depending on how well the team succeeds in producing functionality. The constant inspections also affect the process.
When a sprint is starting, it initiates with a sprint planning meeting. At this meeting, the product owner and the team decide, based on the product owner’s prioritization, what will be done during this sprint. The items selected from the product backlog are put into the sprint backlog.
The sprint planning meeting is time-boxed and can’t last more than eight hours. The reason for this strict time-box is that the team wants to avoid too much paperwork about what should be done.
The meeting has two parts. The first four hours include the team and the product owner: the latter presents the highest-priority product backlog issues, and the team questions the product owner about those issues so members know what the requirements mean. The next four hours are used by the team to plan the sprint and break down the selected product backlog items (PBIs) into the sprint backlog.
When the project is rolling, each day starts with a 15-minute daily Scrum or stand-up meeting (see Figure 3-4). This is the 24-hour inspection. During this meeting, each team member answers three questions:
Figure 3-4. The sprint in Scrum
What did I do yesterday that helped the development team meet the sprint goal?
What will I do today to help the development team meet the sprint goal?
Do I see any impediment that prevents me or the development team from meeting the sprint goal?
The reason for this meeting is to catch problems and hence be able to make timely adjustments to the process. It’s the Scrum master’s responsibility to help team members get rid of any impediments they may have.
When a sprint comes to an end, the stakeholders perform a sprint review. This meeting is also time-boxed, but at four hours instead of eight. The product owner and the stakeholders get a chance to see what the team has produced during the sprint and reflect on it. But it’s important to remember that this meeting isn’t a demonstration: it’s a collaborative meeting of the people involved.
Now there is only one meeting left: the sprint retrospective. It takes place between the sprint review and the next sprint planning meeting. It’s time-boxed at three hours. The Scrum master encourages the team to adjust the development process, still within the Scrum process and practices framework boundaries, so that the process can be more effective for the next sprint.
Some think that documentation and planning aren’t necessary in Scrum. Developers like this idea because they don’t want to write documents, whereas stakeholders tremble at the thought. But nothing could be further from the truth. Scrum doesn’t say you don’t document or a plan. The contrary is true. Planning, for instance, is done every day, during the daily Scrum (see Figure 3-5). Documents should also be written, but you scale away documents that aren’t necessary—those that are produced only for the sake of documentation and are almost never read after they’re produced. You document what is needed for the system and the project. You document your code, you document traceability, and so on.
Figure 3-5. Planning in Scrum
That’s basically it. Scrum is a lean process and appeals a great deal to us. Joachim had the privilege of doing his Scrum master certification during a course held by Ken Schwaber and his product owner certification training at a course held by Mike Cohn; these are two of the legends in the agile world. Unfortunately, some customers and stakeholders find Scrum a bit vague, so they won’t try it. They think they have more control with the way they used to run projects and are perhaps afraid to embrace this modern way of doing projects. This hasn’t changed over the years, although more and more people we meet have seen what Scrum and agile can do to help them run better projects.
We’ve found that some companies think they’re using Scrum just because they develop iteratively. In many cases, they have changed the Scrum process so that it won’t help them solve their development problems—problems that are clearly visible in a true Scrum project. Instead, they use Scrum like makeup to cover the bad spots; and when the project still fails, they argue that Scrum doesn’t work—they still don’t deliver value, they still have overruns, and so on. When you’re implementing Scrum, follow the process and framework, and adjust the organization to Scrum, not the Scrum process to the organization. This can be a real problem in some organizations where, as we said, management resists change and won’t use Scrum or agile for the simple reason that they think they will lose control. If you aren’t in a position to enforce a new way of working, you need to consider how to most efficiently push management in the agile direction.
Definition of Done
The Definition of Done (DoD) is very important, but it also tends to be forgotten. In many projects, at the end of (or during) a sprint or the project, we’ve seen arguments between the delivering development organization and the person ordering the project about whether a task has been done. Perhaps testing was not done the way the client assumed it would be, or the software doesn’t comply with certain regulations. The following conversation is typical:
The product owner (PO), Sofia, stops by the office of developer Mike to check on how things are going.
S: “Hi. How’s the new cool feature you’re working on coming along?”
M: “It’s going great. I’m done with it right now and will start the next feature soon.”
S: “Great! Then I can show it to our customer, who’s coming here after lunch. He’ll be very excited!”
M: “No, no. Hold on. I am not ‘done’ done with it. I still need to fix some test cases, do some refactoring, get it into the build process, and so on. I thought you were wondering if I had gotten somewhere with it …”
For the most part, such arguments can be avoided if people sit down together at the beginning and write and sign a DoD.
There are other reasons for having a DoD, as well. In order for the team to estimate a user story, the members need to know when they’re done with it. Otherwise, it’s very hard to complete the estimate. For a specific user story, you know it’s done when you’ve fulfilled its acceptance criteria. But where do all those general things like style guides, code analysis, build automation, test automation, regulatory compliance, governance, non-functional requirements, and so on, fit in? They affect the estimate of a user story as well.
Here is where the DoD comes into play. The DoD tells you what requirements in addition to the user story’s acceptance criteria you need to fulfill in order to be done with the story. You include the general requirements in the DoD because they affect all user stories in the end.
The DoD is your primary quality document. If you don’t fulfill what is in it, you don’t deliver quality. It’s essential that the PO and the team agree on the DoD. The DoD is part of the agreement between the team and the PO.
There shouldn’t be an argument over this concept during the project. If the PO thinks it’s too costly to use pair programming or test-driven development (TDD), have the PO sign the DoD, which specifies that these things have been removed. If, at the end of a sprint, the PO complains about the number of bugs, you can present the document and say that the PO removed essential parts of the testing process, and hence bugs will be present.
A good starting point for a DoD for an approved user story could be something like the following:
All code is written and checked in (including tests)
Coding conventions have been fulfilled (these are documented in a separate document and not included here)
All unit tests have been passed (must be okay before check-in)
Code is refactored (improved/optimized without change of function)
All code has been reviewed by at least two people (peer programming or peer review)
The user story is included in the build (build scripts updated, all new modules included)
The user story is installable (build scripts updated so the story is included in the automatic install)
All acceptance tests have been passed:
Acceptance criteria must exist
Acceptance tests are implemented (automatic or manual tests)
The backlog has been updated as follows:
All tasks’ remaining time is 0
The user story state is Done
Actual Hours has been updated
All tasks are Done
The user story has been installed on Demoserver
The user story has been reviewed by the PO
The user story has been approved by the PO
Product documentation has been updated and checked in
A user manual has been written
The administrative manual has been updated
Help texts have been written
You could also have a DoD like the following for when the sprint is finished:
All user stories in the sprint fulfill the DoD
The product has been versioned (release management/rollback)
All accepted bugs have been corrected
New bugs that have been identified are closed and/or parked
80% code coverage from automated tests is fulfilled
All chores are done and approved
All integration tests have been passed
The sprint retrospective has taken place, and actions for improvements have been identified
The sprint review has taken place with the PO present
A performance test of the complete system has been done
Let’s continue by looking at how you can manage requirements and estimations with an agile mindset.
Agile Requirements and Estimation
Agile requirements and estimation is a huge but important topic. This section covers some of the most important topics here, but there are a lot of ways you can manage requirements and estimates. If you want to master this subject, there are several training modules you can take and books to read. A good starting point is to visit www.scrum.org or www.scrumalliance.com and see what they currently suggest.
Most of the agile planning and estimation tips and tricks in this chapter come from the agile community but aren’t specific to Scrum. Scrum really doesn’t tell you how to do specific things like planning, estimation, and so on. Scrum is the process framework or process method you use for running your agile projects. However, Scrum works very well with the concepts we look at next.
Requirements
In agile projects, you usually represent requirements in something called user stories. These can be looked at as fluffy requirements—a bit like use cases. You write user stories like this:
As a <type of user> I want <some functionality> so I may have <some business value>.
One example could be
As a manager I want my consultants to be able to send in expense reports through the Internet so that I can be more efficient in my expense report process.
Figure 3-6 shows how Microsoft has implemented a user story into the work item type Product Backlog Item in Microsoft Team Foundation Server (TFS). The terminology is a little different from the previous description, but it works.
Figure 3-6. The user story implementation in the Scrum template Microsoft provides with TFS
User stories capture requirements at a high level and aren’t tangled up with detailed functions or implementation details. The details and non-functional requirements are instead captured as acceptance criteria for the user story. Based on these acceptance criteria, you can develop acceptance tests at the same time you write the requirements.
The DoD is also important here because it describes other important requirements that all user stories need to fulfill before they’re done.
So, how can you begin gathering requirements before you start a project? POs should use any method they think is suitable. We often use story-writing workshops where important stakeholders, end users, business analysts, experienced developers, and others participate to brainstorm the user stories they can think of. During such a workshop, you focus on the big picture and don’t dive into details. These big user stories are often called epics because they’re large and not broken down yet.
But don’t you need to find all requirements at the beginning? No. And that is what makes agile so great. The agile concept builds on the fact that you acknowledge that you don’t know and can’t know all the requirements early in the project. New requirements and changes to early requirements will pop up throughout the process, and that’s okay. The agile approach takes care of this for you. You start with what you have initially, and you continue handling requirements throughout the project. The short version is that you get started right a way and are aware that changes and new requirements will come along.
When the initial requirements are finished, you have the embryo of the product backlog. However, before you can prioritize and estimate these user stories, you need to perform a risk assessment so you can get a grip on the risks associated with each and every one of them. A user story with a significant risk associated with it usually takes more effort to finish and should probably be done early in development.
Estimation
To know how much effort is involved with a user story, you need to estimate it. The sum of all initial estimates gives you a (very) rough estimate of how much time the entire project may take. But because you know things usually change over time, you don’t consider this estimate written in stone.
You have what you need to do estimation: you know the requirements, you have a DoD, and you have acceptance criteria. In the agile world, it’s recommended that you estimate time in something called story points. Story points aren’t an exact size—instead, they’re relative.
Here is an easy example we use when running agile training. Take four animals—let’s say a cat, a pig, a zebra, and an elephant. Without being a zoologist, most people can say that the pig is three times the size of the cat, the zebra is twice the size of a pig, and the elephant is maybe four times the size of the zebra. If you have a couple of people sit down and discuss these animal sizes, you can pretty soon come up with an agreement about their relative sizes.
The same goes for user stories. Most developers can agree pretty quickly about the relative size of user stories. User story A is twice as big as user story B, and so on. You don’t need to be very experienced with the details of each user story to reach this agreement. Novice developers usually end up with the same estimates as experienced ones. Keep in mind that you aren’t talking exact time yet, only relative size.
The most common scale for expressing story points is a modified Fibonacci scale. This scale follows the sequence 1, 2, 3, 5, 8, 13, 20, 40, 100.
Often, teams use a technique called planning pokerwhen making estimates. Each player has a deck of cards containing the numbers from the modified Fibonacci scale. Here is how planning poker goes:
1. The PO/Scrum master (SM) reads the first user story.
2. The team members briefly consider the user story and select a card each, without showing it to the others.
3. The team members show their cards at the same time.
4. If the result varies much, the people with the highest and lowest cards explain their reasoning.
5. After a short discussion, the team plays again.
6. When consensus is reached (or the team members are only one step apart), you’re finished.
7. If the team still disagrees, you pick the highest value.
But what about time? How do you get down to time? You need to know several things to estimate time. The first is team capacity. Consider the following when calculating team capacity:
How long is the sprint?
How many working days are available in the sprint?
How many days does each team member work during the sprint? Consider planned vacation or other days off, planned meetings, and so on.
Deduct the time for sprint planning, review, and retrospective meetings.
The result is the capacity before drag (drag is waste time or unknown activities). You should measure drag in each sprint, but at the initial planning it’s hard to know how much to include. The longer the project, the more accurate the drag. If you don’t know from experience what the drag is, 25% is a good landmark; included in this is 10% backlog grooming.
Now you have the available number of hours in the sprint, and you can connect points and time. You need to know the team velocity, which is the number of story points the team can handle in a sprint. Initially this is impossible to know. The easiest way to figure it out is to perform a sprint planning meeting and create a theoretical team velocity. At this meeting, the team breaks down a user story into manageable tasks—and this is where time becomes interesting. During this meeting, the team estimates tasks in hours so they can plan the sprint and decide how many user stories they can take on. The team usually does this as follows:
1. Estimate the first user story in detail.
2. Break down what the team needs to do to deliver the story.
3. Estimate hours for each activity and summarize.
4. Deduct the summary from the available time the team has in the sprint.
5. Is there still time left?
6. If so, take a new user story and repeat the process until no time is left.
7. Summarize the number of story points from the stories included in the sprint.
Now you have a theoretical velocity.
At this point you can make a rough time plan for the entire project (at this point). This is good input for the POs in their discussions with stakeholders, and also for ROI calculations.
The sprint planning process continues throughout the project, and the theoretical velocity can soon be replaced with one based on experience.
Backlog
When the initial user stories are in place and estimated with story points, the PO can begin prioritizing the backlog. In Scrum, this is called ordering the backlog. Based on the business needs, the PO makes sure the order of the backlog reflects what the business wants. In Figure 3-7, you can see a backlog in Visual Studio Team Services. Usually we do a rough estimate for each backlog item and then a velocity planning. After that, we can see what backlog items should be completed during which sprint.
Figure 3-7. A sample backlog in Visual Studio Team Services
The PO needs to keep the backlog in good shape throughout the project. This means it needs to be ordered. It also needs fine granularity at the top (perhaps three or four sprints down the list) and rougher granularity further down. Keeping the backlog in your ALM toolset gives you the benefit of visibility and traceability. In the best of all worlds, you can link backlog items to code, check-ins, builds, and so on, giving you good traceability.
The PO can also start to look at release planning at this point. It’s important to get an overview of coming releases, especially if you have a larger project. Release planning can be done on the epics (the larger user stories). A good approach is to look for themes among the user stories. What could be useful to release at the same time? If you find such features, you can make a theme from them and plan the theme for a certain release.
When this is done, you can also do a very rough time estimate on the releases—and suddenly you also have a rough time plan for the entire project.
Now you have as much information as you could possibly ask for this early in a project. The next step is the sprint planning meeting, when the team members (as you saw earlier) select the backlog items they feel they can commit to during the sprint.
During the Sprint
During the sprint, you use several important meetings to inspect and adapt your process. We already covered the sprint planning meeting, which takes place at the start of each sprint. But there are other meetings as well, all important to the agile team.
Daily Stand-Up
The daily stand-up is a meeting that takes place every day during the sprint. This is primarily a developer team meeting and is used to provide status updates to the team members. As the name suggests, this is a stand-up meeting: this comes from the practice of having attendees stand at a meeting because the discomfort of standing for long periods helps keep the meeting short.
The daily stand-ups are kept short, at around 15 minutes, so participants should be reminded that it isn’t a working meeting.
As mentioned earlier, all participants should answer these three questions:
What did I do yesterday that helped the development team meet the sprint goal?
What will I do today to help the development team meet the sprint goal?
Do I see any impediment that prevents me or the development team from meeting the sprint goal?
Though it may not be practical to limit all discussion to these three questions, the goal is to stick as closely as possible to them. If further discussions are needed, they should be scheduled for after the meeting. For instance, when team members ask for short clarifications and brief statements, they should try to remember that they should talk about those more after the meeting.
One of the important features of the daily stand-up is that it’s intended to be a communication meeting for team members and not a status update for management or other stakeholders. However, it can be valuable for POs to participate in the meeting so they can catch any issues they need to get involved in. This can remove the need for other status meetings afterward.
The meeting is usually held at the same time and place every working day. All team members are encouraged to attend, but the meetings aren’t postponed if some team members aren’t present.
This practice also promotes closer working relationships with its frequency, need for follow-up conversations, and short duration, which in turn results in a higher rate of knowledge transfer—a much more active result than a typical status meeting.
Sprint Review
Once the sprint has come to an end, you hold another important meeting: the sprint review. At this meeting, the development team shows the result of what they did during the sprint. They show only the potentially shippable increments of software that they finished during the sprint. Typically this is accomplished using a demo.
Most often the PO, the development team, management, customers, and developers from other projects participate in the sprint review. During the meeting, the project is assessed against the sprint goal determined during the sprint planning meeting. Ideally the team has completed each product backlog item brought into the sprint, but it’s more important that the team achieves the overall goal of the sprint.
If some PBIs aren’t finished during the sprint, they’re put back on the project backlog, and the PO needs to prioritize them for the coming sprint.
Sprint Retrospective
The most important meeting takes place after the sprint review. This meeting is often the last thing that happens in a sprint and is called the sprint retrospective. It’s an opportunity for the team to learn from mistakes by inspecting the sprint and adapting to the results of the inspection. No matter how good a Scrum team is, there are always opportunities to improve. A good Scrum team constantly looks for improvement opportunities, and the team should set aside a brief, dedicated period at the end of each sprint to deliberately reflect on how it’s doing and to find ways to improve. Hence the sprint retrospective.
Participants in this meeting should be the development team, the SM, and the PO. Set aside about an hour for this meeting.
There are many ways to do a sprint retrospective. One way is to let the team come up with what was good and what was bad during the sprint. Note these items on a board, and then select (by voting) a number of topics (three to five) from the bad side. Then create action plans for how to improve on them.
Another way is a start-stop-continue meeting. Using this approach, each team member is asked to identify specific things that the team should
Start doing
Stop doing
Continue doing
After an initial list of ideas has been brainstormed, team members proceed and create action plans for how to improve on the “stop doing” issues At the end of the sprint, the next retrospective is often begun by reviewing the list of things selected for attention in the prior retrospective.
Now that you have seen how Scrum is supposed to work, I want to discuss some other agile methodologies that are very commonly used. Scrum is a great process (or rather framework), but it is not the best choice for all organizations or projects.
Kanban
We’d like to present another method that is usually mentioned with the agile frameworks. Kanban is very popular in many organizations and is used by one of our customers today. Even though our preferred project-management method is Scrum for development projects, we realize that Scrum isn’t perfect in every situation. Scrum can be scary in the sense that it requires major changes in the way people work in their organizations. It can be hard to implement Scrum fully because humans seem to have an inherent resistance to change. And if you don’t have management with you, it’s even harder to implement. Wouldn’t it be great if you could find a process that was agile but that made it possible for you to make the changes gradually?
Operations can also be difficult to perform using Scrum. Think about this situation for a moment. Let’s assume you have three-week sprints for your operations team. One week into a sprint, you suddenly realize that there is a bug in the system that affects production. This bug needs to be fixed right away, so you write a backlog item and present it to the product owner. You need to bring it to the next sprint planning meeting, two weeks from now. Then it will take three weeks for the bug to be fixed, because you have three-week sprints. In the worst case, you’ll have to wait five weeks before the fix is available for deployment.
Of course, this is a rare situation. There are obviously ways to handle this better using Scrum. You could, for instance, always have a product backlog item (PBI) of 10% of your available time set aside for bug fixes, and put this PBI at the top of your sprint backlog, allowing you to work on bugs as they’re discovered. But we still don’t think Scrum is optimal for operations work. This is why we started to look at Kanban.
The name Kanban comes from the Japanese word for signboard. Kanban goes back to the early days of the Toyota production system. Between 1940 and 1950, Taiichi Ohno developed kanbans to control production between processes and to implement just-in-time (JIT) manufacturing at Toyota manufacturing plants in Japan. The Kanban method was developed by David J. Anderson and is an approach to an incremental, evolutionary process as well as systems change for organizations.10 By using a work-in-progress limited pull system as the core mechanism, it exposes system operation (or process) problems. In such a pull system, tasks that are to be performed are pulled into the workflow, like when you pull a PBI into the sprint backlog. But you can only pull a task into the workflow when there is free capacity to handle the task. It also stimulates collaboration to continuously improving the system.
The Kanban method has three basic principles: 11
Start with what you do now.
Agree to pursue incremental, evolutionary change.
Respect the current process, roles, responsibilities, and titles.
Let’s take a closer look at these.
Start With What You Do Now
The Kanban method doesn’t prescribe a specific set of roles or process steps. There is no such thing as the Kanban Software Development Process or the Kanban Project Management Method. The Kanban method starts with the roles and processes you have and stimulates continuous, incremental, and evolutionary changes to your system. This is the thing we like the best about Kanban. It allows you to continue using what you’ve invested in; the biggest difference is that you can implement big improvements to the existing process without worrying employees.
Agree to Pursue Incremental, Evolutionary Change
The organization (or team) must agree that continuous, incremental, and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective, but more often than not they fail due to resistance and fear in the organization. The Kanban method encourages continuous, small, incremental, and evolutionary changes to your current system.
Respect the Current Process, Roles, Responsibilities, and Titles
It’s likely that the organization currently has some elements that work acceptably and are worth preserving. You must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities, and job titles , you eliminate initial fears. This should enable you to gain broader support for your Kanban initiative. Presenting Kanban as compared to an alternative, more sweeping approach that would lead to changes in titles, roles, and responsibilities and perhaps the wholesale removal of certain positions may help individuals realize the benefits of this approach.
The Five Core Properties
David Anderson, in his book Kanban, identified five core properties that are part of each successful implementation of the Kanban method:
Visualize the workflow .
Limit work in progress (WIP).
Manage flow.
Make process policies explicit.
Improve collaboratively.
Let’s look at these and learn what they mean.
Visualize the Workflow
The knowledge work of today hides its workflow in information systems. In order to understand how work works, so to speak, it’s important to visualize the flow of work. The right changes are harder to perform if you don’t understand the workflow. One common way to visualize the workflow is by using a wall with cards and columns, called a Kanban board. The columns on the card wall represent the different states or steps in the workflow, and the cards represent the feature/story/task/result of the workflow, usually referred to as work items.
What is great is that you use the steps of your existing workflow—you don’t need to enforce a new way of working that dramatically changes the current approach. You basically place the Kanban process on top of what you have, and visualize this flow. This often feels more comfortable to co-workers and makes them more positive about the small changes you’re imposing on them.
Figure 3-8 shows the Kanban board that is used to visualize the flow. But wait, some may say: isn’t this just like a Scrum board, shown in Figure 3-9? Yes, but there is one significant difference if you compare the figures closely. Above each Kanban board column is a number that identifies the WIP limit. This takes us to the next core property: limit work in progress.
Figure 3-8. A Kanban board
Figure 3-9. A Scrum board
Limit Work in Process (WIP)
The WIP limit is important and tells you how many work items you can have in each step (column on the Kanban board). When the limit is reached, you can’t pull any new items into this step until a work item leaves the step. Limiting WIP implies that a pull system is implemented on parts of or all of the workflow. The pull system acts as one of the main stimuli for continuous, incremental, evolutionary changes to your system. It’s important, even critical, that WIP is limited at each stage in the workflow.
Manage Flow
The flow of work through each stage in the workflow should be monitored, measured, and reported. By actively managing the flow, the continuous, incremental, and evolutionary changes to the system can be evaluated to determine if they have positive or negative effects on the system.
If a step in your workflow is full, you can’t bring any new items into this step. Looking at the board, you can easily see if there is a bottleneck in your flow. If you discover that all columns to the right of the development step on your board are empty, but the development step is full (see Figure 3-10), this means something is stopping development, and people working on development can’t finalize their work. You should use idle resources to try to help the developers solve what is stopping them so you can restart the flow and begin pulling new work items into the steps. By having this visibility, you can manage your flow and make sure you handle problems as they arise.
Figure 3-10. A bottleneck in the flow has been discovered
Make Process Policies Explicit
It’s often hard to improve, or even start a discussion of improving, a process until the mechanism of the process is made explicit. Without an explicit understanding of how things work and how work is actually done, any discussion of problems often seems subjective or emotional. To get a more rational, empirical, and objective discussion of issues, explicit understanding is important. This will most likely lead to consensus around improvement suggestions.
Improve Collaboratively (Using Models and the Scientific Method)
Kanban encourages small, continuous, incremental, and evolutionary changes that stick. David Anderson also discovered this was very effective. Resistance to change, as we’ve mentioned, is easier to overcome if the steps are small and each step has a great payback. Teams that have a shared understanding of theories about work, workflow, process, and risk are more likely to be able to build a common understanding of a problem and thereby suggest improvement actions that can be agreed on by consensus. The Kanban method proposes a scientific approach to be used to implement continuous, incremental, and evolutionary changes. But the method doesn’t prescribe a specific scientific method to use.
Common Models Used to Understand Work in Kanban
Some common models are often used with Kanban to understand how work actually works. We don’t go into these in detail, but include them for reference:
The Theory of Constraints (the study of bottlenecks)
The System of Profound Knowledge (a study of variation and how it affects processes)
Lean Economic Model (based on the concepts of “waste” [or muda, muri, and mura])
Extreme Programming
Extreme Programming (XP) is a deliberate and disciplined approach to software development. XP, like Scrum, was a direct outcome of the Agile Manifesto and incorporates many of its values. Aspects of these models had been in the minds of their founders for a long time, though, and used in many projects. XP stresses customer satisfaction, an important part of the Agile Manifesto. The methodology is designed to deliver the software the customer needs, when it’s needed. XP focuses on responding to changing customer requirements, even late in the lifecycle, so that customer satisfaction (business value) is assured.
XP also emphasizes teamwork. Managers, customers, and developers are all part of a team dedicated to delivering high-quality software. XP implements a simple and effective way to handle teamwork.
There are four ways XP improves software teamwork:
Communication: It’s essential that XP programmers communicate with their customers and fellow programmers.
Simplicity: The design should be simple and clean.
Feedback: Feedback is supplied by testing the software from the first day of development. Testing is done by writing the unit tests before even writing the code. This is called TDD, and it is becoming a frequently used practice in many projects, not only agile ones. You see later how Team Foundation Server (TFS) implements TDD.
Courage: The software should be delivered to the customers as early as possible, and a goal is to implement changes as suggested. XP stresses that developers should be able to courageously respond to changing requirements and technology based on this foundation.
RUP has use cases, and XP has user stories. These serve the same purpose as use cases, but they aren’t the same. They’re used to create time estimates for the project and also replace bulky requirements documentation. The stakeholders (managers, end users, project sponsors, and so on) are responsible for writing the user stories, which should be about things the system needs to do for them. Stakeholders write stories because they’re the ones who know what functionality they need and desire—developers rarely have this kind of information. Each user story consists of about three sentences of text written by the stakeholder in the stakeholder’s own terminology, without any of the technical software jargon that a developer may use.
Another important issue is that XP stresses the importance of delivering working software in increments so the customer can give feedback as early as possible. By expecting that this will happen, developers are ready to implement changes.
The last topic we want to highlight with XP is pair programming. All code to be included in a production release is created by two people working together at a single computer. This approach increases software quality without impacting time to delivery. Although we’ve never had the benefit of trying this ourselves, co-workers we’ve spoken to who have used pair programming are confident that it adds as much functionality as two developers working separately. The difference is that quality is much higher. Laurie Williams of the University of Utah in Salt Lake City has shown that pair programmers are 15% slower than two independent individual programmers, but “error-free” code increases from 70% to 85%.12 In our opinion, this more than makes up for the decrease in speed.
We can make a reference to my old job as an assistant air-traffic controller here. Many are the times he sat in the tower when airplane traffic was so heavy that he needed help keeping track of every airplane. Although this isn’t the same thing, the fact remains that two pairs of eyes see more than one pair—and this is what makes pair programming so attractive.
To learn more about extreme programming, we encourage you to visit www.extremeprogramming.org/.
Scaling Scrum
What happens if you have more team members than can fit on a Scrum team (seven plus/minus two people)? What if 90 people are involved in the project? Can Scrum scale to handle this? According to Mike Cohn, in an article on the Scrum Alliance web site,13 you can use a process called Scrum of Scrums:
The Scrum of Scrums meeting is an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration. Imagine a perfectly balanced project comprising seven teams each with seven team members. Each of the seven teams would conduct (simultaneously or sequentially) its own daily Scrum meeting. Each team would then designate one person to also attend a Scrum of Scrums meeting. The decision of who to send should belong to the team. Usually the person chosen should be a technical contributor on the team—a programmer, tester, database administrator, designer, and so on—rather than a product owner or Scrum master.
By using this technique, you can scale Scrum infinitely, at least in theory.
But there are other ways to scale Scrum and agile as well. We will take a look at two of them here:
Scaled Agile Framework (SAFe)
Scaled Professional Scrum (SPS)
SAFe
Dean Leffingwell’s SAFe, the Scaled Agile Framework (Figure 3-11), is designed by Scaled Agile, Inc. SAFe allows large organizations to move toward a more agile way of working. And by large I mean more than 1,000 people in IT, and more than 250 in software development. But SAFe can be just as effective for teams of 50–100 people.
Figure 3-11. SAFe—The big picture
The debate on how best to scale up the Scrum (and the agile methodology) have sometimes been high. Especially how to do this in large organizations, which often operate their projects in an application environment with several subprojects and many Scrum teams. Much debate has concerned how to best synchronize the development work with multiple teams or subprojects running simultaneously and where people work toward a common goal. Scaled Agile Framework (SAFe) has been developed in order to benefit these organizations and the difficulties they may encounter.
In SAFe the synchronization occurs at many different levels. Roles and activities are organized around something called an Agile Release Trains (ART). These trains depart on a predetermined schedule that gives an opportunity to plan and synchronize releases on a program level.
The agile development team in SAFe consists of cross-functional individuals (8-10) who have the ability and confidence to define, build, and test a solution or system in an iterative workflow. The team consists of developers, testers, a Scrum master, a product owner, and any other necessary skills for the team to succeed in delivering business value. Because teams often use XP techniques, they are often known as a SAFe ScrumXP team.
Several teams create what SAFe calls a release train, which organizes around a program. An ART can have multiple ScrumXP teams, which together build the solution. Each team has its own backlog, which is an excerpt of the overall program backlog. This places high demands on how to synchronize data and work between the team. This occurs in different ways.
ScrumXP teams are the force behind a release train and to sync with other teams all product owners meet in an expanded product ownership team. Additionally, each team’s iterations sync with the other teams to coordinate the construction of the solution.
A further option to sync the teams with each other is through the Scrum of Scrum meetings. These are meetings where representatives of the different ScrumXP teams meet. They are held at least every week but more often when necessary.
In SAFe, the team’s work is synchronized on several different levels in order to maintain a good and stable pace and keep the solution together at a higher level than just the team level. You can find more information about SAFe at http://www.scaledagileframework.com .
SAFe is one way to scale Scrum. We will now take a look at another way that originates from Ken Schwaber and Scrum.org.
Scaled Professional Scrum (SPS)
In Scaled Professional Scrum , a Nexus (nexusguide.org) is an exoskeleton that rests on top of multiple scrum teams when they are combined to create an integrated increment. Nexus is consistent with Scrum and its parts will be familiar to those who have worked on Scrum projects. The difference is that this method pays more attention to dependencies and interoperation between scrum teams, delivering one “done” integrated increment at least every sprint.
The result can be an effective development group of up to around 90 people. Scrum.org recommends 3-9 Scrum teams with 3-9 developers. This includes the Nexus Integration Team. For larger initiatives, the Nexus becomes a unit of scale. This is called Nexus+, a unification of more than one Nexus.
As displayed in Figure 3-12, 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 the Product Owner, a Scrum master, and 3-9 developers.
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 raise this 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. Backlog refinement has become a proper event as well. This is an important practice for single teams but at scale it becomes mandatory.
Figure 3-12. The Nexus framework (nexusguide.org)
All work in a Nexus may be done by all members of the Scrum teams, as cross-functional members of the Nexus. Based on dependencies, the teams may select the most appropriate members to do specific work.
Refine the product backlog: The product backlog needs to be decomposed so that dependencies are identified and removed or minimized. Product backlog items are refined into thinly sliced pieces of functionality and the team likely to do the work should be identified as early as possible.
Nexus sprint planning: Appropriate representatives from each Scrum team meet to discuss and review the refined product backlog. They select product backlog items for each team. Each Scrum team then plans its own sprint, interacting with other teams as appropriate. The outcome is a set of sprint goals that align with the overarching Nexus goal, each Scrum team’s sprint backlog, and a single Nexus sprint backlog. The Nexus sprint backlog makes the Scrum team’s selected product backlog items and any dependencies transparent.
Development work: All teams develop software, frequently integrating their work into a common environment that can be tested to ensure that the integration is done.
Nexus daily Scrum: Appropriate representatives from each Scrum development team meet daily to identify if any integration issues exist. If identified, this information is transferred back to each Scrum development team’s daily Scrum. Scrum development teams then use their daily Scrum to create a plan for the day, being sure to address the integration issues raised during the Nexus daily scrum.
Nexus sprint review: All teams meet with the appropriate stakeholders to review the integrated increment. Stakeholder feedback may result in adjustments to the product backlog.
Nexus Sprint Retrospective: Appropriate representatives from each Scrum team meet to identify shared challenges. Then, each Scrum team holds individual sprint retrospectives. Appropriate representatives from each team meet again to discuss any actions needed based on shared challenges to provide bottom-up intelligence.
SAFe and SPS take different approaches to scaling Scrum. I have seen some efforts to use SAFe at some larger customers but I still wait for long-term results in order to evaluate them better.
How Agile Maps to ALM
According to Forrester, agile adoption has brought about significant support for ALM practices.14 The agile way of working using frequent inspection and adaption coupled with increased delivery cadence has made teams more disciplined in their way of working. When agile was introduced, many people thought the opposite would be true; but reality has proved them wrong.
What parts of agile map to the ALM process? Let’s look at what Forrester says.
Agile Captures Task-Based Work
Daily stand-up meetings allow team members to report progress against their tasks . As you’ve seen in this chapter, the PBIs are broken down into tasks during sprint planning, and each task is reported on, aggregating the results to the original PBI. Using digital tooling for this—such as Mylyn from Tasktop and TFS from Microsoft—allows you to capture effort, time, and other metadata, which can provide valuable insight into the real progress of your software development.
Increased Frequency of Inspection
The iterative approach to development improves the frequency of inspection. During each sprint, you have project inspection at each daily stand-up. At the end of a sprint, during the sprint retrospective, you define what you’ve done well and what needs to be improved. This improves the feedback loop and, together with better visibility for reporting and traceability, has far-reaching implications for ALM.
Many Tools Collect Much Information
Many agile teams use tools that help them collect build and integration information in their continuous integration flow. This improves visibility into the build process as well as traceability, because the tools often allow the team to see which requirements, work items, and tests each build included.
Note
“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily, leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.” —Martin Fowler15
Test Artifacts Are Important
Agile teams often use test-driven development and increase the importance of test artifacts . Business analysts and quality assurance practices are converging, which is something that agile methods encourage. Agile’s emphasis on the definition of done and frequent inspection increases the desire to link work items with test plans and cases. The result is that agile teams create simpler requirements but see higher integration with test assets.
Agile Teams Plan Frequently
Agile teams plan more frequently than traditional teams. Planning takes place when creating work items, during sprint planning, during daily stand-ups, during backlog grooming, and so on.
As a result, agile teams have more information about their projects, such as estimates, actual results, and predictions. This enables ALM to move center stage, because planning activities are an important management component of an ALM application.
Summary
The goal of this chapter has been to introduce agile concepts. We focused on Scrum and Kanban since they are so commonly used. We looked at the details of Scrum so you can understand why the agile approach maps so well to the ALM process.
We also looked at two ways to scale Scrum and agility in order to become more agile in larger projects or larger organizations.
Using agile techniques can help you with visibility, traceability, and collaboration.
Footnotes
1 Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game,” Harvard Business Review, Jan/Feb 1986, https://hbr.org/1986/01/the-new-new-product-development-game .
2 Peter DeGrace and Leslie Hulet Stahl, “Wicked Problems, Righteous Solutions,” 1990, http://www.gbv.de/dms/ilmenau/toc/608728446.PDF .
4 Jeff Sutherland, “Agile Development: Lessons Learned from the First Scrum,” 2004, www.scrumalliance.org/resources/35 .
5 Ken Schwaber and Mike Beedle, Agile Software Development with Scrum (Prentice Hall, 2001).
6 Ken Schwaber, The Enterprise and Scrum (Microsoft Press, 2007).
7 Ibid.
8 Ibid.
9 Ibid.
10 David J. Anderson, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Prentice Hall, 2003), and Kanban: Successful Evolutionary Change for your Technology Business (Blue Hole Press, 2010).
11 Taiichi Ohno , Norman Bodek , Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988).
12 Laurie Williams et al., Pair Programming Illuminated (Addison-Wesley, 2003).
13 Mike Cohn, “Advice on Conducting the Scrum of Scrums Meeting,” May 7, 2007, www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting .
14 Dave West, “The Time Is Right For ALM 2.0+,” October 19, 2010, Forrester Research, www.forrester.com/The+Time+Is+Right+For+ALM+20/fulltext/-/E-RES56832?objectid=RES56832 .
15 Martin Fowler, “Continuous Integration,” May 1, 2006, http://martinfowler.com/articles/continuousIntegration.html .