Sei sulla pagina 1di 103

The Agile with Scrum User’s Guide:

A Compilation of Thoughts and Practices

Compiled by Joel Adams, CSM jadams@devonconsulting.com

Edited by Jillian Neustel jneustel@devonconsulting.com © 2006

This book is an edited and organized compilation of over 100 postings to message boards and a few other texts. The primary source is ScrumDevelopment in Yahoo Groups.

Although the term Agile can cover a wide range, I have always been most interested in people, team productivity, and project management. The subjects selected for this book and these particular answers and comments were useful to me in learning about Agile and teaching others about Agile.

-- Editor

THE HISTORY OF AGILE SOFTWARE DEVELOPMENT

1

1.1 ORIGINS OF SCRUM

2

1.2 IMPLEMENTATION CHALLENGES

4

1.3 AGILE VS. WATERFALL

6

1.4 SCRUM VS. TRADITIONAL SPIRAL DEVELOPMENT

7

1.5 CMMI AND AGILE

9

1.6 AGILE AND PMBOK

10

1.7 SCRUM WITH RUP

12

1.8 PERSONAL SCRUM

14

TEAM SPACE AND ON-SITE VS. OFFSHORE

16

2.1 BULL PENS / CO-LOCATION / OPEN SPACE (QUIET WORKING CONDITIONS VS. COMMON ROOM)

 

17

2.2 DISPERSED (NON CO-LOCATED) TEAMS

19

2.3 ON-SITE CUSTOMER

20

TEAMWORK AND HIERARCHY

22

3.1 APPLICATION ARCHITECTURE ACROSS TEAMS

23

3.2 SELF-ORGANIZING TEAMS

25

3.3 SCRUMMASTER: ELECTED FROM TEAM

26

3.4 SCRUMMASTER: TEAM MEMBER OR COACH

27

3.5 SCRUMMASTER: COMMUNICATION

29

3.6 BUSINESS ANALYSTS AND SCRUM

30

3.7 IS THE PRODUCT OWNER A PIG OR A CHICKEN?

33

3.8 INTERACTION DURING SPRINT

37

3.9 RETROSPECTIVES: WHO SHOULD FACILITATE

39

3.10 SPRINT REVIEW: STAKEHOLDERS ROLE

40

3.11 TEAM MEMBERS

42

3.12 PERFORMANCE REVIEWS

43

DEVELOPMENT PRACTICES

45

4.1 BEST PRACTICES

46

4.2 IMPLEMENTING AGILE ON YOUR OWN

47

4.3 DAILY BUILDS

48

4.4 DAILY SCRUM MEETING

50

4.5 SCRUM OF SCRUMS

51

4.6 SPRINT GOAL

52

4.7

TASK SIZE VS. EFFORT VS. DURATION

53

4.8 TASK SIZE (BREAKING DOWN TASKS)

54

4.9 SPRINT CALENDAR

55

4.10 ESTIMATES

56

4.11 ESTIMATING TESTING

57

4.12 PLANNING AND ESTIMATING TASKS

58

4.13 TECHNICAL DEBT – BIG REFACTORINGS NOT YET DONE

61

4.14 REQUIREMENTS READY FOR SPRINT

62

 

4.15 TESTING

63

4.16 TEST DRIVEN DEVELOPMENT

64

4.17 UNIT TESTING

66

4.18 BUGS – HOW TO HANDLE

69

4.19 RETROSPECTIVES

70

4.20 IMPLEMENTATION OR CUSTOMIZATION REQUIREMENTS

71

4.21 REQUIREMENTS DEFINITION SPRINT

72

4.22 VERY LARGE PROJECTS

74

4.23 SPRINT BURNDOWN

75

4.24 NEW TASKS ADDED TO LIST OF SPRINT TASKS

77

4.25 PRODUCT BACKLOG

80

4.26 MOVING PRODUCT BACKLOG TO THE SPRINT

81

4.27 PRODUCT BACKLOG IS A NULL SET

83

4.28 DEFINITION OF DONE

84

PRINCIPLES, MEASUREMENTS, AND TOOLS

86

5.1 SCRUM PERFORMANCE MEASUREMENTS

87

5.2 SCRUM PRINCIPLES

88

5.3 DECLARATION OF INTERDEPENDENCE

89

5.4 SITUATIONAL OWNERSHIP: CODE STEWARDSHIP REVISITED

90

5.5 THE TOP 10 KEY DIFFERENCES BETWEEN A TEAM OF INDIVIDUALS AND A GROUP OF

 

INDIVIDUALS

92

5.6 BURNDOWN TRACKING

94

5.7 USER STORIES

95

5.8 AUTOMATED TRACKING TOOLS

96

5.9 REFACTORINGS

97

5.10

SCRUM ON A PAGE

99

Section One:

The History of Agile Software Development

1.1 Origins of Scrum

Of historical interest is that Scrum was incubated at Easel Corporation in 1993 where I had just joined them as VP of Object Technology after spending 4 years as President of Object Databases, a startup surrounded by the MIT campus in a building that housed some of the first successful AI companies.

My mind was steeped in artificial intelligence, neural networks, and artificial life. If you read most of the resources on Luis Rocha's page on Evolutionary Systems and Artificial Life you can generate the same mind set:

http://informatics.indiana.edu/rocha/alife.html

I leased some of my space to a robotics professor at MIT, Rodney Brooks, for a company now known as IROBOT

Corporation. Brooks was promoting his subsumption architecture where a bunch of independent dumb things were harnessed together so that feedback interactions made them smart, and sensors allowed them to use reality as an external database, rather than having an internal datastore.

Prof. Brooks viewed the old AI model of trying to create an internal model of reality and computing off that simulation was a failed AI strategy that had never worked and would never work. You cannot make a plan of reality because there are too many datapoints, too many interactions, and too many unforeseen side effects. This is most obviously true when you launch an autonomous robot into an unknown environment.

The woman I believe will one day be known as the primeval robot mother by future intelligent robots was also working in my offices giving these robots what looked like emotional behavior to an external observer. Conflicting lower level goals were harnessed to produce higher goal seeking behavior. These robots were running in and around my desk during my daily work.

I asked IROBOT to bring a spider-like robot to an adult education course that I was running with my wife (the

minister of a local Unitarian Church) where they laid the robot on the floor with eight or more dangling legs flopping loosely. Each leg segment had a microprocessor and there were multiple processors on its spine and so forth. They inserted a blank neural network chip into a side panel and turned it on.

The robot began flailing like an infant, then started wobbling and rolling upright, staggered until it could move forward, and then walked drunkenly across the room like a toddler. It was so humanlike in its response that it evoked the "Oh, isn't it cute!" response in all the women in the room. We had just watched the first robot learn how to walk.

That demo forever changed the way the people in that room thought about robots, people, and life even though most of them knew little about software or computers. (I believe the robot's name was Genghis Khan and he is now in the Smithsonian.)

This concept of a harness to help coordinate via feedback loops, while having the feedback be reality based from real data coming from the environment is central to human groups achieving higher level behavior than any individual could achieve on their own. Maximizing communication of essential information between group members actually powers up this higher-level behavior.

Around the same time, a seminal paper was published out of the Santa Fe Institute mathematically demonstrating that evolution proceeds most quickly, as a system is made flexible to the edge of chaos. This demonstrated that confusion and struggle was essential to emerging peak performance (of people or software architectures which are journeys though an evolutionary design space) as was seen in the robot demo.

On this fertile ground, the Japanese Scrum paper provided a name, a metaphor, and a proof point for product development, the Coplien paper on the Borland Quattro Product kicked the team into daily meetings, and daily meetings combined with time boxing and reality based input (real software that works) started the process working. The team kicked into a hyperproductive state (only after daily meeting started), and Scrum was born.

Jeff Sutherland 1

1 From: Jeff Sutherland jeff.sutherland@computer.org; Sent: Sunday, December 5, 2004 at 2:07 PM Subject: Wholeness

1.2 Implementation Challenges

Hello PaulOldfield1,

Thank you for writing.

> On Thursday, August 3, 2006, at 4:48:34 AM, PaulOldfield1 wrote:

> Yet I don't think this is the root cause, or solution, of the problem Ron was talking about. We've done fairly well

at getting the “buzzword” of Agile across, but we don't seem to be doing too well at following up with the enlightenment about what the buzzword really means. IMHO.

Yes, that's certainly what I've just been going on about. I'll give some examples.

Scrum and Engineering Practices In the Scrum world, the CSM course and the books don't say much about engineering practices. I guess it's assumed that if the team sets itself to producing real releasable software every month, they'll figure out what the engineering practices are that will help them do that. I actually believe that to be true, though it's often terribly slow waiting around for someone on the team to invent testing.

What happens, at least in part because Scrum says so little about engineering practices, is that teams do things that are far from ideal. A short list:

* Start a Sprint with analysis, so that programmers have nothing to do for a week or so;

* Throw the code to the testers at the end of the Sprint, so that they have little to do at the beginning and are overloaded at the end;

* Solve that problem by having a development Sprint followed by a "QA" Sprint, resulting in mostly idle people

half the time;

* Solve that problem by having testing for Sprint N during Sprint N+1, reducing feedback and interrupting Sprint N+1 programmers, and deferring fixes to Sprint N+2, reducing learning profoundly;

and

so on. There are many aberrations. We should produce a list of them. Maybe with a list of things labeled "If

you're doing these things, you're probably not doing it right yet," we could address this enlightenment question.

Agile and Additional Practices We have a number of Agile brands and branches who are strong proponents of some additional practices. Modeling is a popular example. Scott Ambler has been visiting lately, and he has an entire "Agile method" which is (was?) called "Agile Modeling". There are other examples, adding in Use Cases, Modeling, a bit of Up Front Architecture or Design, and so on.

What is unfortunate in my opinion is that most of these "defensive" additions to Agile are unnecessary, and have the result of appearing to say that if you are going to do Agile safely, you'd better do a bunch of requirements first, then some architecture, then some design, then finally code and test the application.

Since people are used to doing things roughly that way, that's what they read. They discover that they're "already doing Agile", add a couple of meetings to their practice, and proceed business as usual.

Agile Without Experience There are a lot of people pushing Agile today who have entered the market from some other realm. There are group dynamics people, PMI people, and so on. Some of these people – I want to say many – have little or no training from people in the Agile lineage, and have never been on an Agile project except for projects they have created and called Agile.

Einstein said: "Example isn't another way to teach: it is the only way to teach.” In Agile, that's certainly true. The best way to learn how much to test is to test too much, not just too little. The best way to learn how much to rely on up front thinking and building and how much on refactoring is to try to build software without all that modeling and infrastructure.

People who create methods without ever having worked with or even examined a really well-operating Scrum or XP project can't possibly know what they would if they had. I think their conclusions and recommendations would be quite different.

Agile Without Skills Software development is an intricate and difficult art. Yet as an industry we send people into the fray terribly poorly equipped. Even developers with degrees in the subject are not well prepared in terms of what is really needed today. More significant is the fact that many – again I'd say most – software developers have no significant training in the subject at all. They're self-taught refugees from some other realm, who have entered programming because it interested them, or because there were no jobs available for semanticists or whatever they studied in college.

To do the necessary engineering practices mentioned above, Agile teams require an especially wide range of skills, and the team needs to be really good at them. I would include human relations skills, requirements skills, design skills, programming of course, how about real Object Oriented programming, almost no one knows how to do that, relational database skills, and more. Add in customer-facing testing, unit testing, test-driven development, and refactoring. Add in some skills in setting up builds, and doing code management.

The list is endless, and if we're going to be Agile, we can't have some bottleneck person who is our only refactorer:

we all need to be good enough at most of these things. But there's no focus on these kinds of skills. Scrum, to name names, scarcely even admits that these skills exist, much less matter.

Now sometimes, Scrum proponents claim "all those things have always been part of Scrum". It's true that all those things have always been part of //successful Scrum projects//, because they have to be. Authors of other Agile

methods say similar things: we don't mention all these foundational things, they are taken for granted. But so few

people have them, how can we take them for granted? Technical skills are often not part of Agile culture need to be.

and they

Summary Ken and others like to say that Scrum is "common sense". In my experience, it isn't. Jeff likes to point to Scrum teams that are "hyper-productive". In my experience, most aren't. The reasons have to do with the passing on of knowledge, and in some cases, the active denial that knowledge is necessary, and the active addition of things that are only sometimes needed.

The Agile marketplace is filling up with people, mostly of good will, trying to do a good job, who, nonetheless, have an n-th hand partial picture of what it's all about. Of course, in the end, all of us only have a partial picture of what it's all about, YT included. And yet, it seems to me that things are getting watered down. Maybe that's inevitable.

Ron Jeffries 2

2 From: Ron Jeffries ronjeffries@acm.org; Sent: Thursday, August 3, 2006 at 4:10 AM Re: Agile 2.0 (2nd Attempt)

1.3 Agile vs. Waterfall

1. The difference between Agile and Traditional Project Management is simple and distinct.

a. Agile is function / goal based – that is to say focused on what the product owner and user feel is critical to their success

b. Traditional is task / cost based – that is to say focused on the providing the customer proof that the resources invested are being consumed according to plan

2. Neither approach communicates needed information to all parties concerned.

a. Agile speaks poorly to customers who want to know where the money went

b. Traditional speaks poorly to the product owner and user as to the usefulness of the functionality being provided

3. The differences are profound but at the same time driven by the audience each approach talks to.

a. Bottom up support from users, customers, and clients will push organizations to use Agile methodologies

b. Top down pressure by stockowners, investors and will push organizations to remain with traditional methodologies

4. There needs to be some thought put into building an interface between the two methodologies so that our customers can better use our skills and we can be seen as useful. 3

3 From: Mike Dwyer mike.dwyer1@comcast.net; Sent: Thursday, January 13, 2005, at 10:35 PM Subject: Lessons Learned Forward

1.4 Scrum vs. Traditional Spiral Development

I work in an organization that is just (finally) beginning to take an interest in using Scrum and other Agile practices. One of the questions I was recently asked was "How does Scrum differ from traditional spiral development?" To be honest, I feel a little stuck. I can probably give some vagueish answers to this, but I'm hoping that someone can point me to a short article on the web that summarizes the differences – with better clarity. Or respond directly to this email with some bullet points. Any input? Tobias 4

Hi Tobias--

I get asked this exact question quite often – in fact, in probably 2/3rds of the Scrum classes I teach. Here are a few key points:

--Boehm's spiral model is risk-driven. To start each pass through the spiral you determine the riskiest thing and do activities to resolve that risk (normally code that part of the system). Scrum, on the other hand, is customer-value driven. To start each Sprint, the product owner selects her highest priority work. This is a very key distinction because spiral model leads to work on risky items that may not be needed. It also puts the development team in a mode of avoiding risk instead of a mode of delivering customer value. This doesn't say we ignore risk in Scrum and often risky stories get prioritized quite highly but risk is not the only or the driving factor.

--Spiral model is iterative but doesn't stress having the same length of Iteration each time.

Sprint length every Sprint. deliver.

Scrum wants the same

This creates a very nice rhythm to the project – every 30 days the team knows it will

--Spiral projects may or may not produce working code each time through the spiral. During the initial go-rounds it is entirely likely they won't produce code, or at least won't produce code that lives in the final product. Scrum teams will.

--The spiral model is really a shortened waterfall if you uncoil it. There are distinct phases. They may overlap slightly but they are not highly/totally concurrent as with Scrum.

I hope that helps,

--Mike Cohn 5 Author of User Stories Applied for Agile Software Development www.mountaingoatsoftware.com

Been thinking/reading a little more myself since yesterday, and believe the following two observations are also true:

--A Scrum team is self-managing and self-organizing whereas a development team on a traditional spiral model is management-driven. Key decisions within a Scrum Sprint are made by the team, collectively, not by management.

--Scrum emphasizes customer involvement at the start and end of every Iteration; spiral, like waterfall, only involves customers at the start of a project.

Would you agree?

Tobias 6

4 From: Tobias Mayer tobyanon@yahoo.com; Sent: Tuesday, December 14, 2005 at 5:45 PM Subject: Scrum vs. "Traditional Spiral Development"

5 From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Tuesday, December 14, 2005 at 7:24 PM

6 From: Tobias Mayer tobyanon@yahoo.com; Sent: Wednesday, December 15, 2004 at 7:23 AM

<Mike Cohn agreed with Tobias. Here is a differing answer. – Editor>

Hi,

Mike gave a nearly perfect summary for the spiral model.

No, I don't really agree. I would go so far that we have to say: Scrum and spiral model are completely different approaches, like basketball and ice hockey are two completely different games. Both have projects and especially software projects in common, like both games are (team) sports

Scrum focuses on a lot of things that I would call "people centric". How to get "people", the team plus stakes holders, to work together. The spiral model is problem centric. What are the core problems in software development? Neglecting risk is one. And most if not all other problems can be translated into their associated risk.

I would say the spiral model does not cover questions about how to organize a team.

doing Scrum, most of the time you do the spiral model as well (or a lot of things similar to spiral model phases),

don't you?

And in fact when you are

One big difference in the area where Scrum and spiral model overlap IMHO is:

Scrum encourages prioritizing by ROI; it’s the ScrumMasters responsibility to point out risks (IMHO) (because risks endanger ROI). The spiral model prioritizes by risk, so the customer/product owner is himself responsible to identify/remove risks.

But Mike pointed that all ready out when he said Scrum is customer value driven. There is no value and a low chance of success if the value only can be achieved by taking a big risk and not focusing on how to lower or remove that risk.

In fact, when one is asking me what is Scrum? Then I answer: a variation of the spiral model. And I give 5 points I find important corner points (like fixed Sprint length). Probably I always answered wrong?

Angelo 7

7 From: Angelo Schneider angelo.schneider@oomentor.de; Sent: Wednesday, December 15, 2004 at 5:39 PM

1.5 CMMI and Agile

1. Adding XP can’t be done because CMMI simply does not provide the means for an Agile-centric development

process.

2. After some more thought and much hand waving, adding Agile can be done because CMMI does not describe the

actual details of implementation.

3. Once over this hurdle, it turns out to be harder than it looks because the two distinct cultures need to be brought

together. Both cultures need to understand each other and search for join points.

4. Then it becomes easier than it looks once the cultural aspects are overcome and the quest for process improvement and software quality is joined in both cultures.

5. Then it becomes hard again once the first major problem is encountered. The naysayers will naturally say, “I told

you not to do that.” The supporters will naturally say, “Give it a chance, and we’ll work out the kinks.”

Steps 4 and 5 will repeat for some time until experience, consensus, and cultural connections are reached about the benefits, risks, issues, and costs of incorporating Agile in the CMMI framework.

Blending Agile Development Methods with CMMI®, by Glen Alleman, in The Evolution of Agile Project Management, Cutter Consortium Paper, 2004

1.6 Agile and PMBOK

Sounds strange in the same sentence, huh? I want to generate some discussion on the following: Can you use PMI concepts on an Agile project? I think you can. The main intellectual jump a PMP project manager has to make (I am one by the way) is that you have to look at the work differently. You cannot view tasks in a plan as delivering value. In software, you have to look at delivering working code. You get past that, and things are no so different.

We all manage risk, cost, time, integration, scope, people, communication, risk, and sometimes procurement. You just have to structure these things according to an Agile philosophy and build flexibility into your systems.

I think we need a language for helping the "establishment" understand how it adds value and can complement existing methods?

Thoughts? 8

I definitely think this is a worthwhile discussion! Having struggled with it, I found some presentations that actually had some good thoughts. They were done by Rally and presented at various conferences. They go through the mapping of Agile Project Management and the PMBOK. It makes for some good reading:

Whitepaper: A project manager's survival guide to going Agile

http://www.rallydev.com/kportal.jsp?doc=wp15

Presentation: A project manager's survival guide to going Agile 9

http://www.rallydev.com/kportal.jsp?doc=wp11

What about an APMBOK?

Particularly small to medium size companies can't bear the whole processes suggested by PMBOK.

Cheers,

Adail 10

PMBOK and Agile are completely different approaches to software development.

The PMBOK takes a deterministic detailed approach to project management that can be used (at least parts of it) in any project be it software or construction.

Agile is a movement based on values and principles (not prescriptions like the PMBOK).

You can be an Agile project manager and look at the PMBOK for "things to consider when managing a project", however, if you are looking for a prescription on how to do Agile project management you are (IMHO) in the wrong crowd.

Agile does not prescribe what you must do, just what values and what principles you should look to for guidance, the rest is up to you.

This is probably one of the factors that makes Agile adoption so hard. People think they can just do stand-ups,

retrospectives, TDD and everything else will work. That's not how it goes

Agile is not a "silver bullet". 11

8 From: "mikecottmeyer" spamhole@cottmeyer.com; Sent: Tuesday, August 01, 2006 at 9:48 AM

9 From: "aggie_melissa2000" aggie_melissa@hotmail.com; Sent: Tuesday, August 1, 2006 at 10:30 AM 10 From: "Adail Retamal" adail.retamal@gmail.com; Sent: Tuesday, August 01, 2006 at 11:32 AM

Dear Sirs,

I guess it is important to remember that PMBOK also doesn't dictate what should be done. As Agile, it is not a prescription. It is a Guide to a set of good practices.

The manager should carry an analysis for each project of what of these practices and in what degree it should be applied. And it doesn't matter in what industry.

Peter Mello, PMP 12

11 From: "duarte_vasco" vasco.duarte@f-secure.com; Sent: Tuesday, August 01, 2006 at 12:02 PM

12 From: Peter Berndt de Souza Mello peter.mello@x25.com.br; Sent: Tuesday, August 01, 2006 at 12:33 PM

1.7 Scrum with RUP

When I heard about this article last week, I was curious if IBM would try to portray Scrum as an "add-on" to RUP, or if they would introduce Scrum as a standalone process with which RUP disciplines/workflows (whatever they call them now) can be incorporated per the discretion of the team. In other words, is RUP presented as the container and Scrum the contents, or is Scrum presented as the container process with RUP workflows as (potential contents).

Although at the beginning of the article they seem to give self-organization and "Scrum is a management-wrapper" lip service, the author seems to forget all of that by the conclusion, which reads:

“In general, RUP satisfies organizational demands by bringing a structured and proven process framework to the table, and Scrum patterns can add additional dynamics to the project.”

I'd argue that Scrum, by virtue of it's foundational requirement for team self-organization and empirical process, can never be contained or absorbed by another process that dictates defined processes, like engineering practices. Can RUP practices be used with Scrum? Of course! Any team that chooses to do RUP workflows because that's what works for them, is free to do so under Scrum's self-organization. In this case, Scrum is the parent-process, not a subordinate process.

But it can't work the other way around: if we are doing RUP our world of engineering practices are limited to the workflows defined in the RUP. That limit flatly violates core Scrum principles, so you can't add Scrum onto a process like the RUP as a subordinate, secondary process.

Actually, if IBM treats Scrum as a sanctioned add-on to RUP, and Scrum allows teams to pick and choose their own engineering practices, doesn't RUP then become "anything the team wants to do". I doubt IBM would want to take it that far.

Any thoughts?

-- Victor Szalvay 13

Rational Unified Scrum/XP

Marco Abis on the XP mailing list mentions a message-thread on RUP and Scrum/XP on the Scrum mailing list Here are some snippets:

Is this

type of metaphor appropriate for Agile processes, or does this level of delineation lead to them being fodder for M/S project, for 'hands-off' management, and for robotic tracking of plans while ignoring realities?"

Ken Schwaber: 14 "Let us hypothesize that having a Scrum plug-in for RUP is an idea worth pursuing. [

]

