Crossing the Agile Divide

Crossing the Agile Divide:

Scrum or Kanban?

by Johanna Rothman, Scott W. Ambler, Suzanne

Robertson, Ron Jeffries, Peter Kaminski, Israel Gat,

Hubert Smits, and Hillel Glazer

In this issue, we depart from our usual Executive Report format to bring you

an opinion piece on a battle confronting the Agile community today: Scrum

versus Kanban. Our lead author, Johanna Rothman, sets forth her argument

that one is not necessarily better than the other; they are just different and

it’s up to the organization to figure out which method is best under which

circumstance. In response, seven of Cutter’s Agile experts discuss their views

on crossing the Agile divide. Each implores those seeking to be Agile to first

and foremost learn and understand the principles behind the practices.

Agile Product & Project Management

Vol. 15, No. 2

NOT FOR DISTRIBUTION • For authorized use, contact

Cutter Consortium: +1 781 648 8700 • [email protected]

The Agile Product & Project ManagementExecutive Report is published bythe Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA 02474-5552, USA.Tel: +1 781 648 8700; Fax: +1 781 6488707; Email: [email protected]; Website:www.cutter.com; Twitter: @cuttertweets;Facebook: Cutter Consortium. GroupPublisher: Kara Letourneau, Email:[email protected]. Managing Editor:Cindy Swain, Email: cswain@ cutter.com.Print ISSN: 1946-7338 (ExecutiveReport, Executive Summary, andExecutive Update); online/electronicISSN: 1554-706X.

©2014 Cutter Consortium. All rightsreserved. Unauthorized reproduction inany form, including photocopying, down-loading electronic copies, posting on theInternet, image scanning, and faxing isagainst the law. Reprints make an excel-lent training tool. For more informationabout reprints and/or back issues of CutterConsortium publications, call +1 781 6488700 or email [email protected].

Cutter Consortium, a unique IT advisory

firm, comprises a group of more than 100

internationally recognized experts who have

come together to offer research, consulting,

training, and executive education. These

experts are committed to delivering top-

level, critical, and objective advice. They

have done, and are doing, groundbreaking

work in organizations worldwide, helping

companies deal with issues in the core

areas of software development and agile

project management, enterprise and busi-

ness architecture, business and technology

trends and strategies, innovation, enterprise

risk management, metrics, and sourcing.

Cutter offers a different value proposition

than other IT research firms: We give you

Access to the Experts. You get practitioners’

points of view, derived from hands-on expe-

rience with the same critical issues you are

facing, not the perspective of a desk-bound

analyst who can only make predictions and

observations on what’s happening in the

marketplace. With Cutter Consortium, you

get the best practices and lessons learned

from the world’s leading experts — experts

who are implementing these techniques at

companies like yours right now.

You can tap into this expertise via print and

online research services and journals, men-

toring, workshops, training, and consulting.

And by customizing our information prod-

ucts, training, and consulting services, you

get the solutions you need while staying

within your budget.

Cutter Consortium’s philosophy is that there

is no single right solution for all enterprises,

or all departments within one enterprise,

or even all projects within a department.

Cutter believes that the complexity of the

business technology issues confronting

corporations today demands multiple

detailed perspectives from which a company

can view its opportunities and risks in order

to make the right strategic and tactical

decisions. The simplistic pronouncements

other analyst firms make do not take into

account the unique situation of each

organization. This is another reason we

present the several sides to each issue:

so you can determine the course of action

that best fits your unique situation.

Expert Consultants

Cutter Consortium products and services are

provided by the top thinkers in IT today —

a distinguished group of internationally

recognized experts committed to providing

top-level, critical, objective advice. They

create all the written deliverables and

perform all the consulting. That’s why

we say Cutter Consortium gives you

Access to the Experts.

For more information, contact

Cutter Consortium at +1 781 648 8700

or [email protected].

ABOUT CUTTER CONSORTIUM

Access to the Experts

Agile Product & Project Management

Cutter Business Technology Council

Rob Austin Ron Blitstein Tom DeMarco Lynne Ellyn Israel Gat Vince Kellen Tim Lister Lou Mazzucchelli Ken Orr Robert Scott

THERE’S NOTHING NEW ABOUT AGILE BY JOHANNA ROTHMAN

Have you noticed the Agile community seems to be more polarized than

ever these days? In one corner, we have the Scrum advocates: “Scrum is

the way to transform your organization to Agile.” In the other corner, we

have the Kanban camp: “Kanban does not require a wholesale cultural

change. You can use Kanban and make the changes you need in an

evolutionary way to Agile.” How can they both be right?

I am not religious about the Agile approach I use. I am agnostic. Maybe

it’s time for a little history.

How Did We Get Here?

In project management, timeboxes have been around forever. I have

taught about timeboxes, and have used them to accomplish feature-

based work, since I began teaching project management back in 1992.

Timeboxes and feature-based work weren’t exactly new back then.

In 1990, Peter DeGrace and Leslie Stahl wrote a small book called

Wicked Problems, Righteous Solutions, where they tackled the obstacles

with waterfall.1 They discussed a couple of team approaches: Sashimi

and Scrum. Yes, they used the word ”Scrum”:

Everyone on the team acts together with everybody else to “move the

ball down the field.” This team pack is called a Scrum.

Six years later, Steve McConnell published Rapid Development: Taming

Wild Software Schedules.2 In that book, he described two incremental

lifecycles: staged delivery and design to schedule. As a developer,

tester, project manager, and program manager, I had used both

lifecycles. McConnell also discussed a “prioritized list of features.”

Does that sound like a ranked backlog to you?

As far as I know, McConnell’s Rapid Development was the first popular

book in the software industry to mention approaches that included

a ranked backlog, iterative or incremental approaches, and ways of

organizing teams other than by function.

Following these two publications, we saw several other books hit

the shelves and came across many articles in popular magazines. As

early as 1997, I wrote about iterative planning.3 And Agile pioneer

Jim Highsmith published his book Adaptive Software Development in

1999.4 By the time the Agile Manifesto came around in 2001, the idea of

iterative planning and incremental development was well established.

1©2014 Cutter Information LLC Vol. 15, No. 2, 22 April 2014 AGILE PRODUCT & PROJECT MANAGEMENT

Crossing the Agile Divide: Scrum or Kanban?

1DeGrace, Peter, and Leslie Hulet Stahl.Wicked Problems, Righteous Solutions:A Catalogue of Modern Software EngineeringParadigms. Prentice Hall, 1990.

2McConnell, Steve. Rapid Development:Taming Wild Software Schedules. MicrosoftPress, 1996.

3See, for example: Rothman, Johanna.“Iterative Software Project Planning andTracking.” Rothman Consulting Group,Inc., 1 January 1997 (www.jrothman.com/1997/01/iterative-software-project-planning-and-tracking).

4Highsmith, James A., III. Adaptive SoftwareDevelopment. Dorset House, 1999.

www.cutter.comEXECUTIVE REPORT 2

How did Lean enter the picture?

You might say Gerald M. Weinberg started the Lean movement with

his book Quality Software Management, Volume 1: Systems Thinking, back

in 1991.5 Later, in 1997, Donald G. Reinertsen published Managing the

Design Factory, where I first learned about work in progress (WIP) and

batch size.6 But I’d have to say that David J. Anderson7 and Mary and

Tom Poppendieck8 deserve much of the credit for Lean applications to

software development.

You can see that Scrum and Kanban were known — if not well known

— before 2001. Some of us had used these ideas, even if we didn’t know

what they were called. In the preface to my project portfolio book, I

explain how I had limited WIP until I had a manageable project portfolio.9

I used a form of Kanban inside two-week timeboxes. At the time, I didn’t

know what it was called. It worked. I used it. That was back in 1990.

Fast Forward to the Present

Today, there are numerous books, papers, articles, and blog posts

explaining the benefits of iterations and Kanban. Maybe it’s time for

a story about each. Let me tell you a couple stories about two clients.

Sam is a project manager turned ScrumMaster at a small company in

the San Francisco Bay Area. Yes, I know, that’s not supposed to work.

But it does. He was never a command-and-control project manager,

so the job is a great fit for him. He hated doing Gantt charts. He would

much rather facilitate the team and help them improve their processes.

His managers want to hold him responsible for the release. But he

has explained that it’s the product owner’s responsibility. Remember,

the product owner has total say about what goes in the backlog and

when the project is done.

Sam’s team is experienced at Scrum, so things are working well now.

But in the beginning, it was a different story. Here’s what Sam said:

When we started, we couldn’t finish anything in two weeks, never mind

four weeks. So I decided we needed to have two-week iterations because

otherwise our work items would continue to grow larger and larger.

Once we started to deliver, our product owner was so excited, she

demanded more and more features. She didn’t want to leave room

for our technical debt paydown for every feature. I had to take her

aside separately and explain that if we didn’t pay off technical debt

for every single feature as we went along, we would be in big trouble.

Our product owner had “feature-itis.”10

We still have trouble with architectural exploration, but we’re getting

there. We’ve trained ourselves to work more closely, so we almost never

take a story that doesn’t have at least two or three people working on it

together. Most of our stories take not more than a day, maybe two. That

allows us to experiment more freely. But the first year was rough.

We really had to use our retrospectives to make Scrum work for us.

We needed our coach. I needed coaching, too, on how to be a great

ScrumMaster. Our managers didn’t understand what they needed to



5Weinberg, Gerald M. Quality SoftwareManagement, Volume 1: Systems Thinking.Dorset House, 1991.

