Tag: scrum

Scrum Skills Series, “Retrospectives, part I”

Posted on by berglundhenrik

For a while, I have been thinking about writing a series of papers with hands-on advice on how to use Scrum. Note that I don’t claim to know exactly what your environment looks like and how you should best make use of Scrum, only you can figure that out.

No, the idea with the paper’s is to share collection of techniques that I have found to work well. If you find them interesting, you can try them out while you are experimenting to get to a way of working that best fits your current situation.

The format of the papers has been choosen to be somewhere inbetween a blog-post and a book. I will try to make them small enough so that many people will find time to read them, yet long enough to contain some useful information.

So, lets see how it works out! Today I posted the first paper: “Retrospectives, Part I – Getting Started”

I hope the paper will be useful both for newly started teams and for existing teams that are interested in improving their retrospectives.

If enough people are interested, I have a series of papers planned out covering various aspects of starting up Scrum teams and how to keep finding improvements.

The paper can be downloaded from here

So, let me know what you think!

Scrum, getting lost and asking for help

Posted on by berglundhenrik

Once I got lost driving to the airport and kept driving for so long before asking for directions so that I missed my flight home…

With people in nothern Europe returning from their vacations I have two questions for all of you that are using daily standup meetings in your teams:

1. How long were you driving this vacation before admitting being lost and asking someone for directions?

2. Did anybody report an impediment being in their way at your daily Scrum this morning? (This is question 3 in a standard daily Scrum meeting)

I recently read an article by Yves Hanoulle where he comments on how hard it is for most of us to ask for help. Either we don’t want to bother others or we want to be able to work things out by ourselves. And it may take a while before we realize that we might need help.

Yves’ advice is to change the third question in the standup meeting to “where do you need help?”. This sounds like a great idea.

I think I would like to try a variation and change it to “With what could someone best assist you?”. If you do that everyone has to think of something, and you cannot routinely just say “all is fine, no help is needed”

Try it! I know I will!

Passed Certified Professional Scrum Master II

Posted on by berglundhenrik

Got the news today that Ken Schwaber had graded my responses to the essay style questions and that I passed the Professional Scrum Master II exam! So far only about a dozen people in the world have passed the level II certification exam and I’m the only person in Sweden it seems!

I have worked in agile teams for more than ten years now and as a full time agile coach for several years, so why did I bother to take this exam?

For one thing, I thought it would be a nice challenge! I find that trying to figure out the answer to tough questions always deepens my understanding. In fact a lot of what I learn, is from people asking me questions. So, I thought it would be interesting to work through some questions considered important by the co-founder of Scrum, Ken Schwaber.

Well…boy did I get what I asked for! Almost needed to use to full two hours to complete the test and some of the questions were really tough! I passed with a 95% score though. I misread one of the questions and I’m not sure that I agree in a few cases where my answer was rejected, so I’m quite happy with that!

Besides the challenge, I took the test just to check it out, and I was very pleased with what I saw. Until now ScrumMaster certifications in the Scrum community have been handed out without the person being certified having to do anything except to stay in a room for two days. I think the new written ScrumMaster assessments from Scrum.org are a welcome change to that! A lot of people, like me, will get more motivated to grasp the subject a bit more thoroughly before taking the test and that will be a good thing! Especially in the case of the level II assessment, where a lot of questions are in essay style, I also think that the assessment result can be an indicator of knowledge.

Another thing that Scrum.org is doing is widening the spectrum of training offered. In addition to ScrumMaster skills, you can now also get training in skills needed as a developer on agile teams. Other types of skills like facilitation and team skills are also mentioned as possible candidates for Scrum.org offerings if I remember correctly. This addresses a main problem in real life Scrum implementations today. People may have a basic understanding of Scrum, but they have not yet experienced what types of issues that can be resolved by adding technical practices for example from eXtreme Programming, XP.

Nothing has affected the spreadin of agile so much as the strength of the Scrum brand. As unfair this may seem to the other fine ideas in agile this is a fact. Hopefully the new Scrum.org organization with its fresh ideas will now contribute to getting the level of agile actually practiced in real developments teams to a higher level.

Move fast, travel light

Posted on by berglundhenrik

Traditionally developed software does not age gracefully. In fact, on average, it only takes about five years for newly developed software to deteriorate to a state where it is no longer economically feasible to maintain it. I.e. the cost of adding new features is larger than the income that the new features would generate.

Why does this keep happening? The answer is that through the years, business people have learned that developers are lazy. When developers whine about impossible deadlines it is just a matter of telling them that it needs to get done, or else… and then they will do it.

Developers, on the other hand, have learned many powerful ways to “speed up” the development when presented with impossible deadlines that “have to” be met. They can skip making the code readable, skip the unit testing, skip refactoring, skip the load and security testing, skip the code review, skip the documentation, … In this way they can easily double the speed at which they produce crap.

Of course the drawback of these techniques is that they do not really produce usable software. So a lot of time will have to be spent on fixing trouble reports. Typically 15-60 times as much as it would have taken to build quality in from the start. Also, over time, the code base gets more and more messed up and harder to modify. Thus, development will get slower and slower.