Ron Jeffries: 15 "The comments from Rational clearly did not reflect the soul [of XP]. They do not get 'Agile' in my

opinion.

thinking, and a command and control orientation. [

belief that it would be better with me than without me, and I think it is. Even so, it is still a long way from expressing what XP is."

My involvement with the RUP XP plugin was based on my

Their philosophy, again in my opinion, is based in large-systems experience, old-style 'up front'

[

]

]

Adriano Comai: 16 "having been involved in many RUP customizations, I think RUP_Scrum makes sense (much more, in my opinion, than RUP-XP). RUP needs _exactly_ the Scrum practices to become Agile. As you know, many shops with an existing waterfall culture buy RUP as an help to move towards a more effective development approach, and then misuse it."

13 From: Victor Szalvay victor@danubetech.com; Sent: Tuesday, February 15, 2005 at 4:26 PM Subject: Re: Scrum + Unified Process = ?

14 http://groups.yahoo.com/group/Scrumdevelopment/message/779

15 http://groups.yahoo.com/group/Scrumdevelopment/message/783

16 http://groups.yahoo.com/group/Scrumdevelopment/message/787

Alan Shalloway: 17 "You can take a committed dev group (most are) and have them do RUP/Scrum in a way that an

here's a chapter discussing this I've just

put on our public wiki (Dan Rawsthorne and I are writing a book on effective software development and this is a likely chapter). See:

upper management that doesn't want to hear about Agile will accept. [

]

Marco Abis: 18 "will try to explain why I think so (after years of effective RUP implementations!): RUP is

fundamentally a very, very big framework [

makes me think that what managers want is something that isn't really useful to deliver the right project and often is the first impediment to the project success."

[

I will not spend time to write why managers like RUP but not Scrum

]

]

Adriano Comai: 19 "Sometimes it's difficult to tell these organizations, who made huge investments into RUP: throw it off, there are more effective approaches out there, try them instead. In such cases, I believe, it is better to suggest an improvement using Agile practices in the context of the existing process."

Marco Abis: 20 "I experienced a lot of clients (of mine, of course) professing they were implementing an "Agile version" of RUP but when I analyzed their work I found they were just cutting off some documents feeling "more

lightweight". I definitely think this is one of the main issues: a lot of people believe Agile means just less docs, they try to cut off some of their docs and then affirm Agile is nothing more than this. As stated by Jim [Highsmith]: they

For those who haven't read

it I suggest 'Agile Revolution' 21 by Mike Beedle. Marco referred to http://www.crystalmethodologies.org/cgi/wiki?AgileVsSelfAdapting, from which I quote Jim

] Doing the change

case is very laborious. Just heard of an airline company that wants to use RUP, so they spent 6 months creating a RUP-for-them. Now every project has to spend 2 months turning that into a RUP-for-the-project. Problem is when the project is only 6 months long, this is too long." Another Highsmith quote on that page: "But lightweight is only one aspect of Agile, the other two are collaborative values and principles and a fundamental understanding of the unpredictability of project activities (although outcomes can be achieved). Agile is much more than lighter documentation and fewer processes. Rational is trying to have it both ways – still telling corporate managers what they want to hear in terms of predictability, control, productivity, etc. while at the same time touting that they are 'Agile' also."

Highsmith: "So self-adapting, by itself isn't Agile." and Alistair Cockburn: "criticisms of RUP [

are missing fundamental understanding of the unpredictability of project activities. [

]

17 http://groups.yahoo.com/group/Scrumdevelopment/message/788

18 http://groups.yahoo.com/group/Scrumdevelopment/message/800

19 http://groups.yahoo.com/group/Scrumdevelopment/message/803

20 http://groups.yahoo.com/group/Scrumdevelopment/message/804

1.8 Personal Scrum

I wanted to share with you an experiment I've been running for the last several months, in hopes that it might spark some interesting conversation. It's the use of a modified version of Scrum for managing my life, and through trial and error it's become quite useful in helping me to do a better job accomplishing goals and filling my life with things that make me happy.

It started several months ago when I realized that my life bore some striking similarities to a dysfunctional software development project. Which is to say it was filled with a lot of unclear direction, goals that weren't being met, responsibilities and obligations going unfulfilled, and important "maintenance" that was being put off again and again – with a net result that "the product" (in other words, the experience of being me) was not all that it could be.

So I set about seeing how Scrum could be applied to improve matters. Here's what over several months I've found worked well for me.

Sprints last one week, and Sprint Planning takes place Sunday nights. I begin by making an estimate of the time I will have available to put toward my goals of the week – typically, this is about 10 hours (or about 1 hour per day during the week, and 2 hours each weekend day). My life backlog has at the top of it a recurring list of items that I consider "must-haves" every week – these are the things that I consider necessary for "the good life" for myself or those around me. I actually have them grouped according to the various personae that comprise "me" – husband, father, son, citizen, learner, body, and so forth. Organizing it this way helps me ensure I don't overlook an important part of who I am, as I think about what I wish to do in the week; it also allows me to aim for a balance among these different directions. So, for example, under "body", my standing backlog items might include "take vitamins on 5 mornings", "do yoga on 3 mornings", "get 8 hours of sleep on 4 nights", etc.