6Reinertsen, Donald G. Managing theDesign Factory. Free Press, 1997.

7Anderson, David J. Agile Management forSoftware Engineering. Prentice Hall, 2003.

8Poppendieck, Mary, and TomPoppendieck. Lean Software Development:An Agile Toolkit. Addison-WesleyProfessional, 2003.

9Rothman, Johanna. Manage Your ProjectPortfolio: Increase Your Capacity and FinishMore Projects. Pragmatic Bookshelf, 2009.

10Rothman, Johanna. “Do You HaveFeature-itis?” Managing ProductDevelopment, 22 June 2011 (www.jrothman.com/blog/mpd/2011/06/do-you-have-feature-itis.html).

3©2014 Cutter Information LLC Vol. 15, No. 2 AGILE PRODUCT & PROJECT MANAGEMENT

do. They needed coaching on shifting their expectations and actions. If

we hadn’t had all that coaching, we could not have succeeded.

Blake is a project manager of a team using Kanban. Here’s his story:

We tried using Scrum. But it was too much of a culture change. All

those meetings. All those rituals. It was crazy. With Kanban, we post

a board, we know our WIP and then we continue.

Our evolution has been slow. At first, we looked a lot like we were still

doing waterfall. I know, you told us we were. But we had many fewer

features in progress, and we were working by feature, not by architec-

tural layer. That really changed how we worked.

Since we did a retrospective every two weeks, we had a chance to

review what we did and improve it. The retrospective provided a

cadence to our work, not the iteration. Once we realized we had

finished nothing during those two weeks — that was a wake-up call!

We knew we wanted to be able to finish work faster than that.

We reviewed our WIP limits and discovered bottlenecks as we worked.

Because Kanban is a pull system, where we pull work, not push it, we

were able to change our process quickly, once we made our stories

smaller. But we had to change our stories first.

Now we do continuous integration across several teams because every-

one uses Kanban. We don’t wait until the end of an iteration. I know,

we shouldn’t have to wait for the end of an iteration, but here, we used

to allow our timeboxes to let our stories stay too large. Now, we keep

things small because we use Kanban. The Kanban itself helps us move

the work across the board because we limit our WIP.

Iterations Are Push, Kanban Is Pull

The way most teams organize their boards, iterations push work across

the boards. Kanban teams pull work across their boards. Figure 1

provides a better picture of what I mean.

Figure 1 — A typical Scrum board.


In this example, the team has a ranked list of backlog items in the

“Ready” column, and they have some number of work items in the

”In Progress” column. Any items that they have completed are in the

“Done” column. There are no limits on any column. For many teams,

that means they “push” work across the board.

For teams new to Agile, and teams new to Scrum, they tend to start as

many stories as they have people. This is a terrible idea, but they do it

anyway.

These types of teams end the iteration by pushing their stories across

the board to get to done. They are exhausted. They ask questions such

as, “Can we get partial credit for stories we didn’t finish?” No. “What

about the stories we didn’t finish? Do we roll them over to the start of

the next iteration?” No. The product owner decides what to do with

them.

Too many executives and managers do not realize that Scrum is a total

cultural change. Or that Agile approaches with their transparency are

a cultural change, not just a different project management approach.

How Is Kanban Different from Scrum?

Contrast the Scrum board with a Kanban board (see Figure 2).

This team also has a ranked backlog in the Ready column. However,

this team has more columns across the board. When I meet teams that

use Kanban, one thing I notice is that every board is different. No two

team boards look identical. (Figure 2 represents a prototype that a team

might start with.)

This board has a column for development and unit testing, and then

a column to note when development is complete. The team noticed

its testers could not maintain the pace of the developers. So the team

created a WIP limit of two items, so that the developers would not

create more features than the testers could test.



For teams new to Agile, and teams

new to Scrum, they tend to start as

many stories as they have people.

This is a terrible idea, but they do

it anyway.

Figure 2 — Example Kanban board (note the WIP limit numbers).


If the developers see the board like this, the developers are supposed to

ask the testers, “What can I do to move items across the board?”

This team — when it saw it had all these items in “Dev-Done” —

stopped creating more features. Because of the WIP limits, the develop-

ers could not start more development. They had to address the work on

the rest of the board, to pull the features currently in progress to done.

The developers were surprised by what they discovered.

They had no idea the testers didn’t have the same environment they

had. So they helped create virtual machines and virtual databases. They

created enough automated scripts to help the testers automate what the

developers and testers called the “easy stuff” — the work the testers

had to test for every build, but had not been automated up until now.

When the developers were done “helping” the testers, the team had

a robust smoke test, a robust automated system test, as well as a new

environment and machines for the testers. Could the testers have

accomplished this with Scrum? Of course. They could have accom-

plished this with any project management framework, if they had

known what to ask for.

Kanban made the bottleneck transparent and forced the team to work

together — because it’s a pull system. These people had no way to

know what they were missing, due to their previous experiences. No

one was a bad person. No one had bad intentions. They were ignorant.

No project management framework can cure ignorance. But you can

select a framework that exposes ignorance.

Where Does Swarming or Mobbing Fit?

I’m a big fan of the entire team working on one item until that item

is complete. That is called “swarming around a feature” or “mob

programming.”11 You can do this inside iterations, or using Kanban.

It doesn’t matter.

If you swarm or do mob programming, you discover a few things:

1. You finish work faster because everyone works together.

2. Your estimates become more accurate.

3. It doesn’t matter what board you use. Everyone works together,

so everything moves across the board together. You have a WIP

limit of one.

Which Approach Is Best?

No, I’m not going to answer that question. I’m firmly in the “it depends”

camp. It depends on your culture. Are you willing to conduct retro-

spectives and examine your project process after each iteration and

see where you can improve? Are you a cross-functional team where

members are all in one location? Are you a team comprised of at least

three people and no more than nine? If you can answer “yes” to these

questions, you hit the Scrum sweet spot and you have a shot of making

Scrum work.11 See http://mobprogramming.org.

No project management framework

can cure ignorance. But you can select

a framework that exposes ignorance.


Scrum has many real-time rituals: the sprint planning meeting, the

daily stand-up, the demo, and the retrospective. In addition, much of

the backlog grooming and the preparation for the next sprint is work

that the team needs to do together, certainly while it is still learning

how to be Agile. If you have a geographically distributed team, you

can be Agile, although it is much more difficult. You might not want

to do Scrum, depending on how many time zones you are apart.12

If you choose Kanban, you must keep your stories small, or your

cycle time will prevent you from releasing anything. Of course, you

can measure your cumulative flow, but just measuring it won’t help

anything. You have to do something about the measurement. If it takes

you weeks to complete anything, you’re not Agile, because you’re not

getting feedback fast enough. If you allow your WIP to become too

large, you’re not Agile; you have a waterfall project, masquerading

as an Agile project. If you have too many people on the team, your

Kanban board won’t help you pull work through the system either.

It will show you what’s going on, but it won’t help you.

There Is No Magic Bullet

There is no magic bullet for transitioning or using Agile for projects.

No matter how you do it, it is hard work.

What you can do is listen to people who have been there and done that.

You can hear their stories of success or failure. You can learn from them.

There is nothing new about Agile. We are merely learning how to more

successfully apply Agile and Lean to projects and teams. But, in some

ways, we’ve known this all along. The challenge is in how to apply it.

CROSSING THE AGILE DIVIDE: AN ENTERPRISE VIEW BY SCOTT W. AMBLER

The Scrum versus Kanban debate, or perhaps more accurately the Agile

versus Lean debate, is a real one for many software professionals. Like

Johanna, I’m an “it depends” kind of person and I believe teams should

adopt a strategy that makes the most sense for them. The implication

being that your organization may have some teams following an Agile

strategy, some following a Lean strategy, and some doing something

else. When it comes to software process, smart organizations realize

that “fit for purpose” trumps “one common process” every time. The

challenge is that all these teams need to be able to work together and

be governed effectively. Therein lies the rub.

The “it depends” philosophy is at the very heart of the Disciplined

Agile Delivery (DAD) framework.13 DAD is a hybrid framework that

helps guide teams through process-oriented decisions, such as which

practices to adopt and which lifecycle strategy to follow, enabling them

to tailor their approach to meet the needs of the situation they face.

The framework is enterprise-aware in that it has built-in support for

governance and IT-level activities, such as enterprise architecture,

DevOps, product management, portfolio management, and more. Such



There is no magic bullet for

transitioning or using Agile for

projects. No matter how you do it,

it is hard work.

12Rothman, Johanna, and Shane Hastie.“Lessons Learned from LeadingWorkshops About GeographicallyDistributed Agile Teams.” IEEE Software,March/April 2013.

13Ambler, Scott W., and Mark Lines.Disciplined Agile Delivery: A Practitioner'sGuide to Agile Software Delivery in theEnterprise. IBM Press, 2012.


enterprise maturity is particularly important given the complexities

modern organizations face.

The DAD framework supports multiple delivery lifecycles and provides

advice for how to choose between them.14 This includes a Scrum-based

Agile lifecycle, a Kanban-based Lean lifecycle, a continuous delivery

lifecycle, and an exploratory lifecycle based on Lean startup strategies.

Every customer that I’ve worked with over the last two years has had

teams following different lifecycles. One organization had several teams

following the Agile version of the lifecycle, two teams following the

Lean lifecycle, and one team experimenting with continuous delivery.

Another organization had a large program where most of the subteams

followed a Lean strategy with one subteam following an Agile lifecycle

to handle the larger “chunks” of work that came in from time to time.

Another reason why it’s important to adopt a framework that supports

