ScrumMaster Certification in Denmark

CSM Training in Denmark
22-23 August 2006
Contact scrum@eos.dk
Eastfork Object Space (EOS), Margrethepladsen 3, 8000 Århus C, Denmark
Tel: +45 8732 8787 / Fax: +45 8732 8788 / Mob: +45 4072 8483

Get Agile in Denmark with Jeff Sutherland, Ph.D., the co-creator of Scrum. The course was formulated to train and certify ScrumMasters and is used worldwide for ScrumMaster training. The book, Agile Project Management with Scrum, by Ken Schwaber is required reading for the course.

Of course, there will be updated material and training exercises in the course which you cannot get from books. Dr. Sutherland has done research and development on Scrum using his last five companies as laboratories. His entire current company at PatientKeeper is run by a MetaScrum, and is one of the most advance implementions of Scrum worldwide.

The entire CSM syllabus will be made available upon registering for the course so you can look it over and bring it with you to the sessions.

Bliv Scrum certificeret
- og få indsigt i en af de agile metoder, der understøtter Lean Thinking

To dages Scrum certificering finder sted den 22.-23. august

Jeff Sutherland, en af fædrene til Scrum, kommer til Danmark for at certificere to nye hold af Certified Scrum Masters. Jeff Sutherland har mere end 30 års erfaring med softwareudvikling og 15 års praktisk arbejde med Scrum.

Scrum er siden 1993 implementeret med succes i flere tusinde projekter over hele verden. Virksomheder som Microsoft, HP, IBM, Yahoo, Xerox, Primavera, CapitalOne, Federal Reserve Bank og BBC har alle indført Scrum som en af virksomhedens værktøjer til effektivisering.
Der er i dag mere end 6000 certificerede Scrum masters i USU, Europa og Indien.

Den agile metode Scrum, understøtter filosofien om Lean Thinking og Lean Software Development. I EOS praktiserer vi Scrum internt ligesom metoden anvendes i forbindelse med vore forskellige kundeprojekter. En vigtig dimension i Scrum er at sikre et højt motivationsniveau og engagement hos de involverede medarbejdere og holde fokus på de ledelsesmæssige aspekter i projektorganisationer.

Scrum er ligesom Lean udsprunget af Toyota fabrikkernes effektiviseringsproces i produktionsmiljøet. Scrum´s gudfædre er, Hirotaka Takeuchi og Ikujiro Nonaka.

Tilmelding på: scrum@eos.dk

Distributed Scrum: Agile Project Management with Outsourced Development Teams

Recently, I had to complete a research paper on distributed programming for the Agile 2006 Conference in a two day weekend. Russian XP expert and project leader, Anton Viktorov, flew into Boston from St. Petersburg to help write up the SirsiDynix project. Over 1,000,000 lines of code were written in record time by a set of Java teams distributed across Utah, Colorado, Canada and Russia.

StarSoft Development Labs, the leading XP shop in Russia, was selected as a partner by Scrum company, SirsiDynix, to replace a large library system installed at over 12,500 sites worldwide. CTO Jack Blount, formerly COO of Borland, ran the project as a distributed Scrum of Scrums with individual teams distributed across geographies. Anton had been pair programming for years at StarSoft Labs with little experience writing research papers. I had over 20 years experience writing research papers and 13 years of Scrum. We decided we better pair write the paper to meet our two day deadline in the middle of a Boston blizzard. I did most of the coding as he framed the details of the project. The SirsiDynix/StarSoft 56-person distributed Java team was as productive as a 6 person colocated team using Scrum. Unbelievable! Needless to say, we wrote the research paper in record time and you can judge the result for yourself. See:

Sutherland, J., Viktorov, A., Blount, J., and Puntikov, N. (2006) Distributed Scrum: Agile Project Management with Outsourced Development Teams. Submitted to HICSS40, Big Island, Hawaii, Jan 2007.

No Silver Bullet: Essence and Accidents of Software Engineering

Fred Brooks comments:

Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy. Hence, they cannot be fixed without fundamental revision--revision that provides for iterative development and specification of prototypes and products.

Incremental development--grow, don't build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.

Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.

So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. [10] That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below.

I have seen most dramatic results since I began urging this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.

The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.

Brooks, Frederick P., "No Silver Bullet: Essence and Accidents of Software Engineering," Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.

Microsoft Vista: Scrum or Not-Scrum

Peter Krantz rants on Scrum, Lies, and Red Tape at the Microsoft Vista project (see below). He's in Stockholm and I'm on a SAS flight over Greenland returning from two weeks in Sweden and Denmark doing several ScrumMaster Certification Classes. While Microsoft adopted Scrum on many programs large and small, I'm not aware of the Windows Vista team using it. Scrum is built on truth, transparency, and trust and was designed to emulate the productivity of the Borland Quattro project where the each developer delivered 1000 lines of quality production C++ code per week. Vista only delivered 1000 lines per developer per year.