The criteria for an item to appear on the backlog is two-part. First, it must be important for "the good life" (now there's a topic that deserves its own posting if ever there was one). Second, it must be something that might not otherwise happen. So, for example, I don't need to put "brush teeth" or "go to the bathroom" on the list (or at least I haven't yet). I began with things that were chore-like (such as taking my vitamins), or which were enjoyable but required forethought and so I tended to miss them (like organizing an outing for my daughter and me). Over time, though, I found it useful to include anything that met the basic criteria above. For example, I love playing computer games, but I was finding that when life got busy, it would be one of the things that got squeezed out. Now it's an item on the backlog: Play an hour of computer games. It might seem a little odd to in a sense "make a date with oneself to do something that's akin to goofing off", but if it's goofing off that matters, it should be on the backlog.

Each of the recurring items on the backlog has a time estimate associated with it, and these become quite accurate over time, since they come up every week.

Once I've gone through the recurring backlog items, I move onto the non-recurring backlog items. These are either one of the things I need to do ("plan family vacation") or represent small progress against big goals ("complete 1 chapter of mandarin textbook"). I generally only have enough of my budgeted time remaining to commit to one or two of these items, but frankly, that's one or two more than I was committing to before.

Once I've made my commitment, I print up a sheet that lists the tasks and time remaining, and I post it in a very visible place in our house (kitchen wall). I'll sometimes talk through it with my wife for a few minutes, as a way of making the commitment even more visible and "real".

Then, just before bed each night, I'll do my equivalent of the standup meeting – looking at the task list, marking tasks that have been completed, and mentally orienting myself to what I'd like to do tomorrow.

Then, when Sunday rolls around, there's usually a little scramble to complete some tasks, but Sunday morning is actually a great time to do this. My "Sprint Review" on Sunday evenings consists of looking over the tasks from the week, and giving myself a pat on the back for what I was able to accomplish, and if there are things I wasn't able to accomplish thinking about why. This leads into planning for the week ahead. In thinking about the week that's passed, I can adjust some of the goals for the week ahead. For example: if I've been feeling dragged out, I might adjust several of the items on the recurring portion of the backlog (increasing 8-hour nights of sleep from 3 to 4, and

swimming from 2 days to 3); or if I have a busy work week ahead, I'll cut back my time budget, and make some calls about tradeoffs.

One of the things I've found is that for this approach to be successful, unbudgeted time must still be preserved. In other words, the time you allocate to personal Scrum must be only a fraction of the free time you have available. Happiness depends in part on being able to decide on the spur of the moment to do nothing, or do something completely silly and unproductive, and do it without any guilt at all.

One of the areas where the approach falls flat is "non-standard" weeks – for example, going on vacation, or having guests visiting, or other situations where budgeting time in this way is undesirable or difficult to do.

Overall, this approach has had a positive effect on my life, and the experience has been similar to that of teams I've worked with in adopting Scrum: greater sense of clarity of direction, repeated satisfaction of accomplishment, greater confidence in setting personal goals, and a greater sense of contentment and peace around living up to one's responsibilities and opportunities.

I'd love to hear about others' experiences with other Scrum – or Agile-based life management techniques. 22

Pete,

Thanks for this. It's a really well described account, and an excellent example of the power of Scrum as a simple means to effect change. I enjoyed reading it.

I have been using Scrum-like practices to organize my daily workload since becoming a consultant. I can get in a total mess with all the things I have to think about on a daily basis so I now keep a backlog of everything (work and personal) that I know needs to be done. At the end of each day I review what I have accomplished, re-prioritize the backlog, and commit to a new chunk of items for the next day. Note that this is only to deal with day-to-day "stuff", and not, as you describe, for self-improvement – although the result is certainly an improvement on my quality of life and peace of mind. The inspection/adaptation element comes naturally as part of the review and re-prioritization process, and I have not (yet) found the need to put aside special times for that.

Scrum is such a simple framework, and its principles can be applied in many different contexts. What I find interesting is that the resistance to Scrum in organizations is often based on a perception that it is a highly unnatural way of working. People fear it because it is so different from what they are used to in the work environment.

When I work with organizations I like to guide them towards finding examples of how they actually use many of the Scrum principles in their daily life already, e.g. making lists, prioritizing important things over non-important ones, trusting that their husband/wife/kids will make good on their commitments, task-sharing on chores, regular family meetings, etc. This frees the mind to see that Scrum is actually a very natural way of thinking and operating.

There was an amusing thread on this list about two years ago regarding the use of Scrum to organize family life. Here is the kick-off post, from Michael Vizdos:

http://groups.yahoo.com/group/Scrumdevelopment/message/3401

Tobias 23

22 Pete Deemer petedeemer@yahoo.com

23 From: Tobias Mayer tobyanon@yahoo.com; Sent: Monday, July 17, 2006 at 5:15 AM Subject: Personal Scrum

Section Two:

Team Space and On-Site vs. Offshore

2.1 Bull Pens / Co-location / Open Space (Quiet Working Conditions vs. Common Room)

At Danube, we have a large Bull Pen that houses all team members without barriers. We've definitely seen the positive effects like spontaneous collaboration and assistance. But I've also noticed people getting distracted and even annoyed by the enthusiastic discussions of teammates or neighboring teams. We've elected to keep our Bull Pen because the value added outweighs the minor interruptions, but I wonder what others have concluded. 24

…My experience with the disturbance phenomenon has been that different people have different thresholds for when and how much they need quiet time to solve problems. It is helpful if team members are sensitive to and respect these individual differences in their teammates.

One technique I have seen work well to indicate someone who needs to concentrate at a given time is the use of headphones. This says: please don't disturb me, I am concentrating. It also helps block out the noise of distracting comments and activity from others. For those who find music itself distracting, there is really no reason you have to play music (no one will know), the visual cue alone may be sufficient. 25

On the one hand I see great value in the common room approach to a team working together… I know that the synergy of a group happens in part because of personal interaction. So I find great value in a process that recognizes this trait.

However I am finding it difficult to balance this with the concept that “knowledge” workers need quiet working conditions to be productive. I think this is common sense. One needs to get into the “flow” and distractions will knock you out of “flow”. 26

For both me and the teams I've coached, the difference is not quiet as such, but whether the noise is related to the project. On-topic discussions don't seem to interrupt flow in the same way that off-topic ones do. The last team I was on developed enough of a conviction about this that we would kick the CEO out of the project room if he started to shoot the breeze with the product manager.

My current favorite trick when I need to have a potentially distracting discussion but don't have alternate space available is to go for a walking meeting. Three people's about the maximum for this, but it's a good way to have a chat, reduce stress, and get a little exercise 27 .

Having worked in both traditional and open workspaces, I much prefer the latter, and find music a good alternative to walls.

But note: without walls, it can be very important to help people reduce peripheral *visual* distractions – I think that, if you can, each person (or pair) should have one direction they can turn and not see anyone else (while seated). This can be done with half-high partitions or filing cabinets, etc. (As soon as you stand up, you see everyone again, and you can still hear everything). This is more important to some than others, but it's important to be sensitive to this. As a visual person, this kind of "visual noise" is MUCH more disruptive to me than sound – it can totally wreck my concentration. I guess if you're using XP's "caves and common" then this would apply only in the "caves". But we used this to achieve a totally "open" feeling workspace while allowing concentration, worked really well. But it requires a little more available desk real estate to keep it "open" otherwise you are back in cubicle land. (This was a SteelCase solution, in case anyone is wondering). 28

24 From: Victor Szalvay victor@danubetech.com; Sent: Saturday, September 18, 2004 at 4:31 PM

25 Michael K. Spayd, COGILITY, LLC

26 From: David A Koontz dakoontz@yahoo.com; Sent: Thursday December 16, 2004 at 11:23 AM

27 From: William Pietri <william@s

>;

Sent: Friday December 17, 2004 at 3:22 AM

28 From: "Deb" <deborah@h

>;

Sent: Friday December 17, 2004 at 8:41 AM

My take is, as always, keep a balance, between isolation and constant communication with the group.

Prolonged time in isolation, i.e. with no "real contact" with people, generally pulls people apart. On the other hand, too much interaction in the Bull Pen can be distracting.

We have had as many as 10 people in the room at any one time, with 1 or 2 people over time, "listening to music" on and off, but when it is time for everyone to get involved, we ask people to re-join the group. Also, on personal calls to cell phones or longish "interesting but not-work-related" conversations, most people leave the Bull Pen.

On the other hand, if there is a spontaneous collaboration conceived, we typically have it done at the Bull Pen, with the option to go to a couple of little conference rooms close by. These rooms have conference phones that are also used to call remote developers or customers. 29

[Reference to interesting article on a team development room. – ED.]

It alternates people so when looking directly ahead there isn't anyone in front of you. 30

29 From: Mike Beedle beedlem@e-architects.com; Sent: Friday December 17, 2004 at 6:01 PM

30 From: “todd” <todd@p

>

Sent: Friday December 17, 2004 at 8:59 AM

2.2 Dispersed (Non Co-located) Teams

My company is doing some pretty interesting things

business successful, but who are part-time and potentially transitory in nature. We will have approximately 6-8

people doing a "normal" full-time equivalent's worth of work.

a community of people that are committed to making the

These folks then are not only geographically dispersed, but chronologically as well. Stand-ups would have to be not only virtual, but modified to say not yesterday, but last time, next time for instance. Estimating, planning and tracking all get highly challenged in this environment as well. The closest and best example I could think of would probably come from the open-source community, but they probably don't have the commercial deadlines that our business might impose on us.

I'd be curious if anyone has had any practical experience with something somewhat similar in an Agile environment, and if you could share what worked or didn't for you. 31

One team is local and the other is offshore 11 1/2 hours ahead in time. I wanted to get some feedback from the Scrum development group as to how to organize such a team. Does "Agile development in the large" cover teams that are in multiple locations and in distant time zones? -Ron Wahler 32

Key practices:

1) Lots of unit tests 2) Daily calls at 10 pm or 7 am (or sometimes both) 3) User-level testing of subcomponents as early as possible.

Using 2) you can ensure 1) and 3) get done, and doing 3) helps spot cultural/stylistic issues early and keeps them from getting embedded all over the code. 33

31 From: "jdmcauliffe2002" jdmcauliffe2002@yahoo.com; Sent: Thursday, September 22, 2005 at 6:05 PM Subject: Interesting Agile Project Management Challenge

32 From: Ron Wahler

33 From: John Brothers jbwork@undefined.com

2.3 On-Site Customer

Scott,

With the Offshore project using Scrum that you have been involved in do you have a local customer representative (that is a person located in the same place as the people doing the coding)? Is that person from the company funding the project or from the offshore company? How much responsibility did this person have?

I have been offered a position that would mean I am acting in this particular role. My concern is that as a local

customer representative I would need to be able to make decisions, on the spot and not always delay and get a response from the person asking for the feature. Any information you could provide about how you have seen this work would be appreciated.

Thanks,

Kristan 34

I have various scenarios, and always it is customer driven; however in light of your question, no in general I do not

have an advocate on site in all projects. Because then that person becomes the team for want of a better phrase. By this I mean that the customer site will always go through the same person for all issues, which for me is not a good place to have a communication bottleneck.

What we do, is use a lot of tools to enable free communication across the teams no matter where they are, this is actually harder than would first appear.

Now to tackle your concerns, as I stated above you could if not careful end up the bottleneck in communication to which you have alluded already, it sounds in the role you are talking about you are more of a product manager <backlog product manager> more than anything else, in this case it could work well if you have very clear and open communication with the offsite ScrumMaster and team, again I can never stress the importance of real time communication when working Agile across distance.

In fact I suspect that you like I, will discover that the Agile process, is more a communication aid than anything else, and its through this communication of project visibility in a near real-time basis that enables Agile projects to react faster and redefine their targets

So in short, you seem to be in a defined product manger role <typical Scrum> correct me if I am wrong, and your client may expect you to able to respond immediately with feature requests and issues? If this is the case, it would be advisable to get the client to agree to a minimal time delay before you can answer, do this by quoting the classic QA Impact analysis line, i.e.: before a quick response can be given you need to get at least a quick/brief idea of the impact to the current Sprint/product development. I have met very few companies/clients that will not allow you to do a quick check on the impact of a new feature.

The only issue then would be how quick you can get feedback from teams on the impact of a change, very rough estimate as always

34 On Behalf Of Kristan Vingrys; Sent: Monday, May 23, 2005 at 8:31 AM Subject: Offshoring with Scrum

Sorry this email all over the place; I am typing on train :) please email further questions, and yell at me in CAPS if I miss the point of the post.

Good luck

Scott Worley 35

35 From: Scott Worley worleys@project-inspiration.com; Sent: Monday, May 23, 2005 at 11:23 AM

Section Three:

Teamwork and Hierarchy

3.1 Application Architecture Across Teams

I was wondering if anyone has any experience or thoughts on how an Application Architect that works across

different teams has been used in a Scrum development environment. We are in a situation where we are thinking about creating an application architect position in which we hope we can better align the architecture and coding standards among different teams so that the company begins to make headway into establishing a more standardized architectures for different applications we host and to be able to create "recyclable" components that can be reused by any team. Have Application Architects been able to work effectively with different Scrum teams? Seems that one of the key elements in Scrum is that the TEAM is really empowered to make their own decisions to keep the project moving along? Does that mean that the Application Architect would really have to be a member of more than one Scrum team to help keep all of the team's architectures aligned? 36

I believe a good approach would be to have one member (possibly two) of each Scrum team be a designated to be a

member of the Application Architecture team. This team might meet once a week to discuss the architectural goals and nominate various components of their Scrum team's architecture as being worthy of being promoted to being part of the overall application architecture. Otherwise, these architects actively participate in their own Scrum's activities where they actively spread the standards and goal of the Application Architecture to the other members of their team. Rotating membership in the Application Architecture team might work if you have enough senior staff.

Creating a dedicated Application Architect position is likely to cause a schism and be less effective than leveraging your current resources and team structure as suggested above. 37

I agree with Steve's comments – my teams use a designated architect in each Scrum team with a "chief" Architect

responsible at a department level. All of the component architects work on a team with the chief architect to ensure

that the standards, patterns, and overall architectural concepts are applied appropriately and, when necessary, challenged if a new paradigm is discovered. 38

I also agree with Steven.

