Sarajevo Special Scrum.org Product Owner Training

  

Studies* show that certain memories help us learn and remember more effectively. Combine a course with a team building exercise, an appraised movie, and you have something amazing - a training with lasting impact. 

This is exactly what we wanted to achieve with the first Bosnia Agile organised Scrum.org Product Owner training.

The PSPO (link) training was build around two events, the Sarajevo Film Festival  and a rafting team building exercise. It does not come as a surprise that this event was sold out 6 weeks ahead.

 

Between watching a great movie 'The Railway Man' and rafting in this beautiful region, the students where also learning everything important about Scrum, value, lean and agile product ownership. Since I was the trainer it might sound pretentious from me to say how awesome this training was, but in all modesty, it truly was. It was an outstanding and new experience not just for myself. I made many friends and shared many great moments with my fellow students. I am sure that Sarajevo played a big part in this. Sarajevo, the capital of Bosnia-Herzegovina, is a very dynamic and friendly city surrounded by beautiful nature and with good reason was the host for the ’84 Winter Olympics. I for myself cannot wait to go there again.

25 happy Product Owners and a happy trainer cannot be wrong. We have been so pleased that the organisers and I decided to repeat this setup once again next year.

If you live somewhere in the EU you should consider combining education with worthwhile memories. More training content will stick and even better, you will have more fun learning. Consider this: even with budgeting in the costs of transportation and accommodation, it is probably still cheaper than your near-by training provider.

See you next year at the 21st Sarajevo Film Festival …

 

*)

http://brainbasedteaching.wikispaces.com/file/view/Caine+114.pdf

http://pratclif.com/brain/neurons.htm

Half-Life of commitments

Half-life is the amount of time required for a quantity to fall to half its value as measured at the beginning of the time period. 

During private PSF (Profession Scrum Foundation) classes my students create a Change Backlog. The idea of this backlog is to codify the things that need to be changed in order to become agile. Actually, after they finished creating the backlog I ask them to put a name on each sticky note, meaning that the person whose name is on the note is responsible for acting on that item and is accountable for it. Finally, I ask them right away to define a date at which they will review this backlog. Inspect and Adapt.

I am doing this to avoid the training conundrum ‘Yeah, this has all been very interesting but right now I don’t have the time and right situation at hand …'

In my opinion if you don’t go out immediately after the training and walk the talk, your motivation will decrease rather dramatically. Not that I have researched, but my feeling tells me that the half-life is about one week. So, after two weeks your motivation is down to a quarter.

Also, I see best results when whole teams get a company private class. Even better when their superiors join in too, if not for the entire training but for the last 3 hours of the second day when we create the Change Backlog. This exercise creates a transparency which hardly can be reproduced in a later setting. At the end of day two, most of my students are really enthusiastic to get started and the managers sense this as well. 

High chances of success: An enthusiastic team with management support: you are ready to roll on your path to agility.

The Antibiotics of Software Engineering - Agile Testing

Surgery is not a recent invention, it dates back millennia. 