multiple delivery lifecycles is process improvement. The 12th princi-

ple behind the Agile Manifesto states: “At regular intervals, the team

reflects on how to become more effective, then tunes and adjusts its

behavior accordingly.”15 The implication is that as a team learns and

improves, the overall lifecycle that it follows will reflect these changes.

I’ve worked with teams that start with an Agile-based lifecycle and then

over time evolve into a Lean-based approach. I even met one team that

evolved from a Lean strategy to an Agile one, an evolutionary path that

made perfect sense for that team.

Agile or Lean?

I will take a stab at addressing the question, “Which works better?”

and I’ll do so by giving two answers. First, as Johanna indicates, it really

depends on the situation you find yourself in. Your team’s culture and

skill set are the primary determinants of which lifecycle you will choose.

My experience is that you can apply Agile and Lean approaches in a

variety of situations, including with large teams, geographically distrib-

uted teams, and teams facing other complexities. More importantly,

my research data backs this claim.16 Naturally, a large team will work

differently than a small team. A team in a life-critical regulatory sit-

uation will work different than a team in a nonregulatory situation.

A team working with an outsourcing company will work differently

than a team that doesn’t. Teams need to tailor their process to reflect the

situation they face, and DAD provides the guidance they need to do so.

Second, my recent research has found that teams following a Lean

approach, on average, seem to be more successful than teams following

an Agile approach.17 On average, Lean teams are perceived to provide

a bit better stakeholder value, product quality, time to market, and

ROI compared to Agile and iterative teams. And, of course, Agile and

iterative teams are significantly better at all four of these success criteria

than waterfall teams. Note that these are all averages and your mileage

may vary, but it’s always interesting to have industry data at hand.

I’d like to end with this thought: don’t think in terms of Scrum versus

Kanban, or even in terms of Agile versus Lean. Instead, think in terms of

Your team’s culture and skill set are

the primary determinants of which

lifecycle you will choose.