(even though we haven't been using Scrum that long) and it has worked quite well.

Have a "Scrum of Scrums.”

We have been doing as he suggested for over a year now

A risk in having a specified application architect is that you might introduce unproductive conflict to the Scrum

team(s). A Scrum team needs the freedom to do whatever is necessary to meet their Sprint goal. Their overriding goal is always to provide working software that meets their customers' needs. If a standard architecture and

recyclable components are not valuable to the customer, then building them should not be valuable to the team. If

an Application Architect is there to enforce those standards, he can become an obstacle to the team.

I've been in that architect's position where a team has found a workable solution to a customer problem but I can see

a more abstract solution that would allow it to work for other projects. The team has already completed their

solution and it meets their customer's need, so who is going to take the time to expand that solution? The team has

no incentive to do so, and I don't have the time.

It can also become quickly overwhelming for one application architect to keep different projects aligned. Even with

two or three small teams (<5) there is so much design and code produced so quickly, (because the teams are empowered to solve their own problems); the Architect can have a difficult time keeping up. If the teams wait for the Architect's approval he again becomes an obstacle.

36 From: Grant grantj@review.com; Sent: Tuesday, September 28, 2004 at 3:20 PM Subject: Role of Application Architect on Scrum Teams

37 From: Steven Gordon sagordon@asu.edu; Sent: Tuesday, September 28, 2004 at 3:53 PM

38 From: "JASchiel" james.schiel@siemens.com; Sent: Wednesday, September 29, 2004 at 01:27 AM

For us the best way of producing recyclable components and consistent architecture is to have lots of open communication across the various teams.

We have the "designated architects" meet at least once a week to describe in general what the teams are working on. This gives us a chance to coordinate dependencies, recognize problems another team has already solved, offer suggestions, recognize common "design themes", make "core" architectural decisions, etc. It is also common for us to call in the other team Architects for a half-hour discussion or so whenever we're considering a significant architectural change. We have no controlling authority, but the best solutions turn into the "standards" because the solution is carried back to each team in the architects' heads.

Another thing that has helped us is to hold frequent "brown-bag" lunches where the entire development staff is invited and someone will "show and tell" about some bit of code. This gives the whole staff some idea of what else has been done on other projects that can be reused, copied, extended or otherwise leveraged.

Another suggestion from Ken Schwaber's book, if this works for you, is to create an "architecture" Scrum team made up of your very best developers. They would do a Sprint or two to establish the core shared pieces and standard architecture. Everyone on that architecture team will gain a large amount of tacit knowledge about the standard architecture. Then split up the members of that team into the other teams doing the regular day-to-day work. This should promote lots of inter-team communication when issues about the standard architecture come up.

This has been my experience. I hope the information is useful to you. 39

39 From: Mike Schenk mike_schenk@yahoo.com; Sent: Wednesday, September 29, 2004 at 04:48 AM

3.2 Self-Organizing Teams

Paul, Alejandro

Self-organizing and self-directing (self-managed) are different. A friend of mine worked for a company that went to self-directed work teams, eliminating project managers. Now the team got to do all the paperwork – HR, reporting, budgets, etc. No more time to actually develop software. To me, self-organizing teams are led (and managed) by a designated project manager, a technical lead, a ScrumMaster, etc. It's the style of leadership that is different – one I've called Leadership-Collaboration rather than Command-Control management. There is just too much evidence that good leadership and management makes a huge difference to success. These leaders are team leaders, not project administrators (although they do take some of this burden off the teams). The idea that you can put a random group of people together and that a "leader" will emerge just isn't borne out by experience. In fact, even Orsburn, "Self-Directed Work Teams (1990)," says it takes 2-3 years for self-directed teams to jell. Who has that long?

Self-organizing teams have a lot of freedom, are empowered to make many decisions, and manage their own work to a great extent. They also have a responsibility and accountability to produce, and they have to be self-disciplined. Self-organized doesn't mean dis-organized. It means a self-disciplined team and a Leadership-Collaboration style leader/manager working hand-in-hand.

Cheers,

Jim 40

40 From: Jim Highsmith jim@jimhighsmith.com; Sent: Friday, June 3, 2005 at 4:28 PM Subject: RE: Agile and Self Managed Work Teams

3.3 ScrumMaster: Elected From Team

Hi,

I'm a project manager at a videogame studio looking to use Scrum for my next big project. However I really want to avoid myself being a bottleneck by being the ScrumMaster, and think it would take the team a long time to get used to me NOT making the decisions in their meetings.

Now I've seen a couple of papers mention the option of allowing the Scrums to elect one of their members as ScrumMaster for each Sprint. While I completely embrace this on the team empowerment front, the project is of utmost importance to the company, and I'm wondering if I'd be introducing a whole new layer of risk by allowing any team member to be elected as SM and then not be able to cope with the role.

Does anyone else have any experience of using self-directed teams, and is there any advice that can be offered for ways to try and reduce the possible risk? I could of course nominate the SMs per Scrum myself, but then am I not breaking the ownership of the Scrum teams and risking their buy-in?

Thanks in advance for any advice on this,

Chris. 41

41 From: "another_chriss" another_chriss@yahoo.co.uk; Sent: Monday, April 25, 2005 at 12:07 AM Subject: Advice for Using Self-Directed Teams

3.4 ScrumMaster: Team Member or Coach

Tobias Mayer [tobyanon@yahoo.com] wrote:

> 1. Should the ScrumMaster be a member of the team, i.e. one of the developers or should he/she be separate from

the team, /only/ concerned with removing obstacles and liaising with the product owner?

In our experience, Scrum works best when the ScrumMaster is a full-time member of the team for very many

reasons:

* Commitment to solve team issues

* Focus in the task at hand

* Constant but not intrusive coaching

* Realization

* Provide constant communication with external teams: Systems, Business, Testing (if it exists, as in integration of many teams)

* Help with technical tasks, but typically:

Testing Documentation Integration and sometimes even Development

Remember the "ScrumMaster" is insurance for the team – insurance that things will get done, that the team will self- organize in a productive way that the right technical decisions have been made, etc. (In many cases the ScrumMaster and the Technical Lead can be the same person, but that in my opinion is "optional".)

When the ScrumMaster is not a full-time member of the team, she typically becomes distant to the team, a "Town Crier" or sorts that simply takes "news" and gives "news". (In this case the ScrumMaster becomes almost a traditional project manager

Tobias Mayer [tobyanon@yahoo.com] wrote:

> If the latter is true, is this always a full time role or can a ScrumMaster work on multiple projects at one time,

even if they are completely > unrelated projects?

In my opinion, working for many projects is *very dangerous*, all of the members of a Scrum team *must be focused* on the realization of the team's goals – FOCUS is one of the very basic premises of Scrum.

> 1. Should the ScrumMaster be a member of the team, i.e. one of the developers or should he/she be separate from

the team, /only/ concerned with removing obstacles and liaising with the product owner? If the latter is true, is this always a full time role or can a ScrumMaster work on multiple projects at one time, even if they are completely unrelated projects?

I recommend that the ScrumMaster not be part of the Development Team or Product Owner roles. It's possible an

individual could maintain the balance needed to be both a participant and a facilitator/coach, but this can be hard especially if it's one of your first Scrum projects. It's kind of like a player-coach in sports – some can pull it off, but not very many. There is a lot of facilitation and coaching needed for both the Product Owner as well as the Development Team.

You speak of the ScrumMaster as if he is a liaison between the Development Team and the Product Owner. This is not the case – these two roles work directly together. In fact, all three roles work closely together as three separate but interlocking roles.

I have a client now with a ScrumMaster successfully timesharing between two teams, and we think he could perhaps

handle a third. But there are some days where he is stretched pretty thin, and not immediately available if a team needs assistance. I think a ScrumMaster needs a certain level of expertise and experience before they can learn how

to be efficient enough to juggle several teams, but I think it's possible. The teams would also have to schedule their planning, review, and daily Scrum meetings in a way to allow the ScrumMaster to attend all of them. 42

It really depends on the personality of the ScrumMaster. I think it works best when the ScrumMaster has few or no

specific deliverables within a Sprint. If the ScrumMaster does, it is usually best that they not be "critical path" type

tasks. That is, I don't want the ScrumMaster taking the hardest or longest to complete tasks and then spending a lot of time on removing impediments (which comes first).

--Mike Cohn 43 Author of User Stories Applied for Agile Software Development

There is no reason that the ScrumMaster could or couldn't be a member of the team. If the ScrumMaster is a team member, then he needs to very carefully separate out the two functions and avoid being "in charge" of the team. 44

My 2 cents about a ScrumMaster taking on Teamwork:

I've acted as a developer and a SM on the same team on various occasions. It appeared as if it "worked," but over the last few years, after learning very much about the role of a SM, I have come to regret those occasions, as I have realized:

-That any time I spent doing any "Team" activities (acting as a Team member/developing/etc) was time NOT spent creating an environment of success for the team or doing other important SM activities (championing process to questioning stakeholders, other coaching, etc. etc.)

-That any work I did to "help" the team may have been a missed opportunity to learn and solve problems on its own (e.g., sure I was able to automate some builds and deployments more quickly or help knock out some stories, but wouldn't the team have benefited from the learning?)

-That any work I did may have detracted (though perhaps only slightly) from the Team's ability to accurately determine what it was capable of implementing in a particular Iteration

I now consciously try as hard as possible to not do any development or other "Team" work- even if I have a

competency in an area that the team doesn't- in this case I'll advise or recommend or guide team members if needed.

Unless the organization I am working with is completely evolved and embodies our principles throughout (haven't been there yet), and all is happy and at peace (dogs and cats playing together etc.), there is likely something that likely can be done by the SM to improve things that would be a better effort than signing up for Team tasks.

DeMarco's wonderful book "Slack" has another view of taking on work as a manager also that I believe is consistent.

George 45

42 From: Paul Hodgetts phodgetts@Agilelogic.com; Sent: Sunday, January 9, 2005 at 12:50 AM

43 From: Mike Cohn mike@mountaingoatsoftware.com

44 From: David A Barrett dave.barrett@lawpro.ca; Sent: Monday, January 10, 2005 11:46 AM

45 From: George Schlitz gjschlitz@comcast.net; Sent: Friday, July 14, 2006 at 9:11 PM

3.5 ScrumMaster: Communication

Bentley has the advantage of highly technical Product Owners, which facilitates communication between the Product Owner and the development team.

The goal of bringing 14 teams up to speed at the same time is ambitious. Of necessity, the teams will get the "What

to do". But with minimal training, the "Why" is missing. Also, the "What” might be close but not exactly on the

mark. ScrumMasters may find themselves answering a lot of questions and fighting a lot of little fires. If so,

consider an ad-hoc mini-retrospective that might get to issues you don't want to let go the entire Sprint.

When we take away technical decisions from the ScrumMasters they can think that they don't have enough to do (initially). If you have this situation, I think it is a mistake to let the ScrumMasters take on technical tasks as part of the project team. (I have more of a fear of this in Bentley's case because everyone is so technical to begin with.) They could use any free time to do some reading on Agile or plan to spend more time discussing obstacles and opportunities with other ScrumMasters.

With lots of rookie ScrumMasters, there will be some variability in their performance. Management should sit in on Scrums and do a lot of observation of teams and ScrumMasters to: 1) identify issues before they become problems, and; 2) demonstrate their support for the new process.

Bhupinder identified the benefit of sharing successes. A frequent gathering of ScrumMasters might be one forum to facilitate this.

A weekly Scrum of Scrums might be too infrequent.

start out with a daily Scrum of Scrums and decrease that if it proves to be overkill.

Better to over-communicate at first.

I recommend that you

Technical input into the product seems to be a hallmark of Bentley. You may need to emphasize that this will continue in the future and show the technical teams how they will be able to accomplish this. The technical teams don't want to feel disenfranchised. One team expressed this and therefore showed us the problem. But they are probably not the only people to feel this way so the problem has to be solved for a wider audience.

I will be interested to see how ScrumMasters deal with the communication issues with remote offices.

Bentley Systems, September, 2004

3.6 Business Analysts and Scrum

Being a Business Analyst, I have been hunting around the web and in bookstores as to how a Business Analyst team would fit into an IT organization practicing Scrum.

We have an IT organization that consists of teams of Business Analysts, Developers, QA folks, Project Managers and Business users.

I understand that Scrum recommends that the same person wear multiple hats, but that is really not possible here.

I haven't heard this specific recommendation in relation to Scrum. At a very, very high level: Scrum “wraps” any

development process with several Agile project planning/tracking/management practices (the primary rule is that the

team cannot be “interrupted” during the Sprint). The details of the development process are essentially a “black box” as far as Scrum is concerned (which would include the specific allocation of roles/people on the team).

In the past I have worked through an organization where we implemented XP successfully and integrated BA and QA by putting BA 1 Iteration ahead of dev

I have also seen this strategy work successfully in certain situations where:

a) The requirements were uncertain, because the business process were being re-engineered in the same time

frame that the system was being developed. In these cases, the 'analyst' worked with the business experts to define

the business processes a few steps ahead of the system development.

b) The requirements were complex, the development team was not familiar with the domain, and/or the customer

could not explain the requirements clearly, succinctly, etc. In these cases, the 'analyst' kept one Sprint ahead of the developers so that they could pre-digest the upcoming requirements into a clear, logical form so that the developers didn't have to come to a standstill in order to understand the new requirements. The developers would use these 'pre-digested' requirements as a starting point, and would continue to have face-to-face conversations with the customer and/or the analyst in the course of the Sprint to get the finer grained details worked out.

and QA one Iteration behind Dev

This makes sense if the QA people are doing incremental hands-on testing (e.g. exploratory testing, usability testing, integration testing, performance/stress testing, etc) against the functionality integrated and released at the end of the Iteration. It's important to remember that the test-first development practice of XP puts a lot of the testing before/during development that is 'traditionally' left for after development.

But

within Scrum everyone stays in the same Sprint. The BA, Dev and QA folks.

Once again, I haven't heard this specific recommendation in relation to Scrum. Scrum's main restriction is that the scope of a Sprint is fixed, and should not change part way through (as a way to reduce churn and keep the team focused). That doesn't necessarily mean that everyone has to work on the same thing during the Sprint. So I believe it is entirely reasonable if the situation requires an "analyst" to pre-digest upcoming work to make the next Sprint proceed more efficiently.

So how could all three groups work within the same PB simultaneously without someone having a good amount of downtime? Since you really cannot develop before analysis and design is complete, and since you cannot QA before dev is complete.

The XP approach of stories/acceptance tests/face-face conversations all occurring in the course of an Iteration works well in an ideal situation where:

a) The developers already have a strong understanding of the domain, or the requirements are simple enough that they could understand them quickly b) And the customer can articulate their requirements effectively

If your situation is not ideal, then adding an "analyst", and/or pipelining the analysis and development work may be

an appropriate solution.

Jennitta 46

How is the knowledge acquired/generated by the team that analyzed requirements in Sprint A to be communicated

to

the team that implements those requirements in Sprint B?

If

that knowledge is to be communication is via heavy documentation then the approach is not in the spirit of XP or

Scrum, and much of the agility one gains by doing XP or Scrum will be lost. Much of the knowledge gained by team A will have to be relearned/reinvented by team B, and given the different skill sets, team A is likely to want to

disown what team B produces.

The idea behind these methodologies is for one group of people to learn, implement, and get feedback in a short time frame on a few requirements. Spreading the learning for the same requirements across multiple groups of people destroys what makes the methodologies Agile and effective.

If the requirements are too complex for a group of developers to figure out and implement in one Iteration, then

reduce the number of requirements per Iteration and/or add a few BAs and SMEs to the team. A separate team of

BAs and SMEs will only muddle things.

Steven Gordon 47 http://sf.asu.edu/

A customer story is a very short paragraph (not even as detailed as an "essential use case") identifying a requirement

or feature. The customer prioritizes these short stories. The team only digs into the details of a story when its priority causes it to be scheduled for the current Sprint/Iteration. The people who will be implementing that story have an extended discussion with the customer at that time to come to an understanding of its details. (Discussing the details before implementation time is pointless, because the details are likely to change in light of the customer's experience with what as been implemented so far, as well as all the factors that cause changes in requirements and how they are understood).

There is absolutely no problem with BAs and/or SMEs participating in that conversation with the customer. There

is a big problem with the BAs and/or SMEs having that conversation INSTEAD of the developers, and then

providing a written specification of some sort to the developers based on that conversation.

The in-between case of having the BA have the conversation with the developer instead of the customer is not optimal, but can work when there is no better alternative. But, that conversation is still a 2-way dialogue about what the requirement really means, not the BA dictating to the developers what to implement. It should not take a full Iteration of work by a team of BAs to support being able to have such a conversation with the developers. 48

Scrum is pretty adamant that you start the Sprint "with nothing" and you end it with a potentially shippable product increment. This means you start with a tiny bit of understanding about what a product backlog item means and you end with shippable software.

Regardless of your environment that should be considered the ideal. But, we can't always achieve the ideal. I've occasionally had teams that need to do some analysis "a Sprint ahead" of the team. This is OK as long as you remind yourself often that:

46 From: Jennitta Andrea jennitta_andrea@transcanada.com; Sent: Tuesday, November 9, 2004 at 9:46 AM Subject: Re: Scrum and Business Analysts

47 From: Steven Gordon sagordon@asu.edu; Sent: Tuesday, November 9, 2004 at 1:28 PM

48 From: Steven Gordon sagordon@asu.edu; Sent: Tuesday, November 9, 2004 at 2:24 PM

a) You are deviating from the ideal, you've selected to do something that works but it would be better if you could get closer to the ideal b) You try to minimize the amount you do ahead and how far ahead you do it.