Notable Milestones in Surgical History (http://surgery.about.com/od/surgeryinthemedia/a/HistoryOfSurgeryTimeline.htm)

6,500 B.C.E. - Skulls found in France show signs of a rudimentary surgery called trepanation, which involves drilling a hole in the skull.

1540 C.E. - English barbers and surgeons unite to form The United Barber-Surgeons Company. These barber-surgeons performed tooth extractions and blood letting. Physicians were considered an entirely different profession, treating illness with medications.

1818 - First transfusion of human blood.

1843 - First hysterectomy performed, in England.

1843 - First use of ether.

1867 - British surgeon Joseph Lister publishes Antiseptic Principle in the Practice of Surgery, extolling the virtues of cleanliness in surgery. The mortality rate for surgical patients immediately falls.

1885 - First successful appendectomy performed, in Iowa.

1890s - Widespread use of chemical agents to minimize germs. Carbolic acid was put on incisions to minimize germs and decrease infection rates.

1896 - First successful heart surgery performed, in Germany. Surgeons repaired a stab wound in the muscle of the right ventricle.

1905 - First successful cornea transplant.

1917 - First documented plastic surgery performed, on a burned English sailor.

1928 - Antibiotics discovered.

…

Even if the procedure was successful, often the patient suffered and usually died of subsequent infections. 

Also, not to ignore is the discovery of Ingnaz Semmelweis, a physician at a Vienna hospital. While working at a Vienna hospital in 1847 he discovered that far more women died after childbirth by the so called childbed fever in the medical ward then in the midwifes ward. Semmelweis postulated the presence and spreading of germs causing the illness by doctors. Even though, after applying a chlorine and lemon based hand-wash solution the death rate could be reduced from ~35% to 1%, he was being labeled a heretic by the doctors. Ignaz Semmelweis was ignored until Louis Pasteur confirmed the germ theory.

Now, after it was accepted that germs caused infections and that hygiene was mandatory for good outcomes it became also obvious that there was a need to have a treatment once an infection set in. As listed above, on September 3rd  in 1928 Alexendar Flemming discovered the antibiotic effect of Penecillin and transformed medicine as we know it. Nowadays, antibiotics are used to treat all kinds of infections and antibiotics are prescribed in a preventive manner for many medical procedures. 

In software development we are able to develop rather fast and make significant changes to existing systems quickly. However, after these procedures the system often falls sick, suffering from bugs, side-effects and other ailments. I like to consider these as infections. Those infections even arise after well planned and executed engineering efforts.

The fundamental question is, how can we cope with them or even better avoid them - what is the the antibiotic equivalent in programming?

For me, the answer is: Agile Testing

Agile Testing is the process to validate that new functionality performs correctly and more importantly to verify that the existing behavior has not changed - that no infection has set in.

1. We have proof that the current system is healthy before the procedure starts

2. We are able to monitor the systems health during the procedure

3. We can intervene the moment side effects set in

4. We have proof that the procedure was successful 

A well done Agile Testing strategy is the equivalent to clean medical equipment and antibiotics. 

The 1000 Students Challenge (4)

In May of 2011 I was able to run my first Pay It Forward Scrum Training at the University of Bern in Switzerland. I had blogged about this event here:  The 1000 Students Challenge

Last week-end I had the third run at the University of Applied Sciences (HS-AlbSig) in Albstadt, Germany. 20 students volunteered their week-ends to learn about Scrum by attending the Scrum.org Professional Scrum Master Training or short PSM. The class was an even mixture of Master and Bachelor students. It's been great fun for them and myself and it is good to know that 20 future and current IT specialists will join the workforce pre-equipped with Agile and Scrum.

A big thanks to the Hochschule Albstadt for being supportive and to Kunt Kliem for organizing.

My mission is to train 1000 students in Scrum - 918 more to go ...

PS If you are interested in hosting such an event at your institution please contact me at www.effectiveagile.com

Cynefin - Making sense of complexity

In my trainings, I’ve been using the Cynfin framework which was developed by Dave Snowden in 1999 while he was working for IBM, for a long time.

It really helps to describe the significant distinction between ordered and unorded - when a defined process works and when to use an empirical approach i.e Scrum.

So, I’ve been looking forward to listen to Dave Snowden first hand at the 5th LAS (Lean Agile Scrum) conference in Zürich last week.

Snowden is a great speaker with lots of insights and british humor. However, each sentence counts and it is loaded with information and very technical terms. As of know I am still digesting his talk.

For exactly that reason, I decided to summarize my take aways and share it for you and myself:

If you don’t understand you cannot adapt - If it works just keep doing it; however what to do if it stops working. Then you are out of your depth and since you did not understand it in the first instance you cannot effectively cope with it

Cookbook - Everyone can cook with a cookbook given the right kitchen with the right tools and all ingredients are available. However, if you lack tools or ingredients you need a ‘chef’ someone who understand the theory and knows the practice. By that time the cookbook is useless to the novice.

Consciousness is a distributed function - the brain, nervous system, hormonal system, … all have an impact in how we work. Consciousness is what a knowledge worker works with.

Body of Knowledge - BoK requires theory and practice. You need the theory and 2-3 years of practice (nervous system) to acquire the skills. Apprenticeship and serving time is key. Theory and practice combined are called praxis. Praxis makes perfect.

Exaptation - using something for something else - far more successful then adaption. Exaptation requires granular elements for recombination. Adaption causes slow change; exaptation is a far more successful strategy for innovation.

Architecture in Software - needs to allow for exaptation. Fairly fine grained objects, good scaffolding allow for free interaction and combination. Software development is a service based provision.

Taking a linear process and drawing it as a circle doesn’t make it non-linear (ditto not faster) - Scrum-er-Fall

Coherence - not perfect data but usable, semantically meaningful. Often we have to make decisions on data which is coherent but not absolute.

People make decisions based on ingrained patterns on past experience - whatever data available, it will be filtered by past experiences.

Complex Adaptive Systems (CAS) cannot be eliminated - we have to manage the non-linear causal dependencies and resulting turbulence in unordered systems.

Meaning exists between the gaps of people, not the people themselves - it is the interaction what counts, the relationship between is more important then the things themselves. Don’t change the person, change the way they interact. Manage networks, the vague gaps between things

Agents are anything that reacts within/withon a system - people, ideas, groups, myth

In the Simple domain - agents are fully controlled

In the Chaos domain - no constraints on the agents, wisdom of the crowds; chaotic system have value but they are complicated to create 

In the Complex domain - beneficial coherence through boundary management and attractors. We manage the emergence. (Emergence requires less resources then other processes). You can only understand it while interacting with it.

The Simple domain is adjacent to the Chaos domain - If an unordered problem is approached in a Simple fashion it  will transition straight to Chaos through an catastrophic event.

We like order, like to conform

The more bureaucracy the more informal networks in an enterprise

Hindsight doesn’t lead to foresight

Stupidity and Intelligence with Deception are the same thing.

The 1000 students challenge (3)

In May of 2011 I was able to run my first Pay It Forward Scrum Training at the University of Bern in Switzerland. I had blogged about this event here:  The 1000 Students Challenge

Last week-end I had the second run at the University of Applied Sciences (FHNW) in Brugg Switzerland. 29 students volunteered their week-ends to learn about Scrum by attending the Scrum.org Professional Scrum Foundations Training or short PSF. It was great fun for them and myself and it is good to know that 29 future IT specialists will join the workforce pre-equipped with Agile and Scrum.

A big thanks to the FHNW for being supportive and to Prof. Martin Kropp for organizing.

My mission is to train 1000 students in Scrum - 938 more to go ...

PS If you are interested in hosting such an event at your institution please contact me at www.effectiveagile.com

Non-Functional-Requirements (NFR) and Scrum

I recorded a small webcast to visualize how I like to work with NFR with Scrum!

Enjoy,
Ralph
effective agile.

Agile Testing Days 2012 - Take Away

Last week I’ve attended the Agile Testing Days 2012 Conference in Potsdam, Germany. It has been a great conference with great talks from various well known thought leaders. I for myself was invited to talk about  'Sprint Backlog in ATDD’.

Every conference has its take away the one thing you take home nagging your mind. For me it was the talk from Gojko ‘Reinventing Software Quality’.

Here my current take away:

1. Measurement

We/business usually measure the wrong thing. In his example he took his book 'Specification by Example’. In the print he found over 20 P1 bugs like sentence cut off, over 70 P2 bugs and so on. So he was very upset with the printing house which allowed the bad quality. However, in the end it has a five star review at Amazon. The errors did not matter as the final product still provided excellent value to the end user. His understanding of quality was different then the readers ones.  

(source: amazon.com)

2. The third Wheel

Gojko’s lesson learned was that we should aim to create the right high quality product but that this is only the beginning. With the two wheels of Sprints and Daily work we only address our internal point of view. We need to make sure that we have delighted customers who are willing to pay for our product and like to use it. 

Therefore we need to add a third wheel powering the other two - the business measuring the satisfaction of the end user.

In my opinion, this is were we will see a future connection between requirements engineering and idea behind ‘The Lean Startup’ of  Eric Ries.

This is also in alignment with the quote (can’t remember the exact words) from Jim Highsmith where he challenges business: If you want us (development) to measure our productivity you (business) need to measure the benefit for the company. 

(source: Gojko Adzic)

3. Agile Testing Quadrants

I am a big fan of the Agile Testing Quadrants which were first described by Brian Marick in 2003 and became famous through the ‘Agile Testing’ book of Lisa Crispin and Janet Gregory. 

The quadrants Q3 and Q4 which are described as to ‘Critique the Product’ are in Gojkos mind wrong as they are still in house before the product hits the market. Essentially we test our process and not the product. We test the adherence to the agile requirements, not how satisfied our customers are. In this regard it should be renamed ‘Critique Process’.

(source: Brian Marick)

How could we then integrate the ‘Critique Product’ testing? I had a great talk with Janet Gregory about how this could be visualized but there is nothing firm yet. We talked about various add-ons and shapes. 

Final thought

For me the circle from Agile to Business and Business to Agile is slowly starting to close - the time to merge management and development has the chance of becoming reality.

I for myself, will dive straight into learning and using Impact Mapping ....

Enterprise Team Spike

When faced with new technology or other not well understood programming problems we like to implement a spike. What is a spike? I like the definition from  

http://www.extremeprogramming.org/rules/spike.html

Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only address the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate.

Well, this spike is of technical nature and does an excellent job to mitigate technical risk. However, I am suggestion another type of spike:

Enterprise Team Spike

What do I mean with Enterprise Team Spike? Before answering this, let’s look at why a spike is a good thing. In my opinion it sheds light on dependencies, weak spots and all other kind of problems. During this discovery process it creates a possible path and provides alternatives. It mostly generates knowledge of how to solve the problem in the given context. So, it is all about generating information and to extract knowledge. How could information and knowledge help us in an enterprise team spike? In Scrum we favor cross-functional teams featuring all skills needed to deliver a done, high quality product increment at the end of the Sprint. Sounds good and works even better when we really do have a cross-functional team. The reality is that too often we have external dependencies to other systems. In large enterprises this could be an ERP, CMS or any other back end system. Typically, those departments we are depending on aren’t working in iterations and increments but with one or two releases a year in a strict serial defined process. In short we cannot be really be done at the end of the Sprint unless it coincides with a release of such a department (and their deliverable actually works out of the  box).

An enterprise team spike is not of technical nature but addresses the team's skill composition. In an enterprise team spike we identify all the skills we need from the very top to the very bottom and aggregate these into our development team. I am sure that once you start to pull this thread all the way out you will discover far more dependencies and skills than you actually thought possible. Once you have this knowledge we can start the HR game in order to get the right people into our team. In my experience this is the biggest problem as we fight existing company structures and believe systems, and worse, attack long established empires within the corporate empire.

It will be a long battle, but once you have the enterprise team spike in place you have a proof of concept that shows how to generate value quickly and reliably. 

In contrast to the technical spike, this spike is absolutely of production quality and must not be thrown away! 

Multitasking vs a 100% Commitment

I recorded a small webcast to visualize the difference between multitasking and a 100% commitment and how this can lead to functional releases - essentially to being agile!

Enjoy,
Ralph
effective agile.

Creating an ATDD Ready Sprint Backlog

The arcticle about 'Creating an ATDD Ready Sprint Backlog' can be found here 
Enjoy,
Ralph

Ralph Jocham is the founder of effective agile. GmbH 

effective agile. believes that agile is more than just working in iterations, doing a daily standup or writing a unit test after the fact.

effective agile. believes that people are the most important part of a successful project and that we should focus on ways to enable them.

effective agile. believes that the world for knowledge workers is changing faster than ever. Only by harnessing the skills of each individual and putting trust into them, technology companies are able to survive.

effective agile. believes that we have to address our current believe system and that we need to challenge everything.

The Separation of Power in Scrum

There is one element in Scrum which I really appreciate. It is the separation of power in Scrum. 

What exactly do I mean with this? Democracies are based on the separation of powers they require.

• Legislative
• Executive
• Judicative

Each one has their rights and responsibilities. The other two watch out and make sure, that third doesn’t abuse it’s power.

In totalitarian governments this is not given. One entity reigns over all three. The usual result is that a few benefit and many suffer - from individuals to whole economies.

What does this have to do with Scrum. Well, nothing - at least at a first glance. But if we apply this concept to classical management, the project manager has the possibility to act as a dictator. 

He or she can decide about all three elements: scope, schedule, people.

The image above is the incomplete ‘iron triangle of quality’. It tells us, you can choose two out of the three, the third has to give. For example, if we have a certain amount of scope to implement by a given date, we need to adjust the number of people working on it.

If all three are set then the quality of the product under development will be sacrified when things get tough. Quality is the forth hidden element. Often the manager tries to convince us about the attainability of the goal with sentences like ‘I know it is aggressive but …. ‘, ‘You are not a team player ….’ and more. 

Quality dies first on every software project. It is not transparent per se, it won’t show until very late in the project or even until the product has been released. This manifests in very high TCO (total cost ownership). Eventually the developers require to rewrite the piece of sh.. garbage software. (see my blog Resetting the Shitty Counter)

How is this handled with Scrum? In Scrum the Definition of Done (DoD) states certain attributes or activities which have to be present in order to guarantee a high quality, potentially releasable product. The compliance of the DoD is paramount to a high quality product with happy customers and low TOC. Now Scrum is not immune to crunch times, times when the Product Owner (PO) is tempted to push the Development Team a little further. In those situations it would be just to easy to abandon the DoD and reduce quality to keep the date and make the Product Owner happy.

This is when the Scrum Master comes in. She will make sure that the DoD stays enforced and keeps the PO at bay. Essentially she protects the people (Development Team) so that they can work in the agreed way and thereby create a high quality product. 

In Scrum the Product Owner has the right to decide which feature gets developed in which order. His tool for that is the Product Backlog.

and the Scrum Master ensures that the Delelopment Team has the right to estimate the work according to the Definition of Done and to implement it according to the Definition of Done.

The separation of power protects the Development Team and allows it to deliver high quality product increments throughout the project. This sustainable approach guarantees high quality software with high ROI, low TCO -- easy to maintain, easy to support, easy to enhance -- for a long time. Best, you should see happy, engaged developers.

In the end everybody wins!

The 1000 students challenge (2)

In May of last year I was able to run my first Pay It Forward Scrum Training at the University of Bern in Switzerland. I had blogged about this event there:  The 1000 Students Challenge

Last week-end I had the chance to do the second run at the University of Applied Sciences (FHNW) in Brugg Switzerland. 20 students volunteered their week-ends to learn about Scrum by attending the Scrum.org Professional Scrum Master Training or short PSM. It was great fun for them and myself and it is good to know that 20 future IT specialists will join the workforce pre-equipped with Agile and Scrum.

967 more to go ...

PS If you are interested in hosting such an event at your institution please contact me at www.effectiveagile.com

Cross-Functionality in Scrum

Scrum recommends that a team should feature all the skills required in order to deliver the releasable product increment by the end of the Sprint. 

Why is it a good thing to have all the skills needed? It is all about dependencies. We try to design our software systems to be loosely coupled and highly cohesive. The same principles apply to team composition. We want our team to be like a special unit, self sufficient and able to deliver on the chosen assignment.

So, what would happen if one significant skill is missing from the team? The team will have a strong external dependency and will need to ask for support from external sources. This is a huge risk. Will the team get access to the person at the right time for the right duration? This creates an additional drag factor and affects the delivery date or reduces the scope of the product to be delivered.

Scrum does not require cross-functional teams, it only recommends them. In practice they have shown to be a significant boost for productivity. Especially in combination with self-organization.

Often it is misunderstood that cross-functional means that any person in the team needs to be able to do all the upcoming work. This is wrong. The unit that needs to be cross-functional is the development team. The dev team has the responsibility to self-organize in order to maximize the usage of its skills.  Hence, the team might be composed of specialists only, however the sum of the individuals needs to possess all required skills.

Nevertheless, as described above, if you only have specialists then you will have rather large teams, as for every skill you will need at least one developer. This will cause larger than needed teams and probably all other kinds of problems: part time team members based on FTE mathematics, work organized by activity not by feature, bad ‘unskilled' estimates, ...

Therefore agile teams favor generalists, developers with a rounded and versatile skill set. I like to use the term specialized generalists, strong all-rounders with one top notch special area.

The Weight of the Christmas Cake

At my daughters school they organize a charity event every year. There are all kinds of different foods, games and lotteries were you can spent money for the good cause. Since it is a british school the mandatory guessing of the Christmas cake weight must not be forgotten. 

In Agile and Scrum we praise ourselves about our estimation skills. It is not that we claim to be infallible. No, we also claim that laws in mathematics help us to be precise. One in particular is of interest: The law of large numbers.
The cake weighing proved to be change to put this practice under test.

This year we had 45 guesses and the weight from all the guesses is 3'742 kg. The real weight was 3'520 kg. The guessed weight is 94.1% accurate. Pretty impressive!

Agile A3 Sprint Report

I really enjoy working with A3 Reports. They have the habit of making you to distill out the crucial information, to really drill down.

There are different kinds of A3 reports. The book 'Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System’ describes three different report types. Problem-, Proposal-, and Status Report. The Problem Solving is the one I use most often.

So what is an A3 report. A3 Reports are size limited and have to fit on an A3 size of paper (for US folks, it is 11.69 × 16.54 inches). The size limitation requires to only present important informations. Furthermore, the use of charts, graphics and other none textual descriptions is highly encouraged. The less words the better. Since the Problem A3 Report describes the current and the target situation they serve as excellent PDCA (plan do check act) tools.

In my profession as Scrum coach, I grew tired of all the different and bureaucratic status reports. Usually the decision makers require lots of text and a traffic light. The text does not get read and all decisions are based on a single color. So, my idea was to create an A3 Report which is hardly text and more differentiated then only one color. Providing a quick and easy way for more information width. 

This is how it looks like:

Top Left - Sprint Burndown

Current Sprint burndown. Blue remaining work in hours, Green remaining Story Points

Top Right - Release Burndown (Burnup in this case)

Up to date, including last Sprint, release burnup

Bottom Left - Risk list 

Up to date, risk list a la Frederic Brooks. New risks are continuously discovered and either handled by outside help (i.e. by the Scrum Master) or they get put into the Product Backlog and mitigated when the Product Owner puts them into a Sprint. The risk list is dynamic and subject to change from Sprint to Sprint. (*) Mitigated risks are kept on the list.

Bottom Right - Open Bugs

Up to date number of open bugs. If I can have my way on a project, the 10-Finger-Rule applies. The moment you run out of fingers to count bugs, you need to fix bugs first. This guarantees clean, maintainable and sustainable code. If a bug is rather tricky to fix, it can be put into the Product Backlog analog to a risk. Again, the Product Owner then schedules the fix, if she sees it to be appropriate. Also, this avoids the growing number of bug triage meetings towards the end of an project (**). If you work on an legacy project with X bugs, the rule changes to X+10. Done right, X will decrease over time and product quality will go up.

(*) On many projects the institutionalized company process requires a risk list. So, at the early beginning of the project a risk list is compiled, checked off on the check list and then put into a drawer. No transparency and accountability.

(**) On many projects you you have severity levels from P1 to P4. With P1 being worst and P4 minor. Usually, you have a company mandate, that no software can be shipped with open P1 and P2 bugs. Guess what ... in the growing number of meetings after each bug fixing cycle, panic tends to creep up. The human reaction is to ‘mis’-label P2 as P3. Problem fixed, process followed.

An Agile Transition done Right

A little over a year, I kicked off an agile change program at a leading swiss devices company. Two weeks ago, I had a chance to visit them during an open house on their new premisses.

This company was fully committed to walk the talk, they decided to do what needed doing.

In August 2010, we started of with a five day PSD (Java) Scrum.org training. I trained 12 very strong developers of various expericene levels. This training was intended to ascertain whether they really want to work in an agile manner. Brave move from management, but to no surprise the developers fell in love with Agile and Scrum and were hooked on day three of the five day training. This training is excellent!

After the developers gave their thumbs up, it took about a month to set everything in motion. This is is a mid size company with over 300 employees at their head quarters. Once we got the ball rolling the company was ready. They had torn down walls to create right sized team rooms, organized great Story Boards or shall I say walls. Again, they were serious. In the first two weeks, apart from coaching the teams, I trained ten people as Scrum Master (PSM) and ten more as Product Owner (PSPO). We didn't really know who is going to fulfill which role, we just knew that the future person would be coming from those groups. Also, the intention was to really create an agile culture and what could be better then to reach out and train and convince as many people as possible. After that I gave about ten introductions to Scrum, each lasting about two hours; the target audience was marketing, sales, support and other departments on the projects periphery.

For the frist two sprints -- 2 weeks in duration -- I was coaching a 100%. Essentially being a Scrum Master. After two Sprints I was only around at the beginning and at the end of the Sprint. During my absence the teams had the chance to walk on their own without training wheels, getting first-hand experience into when they started to struggle. After 5 Sprints the teams decided on their own who should replace me as the Scrum Master. In the remaing four Sprints, I worked closely together with my replacements. My presence became less and less. At the end it was about 20% of the time. By the end of last year, they didn't need me anymore and I moved on.

This whole engagment lasted about four month in calendar time and about two month of coaching from my side.

Now, during the open hours, I had the chance to meetup with a couple of guys from the old teams and we chatted a little. It was a great to see, that all of them really had drunken the agile CoolAid. They did not roll back one inch - instead they kept on pushing hard. Now, there are three teams and more coming soon.

For me and my company effective agile. this coaching approach has become my favorite modus operandi for change engagements.

By the way, the last two releases were two and six weeks early! It humbles me to know, that I was the initation.

The right Sprint Length

In order to keep the blog short here is the answer:

     Let the Development Team decide

If you are curious why this is the answer then keep on reading.

Again and again, I hear from outsiders that we should extend our Sprint length. Usually, I like to work with two weeks. When I ask for a reason, the answer is typically the following: 'With all the meetings you don't have time to do real work, so I think you should add another week or maybe even two!'.

Interesting statement, but completely wrong and obviously from someone who does not understand Scrum. 

Here is Why:

1)  Apart from the 15 min Daily Scrum all meeting durations are proportional to the Sprint length. The Product Backlog grooming which is paramount to an executable Product Backlog and often neglected in literature is about 5% of the Sprint length in average by my experience . 
Here a chart showing how the meeting time per day actually slightly increases when the Sprint is longer