14Ambler, Scott W. “A Full DeliveryLifecycle.” Disciplined AgileDelivery, 30 December 2012 (http://disciplinedagiledelivery.wordpress.com/2012/12/20/a-full-agile-delivery-lifecycle).

15“Principles Behind the Agile Manifesto”(http://agilemanifesto.org/principles.html).

16“Agility at Scale Survey.” Ambysoft,2012 (www.ambysoft.com/surveys/stateOfITUnion201209.html).

17“2013 IT Project Success Rates SurveyResults.” Ambysoft, 2014 (www.ambysoft.com/surveys/success2013.html).


what approach is best for your team. You’ll find that you end up pick-

ing and choosing strategies from various sources, something the DAD

process decision framework was specifically designed to help you with.

SCRUM OR KANBAN? IS THIS THE RIGHT QUESTION? BY SUZANNE ROBERTSON

Talking about and contrasting Scrum, Kanban, Lean, and any other

methods that label themselves “Agile” should be a useful way of

learning more about which approach increases your ability to be

more agile in which circumstances. But focusing on the mechanics of

the techniques often has the result of missing the real issue: what are

we trying to improve, and how will we know when we’ve done it?

As Johanna points out (and my experience concurs): “There is nothing

new about Agile. We are merely learning how to more successfully

apply Agile and Lean to projects and teams. But, in some ways, we’ve

known this all along. The challenge is in how to apply it.”

So what are the factors that lead people to focus more on techniques,

methods, and procedures than the problems that the techniques are

trying to overcome?

Techniques Are Tangible

Human beings, regardless of their job titles, prefer to focus on things

they consider to be tangible. For example, I often hear business analysts

complaining that business stakeholders don’t state their requirements;

instead, they come up with solutions. For example:

n “I need an interim total down here on the right of the screen.”

And then the analyst has to dig behind the why of the solution to

discover what the real problem is:

n “Why do you need this interim total?”

n “Because I need to write it down so that I can compare the figure on

the next screen.”

... and so on, until the analyst understands that the real problem is to

analyze and communicate the difference over time between two values

so that the special offers are made to the appropriate client. The busi-

ness stakeholder focused his attention on something tangible to him —

the current computer system and how it works — rather than analyzing

the real business problem and then working with the analyst to come

up with the best solution. This, of course, is why we have analysts

trained to look past the tangible and uncover the real business need.

The parallel with Agile techniques is that they are tangible; each one

has its own language, methods, procedures, cards, boards, language,

documents, review procedures, stories, roles, iteration cycles, and so on.

Familiarity with one particular technique — doesn’t matter which one

— inevitably focuses practitioners on the tangible characteristics of how



Focusing on the mechanics of

the techniques often has the result

of missing the real issue: what are

we trying to improve, and how will

we know when we’ve done it?


to use that technique. This focus on concrete procedures sidetracks

thinking away from why we want to be Agile and how we will know

if we are.

Equating the Technique with the Problem

In our profession, every so often somebody articulates a common prob-

lem with the way we are developing systems and comes up with a new

paradigm for addressing that problem. Then, as the paradigm becomes

more widely accepted, people come up with ways of implementing the

paradigm. The Agile Manifesto is the result of identifying and commu-

nicating problems with the way we develop software: it takes too long

and by the time we deliver it, the users’ needs have changed, we can’t

respond to changes; in short, we are not delivering continuous business

value. This led to the awareness that we should be working in a way

that we can continuously respond to business change and deliver valu-

able working software. In summary, instead of being bound by sequen-

tial procedures, we need to be more agile.

The manifesto states what we are trying to improve. Agile techniques

are a mixture of ways of achieving the advantages identified in the

manifesto. But, like any techniques, we need to use them with the brain

engaged. Sometimes I see teams that have fallen into the belief that if

they follow one or another of the prescribed techniques, then they will

be an Agile team — but if they are really thinking like that, then they

have forgotten what they are trying to do.

When adherence to the technique takes over and obscures the problem,

it makes it difficult to respond to changes — in these cases, the technique

makes it more difficult to be Agile.

Methodological Confusion

If you look at the list of software development philosophies, processes,

and methodologies on Wikipedia,18 you will see that many of the tech-

niques listed could be said to be Agile, or at least to contain some ele-

ment contributing to Agile — it all depends on how we apply them.

Other professions like architecture, medicine, and engineering have,

over a very long period of time, developed a language for talking about

the essence of their work. When one of these professions gets a new

method, they have the common vocabulary to be able to relate it to

a well-understood problem — building foundations, blood circulation,

bridge span. Software development has only been in existence for 60

years and has undergone more change than any other profession. We

do not have a consistent shared language (e.g., what do we mean by

value, system, user, story, requirement ... and all the other terms we

use?). So it is not surprising that we suffer a certain amount of confu-

sion about the relative merits of the approaches that we use to develop

software. We are still in the process of figuring out how to talk to

each other about the work that we do.

When adherence to the technique

takes over and obscures the problem,

it makes it difficult to respond to

changes.

18See http://en.wikipedia.org/wiki/List_of_software_development_philosophies.


SCRUM OR KANBAN? IT’S NOT A COMPETITION BY RON JEFFRIES

If someone were to ask me what to read first in order to decide whether

to use Scrum or Kanban, I would be inclined to say, “Read something

about false dichotomies.”

There are three notions I’d like to talk about here: ScrumTM, KanbanTM,

and generic “kanban” ideas. All three are full of ideas, and those ideas

are not in conflict in any important way.

I emphasize the “TM” in Scrum and Kanban because we need to keep

in mind that these are, in some usage, brand names, with individuals

and organizations behind them, selling them. Then there is also a family

of ideas that I’m calling “generic kanban” — ideas around using simple

boards to display work status.

Generic Kanban Ideas

Generic kanban boards are useful anywhere. If you put sticky notes

on your refrigerator, you have created a simple “kanban” task board.

If you went so far as to have a few separate areas, for “Honey Do,”

“Doing,” and “Done,” you’d be visualizing your work. More areas

can be better, if they help you communicate status and priority, and

if you wind up with too many, you’ll find that you can clutter the

fridge and then have no better idea where you are than you did before.

Fiddle with what you put on the fridge and how you classify it. Change

it to say what you like, providing the info you need.

Boards like this can be quite useful. They are best when placed in the

hands of the people doing the work. Work comes in and goes into

Honey Do. Maybe the work provider keeps Honey Do organized by

priority. As Honey picks up things to do, they get moved to Doing or

perhaps “Waiting for Parts to Come In” or “Need More Info.” Some

of them get moved to Done. That makes everyone happy.

Look for examples of kanban boards and task boards online. Fiddle

with yours. Make it useful. Don’t worry about making it elegant; it

works best with cards or sticky notes on a white board.

ScrumTM and KanbanTM: The Frameworks

These are two packaged frameworks. While they both focus on continu-

ous improvement, they do have some key differences.

Starting

Scrum prescribes a particular way to start, with an empowered product

owner who decides what to do, a cross-functional team that decides

how to do it and then does it, and a fixed time period of a couple of

weeks, within which each increment of work will be completed. Scrum

specifies that you should have a “backlog” (a list of what needs to be

done) but doesn’t say how to represent that list.

Kanban suggests starting where you are. It asks that you visualize the

actual flow of your work, typically on a kanban board as described



Fiddle with what you put on the

fridge and how you classify it.

Change it to say what you like,

providing the info you need.


above. It doesn’t care how you define the work, nor whether your

team can actually do it, nor whether they get to decide how to do it.

The Kanban method just asks you to visualize the flow.

Either way can be good. Scrum starts you in a place that is likely

more effective than where you are now. Kanban lets you start more

painlessly. You get to choose.

Moving Along

Scrum has you deliver software every couple of weeks. At that interval,

you have a “retrospective,” wherein you look back at how things went

and think of ways to improve. Scrum doesn’t tell you specific ways to

improve; it assumes you are smart enough to figure things out, to look

things up on the Internet, and to ask around.

The Kanban method also expects you to look at what’s going on and

improve it. It doesn’t say how often you should look back, but it does

recommend a regular “cadence” for things like that. And it offers some

specific ways of looking at things, based on your board. Having visual-

ized your workflow, you limit WIP. This means that you don’t take on

a bunch of work and try to do it all at once, and it also means that you

don’t build a big buffer of Honey Do with nothing happening to it. You

manage the flow of work through your board, changing the process to

make it flow better, and you improve collaboratively.

The Kanban method focuses very particularly on flow. Kanban’s ideas

are perfectly compatible with Scrum, and if you secretly applied those

ideas and brought them to Scrum retrospectives, the ideas would fit in

just fine. Scrum doesn’t care where you got the ideas; it just wants you

to have them and apply them.

It All Comes Down to Continuous Improvement

Both methods work by focusing on continuously improving what you

do. If you in fact do that, you’ll prosper with either one. If you don’t

focus, you won’t get the benefit.

Scrum Improvements

Scrum starts you off in a pretty good place, but it can be hard to start

there. Politics or staffing concerns can make it difficult. If the company

has a single team doing a million things, it’s hard to provide a truly

empowered product owner. But if you can get to the starting point,

trying to do Scrum will highlight many of the things that are holding

your organization back. And Scrum’s relentless focus on delivering

“done” software generally increases productivity right away.

With Scrum, it’s easy to focus on improvement inside the team, and

the result can be a team that gets things done very rapidly after waiting

months for decisions, and before waiting months for deployment. Since

those things are outside the team, they might be hard to spot, even

though they’re the most important issues facing the organization.

Scrum starts you in a place that is

likely more effective than where

you are now. Kanban lets you start

more painlessly. You get to choose.


It’s also easy to decide that some improvements just aren’t possible,

because they’re controlled outside the team. What “should” happen is

that the team identifies some issue (e.g., months before deployment)

and then begins lobbying to improve that issue, usually by displaying

the overall flow of things. Hey, what’s that? A kanban board showing

the workflow!

Kanban Improvements

Kanban starts you wherever you are, which is almost always a bad

place. It causes you to look at the overall flow of things and improve

that flow. Suppose work ideas hang around outside the team for

months. A suitable kanban board would show that, and it would show

those ideas as WIP. It would suggest limiting that work, which would

get decisions made faster. That would smooth the flow of work to the

development team, which would be good.

This is a bit glib, however, because it misses a key point. Scrum starts

with the team and that’s easy to do. Kanban starts where you are and

that’s even easier to do. However, neither Scrum nor Kanban is likely to

have a lot of uptake higher up in the organization, and no matter which

framework you use, your influence up the chain is likely limited. Both

methods suggest exposing what’s going on up the ladder, and applying

persuasion to change it.

Kanban’s global focus can also cause the team’s needs to be ignored in

the bigger pictures. This can be good for the company, but not so good

for the team.

Stop Comparing, Start Doing

Improvement always comes a bit at a time. Don’t ask yourself “hammer

or screwdriver?” or “Scrum or Kanban?” Learn about each of them, and

learn how to apply their ideas in your situation. Your job is to improve

at building things for your organization, not to become really good at

Scrum or really good at Kanban.

Become really good at your work. These ideas can be part of that. They are

not in competition and they are not the whole answer to anything.

They’re just ideas that you can use.

IT’S ALL ABOUT AGILE LITERACY BY PETER KAMINSKI

Like me, the Agilists I know are fairly practical folks, and so hearing

Scrum and Kanban put in opposition doesn’t quite parse for them.

After all, Scrum and Kanban are not goals in and of themselves. They

are both means to an end: customer satisfaction through early and con-

tinuous delivery of valuable software, as the first Agile principle says.19

So why talk about process instead of talking about goals?

My Agilist friends say things like, “It’s not Scrum or Kanban — it’s

Scrum and Kanban”; “Personally, I like to use Scrumban”; or “It’s

about the values and principles in the Agile Manifesto — the particular



Neither Scrum nor Kanban is likely to

have a lot of uptake higher up in the

organization, and no matter which

framework you use, your influence

up the chain is likely limited.

19“Principles Behind the Agile Manifesto”(http://agilemanifesto.org/principles.html).


methodology isn’t critical.” My inner voices say the same sorts of things

when I hear the topic come up.

So I take a deep breath and quiet my inner voices. There was a time, of

course, when I didn’t know about Scrum and Kanban and would have

been puzzled about how — or whether — to choose between them. And

so the question is a useful one, to help me and someone learning Agile

reflect together on how Scrum and Kanban, Agile and Lean, fit together.

Often, the discussion is either with someone in management, or with

the members of a dev team who have been told they need to “get Agile”

and they are trying to figure out what that means.

The conversation is similar in either case, although for the management

folks, it’s a higher-level discussion about the goals of Agile — and

empowering the team. For dev folks, it’s worth also diving into the

nuts and bolts of process more.

I tell them not to be too distracted by the various flavors of Agile. We

talk about the overarching goal — product delivery in service of cus-

tomer value — and walk through the values and principles of the

Agile Manifesto. (It’s worth a read again, at agilemanifesto.org.)

With that, we can launch into a pros-and-cons discussion about Scrum

and Kanban and whatever else they have heard about Agile process.

The nature of the project or work can strongly bias a choice between

Scrum and Kanban. Scrum is a good fit for new development, where the

team will take a number of months to incrementally create something

large, with a regular rhythm of incremental delivery every sprint.

Conversely, for work that has repeating activities, which may include

bursty and unpredictable changes, or which requires an irregular

delivery rhythm, Kanban is often a better choice. This is just a struc-

tural consequence of the different ways Kanban and Scrum are set up;

Kanban just goes with the flow of work that needs to be done, whereas

Scrum has the regular rhythm of two-week or four-week sprints. Many

operations-oriented teams choose Kanban because it better harmonizes

with the rhythm of the work they need to do.

Another lens is the nature and experience of the team.

Scrum is more structured, with its small but crisply defined set of roles,

artifacts, and ceremonies. These “rules of the game” are often easy and

interesting for developers to pick up; after all, developers are used to

picking up rules of programming languages and systems as part of

their daily work.

Scrum does work well for a cohesive team that has a lot of practice

working together. However, it really shines when used as a set of

“training wheels” for a team that’s just assembling. The structure of

Scrum helps a team begin to be Agile, and work together as a team,

even without really understanding what those things mean. Over time,

as the routine of working together as a Scrum team becomes second

nature, team members can start to reflect on how they have been work-

ing as an Agile team, and start to apply Agile principles on their own,

without the training wheels.

The nature of the project or work

can strongly bias a choice between

Scrum and Kanban.


Kanban is more loosely structured, and it is easy to pick up the basic

practice of visualizing work and limiting WIP. This makes it well suited

for teams that are already working cohesively, are skeptical of process,

and want to just focus on working. Conversely, though, to get the full

benefit of Kanban requires a good deal of thoughtfulness and maturity

from the team, which bears the responsibility for developing feedback

mechanisms and managing and improving the flow of work. Beginning

teams may face challenges in understanding what they need to do and

how to do it.

Now that we’ve gone through some reasons to choose one methodology

or another, let’s revisit our original goal: customer satisfaction through

early and continuous delivery of valuable software.

To accomplish this, Scrum and Kanban — and Agile in general —

emphasize “individuals and interactions over processes and tools.”

They depend on giving the team agency, and allowing — or even

requiring — the team to work together to solve process problems and

improve process. Scrum and Kanban depend on a good deal of team

introspection and process experimentation in order to continually strive

to improve the output of the team.

In my experience, good Agile coaches will encourage teams to experi-

ment with bits and pieces of various methodologies, to see what best

helps the team deliver. I encourage “Agile literacy” — an understand-

ing of not only what the different methodologies — Scrum, Kanban, XP,

Lean Thinking, and so forth — ask you to do, but why.

At some point, then, as the team mixes and matches learnings and tech-

niques from a variety of sources, the question of “Scrum or Kanban?”

becomes moot. It’s certainly a good framing question to start an explo-

ration of Agile, but a mature Agile team will apply lessons from both,

and more.

YOU ARE NOT CONDUCTING AN ORCHESTRA BY ISRAEL GAT

Great conductors are known to be supremely confident: in their tech-

nique and in themselves. You can see the confidence when you watch

video clips of giants like Mengelberg, Toscanini, Furtwangler, Kleiber,

or Bernstein. Moreover, you sense their confidence when you listen to

an audio recording of theirs: they are sure-footed with each and every

note in the symphony they are conducting.

Conversely, great software development coaches are, in my opinion,

confident in themselves, but must choose their method/technique to fit

the specific context of the engagement they are carrying out at a certain

point in time. They might choose Scrum for one engagement, Kanban

for another, and a combo of Scrum+Kanban (aka Scrumban) for a third

engagement. They are not bound — and don’t bind their clients — to

any single method or technique.

Listen to Beethoven’s Fifth Symphony under Furtwangler, then listen

to the way it is performed under Kleiber. Fate, of course, knocks on the



Scrum and Kanban depend on a

good deal of team introspection

and process experimentation in order

to continually strive to improve the

output of the team.


door in the two interpretations. With Furtwangler, fate is solemnly

majestic, while Kleiber’s is a fascinatingly vibrant “daemon” (in the

ancient Greek sense) that could easily play a role in Black Orpheus. For

some 50 years now, I have been trying, and failing time and again, to

make up my mind as to which of the two fates is more magnificent.

Alas, I can’t make this determination and will probably never be able

to do so.

The big difference between conducting and software development

coaching is context. The context in which Furtwangler and Kleiber

apply their genius is identical: Beethoven’s Fifth Symphony. In contrast,

the context in each and every client engagement is different. You need

to carefully determine which software method will be most appropriate

for the specific context.

Let me illustrate this all-important point about context by describing

two engagements I carried out recently:

n Client A was a startup that was growing rapidly and considering

implementing Scrum. Cutter colleague and friend John Heintz and

myself were entrusted with advising this client. Upon spending

quality time with its CTO, we concluded that (1) the CTO is extra-

ordinarily talented; and (2) he could easily handle by himself much

more than the amount of code the startup had (a couple of hundred

thousand lines of code). Hence, we recommended to the venture capi-

talist for whom we were carrying out this engagement not to worry

about software methods at this point in time. The only real risk the

startup faced from a technology/software perspective was the possi-

bility that the CTO might be hit by a bus. Hence, in our opinion, all it

needed to invest in was bringing aboard a strong #2 whose main task

would be to absorb the knowledge of the CTO, get familiar with the

code, and be ready to jump in should something bad happen to

the CTO.

n Client B was a large manufacturer that (naturally enough) had a

ton of well-established procedures, processes, and standards. For this

engagement, Cutter colleague and friend Tom Grant and I focused

on the principle of iterative software development, not on any specific

Agile/Lean/Kanban method. For example, we insisted that even if

the client chose to stay with waterfall, they must devise an effective

way for the business to provide input and validation. It made no

difference to us whether business input and validation would be

provided by the business partner, project manager, program man-

ager, project owner, product manager, or any other player, or combi-

nation thereof, in the organization.

I would like to think I am not naive about human nature. Furthermore,

I fully understand that great passion can easily lead to strongly held

convictions on one topic or another, or one software method versus

another. I am, however, at a loss about the polarization in the Agile/

Lean/Kanban domain. The only thing that really matters is being true

to a universal core set of software development principles. And, yes, if

you apply these principles wisely, even waterfall will work well.

I am at a loss about the polarization

in the Agile/Lean/Kanban domain.

The only thing that really matters is

being true to a universal core set of

software development principles.


PEOPLE OVER PROCESS BY HUBERT SMITS

It is like a finger pointing away to the moon. Don’t concentrate on the

finger or you will miss all that heavenly glory.

— Bruce Lee

The Agile Manifesto holds four values; the first being “people and

interactions over process and tools.” Yet the debate and efforts to imple-

ment either Scrum or Kanban focus more on the process and tools.

Interesting! We need to turn around the debate; it should focus more

on the people and interactions and less on the process and tools.

Too often overlooked, and too often the cause of failing the goal of

“Improving the World of Work,” is the effect that a move to Agile has

on the organization. We can make arguments in favor of either Scrum

or Kanban and their effects on product development, but for each

approach there must be a need and a desire for change, and in both

approaches the product delivery will feel and happen very differently

from what happened in past delivery efforts.

Both Scrum and Kanban work with a different metaphor, an iterative

process in the core: small or very small steps to deliver little bits of the

product. This allows a rapid inspection of the product and the people,

providing those involved with a mechanism to inspect and adapt both

product and people. That is the part that everybody sees, which attracts

most publications, and which makes up the core of most Scrum and

Kanban classes. Sadly, it is also the core of most comparisons between

the two approaches.

But it is only one side of the coin; the other side is about different

behaviors, different ways of people working together, and different

ways of “managing” people. To ignore the immense change pushed

onto the organization and the people when implementing either Scrum

or Kanban is a certain reason for disappointment and frustration, often

for failure to get better product development results out of the imple-

mentation of an Agile framework.

Implementing Scrum or Kanban — or Scrumban if you can’t make a

choice — requires the involved people to deliver increments rapidly.

This only works when these people work as a team — like a basketball

team, they can only win a match if the attackers, the defense, and the

coach are all working together to be better than the opponent. In the

software world, this means that the development manager and the test

manager can’t point at each other anymore for failing results. Instead,

they must reeducate their people to collaborate with all contributors.

The managers become guides for people, team builders, and developers

of social skills. Thinking of people as “resources” will disappear, and

when the organization becomes Agile most behaviorism thinking will

be gone: no more punishments, no more rewards, just people owning

their jobs and their future.



To ignore the immense change

pushed onto the organization and

the people when implementing either

Scrum or Kanban is a certain reason

for disappointment and frustration.


Rather than once in a while providing a decent report with specs, and

then inspecting the delivered results several months later, product man-

agers must have one foot in development and the other in the market.

All the time, they are part of the delivery. Requirements appear in a

continuous flow, and the handover to the developers is now all about

collaboration. Product managers are responsible for results, for plans,

for the hard decisions. They are exposed when bad decisions are made.

This is quite different from the time when the development team ended

up with the blame for problems in the product.

Executives don’t escape the change either. The world of “punish and

rewards” is a thing of the past. Neither a bonus nor a penalty motivates

people; this style does not positively influence performance. The exec

becomes the leader-servant who is ahead of the team and behind the

team at the same time, leading from the front, serving behind the team.

This is quite easy in an established situation, and immensely difficult

to achieve when coming from a command-and-control environment.

Neither Scrum nor Kanban is better when it comes to changing the

dynamics in an organization. The choice is not even that important —

start one of the two (or both) and the best possible process in a given

situation will emerge.

What makes the change easier or harder is how serious you take the

change. Each person must think, sometimes study, always try, and

continually learn about what the new way of product delivery means

to him or her. Vulnerability, or openness to change, is a skill that isn’t

understood well, let alone embraced.

Does the process choice, Scrum or Kanban, have no effect on the

organizational change, or the speed with which the change can be

implemented? Maybe. A bad choice will take longer to correct through

the inspect-and-adapt cycle (the retrospectives). A bad choice can demo-

tivate or obscure positive results in the people domain. Variables that

influence the choice for either Scrum or Kanban as the better-fitting

process include factors like the level of uncertainty on product goals,

the requirements change frequency, the release frequency, and the

product complexity. When product development is more a discovery

or a research approach or when the release moments are very frequent,

then the shorter cycle of Kanban may be a better option. When product

complexity is high, when dependencies are numerous, even when

delivery is sliced thinly, then Scrum provides some more appropriate

practices. For either choice, the “by the book” solution won’t be the

end. Both approaches are a framework, and those involved, together,

will have to discover the best filling for that framework.

There is a need to change the world of product development, certainly

within the software world where three out of four (and some reports

say even more) deliveries run into trouble; time, energy, money, and

motivation are wasted. Too few people appreciate what is involved in

making the change toward an Agile organization. The result: execs

The world of “punish and rewards” is

a thing of the past. Neither a bonus

nor a penalty motivates people; this

style does not positively influence

performance.


approach this problem by “buying Agile” in the form of a product or

tool. They are missing the point. Change cannot be bought; we can only

create change through participation, by being “in the arena.”

People deliver products. If you don’t master people skills, then master-

ing process skills won’t make up for the lack of the former.

SCRUM VS. KANBAN: DID WE REALLY HAVE TO GO THERE? BY HILLEL GLAZER

I suppose it was inevitable. As if “Agile versus CMMI” wasn’t bad

enough, the software world had to go and invent another reason to

stop thinking and start bickering.

No sooner do people decry the failures, foibles, and frustrations of

a (perceived) one-size-fits-all approach do they immediately turn

around and create such a method of their own, declare it “perfect”—

only to have others implement it imperfectly — and then accuse

everyone else of not bowing to the methods!

So for me, that’s the real point. Buried in the above paragraph is this:

implement it imperfectly. Never mind the religious war of words. The

wars are a symptom of people not listening, or learning piled atop

poorly doing whatever it is they’re doing. Again.

At this point in the campfire, I’m the last to contribute my point of

view. So far, it’s a lovefest. Everyone is in agreement. I’m a bit disap-

pointed that I must admit: they’re all correct. It really does depend on

the situation at hand whether Scrum or Kanban is appropriate. It really

is important to just start doing something to improve. You really can

use DAD to figure out a path that works. And at some point, people

do need to figure out the difference between the problems they’re trying

to solve and the methods in which they’re trying to solve them.

All of this is true. But to me it points back to a fundamental problem

with all software methods in the discussion (if not, I suspect, with any

method): the method doesn’t matter if it’s used incorrectly.

Methods, as we’re discussing here, tend to be comprised of practices.

To many, the practices are the definition of the method. But for those

who created the methods, the practices are teachable manifestations to

enable the principles behind the methods.

When the practices are divorced from the principles behind them, they

become detractors, not enablers, of the method. For example, what’s

the point of a daily stand-up? To stand around for 10-15 minutes? Just

to say that you had a stand-up? Or to communicate status, plans, and

needs?

What if the need to communicate status, plans, and needs could be done

some other way, or was necessary less (or more) frequently than once per

day? Would the daily stand-up still be the right activity for the team?

What if status, plans, and needs were handled automatically by a tool the

team uses? Would discussing something else at the stand-up be wrong?



When the practices are divorced

from the principles behind them,

they become detractors, not enablers,

of the method.


People who don’t understand the purpose behind the daily stand-up

may be quick to condemn an activity called the “daily stand-up” if the

team conducted it sitting down. What if, at a retrospective, the team dis-

cussed nothing more than defects found during user acceptance testing?

Would the retrospective add as much value as it could? Would it add as

much value as the team needs it to add?

A team using a Kanban board complete with WIP limits is still not get-

ting any closer to a smooth delivery pace after months of use. Defects

still accumulate, bringing along their logarithmically powerful ability to

interrupt ongoing work. Is the Kanban method at fault? Would Scrum

have prevented this?

It’s this exact same mindset that caused problems between Agile and

CMMI.20 People (on either side of the user population) were placing far

too much emphasis on practices and their respective artifacts, or inter-

preting the practices in ridiculous extremes to the exclusion of the real

value behind the practices.

Practices are contextually dependent. Separating the practices from

the contexts within which the practices are being carried out precisely

removes the practices from their value. In the hands of experts who

understand the value behind the practices, this rarely happens. The

experts can easily adapt practices to meet the context they’re working

within. Reading a book or three or taking a class or more does not

necessarily create experts.

One of the problems with this is rather obvious: there are far more

nonexperts than experts. However, that does not stop nonexperts

from dabbling with the methods, spreading their ideas, or proliferating

their failure to understand the principles behind the methods’ practices.

And so wars of words spark. People with insufficient understanding

arguing with other people with insufficient understanding over which

of their ill-fitting practices are best suited for slavish following by the

masses.

I won’t get into any of the arguments attempting to delegitimize any

Agile method in favor of another. As pointed out by other contributors

in this Executive Report, much of these are tied to business concerns.

Those concerns are, as the saying goes, none of my business. I will,

however, note that the desires tied to defending one’s ideas are

extremely powerful motivations and have a way of causing otherwise

reasonable people to not hear what’s truly being said and to not be

open to learning confronting concepts.

I will also point out that Kanban and Scrum contain many new and

challenging ideas that often require a large investment in emotional

capital to put in place. In particular, when one method is someone’s

“first” or when one method works after a prior method failed, anyone

coming along with strong ideas about the other method will be easily

construed (and sometimes even deliberately framed) as to contest,

question, or dispute the legitimacy of the opposing method.

20Glazer, Hillel (ed.). “Agile CMMI: WhyIsn’t This Conversation Dead Yet?”Cutter IT Journal, Vol. 25, No. 11, 2012.

And so wars of words spark. People

with insufficient understanding argu-

ing with other people with insufficient

understanding over which of their

ill-fitting practices are best suited for

slavish following by the masses.


So, after all, I suppose it was inevitable. We’re human. We are con-

stantly seeking validation. Validation makes us happy. Validation

is security, and when we are very insecure we seek more validation.

Transforming an organization with new ideas such as Scrum or Kanban

puts many people into a very insecure space. Trying to make sense

of new ideas and then integrate these ideas into their places of work is

taxing — emotionally and intellectually.

Why are organizations working to transform themselves? Typically

because their current performance isn’t enough to satisfy their evolving

needs. So by definition these organizations are not expert at the new

methods, their people are likely already overloaded with work, and

now Scrum or Kanban are asking them to do something differently.

Their people are defending these new ideas in every direction and

seeking validation from any direction.

Scrum or Kanban? My suggestion is to understand the problems these

methods are working to solve and what can be expected when using

them. Next, don’t just read up on their respective practices; talk with

the experts to understand the principles and even some of the theory

behind the practices. Both methods are about continually improving

performance. This means that as the organization’s context changes

over time, the practices will have to continually adapt. If you only

understand the practices as described for teaching purposes, then the

instant the context changes, you will be right back where you started:

dumbfounded and floundering for answers, and asking, “Which should

I use? Next-Big-Thing-A or Next-Big-Thing-B?”



Transforming an organization with

new ideas such as Scrum or Kanban

puts many people into a very insecure

space. Trying to make sense of new

ideas and then integrate these ideas

into their places of work is taxing —

emotionally and intellectually.


Scott W. Ambler is a Senior Consultant with CutterConsortium’s Agile Product & Project Management and Business& Enterprise Architecture practices. He is the thought leaderbehind the Disciplined Agile Delivery (DAD) framework,Agile Model Driven Development (AMDD), the Agile Data(AD) method, and the Enterprise Unified Process (EUP),working with clients around the world to improve the waythey develop software. Mr. Ambler is coauthor of severalsoftware development books, including Disciplined AgileDelivery, Agile Modeling, The Elements of UML 2.0 Style, AgileDatabase Techniques, and The Enterprise Unified Process. He isalso a Senior Contributing Editor with Dr. Dobb’s Journal. Mr.Ambler has spoken at a wide variety of international confer-ences, including Agile 20XX, Software Development, IBM Innovate,Java Expo, and Application Development. He can be reached [email protected].

Israel Gat is Director of Cutter’s Agile Product & ProjectManagement practice, a Fellow of Cutter Business TechnologyCouncil, a Fellow of the Lean Systems Society, and a memberof the Trident Capital SaaS advisory board. He is recognizedas the architect of the Agile transformation at BMC Software,where under his leadership Scrum users increased from zeroto 1,000, resulting in nearly three times faster time to marketthan industry average and 20%-50% improvement in teamproductivity. Among other accolades for leading this trans-ition, Dr. Gat received the Innovator of the Year award fromApplication Development Trends in 2006. His executive careerspans top technology companies, including IBM, Microsoft,Digital, and EMC. He has led the development of productssuch as BMC Performance Manager and Microsoft OperationsManager, enabling the two companies to move toward next-generation system management technology. Dr. Gat is also wellversed in growing smaller companies and has held advisoryand venture capital positions for companies in new, high-growth markets. He currently splits his time between consultingand writing. Dr. Gat focuses on technical debt, large-scaleimplementations of Lean, and DevOps. His e-book, The ConciseExecutive Guide to Agile, explains how the three can be tiedtogether to form an effective software governance framework.Dr. Gat holds a PhD in computer science and an MBA. In addi-tion to publishing with Cutter and the IEEE, he posts frequentlyat The Agile Executive and tweets @agile_exec. He can be reachedat [email protected].

Hillel Glazer is a Senior Consultant with Cutter’s Agile Product& Project Management practice. He is founder, Principal, CEO,and all-around Performance Jedi of Entinex, Inc., a companywith global reach that focuses on generating powerful resultsfor high-performance operations among companies motivatedto be Lean, Agile, and achieve world-class levels of operationalexcellence. Mr. Glazer’s work in Lean and systems thinkingbegan in 1991 and since then he has become the world’s leadingauthority on bringing Lean and Agile values and principles into

the regulated world. Leveraging his education and experience asan aerospace engineer, he solves hairy complex business prob-lems with the same creativity and discipline used to put peopleon the moon and grandparents at graduations. By seeing clearlyinto complex problems, Mr. Glazer finds the root of difficultbusiness operational issues, exposes what’s going on, and thenworks with companies to find, design, and implement simple,elegant solutions to lower costs, raise profits, foster innovation,and improve quality and speed responsivity to the market. Mr.Glazer’s professional passion is to generate powerful results forhigh-performance operations among companies motivated to beLean and Agile and to pursue world-class levels of operationalexcellence. He is an in-demand speaker and presenter, widelyread, broadly published, and appears worldwide on topics per-taining to operational excellence. Mr. Glazer’s approaches havesuccessfully harmonized Lean and systems thinking into highlyregulated industries that demand adherence and governancewhile in pursuit of excellence and profits. His book HighPerformance Operations: Leverage Compliance to Lower Costs,Increase Profits, and Gain Competitive Advantage lays outexactly how he does it. He can be reached at hglazer@cutter.

Ron Jeffries is a Senior Consultant with Cutter Consortium’sAgile Product & Project Management practice. He has more than30 years’ experience in leadership and development of commer-cial object-oriented, relational database, programming language,and operating systems software. Mr. Jeffries has particularexpertise in teaching and applying XP. He entered the XPmovement in its beginning, as the first full-time XP coach,working with Cutter Senior Consultant Kent Beck on the well-known C3 payroll system. He is coauthor, with AnnAnderson and Chet Hendrickson, of Extreme ProgrammingInstalled. He can be reached at [email protected].

Peter Kaminiski is a Senior Consultant with Cutter’s AgileProduct & Project Management practice. He has served as tech-nical cofounder for five Internet startups, including Socialtext,a leading provider of enterprise social software, and YipesCommunications, a pioneering provider of Ethernet WAN ser-vices. As a veteran Silicon Valley entrepreneur, Mr. Kaminskiprovides intelligent and experienced insight into discussions ofproduct and service development and operations. He also has30 years’ experience in delivering interactive, consumer-facingproducts as a game designer and software developer. With hisstartup background, Mr. Kaminski has an eclectic and broadrange of knowledge and skills, from the detailed minutiae oflow-level code, networking and data representation to teamdynamics, Agile development, and business/technology collab-oration to overall technology architectures, strategic alignment,and high-level business and market strategy. He has a particularpassion for small team dynamics, enterprise collaboration toolsand techniques, wikis, social media, gamification, and cloudcomputing. Mr. Kaminski tweets @peterkaminski. He can bereached at [email protected].

About the Authors


Suzanne Robertson is a Senior Consultant with CutterConsortium’s Agile Product & Project Management practice.She is also Principal and founder of the Atlantic Systems Guild.Ms. Robertson’s work includes research and consulting onthe management, sociological, and technological aspects ofrequirements. Volere, the product of her research, is a completerequirements process and template for assessing requirementsquality and for specifying requirements. She is the author ofseveral papers on systems engineering and speaks at numerousconferences and universities. Ms. Robertson is a member ofthe IEEE and board member of the British Computer Society’sRequirements Groups. She is the founding editor of the require-ments column in IEEE Software. Ms. Robertson is coauthor, withJames Robertson, of Requirements-Led Project and Mastering theRequirements Process. Other interests include a passion for theopera, cooking, skiing, and finding out about curious things.She can be reached at [email protected].

Johanna Rothman, known as the “Pragmatic Manager,” isa Cutter Consultant who helps organizational leaders seeproblems in their product development by assisting them inrecognizing potential risks, seizing opportunities, and removingimpediments. She has been President of Rothman ConsultingGroup, Inc., since 1994. A frequent speaker and author on man-aging high-technology product development, Ms. Rothman iscurrently Technical Editor at AgileConnection.com; a columnistat StickyMinds.com and ProjectManagement.com; and bloggerfor Managing Product Development, Hiring Technical People, andCreate an Adaptable Life (all at jrothman.com). She was Chair forAgile 2009 and has written articles for Cutter IT Journal, SoftwareDevelopment, Better Software, IEEE Software, Crosstalk, and IEEEComputer. Ms. Rothman is the author of several books, includingManage Your Job Search; Hiring Geeks That Fit; Manage YourProject Portfolio: Increase Your Capacity and Finish More Projects;the 2008 Jolt Productivity award-winning Manage It! Your Guideto Modern, Pragmatic Project Management; Behind Closed Doors:Secrets of Great Management; Hiring the Best Knowledge Workers,Techies, & Nerds: The Secrets & Science of Hiring Technical People;and Manage Your Project Portfolio: Increase Your Capacity andFinish More Projects. Currently, she is writing a book aboutAgile and Lean program management. She can be reached [email protected].

Hubert Smits is a Senior Consultant with Cutter Consortium’sAgile Product & Project Management practice. He is an innovative,assertive, and goal-oriented Agile consultant, coach, and trainerwith a track record of successfully spearheading enterprise-levelAgile and Lean enablement efforts. As the lead consultant atCisco Voice Technology, Mr. Smits designed and implementedthe Agile software development lifecycle, replacing multiyearwaterfall processes with iterative product development cycles.At Cisco, more than 3,000 participants in product development,including executives, product managers, program managers, anddevelopment teams moved into their Scrum roles and processes.His customers and successes include companies such as Oracle,Avaya, BMC Software, AOL, Fender, General Electric Energy,Amdocs, MySpace, and Compete. Mr. Smits has a track record ofworking with globally distributed teams, contracting with andcoaching teams in India, Argentina, Israel, and Europe. Alongwith a keen sense of business acumen, he is an exceptional com-municator offering strong negotiation, problem resolution, andteam-building skills. Mr. Smits enjoys leveraging Agile princi-ples and practices to mobilize teams, establish focus, promotepositive organizational change, enhance performance, improvequality, and reduce team turnover. He specializes in workingwith large product development efforts in organizations thatrequire a gradual organization-wide move to Agile. Mr. Smitsis confident in restructuring software development lifecycles,interacting with IT parties, and managing the impact of organi-zational change on finance, product management, marketing,and sales. In addition to publishing with Cutter and the IEEE, heis a frequent speaker at Agile events and has published articleson planning with distributed teams as well as Agile planningand tracking. He can be reached at [email protected].

About the Authors

Cons

ultin

g&

Trai

ning

Agile ProductManagement &Software EngineeringExcellence

The Agile Organization

Make your software, systems, and software organization asource of sustainable competitive advantage in an era characterized by constant change. Customized training, consulting, and executive education from Cutter’s expertswill help you get there.

Agile LeadershipIn today’s fast moving world, organizationalagility is a necessity for business performance— and agile leadership is the foundationupon which organizational agility is created.

As an executive and change leader, CutterSenior Consultant Don MacIntyre has led largeand small engineering organizations throughsuccessful transformations. He’s helped manyleadership teams empower their organiza-tions. And now you can benefit from hison-the-job experience. Don MacIntyre’s 2-dayAgile Leadership workshop is designed to helpleaders succeed with their agile transformationand develop the leadership skills required toachieve organizational agility.

Over the course of this 2-day workshop, you’lldiscuss the complexity and uncertainty ofwork, trust and collaboration within yourorganization, Agile principles and frameworks,high performing teams, leadership agility,challenges for leaders when scaling agile, theimpact of leadership attitudes toward risk andchange, Agile approaches to change, organi-zational structures and metrics, governancepolicies, continuous improvement, and more.

The insight and leadership skills you will gainfrom Don MacIntyre — an expert who’swalked in your shoes — during this fast-moving workshop will enable your managersto be better, more effective — and more agile— leaders during your Agile Transformation.

Agile EnablementJump-start and guide your transition to agilemethods with Cutter’s team of expert practi-tioners. You’ll identify which agile practiceswill bring the greatest return on investment toyour organization. Our goal: to enable you toimplement agile methods quickly and effec-tively, shorten your product developmentschedule, and increase the quality of the resultant product. A typical agile enablementengagement contains five steps:

1. Education. We offer two introductory ses-sions: one customized for senior executivesand one for your implementation staff.

2. Assessment. Prior to an onsite evaluation,we collect data from your staff to providean initial comprehensive picture of yourorganization.

3. Creating an agile vision. We’ll help youcreate an end-state vision of your agileapproach, relating your core values to specific agile approaches.

4. Determining specific solution compo-nents. We’ll make methodologyrecommendations covering product devel-opment, project management, softwaredevelopment, and portfolio management.

5. Action plan. Together, we’ll set an actionplan that meets the objectives of your agileinitiative.

Cutter ConsortiumAccess to the Experts

Agile AssessmentAre you as good at Agile as you think youare? Where do you go next? Given the depthand breadth of Cutter’s Agile expertise, weare exceptionally skilled at performing bothqualitative and quantitative assessments. Atypical assessment includes the followingcomponents:

Interviews with team members, people inthe rest of the software value stream, thepeople who manage that value stream, andcustomers.

Short surveys or other tools for generatingquantitative data, to supplement the quali-tative information collected.

Review of any documents that the customermay provide.

From this information, we assess the “Agile-friendliness” of the client’s organization.Where are the opportunities for expandingAgile, or complementary techniques? Whatare the threats? We deliver this assessment ina presentation to the client, which includesmaterials for the client’s future reference.While this approach provides a starting pointfor any Agile assessment, we also tailor theassessment to fit the client’s organization andobjectives.

Technical Debt Assessmentand ValuationDo you really govern the software develop-ment process in your IT organization or do itsuncertainty and unpredictability leave youaghast? Is technical debt playing havoc withdeployment dates you commit to and keepingyour development staff from respondingquickly to customer requests? Do you knowhow much money is required to “pay back”your software’s technical debt?

The primary goals of this workshop are togive you a solid understanding of the natureof technical debt and how it impacts valuedelivery, and to familiarize you with stateof the art tools for measuring technical debt.You’ll also be introduced to a correspondinggovernance framework that ensures you canscientifically manage your software develop-ment process. Between the tools and theframework, you will be able to meaningfully

“x-ray” the software you are developing atthe desired granularity at any point in time.Moreover, you will be able to reduce a largenumber of complex technical considerationsto a common denominator that is easilyunderstood by your peers and superiors —the dollar amount required to pay back theaccrued technical debt.

Agile ManagementThough Agile practices are highly beneficialfor development teams and their organiza-tions, they place unique challenges onmanagement. Executives must bring theirbroad view of the business, including itsneeds, the competition, the pace of innova-tion, and product demand, to the task ofmanaging Agile development.

Cutter’s Senior Consultants are experts intraining management teams on how to bothmeet the needs of the Agile developmentorganization and pursue the strategic goals ofthe business. At the end of this two-day AgileManagement session, your executives andmanagers will know how to balance empow-erment with governance, align goals andmetrics up and down the organization, anddetermine the exact amount of agility (or stability!) your organization needs to supportits business objectives.

Software DevelopmentAnalyticsIn today’s fast-paced business climate, it takesconstant learning about your operation tocompete. Although improving your softwaredevelopment process will free up assets todevote to innovation, many of today’s realities— from framework wars to “one size fits all”methodologies — make it nearly impossibleto accurately estimate, plan, track, and governsoftware development work at the team, project, program and portfolio levels.

Cutter’s software development analytics consulting, led by Cutter Senior Consultant Dr.Murray Cantor, delivers real-time knowledgeabout your software development operationand the adjustments you can make to deliveroptimal business value — whether the goal isbetter financial outcomes, faster time to market, or operational efficiency. You’ll move

Consulting, Training & Exec Ed

Cutter Consortium consulting, training,

and executive education offerings are

developed and presented by its Senior

Consultants: you’ll benefit from cutting-

edge ideas, methods, and strategies

presented by the thought leaders who

developed them.

Cutter’s extensive offerings can be

customized to meet your organization’s

needs and ensure everyone shares

the same base knowledge and is well-

equipped to take on the challenges

of new ways of doing business.

Don MacIntyre

from the subjective analysis of your software development process to a quantitative one,from the “belief” that your software develop-ment methods are effective to anevidence-based understanding that enablesyou to measure progress and make modifica-tions where necessary. This program helpsyou assess your mix of software developmentefforts, determine your process debt, createactionable goals for achieving hoped-for outcomes, and employ measures and feed-back loops to set and track goals.

What Leaders Need to KnowAbout DevopsThere’s too much lead time between idea con-ception and production in many organizations,despite various project management method-ologies and the push towards operationalexcellence. Internal fights emerge asDevelopment and Operations strive towardsconflicting goals: Agile shortens softwaredelivery time by introducing a greater numberof smaller changes; ITIL increases stability byminimizing changes. How can an organizationovercome this internal conflict? With devops.

Devops looks to optimize the whole process.In this workshop, you’ll learn:

The history and drivers that have pushedforward the notion of devops

The translation of agile concepts withinthe traditional ITIL world

Where devops fits with existing conceptslike Scrum, Kanban, ALM

The role of tools such as virtualization,infrastructure as code, and monitoring

How to introduce devops withinexisting/new environments

Devops is not about tools, but about mindsetand trust. Technologies such as infrastructureas code, virtualization, monitoring and deploy-ment can play a crucial role in supporting thiscollaboration. Exploiting the “symmetry ofignorance” and moving beyond the traditionalboundaries inside organizations will make itpossible to collaborate more frequently toreach business goals.

Agile Analytics: Program andProject ManagementProper Agile project planning is a foundationof Agile Analytics. Agility calls for planning forwhat you know now and being prepared toadjust in the face of change. Agile Analyticsplanning is a highly collaborative process thatincludes long range DW/BI road mapping toestablish future vision, and short horizon planning of near term delivery projects. Thistwo-day course will walk you through program road mapping and project charteringsessions to introduce you to a set of effectivepractices for facilitating collaboration betweentechnical team members, end users, and management stakeholders. This course willshow you how to:

Charter an agile BI/DW project using theagile project management framework

Coordinate an effective and collaborativeprogram road mapping session

Use Innovation Games for ideation,convergence, and prioritization

Estimate and prioritize agile BI/DW projectsand features

Map features, epics and stories intoiterations and releases

Some of the topics you’ll discuss may include program road mapping, program inception,project chartering, sizing and prioritizing, projects and features, and story mapping.

Executive Overview of AgileAlthough Agile is a team-level methodology,the success of Agile often depends on execu-tive sponsorship. Executives usually havemany questions: How long does it take forAgile to start showing results? How do execu-tives best assess whether the Agile effort is ontrack? How deeply do executives need tounderstand Agile practices and principles?

This one-day workshop is designed to answerthese questions, and many others. Many Agiletransformation initiatives succeed because ofenlightened leadership from the executivewing. Many others fail because of executiveneglect. This workshop helps you ensure yourAgile teams receive the executive-level support they require.

Agile Beyond the TeamOriginal practitioners may have mixed andmatched from Scrum, XP, DSDM, and otherAgile flavors, but the set of practices and principles was more limited than it is today.What it means to be Agile today involves alarger menu of techniques, mixed in more varied combinations, and matched more precisely to challenges. Many of thesemethodologies go beyond the team, changingthe way the software value stream works.

This three-day workshop provides anoverview of the practices beyond the originalAgile core that are now common features ofAgile. Whether it’s Kanban, continuous integration, continuous delivery, story mapping, UX design, alternate estimation andplanning techniques, or scaled Agile, you’llreceive an overview of these and otherapproaches that now complement the traditional Agile core, and discuss how toselect among them when deciding which isthe next approach to adopt.

Getting Better CustomerInsights FasterThe last several years have been a time ofintense innovation around customer insights.Agilists have combined techniques from several disciplines, such as user experience(UX) design, software analytics, and evenresearch techniques borrowed from anthropology and psychology. They have alsoexpanded and honed elements of the Agiletoolkit, such as using user story mapping togenerate an initial backlog of user stories.

This workshop provides an introduction to allof these techniques. You’ll learn how to builda strategy around these techniques, increasingthe speed of collecting these insights, improv-ing their reliability, and lowering the cost ofacquiring them.

Consulting& Training

Agile Product Management & Software Engineering Excellence

Agile: The BasicsWhatever the number of teams, the level ofAgile experience, or the type of project orproduct, our approach is the same: Get teamsto the Agile starting line as quickly as possible. We include many hands-on exercisesduring this three-day training, and we startimmediately defining, estimating, and prioritizing the backlog. We move quickly intorelease and sprint planning, so that when theworkshop is finished, your teams are as readyas possible to start.

Naturally, we offer follow-on coaching as well.In most cases, this workshop rolls immediatelyinto whatever additional backlog creation andplanning the team needs to get working assoon as possible.

Improve Measured BusinessPerformance with LeanHistory has shown that nobody can imposelasting change on an organization. But organicchange can become permanent. Throughtraining, advisement, and/or facilitation andcoaching, this workshop will lead your organi-zation through an approach that incrementallyweaves such change into your organization’sfabric, decreasing waste and increasing business performance.

Drawing up four major toolkits, Lean, Kanban,Complexity Management including Cynefin,and modern Systems Engineering, and thehighly effective Lean Startup experimentalapproach to value determination, you’ll discover a strategy that is different than the“cut waste” strategy of many American Leaninitiatives; this strategy reliably improvesvalue, flow and business results.

Leading Successful ProjectsMost of the fixed rules that governed projectsonly a few years ago have been thrown outthe window. Today a project needs to be runas a spry organism, nimble to the changes it’ssure to encounter. We think of ourselves assystems designers, but the project is a systemtoo, and do we ever turn our skills to properlydesigning it? All of the heuristics governingsystem design can profitably be applied todesign of the project, including design so thatsuccessful implementation is possible; designthat allows for ease of testing; defensivedesign that counteracts error and fault; iterative design; and design for ease of humanuse. Each of these heuristics is routinelyapplied to the design of software products.Now it’s time to apply them to designing software projects. The goal of this course, ledby Cutter Fellow Tim Lister, is to help yourprojects be more productive and better able toturn out quality results. You’ll be prepared fora leadership role in designing, populating, andinhabiting these adaptive project organisms,ensuring your project meets its challenges,and achieves its promise of success.

For More Information

For more details and a complete listing

of all Cutter Consortium’s Agile Product

Management & Software Engineering

Excellence offerings, visit cutter.com,

contact [email protected] or call

+1 781 648 8700.

John Heintz

37 Broadway, Suite 1

Arlington, MA 02474-5552, USA

Tel: +1 781 648 8700

Fax: +1 781 648 8707

Web: www.cutter.com

Email: [email protected]

Cutter ConsortiumAccess to the Experts

Ab

out

the

Prac

tice Agile Product & Project

ManagementFrom applying the “nuts and bolts” of Agile, to transforming your organization at the

enterprise level, to applying technical debt to reduce risk and improving software

governance, Cutter offers the consulting, training, and research you need to make

your Agile initiative a source of strategic competitive advantage.

Cutter and its experts are pioneers and leaders in the Agile movement. The Agile

practice goes well beyond software methods to include just about any aspect

of software engineering that interests you. We have deep expertise in Agile/Lean/

Kanban deployments, system engineering, human systems dynamics, devops,

technical debt, software governance, and much more. We carry out technical

due diligence and code audit engagements for investors, venture capitalists, and

corporations in a broad spectrum of industries. Our experts also address the strategic

aspects of world-wide product development, and we even assist downstream

functions and departments, such as marketing, to extend these principles into their

fabric. Through consulting, research, training, coaching, and speaking engagements,

we help clients embrace enterprise agility. In so doing, we make clients’ software

and other systems a source of sustainable competitive advantage in an era

characterized by constant change.

Your team will find many forums in which it can interact with Cutter’s Agile experts

to brainstorm, debate, and learn. From research and inquiry privileges to regular

virtual meetings with Cutter’s Agile thought leaders, participation in webinars, and

Agile-specific Q&A sessions, the opportunities to discover new strategies, gain

insight into how to launch new practices, secure support for your governance

strategies, and more are boundless.

Products and Services Available from the Agile Product & ProjectManagement Practice

• The Agile Membership

• Research & Analysis

• Inquiry Response

• Consulting

• Inhouse Training & Executive Education

• Mentoring

• Research Reports

Cutter Consortium Practices

Each Cutter Consortium practice includes a subscription-based research service,

plus consulting, training, and executive education services:

• Agile Product & Project Management

• Business & Enterprise Architecture

• Business Technology Strategies

• Data Insight & Social BI

Senior ConsultantTeamThe Cutter Consortium Agile Product & Project

Management Senior Consultant Team includes

many of the trailblazers in the project

management/peopleware field, from those

who’ve written the textbooks that continue

to crystallize the issues of hiring, retaining,

and motivating software professionals, to

those who’ve developed today’s hottest Agile

methodologies. You get sound advice and

cutting-edge tips, as well as case studies and

data analysis from best-in-class experts. This

brain trust includes:

• Israel Gat, Practice Director

• Scott W. Ambler• Jurgen Appelo• Christopher M. Avery• Kent Beck• Tom Bragg• Alistair Cockburn• Jens Coldewey• Ward Cunningham• Patrick Debois• Esther Derby• Khaled El Emam• Hillel Glazer• Tom Grant• Sebastian Hassinger• John Heintz• Ron Jeffries• Peter Kaminski

• Mark Levison• Tim Lister• Alan MacCormack• Michael Mah• Sue McKinney• James Robertson• Suzanne Robertson• Alexandre Rodrigues• Dave Rooney• Johanna Rothman• Andrew Shafer • Hubert Smits • David Spann• Giancarlo Succi• James Sutton• Rob Thomsett• Lynn Winterboer• Robert K. Wysocki

Crossing the Agile Divide

Documents

Transcript of Crossing the Agile Divide