(All the same with "behind" as appropriate)

Whatever the analysts feel the need to produce upfront should be kept as lightweight as possible. We want to view their work as inventory and it could be wasted inventory if the feature isn't prioritized into the Sprint.

I can't think of any real circumstance in which I would have significant testing occurring AFTER a Sprint. I've had some teams where we do things like usability testing (bringing users into a usability lab for observation) every 3rd Sprint or so but it's still done in a Sprint. It's just not something needed every Sprint though. I'd push back hard on testers wanting to work behind. Usually when they are doing that they are trying to optimize the test process at the expense of the overall process. Imagine a sandwich store with 13 order-takers and 1 sandwich maker. Order-taking will be optimized – “Never a wait to place your order" will be in the ads. But imagine the wait for the sandwich to be made. You want a process that is optimized across the range of activities. This means that some processes will look inefficient. It's very "inefficient" (when measured locally) to write tests first but it can help optimize the entire process.

--Mike Cohn 49 Author of User Stories Applied for Agile Software Development

Much of the information can often be conveyed during a Sprint planning meeting. If there's more to be conveyed (there almost always will be on some stories) then the relevant programmers, testers, etc. all talk to the customer. If there's that much talking going on (e.g., this is a complicated requirement) the customer hopefully starts to write down an example (see www.exampler.com) or a test demonstrating how the system should behave. The best becomes the most powerful way of capturing the communication for later use.

--Mike Cohn 50

49 From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Tuesday, November 9, 2004 at 8:19 PM

50 From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Tuesday, November 9, 2004 at 8:24 PM

3.7 Is the Product Owner a Pig or a Chicken?

> 2. Is the Product Owner a Pig or a Chicken?

In my opinion, it is neither. In Scrum, the Product Owner is the person that makes the final decisions about the content of a Sprint, and it is typically a decision-maker that is not available at all times – as a good pig should be. And it is neither a chicken – a person that is not committed to the goals of the team.

There is another role, the Customer, that needs to be introduced, imo. The Customer, is or are representatives of the business that typically work for or with the Product Owner. These representatives are pigs i.e. they are committed to the project on a daily basis to clarify requirements, and are capable of giving feedback on a day-to-day basis on the functionality of the daily builds in terms of testing and tactical decision-making. 51

Tobias Mayer [tobyanon@yahoo.com] wrote:

>It seems to me that the product owner is certainly committed, but I do not see a place for the product owner to speak in the daily Scrums, it seems that he/she should just listen.

The Product Owner is brought in typically when major decisions are made regarding a Sprint. For example, to answer questions about compromises such as: "Can we live without the Complaints Workflow for the next release?"

We call these meetings "Reprioritization Meetings", and typically there are one or two of these meetings at most per Sprint.

For most other tactical decisions, other representatives of the Customer are usually sufficient.

In Scrum, it is *the worst-case scenario* to not interact with the Customer (either the business representatives or the Product Owner) only through the Sprint Planning Meeting and the Sprint Review Meeting. 52

I consider the Product Owner to "have skin in the game" for a Sprint, and thus be a "pig" (I dislike that term :-P). They will have different tasks during a Sprint, mostly focused on building and accepting backlog items, but they must complete work for Sprints to move forward. They will report on their tasks just like the members of the Development Team do. 53

The ideal product owner is definitely a pig. The product owner should be saying things like, "Yesterday I checked

with marketing on

of tasks associated with writing (specifying at least) acceptance tests for the work of the Sprint. Product Owners should be close to the team if not in their same space – availability is more key than location. The Product Owner and ScrumMaster meet whenever they need to. I typically tell them that they should be in sync before each planning

and it's what we thought so you can go ahead and.” The product owner should also have lots

meeting and should also have a good feel for what will likely be stated as high priority by other stakeholders/customers. Neither should ever surprise the other.

--Mike Cohn 54 Author of User Stories Applied for Agile Software Development

51 From: Tobias Mayer tobyanon@yahoo.com Subject: Pigs vs. Chickens

52 From: Mike Beedle beedlem@e-architects.com; Sent: Sunday, January 9, 2005 at 1:01 AM

53 From: Paul Hodgetts phodgetts@Agilelogic.com

54 From: Mike Cohn mike@mountaingoatsoftware.com

The Product Owner is a chicken. Sorry Hubert, but I have to disagree with you here. Yes, the Product Owner is committed to the outcome of the work, but he's not a part of the work. Within the Scrum structure, the Product Owner has a single role: To maintain the Product Backlog and to prioritize the PB items. Remember that the team is jointly responsible for completing the Sprint Backlog. The Sprint Backlog isn't carved up into a bunch of individual commitments for each team member, so every team member is expected to become involved in any aspect of the Sprint backlog that requires attention when necessary. Your most senior programmer may spend three days stuffing envelopes if that is what is needed, and if the team decides that is the best use of his time.

I divide the Scrum world into two kinds of people: Team Members and Resources. A team member is someone

described above, who is fully committed to all of the objectives in the Sprint backlog and who will work in any capacity required (providing that he has the skills) by the team to achieve those objectives. A resource is someone who is available to a specific task, or whose skills are highly specific or whose available time for the project is extremely limited. The team decides how best to use that resource, and the resource usually wouldn't attend a Scrum as a pig. What usually happens here is that a team member becomes responsible for watching over the resource, and reporting that person's progress and issues to the team in the daily Scrum. If you have someone who is part-time on the project, the decision over whether or not they are a team member depends on how much time you have them for. If you have enough of their time for them to attend the Sprint Planning meeting and all of the Daily Scrums, then they're probably going to work best as a team member. If you only have them for 1 day a week, then they'd probably best utilized as a resource.

Dave Barrett 55

I disagree. Pigs are those who have commitments, or whose bacon is on the line, during a Sprint. That applies to

the Product Owner who is responsible for specifying (and writing if possible) tests that indicate if each backlog item meets her expectations. While the team can self-organize and influence the amount of effort needed by the product

owner to do this, the product owner must do some of it as no one can express the product owner's acceptance criteria except the product owner.

--Mike Cohn 56

I believe having a Product Owner as a pig is ideal.

ScrumMaster takes some of the burden of Product Owner. This can happen when the Product Owner cannot be involved as much as we would like and delegates much of the role to others. At this point, the Product Owner

becomes a chicken. This causes for a lot more work from the team, which is why it is better when the Product Owner is a pig.

If this is not an ideal situation because of circumstance, the

As a pig, the best of all is when the Product Owner is part of the Daily Scrum!

Brent 57

The "chickens and pigs rule", is about who talks at the Daily Scrum project, or who has "skin in the game".

not who is committed to success of the

Chickens are only involved in the process – they provide the eggs in the "eggs and bacon" breakfast. For example, there could be a system administrator there to know what new users to add, or a configuration management guy, or a DBA, or a senior VP (wanting to know where things are), etc.

55 From: Dave Barrett, Lawyers' Professional Indemnity Company

56 From: Mike Cohn mike@mountaingoatsoftware.com

57 From: Brent Barton bbarton@solutionsiq.com; Sent: Monday, January 10, 2005 at 9:05 AM

Pigs are committed to deliver the (software) through and typically have something to show for in the "Daily Build" (even if they are documents), and therefore are typically developers (in the larger sense more than programming) – they provide the bacon in the "eggs and bacon" breakfast.

This rule goes into effect so that people only "involved" with the project take over the Daily Scrums. For example, the CIO, the VPs, or the Directors don't take over the meeting and start thanking people, telling them how great they are, or start threatening with contract fines, or panicking, etc.

This is why the "Product Owner" does not typically talk at the Daily Scrum…; therefore, most Product Owners are chickens at the Daily Scrums. And yes of course he is committed to the project and he has "skin in the game" – but that's not how we use the "chickens and pigs rule".

On the other hand, there might be business people working on a day-to-day basis as part of the team (or with the

but they are typically not

the Product Owners (although it is possible they might be involved at that level), they are simply "On-Site

Customer". 58

team), that are responsible for delivering the solution – those people are of course pigs

Well, you're the expert. But now I'm confused. AFAIK "On-Site Customer" isn't a Scrum term. I thought that the Product Owner was the one who defines the Sprint Goal, in its general form and its detailed form. Yet they aren't present with the team?

Ron Jeffries 59

Ron,

You are right, in Scrum we don't have an "On-Site Customer", we simply have a "Customer" ;-)

The Product Owner helps define the Sprint Goal and content, but of course the team determines how much can be done and how to deliver it.

It is ideal that the Product Owner is available all the time – during the Daily Scrums and during the day, but that is typically not possible, nor is it required in Scrum; instead, most of the time we have a committed Customer representative that helps the team, full-time or part-time, in testing the deliverables and understanding the requirements.

The absolute "worst case scenario" is when neither the Product Owner nor a Customer representative are available during the Sprint. Then all the interaction with them happens at the Sprint Planning and Sprint Review meetings.

- Mike 60

Given that the Product Owner is establishing acceptance criteria for the product backlog items, the product owner is undoubtedly a pig (that is, "is committed") and should most definitely talk in the meeting. If that were not the case it would lead to a pathology such as having the product owner telling a tester prior to the meeting "speak up if these acceptance criteria are not being met or if others are" and then having a tester become the mouthpiece of the product owner. If I were a Product Owner and the team told me "you can't talk during our meetings" I would find a new team-that day. Agile (and Scrum) teams should value communication-in all its forms and in all ways that help. Telling the CEO he can't come interrupt a meeting with his questions is a good idea; telling the product owner the same is wrong.

58 From: Mike Beedle beedlem@e-architects.com; Sent: Monday, January 10, 2005 at 1:22:30 PM

59 From: Ron Jeffries ronjeffries@Xprogramming.com

60 From: Mike Beedle beedlem@e-architects.com

I might have been able to believe the "product owner is a chicken" argument in the old days before Scrum teams started seeing the value of acceptance-test-driven development. However, many Scrum teams have been shifting in that direction and having Product Owners come into a Sprint with known, high-level conditions of satisfaction (COS) identified for each or many product backlog items selected for the Sprint. During the Sprint the product owner (in collaboration with others, esp. testers) refines and automates those high-level COS into more specific ones. These become the actual tests. This means the Product Owner has deliverables. The Product Owner has always been committed. The Product Owner speaks in the Daily Scrum. That simple change of mindset eliminates this entire class of problems.

--Mike 61

Yes, fully agree with Mike AS LONG AS the product owner has committed with the team to what will be demonstrated at the Sprint Review. Without the commitment, the Product Owner remains a highly interested but not committed chicken,

Ken 62

61 From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Wednesday, April 6, 2005 at 9:09 AM

62 From: Ken Schwaber ken.schwaber@verizon.net; Sent: Wednesday, April 6, 2005 at 9:50:12 AM

3.8 Interaction During Sprint

I understand that the customer should not talk in the stand-up meetings, but as a customer I sometimes find this is not practical.

When developers are starting to talk about an issue and are off track I feel that I should be able to speak up and correct them. Or if they are discussing a problem and I have a potential solution by changing the requirement slightly, I also think I should speak up or in some cases I have some information about how the feature is going to be used which will help the issue.

If as a customer I cannot speak in a stand-up meeting and must wait until the end of an Iteration before I can interact with the team, that seems wrong and not very Agile.

What is the best way to deal with this? Sometimes I keep quiet in the meeting and at the end seek out the people involved in a particular task so I can discuss the issue further. Is this how it should be handled, or should I just speak during the stand-up meeting but keep any chatter short and relevant to the current topics being discussed?

Regards,

Kristan 63

As ScrumMaster, I pay close attention to the chickens in our meetings, as well as to the pigs. If a chicken, esp. the PO makes eye contact with me or raises his/her hand, I know that there is an issue to talk about after all the pigs share (and we always get thru under 15 minutes).

I'll point out that the chicken has some valuable information as soon as the last update is complete, or, if the team is really tightly integrated and comfortable, the chicken could very well "cluck" quickly and say that they have some pertinent info to share at the end. We also have an alias, so if information needs to be shared that would benefit the team, the chicken can mail the team the info if appropriate to be shared in that way or call for a separate meeting.

I think it is important to allow the momentum to continue and not interrupt in the standup, and also important that

the team is not operating under incorrect information. I think your solution is perfect, seeking out the right people to discuss after, and that may drive Iteration as long as it is shared in the next meeting or communicated widely. 64

I would have thought the customer should be constantly interacting with team members throughout the Sprint, what

I am not sure of is how. What is the protocol, if the standup meeting is not a good time, then when is?

As I said, during a Sprint the team is taboo. You do not even go near it. The Planning Meeting and the Sprint Review are the two days where the Product Owner should interact heavily with the team. The rest of the time you will leave the team, alone unless the team approaches the Product Owner. This will happen most likely when:

a) There is too much work in the Sprint left and they cannot deliver, asking the Product Owner to drop some items from the Sprint backlog. b) There is too much time left, asking the Product Owner to pull some more items from the backlog to the Sprint backlog. 65

I'd add c) There is not enough information about a backlog item on in what is really wanted, and the team wants elaboration.

63 From: Kristan Vingrys kvingrys@agentissoftware.com Subject: Pigs vs. Chickens

64 From: Traci Boyle traci@yahoo-inc.com

65 From: David H.

Product Owner is the person with the most information about the items on the backlog. It is usually not possible and not sensible to document/communicate all the functionality of the backlog items in great detail during the Sprint Planning Meeting from the Product Owner to the Team.

Therefore most common way of interaction in our organization between the Product Owner and the team is when the Team/Team Members ask for more information about a certain feature that is being implemented during the Sprint. I think it is a vital part of Agile methodologies (including Scrum). I agree with you that the initiator should be the Team, not the Product Owner. The Team knows (at least they should!) when they do not have enough information about the specific details of a backlog item.

Regards,

Jukka 66

66 From: Jukka Lindström jslindst@reaktor-i.com

3.9 Retrospectives: Who Should Facilitate

I've seen teams taught that the ScrumMaster should facilitate the team retrospective. I don't find this as effective as having a neutral facilitator (someone outside of the team), at least for the first few Sprints and would like to get your thoughts on this.

My thinking is that you should have someone who is outside of the team for the following reasons:

1. The facilitator won't bias the opinions given out by the group as much if they are outside of the team.

2. The ScrumMaster has valuable feedback that may be lost if they are not allowed time to give their opinions during

the Retrospective.

3. The team may have problems with the ScrumMaster themselves and not feel free to give feedback if the SM is

running the retrospective.

I've been getting someone experienced in running retrospectives lead the first one for the team, then training all the ScrumMasters on multiple teams to help each other. They buddy up and go to each other's retrospectives. This had the double advantage of keeping the facilitator neutral, allowing SM's to learn from other's teams retrospectives, and providing support for the SM group which is very valuable when you are scaling through a large organization.

~Gabrielle Benefield 67

I agree on the 'improvements' focus on a retrospective, and I'm glad you bought it up Diana. It's all too easy to have teams vent (some people just like this as their general modus operandi as well ;).

Things I've seen work to ensure the items are worked on are:

1. Putting the improvement suggestions onto the backlog for the next Sprint.

2. Putting up the improvement suggestions on a large piece of paper and posting these in a team room so they are