2)  All of the above meetings are real work and important. They are the empirical process controls you need when you work in complex environments and domains. Especially the Daily Scrum is the catalyst for an effective and hence productive working day. The Daily Scrum is not disruptive it creates focus and team spirit. I just read the slides of a recent talk of Tobias Mayer. He stresses that Scrum is essentially five things.

• self-organization
• collaboration
• focus
• alignment
• rhythm

Each of these points is addressed by one or even a couple of those meetings. 

3)  The rhythm is to be discovered by the team. In my experience two weeks is a great fit for most environments but if the team cannot find it's own rhythm and cadence within a given Sprint length, then let the team decide. Often they adjust their defined working rules, and sometimes they decide a different Sprint length is what they need. If so, let them choose whether they want to go shorter or longer. The rhythm is a function of the domain, the planning horizon, team configuration, dependencies, other Scrum Teams, and more. It cannot be decided by an outsider.

4)  Finally, the underlying problem is, that people with that recommendation are usually bottlenecks themselves. It is a latency issue by those very individuals. When problems do pop up it takes too long for them to turn around. Since a loss of a couple of hours or even days is more visible or shall we say dramatic in a two weeks Sprint then a four weeks Sprint. Those 'well' intended recommendations try to mask the problem and thereby slowly turn the project into a ScrumBut.