Philip Su thinks Vista is the largest software project in the world and maybe the longest. However, Jim Coplien was in my Copenhagen ScrumMaster training last week and pointed out that he delivered weekly releases into a 100 million line code base deployed worldwide by ATT so that was at least twice as large as Vista. Jim also wrote a case study of the Borland Quattro project that was the inspiration for the Scrum Daily Meeting while he was at ATT. It was interesting to dive into the details of that project, but I digress. Here's Peter:

Scrum, Lies, and Red Tape by Peter Krantz

Philip Su from Microsoft gives us a glimpse of the inner workings of one of the most complex software projects in the world. It is interesting to see that the same problems that sometimes plague small waterfall projects (lies, red tape) exist in an organization that have put a lot of effort into their development methodology... Didn’t Microsoft adopt Scrum a year go? Maybe they skipped the part about transparency.

Broken Windows Theory by Peter Su

Vista. The term stirs the imagination to conceive of beautiful possibilities just around the corner. And “just around the corner” is what Windows Vista has been, and has remained, for the past two years. In this time, Vista has suffered a series of high-profile delays, including most recently the announcement that it would be delayed until 2007. The largest software project in mankind’s history now threatens to also be the longest...

Let's see if, quantitatively, there's any truth to the perception that the code velocity (net lines shipped per developer-year) of Windows has slowed, or is slow relative to the industry. Vista is said to have over 50 million lines of code, whereas XP was said to have around 40 million. There are about two thousand software developers in Windows today. Assuming there are 5 years between when XP shipped and when Vista ships, those quick on the draw with calculators will discover that, on average, the typical Windows developer has produced one thousand new lines of shipped code per year during Vista. Only a thousand lines a year. (Yes, developers don't just write new code, they also fix old code. Yes, some of those Windows developers were partly busy shipping 64-bit XP. Yes, many of them also worked on hotfixes. Work with me here.)

Lest those of you who wrote 5,000 lines of code last weekend pass a kidney stone at the thought of Windows developers writing only a thousand lines of code a year, realize that the average software developer in the US only produces around (brace yourself) 6200 lines a year. So Windows is in bad shape -- but only by a constant, not by an order of magnitude. And if it makes you feel any better, realize that the average US developer has fallen in KLOC productivity since 1999, when they produced about 9000 lines a year. So Windows isn't alone in this.

Why the Three Questions in the Daily Scrum Meeting?

What did you do yesterday?

A huge accelerator in a Scrum occurs when every developer sees the entire progress of the project every day. Hyperproductivity ensues when the typical comment becomes, "Wow, I thought it was going to take 3 days to do my next task, but I see from what you did yesterday that 3 lines of code and one hour are all that is necessary!"

This question tests the focus of the team. Anything done that was not work on the backlog is questioned. Meetings that are interfering with the Scrum are reduced or eliminated. Participants who repeatedly do not further work on the backlog may be removed from the Scrum.

It also generates peer pressure to get stuff done that is impeding progress of others.

The ScrumMaster wants to know what tasks are "done" and whether tasks in progress will complete as expected. If estimates are expanding or new tasks are discovered, this will change the burndown chart.

The ScrumMaster also wants to minimize work in progress. To many open tasks at once introduces risk into the Sprint and is an early warning that delays may be expected.

What will you do today?

This question replaces GANTT charts. Dependencies are constantly changing. Answering this question revises project strategy on a daily basis by reorienting the team due to dependency changes that were revealed by the previous question.

The question also surfaces dependencies or tasks that may have been overlooked. This will revise the plan in the minds of the team.

It also tests the focus of the team. Anything to be done that does not further progress is questioned.

The ScrumMaster wants to know what new tasks are starting. Failure to see tasks opening and closing regularly is an early warning that things may be going off track.

What is blocking progress?

Impediments to progress are often caused by software or technology not showing up at the right time. The ScrumMaster or the team may be able to resolve this. Otherwise, management must fix it.

Blocks are often due to meetings irrelevant to the SCRUM. Often management must get involved to fix this.

Hard technical problems often slow things down. The team can often fix this. Alternatively, management must bring in other resources.

This question will create issues that may result in new tasks in the backlog. It could revise the plan.

The most important effect of this question is to create a list of impediments that are assigned to the team or to managers. A major responsibility of the ScrumMaster is the manage, prioritize, and assure this impediment backlog is burned down. The Scrum team should expect management to help work the impediment backlog. Eliminating bottlenecks is the fastest way to improve productivity. See Goldratt's book, "The Goal." All managers should read this book. Developers will find it useful also.



One of the biggest impediments to improving productivity in Scrum teams that I see in many companies is failure of the ScrumMaster to track and prioritize impediments. Management cannot help fix them if they are not clearly identified along with a recommended plan of action.