visible.

3. One I just heard about today, is the team went through the last set of improvements and added happy faces for the

things they resolved and sad faces for the things they still need to work on. They then posted this back on the wall.

Are there any other tricks for making progress on the items out there?

Gabby 68

67 From: "gabby_robertson" gabby_robertson@yahoo.com; Sent: Monday, May 16, 2005 at 5:26 PM Subject: Who should Facilitate the Retrospective?

68 From: "gabby_robertson" gabby_robertson@yahoo.com; Sent: Monday, May 16, 2005 at 8:25 PM

3.10 Sprint Review: Stakeholder’s Role

One problem I see in organizations trying to become Agile is folks getting together for Iteration demos, and the stakeholders not really quite sure what they are supposed to do. They aren't used to seeing subsets of features and don't quite know how to, or that they are supposed to, give feedback.

Does anyone have any facilitation tricks (lists of questions, etc.) that they use at demos to get folks giving the proper feedback?

Ken DeLong 69

Ken, we've started providing short surveys for our customers that ask questions like:

* How closely did our demonstration match what you had hoped to see?

* How easy has the development team been to work with?

* Are there requirements (new ones or ones we missed) that you would like to discuss?

When handed out at the beginning of the review, the stakeholders tend to read them, which then causes them to think about how to answer the questions during the course of the demo.

You have to be careful with this approach (too many questions takes attention away from the demo), but it can be successful in both focusing the stakeholders and getting feedback that can be used to evaluate the success of the Sprint and, across Sprints, the team.

Of course, it also helps to communicate what you want from the stakeholders at the beginning of the meeting and (if possible) when the invitation to the review is sent/spoken to the stakeholders. 70

If you begin the Sprint with a specific set of requirements (this is an advantage of TDD) then you show and tell at the end. Here is what you said you wanted; here is what it does. Then you show them how to do it and let them loose. If they can't break it, then have them sign off on it. (I mean that literally.)

Michael F. Dwyer 71

Hi folks,

Mike Dwyer mike.dwyer1@comcast.net wrote:

> If you begin the Sprint with a specific set of requirements (this is an advantage of TDD) then you show and tell at the end. Here is what you said you wanted, here is what it does. Then you show them how to do it and let them loose. If they can't break it, then have them sign off on it. (I mean that literally.)

This is how we do it: We create a list of assertions for each backlog item. The assertions may determine a specific level of availability or just a feature, which has to be implemented. After the Sprint review – where we discuss the results and get a general overview – our teams take their product owner and check the assertions one by one.

Each assertion has to be proven by a range of successful tests. These may be load tests if there was an availability question. We use acceptance tests for actual functionality, too. The product owner signs the assertion checklist and we're through it.

69 From: Ken DeLong ken.delong@valtech.com; Sent: Tuesday, February 8, 2005 at 5:55 PM Subject: Facilitating Iteration Demos

70 From: Schiel James – SHS Malvern james.schiel@siemens.com; Sent: Tuesday, February 8, 2005 at 7:28 PM

71 From: Mike Dwyer mike.dwyer1@comcast.net; Sent: Wednesday, February 9, 2005 at 12:28 AM

Of course, as we are gathering more and more assertions, the product owner won't look on every detail. We accomplish this through frameworks that put all tests and other checks together and display them on a common dashboard. Check out CruiseControl for that kind of stuff.

HTH

Andreas Schliep 72 Software Factory WEB.DE AG

72 From: Andreas Schliep andreas.schliep@web.de; Sent: Wednesday, February 9, 2005 at 7:51 AM

3.11 Team Members

I've been involved in a fair number of passionate debates about who is and isn't part of The Team, who's a pig and who's a chicken, etc. My observation is these debates have a rapidly diminishing rate of return.

I've noticed that a healthy Scrum organization (not just team) forms multiple affinity groups around the work products being produced, who's working on what, who needs to know about what, who needs to collaborate with whom, etc.

As Dave points out, Scrum by the book emphasizes the affinity group that is focused on the potentially shippable increment of product that is emitted from the current Sprint, and calls that The Team. This group tends to be focusing on the most concrete construction type of tasks, with a high level of immediacy to the completion of them, and tends to have quite a bit of collaboration going on among themselves.

If we look at, say, a Business Systems Analyst that is working on helping to define and write some backlog items for the next Sprint, they too are performing tasks necessary to complete product, and they too are committed to the product. The tasks are a bit more abstract, of the visioning variety, and may not be targeted at product delivered in this Sprint, so they don't have the same immediacy. They may collaborate very closely with the Product Owner and perhaps QA if defining acceptance criteria, but not as closely with the folks working on the construction tasks.

However, there is still some affinity between the two groups. As a programmer working on construction tasks for this Sprint, I still have common interest in what's going on with the BSA and the requirements work, both as a heads up to my future work and for the sake of knowing the entire project's status.

The bulk of the synchronization in the daily Scrum is for the core affinity group. But in the healthy teams I've coached, they develop some sort of mechanism for synchronizing with the weaker affinity groups as well. Some even include them in the daily Scrum activities, perhaps not every day.

So I don't view being part of The Team or not as so black and white, nor constant. I tend to err on the side of inclusion, with the intent of encouraging collaboration and visibility. I've noticed that most teams are pretty good at self-adjusting the involvement level of people to match their affinity levels. Although some rules about who's part of The Team may be useful to a new team so they can instead focus on more pressing issues, it seems to me the question becomes more and more irrelevant as a team matures.

Paul 73 CEO, Coach, Trainer, Consultant: Agile Logic – www.Agilelogic.com

73 From: Paul Hodgetts phodgetts@Agilelogic.com; Sent: Friday, March 18, 2005 at 6:11 PM

3.12 Performance Reviews

Tobias,

When I've have one or more team members whose performance is also measured by someone external to the team, I've sought out these external managers with the aim to create a "win/win" for both the manager and the person being evaluated. What are the objectives of the external manager with respect to the person being evaluated and how do these objectives fit within the environment we are trying to cultivate? One of the ScrumMaster's jobs is to create a "safe" environment for the team, where the team members can try out new things without fear that they will be adversely impacted when they are evaluated by their management. I've found that getting these managers to express their support for what the team is doing in front of the team has tremendous therapeutic effect.

If you can't create the win/win, the individual, the team, and the project will fail, and it's probably best to move the person off the team. Bottom line – find a way to make it work for everyone.

To your question about manipulation, any external manipulation should surface in the daily Scrum. The ScrumMaster is responsible for exposing and confronting these external influences real-time. Seek agreement with these external managers upfront and continually assess what is really happening. Make sure everyone "walks the talk."

Jim 74

At the large financial institution where I've been working lately, there was a different problem with the reporting hierarchy: no one on the team reported into the team. In fact, the team was composed of individuals who reported into a "center of excellence". This had the effect that people were strong specialists and had no real motivation to have the project succeed.

I recently had the bounty of working with Mary Poppendieck for several days on a related project at the same large financial institution. She pointed out that there is an underlying problem both with what I encountered, and I believe, with what you are describing: sub-optimal measurements.

It is true that both reporting structures also are problematic, but my guess is that the worst of the effects of these poor reporting structures can be mitigated by introducing Lean-based performance measurements. If people's performance is measured based on their sphere of influence rather than their sphere of control, then people will work together.

Mary describes three important measurements:

1. Business Value delivered by the project: The team is measured on this basis rather than individuals on some other

metrics.

2. Process Cycle Time: The time from the start of a project to the moment when it is delivered to and accepted by

the customer.

3. Process Cycle Efficiency: How much time is value-added time vs. the overall time spent on a project.

74 From: Jim York jim.york@ccpace.com Subject: Reporting Hierarchies

These three measurements can all be improved by an empowered team (regardless of its internal reporting structure). If the performance of individuals in the team is measured by these team-level metrics, then individuals will work to maximize them. And True Goodness will result.

:-)

Mishkin. 75

Great points Mishkin. Team-based performance evaluation based on the metrics Mary proposes will go far towards "True Goodness," as you say. Individual performance rewards are almost always sub-optimal. Finding a way to move the individual's performance feedback towards team-based metric, say 60/40 split, team versus individual, is a good place to start.

Jim 76

75 From: Mishkin Berteig mishkin-Agile@berteig.com; Sent: Thursday, January 13, 2005 at 11:41 AM

76 From: Jim York jim.york@ccpace.com

Section Four:

Development Practices

4.1 Best Practices

What's confused me on this thread is what the expectations of a best practice are. Any method of any kind will work better in some situations that others, and work better with some teams than others.

It's not written anywhere that a best practice will work even 50% of the time, but it's implied that a best practice has been used successfully more often than not, and has a clear and common problem it solves or avoids. Using a scalpel to make incisions is a best practice for surgeons, but there are some situations (e.g. a headache) where using

a

scalpel would be ill advised: part of defining a best practice is defining the situations it applies well in, and which

it

doesn't.

While I agree that some practices are more universal than others, the more universal they are, the more basic the problem they're trying to solve. The more complex the problem, the fuzzier the toolkit of solutions will probably be.

And since projects are complex, and teams are complex, it's inevitable that some best practices conflict with each other. This isn't evil – it just implies that project managers or team leaders have much work to do beyond reading about and following lists of best practices: they have to be using judgment and awareness to decide which things to apply, and when, and what actions to take when their are conflicting intelligent opinions about the best course of action.

This is part of my problem with tight adherence to any methodology: it applies a singular context to the project and team that may or may not be useful. It seems best to start the other way, with the needs of the project, and the background of the team, and choose/blend a methodology based on what best serves both the project and the team. (Advice I guess I'd offer as a methodological best practice :) 77

In agreement, though the best practices I've seen as referred to as best practices did not work a majority of the time.

The most memorable one is having all the progress diagrams and artifacts pinned up in one room – nicknamed the war-room. Rather than being a nerve center for the project, and promoting a clear communication channel to management, the room became a "torture chamber", where members of the team were defaced by executives and senior management could hear the yelling even with the door closed.

Another one that makes me shudder was how feedback sessions were done at this one place. They all boiled down to people making personal attacks back and forth.

Too many people cling to "best practices" without understanding why they are best practices. It's the understanding, not the practice that makes the biggest difference in the practice's success rate.

“Best practices” reminds me of some haunting phrases

"We did it like that at another site" "In his book, he said we should do this" "We should do it this way because I have more years in the industry than you do" "I know what's best. Trust me." "I've written several books on the topic." 78

77 From: Scott Berkun scottberkun2002@yahoo.com; Sent: Wednesday, November 10, 2004 at 3:54 PM Subject: Re: Observation for Best Practices

78 From: Chris Pehura chris@pehura.com; Sent: Wednesday, November 10, 2004 at 5:21 PM

4.2 Implementing Agile on Your Own

Hi All,

As a lurker on this list for about the last 10 months, I would like to make some observations on the - ahem - robust discussion that has been going on the nature of Agile development, standards, etc.

We have implemented a development approach here that started by applying the material called "Scrum" and the material called "XP". Neither myself, nor anyone else here is a certified ScrumMaster, XP Wizard or has any other qualification in "Agile". We are all however, experienced software developers.

What we did was look at the development organization we had that was not delivering. We read some of the publicly available material on Agile methods and read Ken's Scrum book and a few of Kent et al's XP books and the Agile ecosystems book (spending in total probably under $100 US).

Then we tried stuff, we listened to each other's suggestions, we implemented some, and we threw some away and tried again. We've been doing this for about a year now, and continue to do it.

During this time, we found we delivered software. On time. Within budget. To customer's great satisfaction. We also found that the team got happier, and had better lives.

I feel no compulsion at all to determine whether we are "doing" Scrum or XP or Crystal or whatever: we are doing something that works, which we came to through /guidance/ provided by the thinkers who call themselves the "Agile movement".

Is this perhaps the problem here? Is the very essence of Agile development that good people get together, communicate and cooperate to do what works for them in their situation? If this is the case, is it futile to try and encode it beyond the point where we are now?

Cheers,

Leo Zancani

Zynap Ltd.

4.3 Daily Builds

During our first Scrum project (currently Sprint 7) we got nightly builds working early in Sprint 1 but didn't really see the point of anything more frequent. It didn't take long, however, to realize that more frequent builds did have advantages so we moved to continuous integration (up to 30 or more builds per day). It certainly improved our confidence in the code base and improved our efforts from 1 or 2 failed builds per day to it being a very rare occurrence.

The point is we realized the benefits ourselves and so implemented the practice.

Ian 79

Do you feel there is a point where the ability to deliver quickly is overcome by the number of builds? Doing upwards of 30 builds a day seems like a lot of time being spent during an 8-hour day (like a build every fifteen minutes). Then if you take into account the cycle time for a build, it would seem to leave you with very little time to actually improve/extend the software. 80

The build is, of course, automatic. A service listens for check-ins to the source control and, after a short delay to allow for multiple files, kicks off the build, unit tests, etc. If the build fails, an email is sent to the whole team to finger the culprit!

As an aside, these builds are not available to the tester on the team but the build also generates installation files so that when the tester requests a latest build, we can simply pick the latest install file and it takes only a minute or two to deploy to the test environment. This means that integration and test builds barely appear on our radar as impacting productivity.

Ian 81

Congratulations, this is continuous integration nirvana!

As a contrast, I started coaching a Scrum adoption recently where the team has a two and a half day build and test

cycle (really).

When they check their changes in, their changes go to a unique branch in version control for that

developer.

When the team wants a build, a wholly separate CM group takes all the individual developer's branches and merges them into the baseline, one by one, with much pain and many restarts.

The build itself is composed of a series of manually triggered scripts, with manual file copies and tweaks in between. The build often fails to configure together the correct set of modules, so it often fails tests due to out of date modules. Once they actually get a build, the automated tests take about seven hours to run, and the automated tests cover less than 50% of the system functionality.

79 From: Shimmings, Ian ian.shimmings@conchango.com; Sent: Monday, September 13, 2004 at 3:25 PM Subject: RE: Re: Intermediate Result Presentation

80 From: Mike Dwyer mike.dwyer1@comcast.net

81 From: Shimmings, Ian ian.shimmings@conchango.com

Which team will get better feedback as to the true state of their system? ;-)

I'm curious, what realizations did the team have that made them move towards faster build cycles? Were there specific incidents, or what motivated them to take it to that level?

Regards, Paul 82 CEO, Principal Consultant: Agile Logic – http://www.Agilelogic.com/

82 Paul Hodgetts phodgetts@Agilelogic.com

4.4 Daily Scrum Meeting

For example, is a "Daily Scrum", a "status meeting", a meeting "to identify issues", a "testing results" meeting, a "configuration management" meeting, an integration meeting, a sharing knowledge meeting, a meeting to hunt to spontaneous collaborations, a "team building" exercise, or a place to share stories?

Well, it is all of the above. And the same is true for many other Scrum practices – they are multi-purposed. 83

83 From: Mike Beedle beedlem@e-architects.com

4.5 Scrum of Scrums

Hi everyone; I just signed up with the group yesterday. Scrums.

I have a question / looking for advice on the Scrum of