Naturally a project like this will overrun its initial schedule & budget. After a few years it will no longer be possible to maintain the system and the company will be in serious trouble.

The way to make this madness stop is to shift to iterative, value-driven development. I.e. each release is split into a number of iterations. Each iteration a number of features of value to the users will be completely developed. The most important thing with this is to establish a “definition of done”, a detailed specification of what it takes for a specific feature to be considered as “done”. If the definition of done states that quality shall be built in from the start, it will no longer be possible to “speed up” development by reverting to produce crap instead of working software. Business people will not be able to tell developers to work faster anymore, so instead they will need to start selecting the features for each iteration/release that give the maximum return on the investment.

One interesting thing about that is that an average requirements specification contains 64% features of little or no use to customers. These features will never be selected for implementation when doing value-driven development and thus the project time may be cut in half.

Here are a few ideas on what to put into your definition of done:

  • Code shall be covered by automatic units tests with at least 90% branch/condition coverage
  • The design shall have been refactored to integrate the new features in the cleanest possible way
  • There shall be no duplicate code
  • Coding standards shall have been met
  • The code shall be easy to read and understand
  • Documentation required for future maintenance shall be done
  • Cycliomatic complexity of the code shall be < 10
  • Maximum levels of nested code (if statements etc) shall be 3
  • The code passes some lint-type tool at some specified warning level
  • All automatic tests have been run with a dynamic checking tool such as Purify
  • The new feature shall be covered by automatic customer acceptance tests
  • All non-functional requirements applicable to this feature shall be covered by automatic tests
  • User documentation shall be done
  • Release documentation shall be done
  • The feature shall have been accepted by the customer
  • The feature shall have been installed at the customer site

Pair programming is very useful to make it possible to maintain extreme dicipline like this under pressure. For the same reason, whenever possible, try to cover your definition of done with automatic tests. Some useful tools for this are BullsEye, Lint, Purify, CloneDetective, …

The list above is just a quick example. You will be able to add a lot more to your list, and yet most teams will not be able to meet the example list initially. But just get started with whatever you can manage today and keep working on it. With time you will be able to expand your definition of done so that there is really nothing left to do when the code is marked as done.

When you get to that point, you will always be operating at maximum speed since there will be no old baggage slowing you down. At this point, few of your competitors will be able to keep up with you. That is a good place to be…

– Henrik

Co-located teams

Posted on by berglundhenrik

One of the best ways to get started with an effort to get more agile is to co-locate teams, creating “war-rooms” for them to work in. Studies like this show that co-locating teams at least doubles productivity. In the study above, the teams that used the new facilities after the study was finished actually did even better, doubling their productivity again, performing four times better than the company baseline. Also, both the teams and their sponsors were in general very satisfied with the experience.

How can such a large improvement be possible? Being co-located makes very high bandwidth communication possible, enhances learning and supports creating teams that really jell together. Remember, the bottleneck in software development is learning and the best work is carried out by small self organizing teams.

In the research on co-locating there are also some really interesting findings on what happens when people are not “at hand”. Communication drops of significantly it seems, right when people are first out of sight. Being 30 meters apart is essentially the same as being truly remote. One would think that use of email, phone calls, and video conferences would make up for distance in today’s high tech workspace, but in practice this is not so. Professor Thomas J. Allen puts explains it like this: “We do not keep separate sets of people, some of which we communicate in one medium and some by another. The more often we see someone face-to-face, the more likely it is that we will telephone the person or communicate in some other medium.”

So, if you feel up to trying out some co-located teams, here are a few tips:

  • Provide facilities for teams to work in, but don’t co-locate a team until they request this. Remember, the basic rule for all change is that it does not happen unless everyone involved individually takes the decision that the new way working is of direct personal benefit to them.
  • People may feel that giving up a private office for co-located space is a loss of status. To handle this, a co-located space must be made an attractive option. Working in a well designed space like this should be made feel like a privilege, not as a cheap alternative to offices. So use your best spaces and don’t crowd them. Provide windows, air, plants and lots of first class work equipment like whiteboards and computers.
  • Have just one team (i.e. ideally < 10 people) in each room. Agile teams get noisy and that is the way it should be. Provide noise isolation to prevent disturbing other teams/persons.
  • Supply adjectant conference rooms for meetings and hotelling cubicles for work away from team, making private calls etc.
  • Make sure desks support pair programming by having space for two people working side by side, shifting keyboard back and forth.
  • Encourage each team to write down and maintain its own set of rules on how to work together. This could include work hours, handling phone calls outside of war-room, no speaker phones, phones on vibrator mode, which type of discussions to hold in the war room and which should be taken to conference rooms, signals for indicating that a person wants some privacy etc
  • When co-locating and shifting focus from individual work to teamwork, remember to also update your performance evaluation systems. Bonus goals and other performance metrics need to be measured at team level (or in general, one organizational level up) to prevent sub-optimisation.

So, get right to it and tear down those office walls now…for people working in solitude refining the latest statistics on the wheat production in the EU, offices may be great. For software development it is simply not good enough anymore…

– Henrik