Scrum is Open for Extension and Modification

Today, Scrum.org and Scrum Inc. are announcing a formal model for modifying and extending Scrum. Scrum's creators, Jeff Sutherland and Ken Schwaber, are inviting practitioners from around the world to contribute to Scrum's future.


Scrum was first developed 15+ years ago, and it has been evolving and adapting ever since. Informed by their experiences and those of the Scrum community, Jeff and Ken have carefully codified the framework in the Scrum Guide, which documents the basic rules, artifacts, and events of Scrum.

Today's announcement marks a new era in Scrum's evolution by making available a public mechanism for providing feedback on the Scrum Guide and a model for proposing extensions to the basic framework.

The formal process for proposing and integrating changes into Scrum is available online at Scrum.org. To learn more about Scrum, or proposing your own contribution to Scrum, you can use the following links:

Read It - http://www.scrum.org/scrumguides/
Change It - http://www.scrum.org/scrum-guide-proposal/
Extend It - http://www.scrum.org/scrum-extensions/

We look forward to hearing from you.

Capacity: Help with Excel

For every Sprint Planning the capacity, the hours available for the team is an important ingredient. Usually, this is rather straight forward and easy to do. At my current project we have two teams. Each team is cross-functional, i.e. being able to deliver a piece of done software. However, in this case, the skills are very different, so that the overall number of available hours can be deceptive as there might be 120 h of development tasks and only 80 h available. We actually run into this problem when we got additional business analysts. The overall capacity went up so that we could commit to more user stories. As a result, we had far too much programming work and not enough analysis work.

Now, we break the capacity down per skills we need in our teams. Once Sprint Planning Two is over, we add up the hours per skill and see if we are still in the range. If yes - great! Otherwise the Dev Team and Product Owner self-organize and figure out a way to handle it.

Long story short - here is the link to the Excel sheet. It is not fancy but does a great job for the current project.

Enjoy!