I currently have 4 Scrum teams all working of the same code base / project, each team consisting of 6 people. I have two daily stands up sessions, one at 9:30-9:45 for two of the teams (in separate rooms / areas), and one at 9:45- 10:00am for the other two teams (using the two same separate rooms / areas that the first two teams use). Meeting room space is in short supply, which is partly the reason for doing the above. Then at 10:05-10:20am I have a Scrum of Scrums whereby the ScrumMasters for each of the four teams attend, as does one 'pig' representative from each of the teams. At the Scrum of Scrums we ask each 'pig' representative to answer the following questions: What did my team do since the last Scrum of Scrums? What is my team planning on doing before the next Scrum of Scrums? What blocking issues does their team have? I also find us ScrumMaster discussing the blocking issues although we are pretty good at keeping the meeting to 15 minutes.

So my questions are:

1. Is this the recommended approach when using multiple Scrum teams?

2. Do other people hold the Scrum of Scrums straight after the daily Scrums or do people have better suggestions on

timing?

3. I feel for some of the team members instead of just being involved in a 15 minute daily stand up, they are

involved in 30-45 minutes of stand ups, which feels too much. Am I basically on the right track with my approach or can I refine it? 84

Responses. Much agreement and added suggestions:

1) Scrum of Scrums (SoS) meet daily for first and last week of every Sprint but not that often in the middle. 2) After 8 or 10 SoS’s, the only question asked and answered was “impediments”

-- Editor

84 From: "dtrowern" dtrowern@aol.com Subject: Scrum of Scrums

4.6 Sprint Goal

I use Scrum with user stories. I use the Sprint goal to encapsulate the business functionality that the user stories achieve when they are combined – this business functionality is meaningful and tangible to the product owner. The engineering tasks identified during the planning meeting (and adjusted daily through the Scrum) represent the work to be completed to deliver the user stories, and collectively the business functionality. If development goes awry and the engineering tasks cannot be completed, e.g. due to re-estimates exceeding the remaining time, then the Sprint goal gives the team latitude to re-interpret the user stories and find an alternative aggregation of work that still delivers the desired business functionality and is acceptable to the product owner.

The Sprint goal provides the team with the flexibility to constantly assess, through their daily inspection and adaptation, how they can best achieve the business functionality given their situation and disposition. It does not lock the team into a single and fixed set of mandatory engineering tasks that provide the business functionality.

The great thing about user stories is that they come with acceptance tests, which also help to describe the desired business functionality. The acceptance of the Sprint during the Sprint Review includes a demonstration of the acceptance tests passing for each user story (currently these are a mixture of manual tests through the UI and automated tests using FitNesse) and, based on a free-format session where the product owner gets to “play” with the delivered business functionality, a more holistic assessment by the product owner of whether she has the business functionality she requires, in some shape or form. 85

85 From: Simon Baker simonbaker@think-box.co.uk; Sent: Tuesday, November 16, 2004 at 4:38 PM Subject: The Sprint Goal

4.7 Task Size vs. Effort vs. Duration

Dan – I agree with you completely. The only addition/distinction that I make is that there are three estimates: size, effort and duration. The effort estimate is how many hours it will take to do the work. The duration is the elapsed

In my world, size is in bananas (or whatever you want),

effort is in hours and duration is in days. Just a nuance that keeps the concepts straight for me and everyone that I

time that will be required to undertake the effort hours.

work with.

Bud 86

86 From: Bud Cookson bud@ridgelinesoftware.biz; Sent: Wednesday, June 21, 2006 at 2:13 PM

4.8 Task Size (Breaking Down Tasks)

When should large tasks be broken down into detail tasks and who should do it?

The sub-teams should break down the tasks and the Product Owner should be there to help if clarification is needed. Sub-teams should also communicate if there are things that they are depending on each other for. We stick to the 16-hour rule as best we can; it's going to be an ongoing effort until everyone understands the reason for doing it.

the teams (sub teams) are formed, make sure they go through a team building exercise to

give themselves an identity (team name or logo), and they establish their common goal/mission, and how the team will add value to the project. It is important for the team to learn the strengths of each player, and figure out how they are going to optimize what they've got.

Additional advice

when

Bob Schatz CTO of Primavera

4.9 Sprint Calendar

Being new to Scrum, I stumbled on a question while reading through the Scrum books:

Seeing as how a Sprint is defined as 30 working days, what is the experience with teams trying to keep straight in their head where they are in relationship to the Sprint end? In other words, since there is no correlation between day X of a Sprint, and the Xth day of the month, do people get confused?

Does it make more sense to start a Sprint on the 1st working day of a month, and end it on the last working day of the month? Obviously, if a Sprint were ever terminated abnormally, or if a "Release Sprint" is undertaken for less than a month, then even this will fall into the same trap

How do people handle this? room?

Thanks,

Jay 87

Does the ScrumMaster keep some sort of "This is day X of Y" flip chart in the team

Jay--

This is one of the reasons I use four-week Sprints (or, for some teams two-week Sprints). It's much easier to keep track of, the regular rhythm is beneficial, and teams like setting it up so that Sprint planning always happens on a

Friday or a Monday (or whichever day they prefer).

--Mike Cohn 88

A highly visible burndown chart also helps with this, so long as the chart shows each day of the Sprint to scale. Team members get a sense for being 1/3, 1/2, 3/4, etc. through the Sprint.

Interestingly, I just visited an organization where the crafty ScrumMaster posted a flipchart reading "Day X" of Sprint. I thought this was a great idea. 89

Yes, I agree

Chart that you can take in at a glance.

the burndown is the simplest, most accurate way to know "where are we?” Nothing like a Big Visible

Another thing we did, was tie our Sprint dates to the monthly reporting cycle of our PM. Since his reports were due on "the 1 st Friday of the month" (or some such) we made an abstract calendar for our Sprints, which had us always finish Sprint Planning in time to feed into his management report. This way his projections for the month were actually generated by the team!

So our Sprint Planning always happened on the 4 th Monday of the prior month, and we ran our Sprint for 4 weeks from that point. We knew that our Demo would always fall on the 3 rd Thursday of the month – this allowed us to plan our Demos way in advance (getting large rooms and multiple customers available at once was a challenge). Being calendar-based, twice a year we had a 5-week Sprint. Or a free week to do cleanup, or whatever. 90

87 From: Jay R. Gindin jayg@blarg.net; Sent: Monday, December 06, 2004 at 11:29 PM Subject: Sprint Calendars

88 From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Tuesday, December 7, 2004 at 7:28 PM

89 From: Victor Szalvay victor@danubetech.com; Sent: Tuesday, December 7, 2004 at 3:08 PM

90 From: "Deb" deborah@hartmann.net; Sent: Tuesday, December 7, 2004 at 11:02 PM

4.10 Estimates

If we have a meeting like "HR Meeting on Harassment" we don't include that as a task. If it's something like "Schedule a meeting about the xyz design" that we write up (as a task card, for us) we do put a number on that and do write it as a task, mostly so we don't forget about it. The interesting thing about meetings is that they add predictability to your burndown. For example, if 5 of us need to meet about the xyz design for (we think) 2 hours. We put 10 hours on that task card. Meeting estimates are much more accurate than coding estimates, for example. So, we'll meet for 1:45 or 2:10 and that's pretty close to the 10 hours total we planned. Next day we'll have burned- down 10 hours for that meeting. There's nothing wrong with this except it's something to be aware of. For example, my current team starts each 2-week Sprint with around 250 hours of work planned. If a lot of that is meetings (it shouldn't be) that 250 might be fairly easily completed. If none of it is meetings, it might be hard to finish all the planned work.

In general, any time I know something new about a task, I update the card. So, in your example below if I have a "code the xyz" task that I think is 5 hours but then discover I need a big meeting. I'll keep the "code the xyz" task card (possibly increasing or decreasing its estimate) but may add a new card saying, "xyz design meeting, 6 hours" (6 = 2 hours * 3 developers). If it's "a couple of hours" I don't bother changing the card. By the way, all these cards are hanging on our wall so we can all see them and update them continuously. I can provide a photo if it would help. 91

91 From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Monday, September 27, 2004 at 2:33 PM Subject: RE: Seeking Some Experienced Advice

4.11 Estimating Testing

I'm a tester who's trying to wear the ScrumMaster hat for three teams in a company that's never done Scrum before. Each team has 1-2 testers, and 2-6 developers who do varying degrees of testing on their own work. Testing has been fairly informal, but there is some push to make it more documented and formal. The testers claim they can't give time estimates for their tasks and my experience with testing makes me tempted to agree with them. What am I overlooking? How do you estimate testing time?

Thanks in advance for your wisdom and experience, Liz 92

Testing effort has traditionally been hard to estimate because what was really being estimated was the code quality that the programmers would deliver. And that was impossible. In Scrum, however, where the programmers should be delivering pretty high quality code to start with, estimating test effort is quite feasible. Besides, the programmers should not be throwing the code over the wall to the testers, so the testers should be testing much earlier and more or less continuously through the Sprint.

That's all nice and vague, though. Here's exactly what I do:

During the Sprint planning meeting we list every task we can think of to finish the potentially shippable product increment. Obviously that means things like "Code the UI" and "Code the abc class.” But, it also means we write down tasks such "Write FitNesse tests for the abc class" and "enhance the UI tests to cover the changes to the xyz screen.” For each user story / feature we pull into a Sprint, we discuss (right upfront during Sprint planning) exactly how we will test it. If it's a FitNesse test, we may write tasks such as "Code fixture for xyz" and "write FitNesse tests for xyz.” We don't specify the tests during Sprint planning but we decide if we are testing at the UI level, at the service level, or just with automated unit tests. These tasks are easily estimatable. The tester may suggest the first estimate but the programmers may often commentary on the estimate such as "No, this will take much longer to test. There are lots of variations.” Or "No, this one will be easy to test and I'll show you all the unit tests I'm doing."

Also, even if something *is* hard to estimate, take a guess and refine that guess every day during the Sprint.

--Mike 93

Estimating is hard for everyone; I don't know why it should be any harder for testing than for coding. Mike's approach of specifying testing tasks on a card, eg., "write FitNesse tests for the XYZ story" really helps. If this isn't enough to help you estimate, you can break it down even further: "Work with product owner to define details of story", "Define test data", "Specify test cases". The problem with that is that you may end up spending too much time to come up with the estimate. But it might be a way to learn to estimate.

It's my own experience that testing tasks for a particular feature usually takes between 30-50% of the time spent coding it. Most fall in the low side of that, but if it's technology new to the team, integrating some 3rd party product, or something unfamiliar to the testers, it could be even 100% of the coding time. As Mike says, look to the programmers for guidance. Your testers will get a feel for it over time. I found we had vastly underestimated some testing tasks one Sprint, so the next Sprint I upped the estimates for similar tasks.

I think it's important for the entire team, programmers included, to take ownership for all the testing. Everyone will get a better feel for how long it takes – and with collaboration, it may go faster than you estimated!

-- Lisa 94

92 From: Lizard <muddlizard@g

Subject: Newbie Q About Testing Time Estimates

93 From Mike Cohn mike@mountaingoatsoftware.com; Sent: Saturday, December 18, 2004 at 6:06 PM

94 From: Lisa Crispin <lisa.crispin@a

>;

Sent: Friday, December 17, 2004 at 7:54 PM

>;

Sent: Tuesday, December 21, 2004 at 4:47 PM

4.12 Planning and Estimating Tasks

Our backlog consists of stories, each of which is estimated using a coarse-grained points system (0.5, 1, 2, 3 or split

it please).

signed-up-for stories into tasks, which are estimated in hours. (The reasons for doing this have much to do with the team's need to manage itself better during long – 4-week – Iterations, and is largely historical.)

THEN, the team breaks down these

The team signs up for the number of points it delivered last time.

It is the TASK estimates that we halved. The upshot was that we did them faster, and so brought some stories forward. Which we also split into tasks with halved estimates. Next Iteration we had higher Yesterday’s Weather, so we scheduled more story points. Again, when we broke these down into tasks, we estimated their time at the 50% point (ish). We delivered all the story points. And again in the next Iteration.

So to answer your question: We didn't change the points estimated on stories in the backlog. We only changed the process at the start of each Iteration, when the team worked out how to subdivide and deliver those stories. We changed that process by introducing a slight of hand whose effect was to drastically reduce the effects of Parkinson.

Ah, you're right, that story/task thing was what I had missed. Thanks.

I like task breakdown at planning time, as a design step. I like to see the tasks written on the whiteboard. Very frequently, however, when teams sign up for tasks, I see problems. The problems include:

- Task programmer does too much;

- Task programmer does too little;

- No one notices a task not needed after all;

- No one notices need for a task that wasn't mentioned;

- Tasks don't add up to equal the story.

Some of these, externally, would look like Parkinson's Law.

Crunching the time allowed for each task would help with these, if through no other means, through allowing less time to do too much, and getting to story integration sooner, to discover the other issues.

I used to recommend having a story owner, in addition to task owners, and that is still IMO a good idea if you're going to schedule and work on tasks.

But I think that a better idea is to sign up /only/ for stories, not for tasks. The story owner sees the tasks and works with all the necessary people to get things done, taking what people call a "vertical" slice through the system, meaning cutting down through all the levels of the code: GUI, model, database, etc.

This works well with a team in a room, less well the more separated and more specialized a team is.

And it works better the smaller the stories are.

Thanks for helping me express it all in a more understandable way, Ron.

Thanks for sticking with me until I got it. My theory at the moment is that the smaller time boxes get at the problems I listed above /indirectly/, by reducing the time to overbuild, and decreasing the time until the thing is integrated and the other problems discovered.

But I'm wondering how your team addresses making the tasks "add up" to the story? Some teams, I think, accomplish that by letting the GUI task serve as the integrator. (I think that's not the best idea.) How do you get things integrated or added up?

Does the above undermine your thought experiment below?

Well, it supports my standard theory that smaller stories are better, down to a day or two anyway. I'm not sure about the time-box idea, but I suspect that if a person worked by taking a multi-day story and slicing it into mini /stories/ rather than little /tasks/, and implemented it punching through most or all of the software layers, it would work better.

So if in two (or more) time boxes, my focus was on story completion rather than database reorganization, I think a team would get at the root causes that your short estimates are getting at indirectly.

For me, the distinction between size estimates and duration estimates is crucial. Much trouble ensues when size estimates are expressed in time units. This is why I believe Mike Cohn is correct to favor Relative Sizing Points (or bananas, or gummi bears) over Ideal Days. Both are estimates of size, but the second implies a duration and chronic confusion will follow.

Remember that the size of an item is unchanging. My most frequent analogy (which I stole) is that of cutting grass. The size of the job is expressed in acres, say 2 acres. The length of time it will take to mow this amount of grass is a duration estimate, which is dependent on many things (equipment, number of people, weather, etc.). The size of the job, 2 acres, never changes.

So, backlog items are given size estimates. Tasks are given duration estimates. It is at the task level where an actual duration is estimated.

Dan Pierce 95

I like this idea of size vs. duration.

items. Initially our estimates were time-related, but that brought all sorts of trouble. Once we moved into size

estimates, the troubles pretty much stopped completely.

We never estimate duration of tasks; we only ever estimate size of backlog

I actually believe that time estimates for tasks depend on so many factors that they become virtually meaningless. Resources become available or unavailable as you go along and the environment changes all the time.

If a given task is executed by resource A, it will take 4 hours. Resource B will need 8 hours (lack of domain knowledge or technology skills). At the beginning of a Sprint it is virtually impossible to tell who will execute a given task, so how are you going to estimate time? Sometimes what appears to be simple grows out of all proportion and sometimes something that appears complex collapses into nothing because somebody digs up a piece of information that wasn't available during the estimating. If one wanted to pin down exact time estimates, this would require exact knowledge of resource availability and very soon one would find oneself back in the world of waterfall.

The temptation is strong, but from experience I'd have to say, stay away from it.

In addition, what are the time estimates going to be used for? At the end of the Sprint the amount of work remaining (in hours or whatever unit you like) is meaningless, as is the amount of actual work done. The only thing that counts is the number of backlog items DONE.

95 Dan Pierce, Embedded Software Development Manager Thales Communications, Inc.

22605 Gateway Center Drive

Clarksburg, MD 20871

To stay with the analogy: it doesn't matter how many people or hours were needed or whether it was raining or not, the only question that remains is: has the grass been mowed on all of the 2 acres?

Regards,

Wolfgang 96

96 From: Wolfgang Schulze Zachau wolfgang@mobilefun.co.uk; Sent: Wednesday, June 21, 2006 at 8:07 AM

4.13 Technical Debt – Big Refactorings Not Yet Done

On Thursday, January 20, 2005, at 7:47:10 AM, Paul Wilson wrote:

> I've been using a cut-down Scrum to manage some freelance work I've been doing recently. (Development team

== me). It worked well, keeping the client and me tightly focused on the weekly increments.

> I had an issue with how to track technical debt issues in the product backlog; when planning the next Sprint it's

difficult for the product owner to prioritize (or even care about) non-functional items. Mike Cohn makes the same point in his (excellent) User Stories book, and suggests having only Stories in the backlog.

> Never the less, I feel these big refactorings do need to be done: hence they should be planned, tracked, and made

visible at least to the developers. How have other people coped with this problem?

Here's what I try to do

1. Write code that doesn't need refactoring, by removing all duplication and other code smells immediately. Learn

to recognize refactorings before they're big. I believe that there are always signs.

2. Make a note of a needed "big" refactoring and put it somewhere where you won't forget it. If the bad code is not

slowing you down, don't do anything about it. If you never work in that part of the code again, the refactoring

wasn't needed.

3. If you do work in the area and the bad code does slow you down, see whether you can make a little improvement

each time you pass through, rather than bite the bullet.

4. If the bad code continues to slow you down, you'll feel increasing pressure to fix it. I'm not sure why just bearing

down a bit in item 3 isn't enough. If you must divert to fix it, try not to take the whole bite. My experience suggests that there's usually a way.

5. If the bad code is still slowing you down, estimate whether fixing the whole thing will really give you a net

speedup. This is a function, among other things, of how close you are to the end. Then decide whether to go all the way. My experience suggests that this is usually a mistake.

None of these things can be done perfectly – at least by me. I see it as a sort of escalating thing. I believe it is probably possible to work mostly in the 1-3 range. I believe this keeps the pace mostly constant, while 4 and 5 usually involve too much speculative investment in the future.

Now then

approach. I'm not sure what to do with that observation.

it seems to me that what I'm really describing are points on a continuous curve, not steps in a planned

Ron Jeffries 97 www.XProgramming.com

97 From: Ron Jeffries ronjeffries@XProgramming.com; Sent: Thursday, January 20, 2005 at 8:07 AM Subject: Re: Technical Debt and the Product Backlog

4.14 Requirements Ready for Sprint

I recently joined a software company that started using the Scrum process. We are finishing up our second Sprint. We are generally satisfied with Scrum, but are having a problem in having the requirements ready for the beginning of the Scrum. The people who write our requirements are spread around geographically but the development team is all located in one place. We are looking at having an even heavier process to define the requirements because of the geographic issues. I am concerned that we will have a mismatch between the 2 processes. I would be interested in hearing from others who have had project with similar issues and what they did to solve the issue.

Thanks. 98

You should have a backlog of prioritized, "ready" requirements. The product manager should be collecting requirements into that backlog. By making it clear when the cutoff date is for requirement submission for the next Sprint, the customers know when they have to get their requirements submitted. When the next Sprint starts, its requirements come from the backlog. If any customer is late getting their requirements in, then those requirements just go on the backlog for a later Sprint to do. If enough customers are late with their requirements, then the backlog will be quite full enough that it is never a problem to find requirements for subsequent Sprints.

Perhaps, customers are having trouble "writing" requirements because they are being asked to document their requirements in too much detail. A brief description should be enough to prioritize requirements. The details can be collected during the Sprint when it is actually being implemented. This approach prevents the details from getting stale over time, creates an opportunity for constructive communication between developers and customers that makes the requirement better understood than any written documentation can, and makes life easier for customers. 99

Without getting pedantic, I would like to point out that one of the key attributes of Scrum is the collaborative nature of the working relationship of the user/product owner and the Scrum Team. From what little you have told us, one could draw the impression that you are actually doing timeboxed waterfall tasks where requirements are built by separate teams and then handed off to the coders. There is nothing wrong with this, as it is a common way for organizations to get comfortable with the methodology.

It might be a good time though to blur the lines between the requirements and the coding by using the product owner's priority of the backlog create the need to assemble Scrum teams made up of people from the two previous Sprints. This is not an endorsement of jumping whole hog into Scrum, rather it is a suggestion to let the product owner's priority drive the melding of the development team.

--Mike Dwyer 100

98 From: "tiggerbob_93003" bbrodie@epolicysolutions.com; Sent: Wednesday, March 16, 2005 at 8:31 PM Subject: Requirements Process and Scrum

99 From: Steven Gordon sagordon@asu.edu; Sent: Wednesday, March 16, 2005 at 2:48 PM 100 From: Mike Dwyer mike.dwyer1@comcast.net; Sent: Wednesday, March 16, 2005 at 9:59 PM

4.15 Testing

…I've never used Scrum on a project that was done in a scripting language, if that's what you mean. We have used scripting languages as part of our approach to testing. The tester needs to be an integral part of the team – as much so as any programmer. I like to have the tester spend some time talking with the customer about the likely stories (features) coming into the *next* Sprint so that when the programmers start coding they already have high-level acceptance tests written. We like to capture these in FitNesse. Involve your tester in more discussions and have her use the strengths she brings to the team – presumably she's a good tester despite your comment that she doesn't have strong tech skills. She should still be able to specify tests in advance or use tools such as FitNesse and Canoo WebTest. 101

101 From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Monday, September 27, 2004 at 2:33 PM Subject: RE: Seeking Some Experienced Advice

4.16 Test Driven Development

…I hear (and experience) things like "I started coding some tests for feature X, but they weren't working, so I spent three hours trying to figure out if my code was wrong, and then figured out that there was a bug in Z. So I spent half a day and accomplished nothing.” It takes a lot longer to write tests for buggy programs because every unexpected behavior you encounter must be analyzed, to check whether it's your own mistake or a real bug. So how do you estimate ahead of time how buggy the code will be when you start testing it?

How do I encourage this paradigm shift? Right now I frequently hear "it's done, it just needs to be tested.” I don't have the power to mandate TDD yet (either management backing or respect from the team), so how do I survive until the team itself asks for TDD and encourage them in that direction? The teams that have completed at least one Sprint have, in their retrospectives and suggestions for the next month, made the gap between "creating the new feature" and "fixing bugs in the feature I just implemented this Sprint" bigger.

Thanks,

Liz 102

Hi Liz--

A couple of suggestions:

1) You say that you hear things like, "it's done. It just needs to be tested." Yep, that's a very common (and annoying) statement. I encourage teams to spend 15 minutes agreeing on what "done" means. That usually ends up being something like "well-written, unit-tested, checked-in, etc. etc.” (I don't want to write more because I don't want to overly suggest an answer – that's up the team.) I typically write this definition on a shared whiteboard for everyone to see and remember for the next few months. I've gone so far as to buy a cheap dictionary, print our definition and tape it into the dictionary in the right place. The dictionary becomes a bit of a joke but a symbolic one that helps us remember our definitions of "done" as well as "trivial" (="will take at least 2 weeks") and "today" and a few others that may come up.

2) Keep stressing that work *has to be finished* in the Sprint. That there is no carryover of "fixing" it in the next Sprint. This is where I really like the XP idea of velocity. A team's velocity is measured by work it completes (I'd say "all the way" but that's really redundant with "complete"). If I don't quite finish a lot of things, my velocity is very low relative to what it could be. This helps teams understand the importance of really finishing.

3) I like to tell teams something like "I'd really like us to try TDD. I don't know how often and how much of it we should do but I know it's not 0% and I know it's not 100%. So collectively let's figure it out." [Note: I actually do think it's 100% but I lie and let them think I top out at 99%.] Once I get a team to start trying TDD, it's easier to keep nudging them and someone on the team will usually start to "get it" and then it's easier.

4) I think that estimating test tasks during Sprint planning sets the stage for treating test tasks as first class citizens throughout the Sprint. I think that will help encourage the "paradigm shift" you're after.

5) I'm not sure it really takes longer to write tests for buggy code. It takes longer to execute those tests perhaps but you want to (a) not have such buggy code and (b) have a test automation process that lets you write tests without any code (so buggy code doesn't matter). Find a way of specifying the tests you want that is independent of having running code. Push this activity as early into the Sprint as you can (ideally before or concurrent with the first lines

of code for the Sprint). Tools like FitNesse are wonderful in this regard. If you find you can't do much of that yet,

then you estimate how long it will take based on past experiences with how buggy the code will be. "I estimate it will take 8 hours to write tests for Jim's new code but since his code is always buggy, let's put 24 hours on that card.” I think that's a fair statement if Jim is that buggy. --Mike Cohn 103

102 From: "Schoof" <muddlizard@g

Subject: Re: Newbie Q About Testing Time Estimates

>;

Sent: Tuesday, December 21, 2004 at 9:10 PM

TDD is hard to start doing, period. So it's much harder to do without someone in authority prodding the team to deliver better quality. It's harder to influence the team if you're a tester and not a programmer. I feel your pain. Are there any programmers who are sympathetic to your point of view? If so, see if you can brainstorm with them.

If you're automating your customer-facing tests, and the programmers are not writing automated unit tests, you can point out that many of your tests could be covered by unit tests, which have a much better ROI.

You can always do what I've done and say, "Ron Jeffries said the entire team is responsible for testing, and the story isn't done until the acceptance tests are done.” (OK, I didn't say Ron specifically, but I pointed out what the many publications on XP said, being as I was on an XP team). If your team honestly wants to benefit from Agile principles and values, they need to try to implement key practices.

I highly recommend "Fearless Change" by Mary Lynn Manns and Linda Rising. I have used their patterns to get teams to try Agile practices.

-- Lisa 104

103 From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Tuesday, December 21, 2004 at 10:21 PM

104 From: Lisa Crispin lisa.crispin@att.net

4.17 Unit Testing

Coding does not require unit testing. Most of the working code in the world does not have unit tests. Thus unit tests are extrinsic.

I have drunk the unit testing Kool-Aid, but if you bypass the cost of something, you lose credibility with those you are talking with. I have learned this through many, many conversations with developers who consider unit testing a lot of extra work up front and a lot of extra maintenance work. Saying it's not a lot of work doesn't give you much street cred. You and I may think we have excellent reasons for doing the work, but it is still a lot of work. 105

Yes. However, debugging and fixing also costs a lot. So if you want to have software at a reasonably low level of defects, it just might be that unit testing costs less than (not unit testing plus debugging plus fixing).

Ron Jeffries 106 www.XProgramming.com

The real electric Kool-Aid Test lives in the dark side of software – maintenance and problem resolution. Since it is here that you can see the hubris of those who felt their code was too smooth, too simple, or too cool to need a unit test. Is there a lot of energy in that statement? Yup. So perhaps I should rephrase.

It is rare to see code come into the shop that had well designed unit tests. That is to say tests that:

Defined the input, tested all combinations of input, tested to make sure they could tell good input from bad. Ensured that all logic flows had errors trapped – with some meaningful documented schema to tell where the error came from. Validated that all the output meant the interface requirements that the users of the software had stated they needed. Documented all of the conditions that could occur that were not covered by the interface specification.

Now the really GOOD engineers had a parm you could pass that would open up the dbug logic in the software so that we grunts on the dark side had some idea what was going on.

Finally, speaking from my tenure as chief testing troll, the REALLY GOOD AND SMART Engineers enlisted a testing troll in testing the tests.

Michael F. Dwyer 107

> Todd Hartle wrote:

> However, not unit testing does not imply not testing all. And it also seems that unit testing can still exist even

though the tests do not live in the code.

If you don't write unit tests before writing code, your tests won't easily cover everything, and you will spend more time debugging.

Folks who use TDD very frequently report _zero_ debugger usage.

Think of it like this: Each time you debug, you set a breakpoint, you run the program and load sample data, you hit the breakpoint, and you inspect the local values to see if they are correct with respect to the sample data.

105 From: Todd Hartle thartle@gmail.com; Sent: Saturday, December 4, 2004, at 1:57 PM Subject: Unit Testing

106 From: Ron Jeffries ronjeffries@XProgramming.com; Sent: Wednesday, December 08, 2004 11:30 PM

107 From: Mike Dwyer mike.dwyer1@comcast.net; Sent: Friday, December 10, 2004 at 8:08 PM

TDD converts debugging into a system that records an endless trail of each of these experiments. Going forward into maintenance, for each change you make, you get an invisible programmer debugging your code, over thousands of scenarios, in a second.

-- Phlip 108

Hi,

Unit testing as it is emphasized today in TDD and XP has mainly two backgrounds:

a) In XP you do not very detailed requirements analysis, but story boards and planning games, like CRC card

sessions.

So, writing unit tests first helps the programmer to understand the requirements. With "the customer in house" you can use (and must use) the tests to validate whether your requirements are right. Further: writing a lot of unit tests comes from the Smalltak development fraction where your unit tests partly replace the compiler type checking and also lint.

b) Your main goal in having unit tests is to have a "regression test suit" in case you do refactorings, bug fixes or you

simply continue in your next development goal.

Finally: most software development shops have no clue how to value whether they "need" unit tests or not. If you ask one who does not do unit tests he will ALWAYS claim he either does not need them or they don't bring him any value (ROI). Likewise everybody doing them knows that they bring him ROI, like I pointed out in b) As long as one without unit tests never does one, he has no numbers from which he could judge. Most of the time, people without unit tests have no decent issue tracking/bug fixing/project tracking either. So how should they know how much it costs them NOT TO DO TDD?

I disagree that detailed requirement analysis does not work, and also I disagree that the tests are needed to get the requirements fixed. Often this may be the case but as a general rule, it’s far to strong.

Suppose you don't do a use case and a few scenarios, but write the test and the code, which passes that test. And now? Now you check whether the code/test is right. That’s expensive, especially if the code and test is wrong!

Before you code, regardless whether with TDD or not, you should do planning games with paper sheets where you have a paper form holding data and objects and you pass them around between requirements analysts like in CRC or XP planning games.

If you start directly with TDD you are not "coding" but "prototyping" different goals