Inductive Bias

In the last post I promised to share some more information on techniques I came across and found useful under an increasing work load. Instead of taking a close look at my professional calendar I decided to use my private one as an example - first because spare time is even more precious then working hours, simply because there is so few of it and secondly because I am free to publicly scrutinize not only the methods for keeping it in good shape but also the entries in it.

I am planning to split the article in four pieces as follows as keeping all information in one article would lead to a text longer then I could possibly expect to be read from beginning to end:

Part 1: Traveling minds - how to stay focussed in an always-on community. Part 2: Tracking tasks, or: Where the hack did my time go to last week? Part 3: A polite way to say no - and why there are times when it doesn’t work. Part 4: Constant evaluation and improvement: Finding sources for feedback. Part 5: A final word on vacation.

Several years ago, I had no problem with tasks like going out reading a book for hours, working on code for hours, answering mails only from time to time, thinking about one particular problem for days. As the number of projects and tasks grew, these tasks became increasingly hard to accomplish: Writing code, my mind would wander off to the mailing list; when reviewing patches my mind would start actually thinking about that one implementation that was still lingering on my hard disk.

There are a few techniques for getting back to that state of thinking about just one thing at a time. One article I found very insightful was an essay by Paul Graham. He gave a pretty good analysis of thoughts that can bind your attention and draw them away from what should actually be the thing you are thinking about. According to his analysis a pretty reliable way to discover ideas that steal your attention is to observe what thoughts your mind wanders to when you are taking a shower (I would add cycling to work here, basically anything that lets your mind free to dream and think): If it is not in line with what you would like to think about, it might be a good time to think about the need to change.

There are a few ways to force your mind to stay “on-topic”. Some very easy ones are explained in a recent blog post on attention span (Thanks to Thilo for the link):

• Organising your virtual desktops such that applications are sorted according to tasks (one for communication, one for coding project x, another one for working on project y) helps to switch off distraction that would otherwise hide in plain sight. Who wants to work on code if TweetDeck is blinking at you next to your editor? In contrast to the original author I would not go so far to switch off multiple monitors: Its great to have your editor, some terminals, documentation in the browser open all at the same time in one workspace. However I do try to keep everything that has do with communication separate from coding etc.
• Train to work for longer and longer periods of time on one task and one task only: The world does not fall apart, if people have to wait for an answer to your mail for longer than 30min - at least they’ll get used to it. You do not need to take your phone to meetings: If anything is starting to melt down there will be people who know where you are and who will drag you out of the meeting room in no time. Anything else can well wait for another 60min.
• When working with tabbed browsing: Don’t open more tabs then you can easily scan. You won’t read those interesting blog post you found four weeks ago anyway. In modern browsers it is possible to detach tabs. That way you can follow the first hint of keeping even the web pages sorted on desktops according to activity: You do not need your time tracking application next to your editor. Having only documentation and testing application open there does help.
• Keep your environment friendly and supportive. Who has ever shared an office (or a lecture at university back when I was a student) with me knows that close to my desk the probability of finding sweets, cookies, drinks and snacks approaches one. Being hungry when trying to fix a bug does not help, believe me.

One additional trick that helps staying just focussed enough for debugging complex problems is to make use of systematic debugging by Andreas Zeller (also explained in Zen and the Art of Motorcycle Maintenance). The trick is to explicitly track you thoughts on paper: Write down your hypothesis of what causes the problem. Then identify an experiment to test the hypothesis - you should know how to use your debugger, when to use print statements, which unit tests to write and when to simply take a very close look at the code and potentially make it simpler for that. Only when your experiment confirms that you have found the cause of the problem you really have identified what you need to fix.

There are a few other techniques for getting things off of your head that are just there to distract you: If you ever have read the book “Getting things done” or seen the Inbox zero presentations you may already have an idea of what I am hinting at.

By now I have a calendar application that works like a charm: It reminds me of meetings ahead of time, it warns me in case of conflicts, it accepts notes, it has an amazing life span of one year and is always available (provided I do not forget it at home):

- got mine here That’s for organising meetings, going to conferences, getting articles done in time and not forgetting about family birthdays.

For week to week planning we tend to use Scrum including a scrum board. However that is not only for planning as anyone using Scrum may have expected already.

For my inbox the rule is to filter any mailing list into its own folder. Second rule is to keep the number of messages in my inbox to something that fits into a window with less than 15 lines: Anything I need for further reference (conference instructions, contacts, addresses that did not yet go into my little blue book, phone numbers not yet stored in my mobile phone) goes into its own folder. Anything that needs a reply is not allowed to stay in the inbox for longer than half a week. For larger projects mail gets sorted into their own project folders. Anything else simply goes to an archive: There are search indexes available, even Linux supports desktop search, search is even integrated in most mail clients. Oh and did I mention that I managed to search for one specific mail for an hour just recently, though it was filed into its own perfectly logical folder - simply because I had forgotten which folder it was?

To get rid of things I have to do “some time in the near future but not now” I keep a list in my notebook - just so my mind knows the note is there for me to review and it knows I don’t forget about it. So to some extend my notebook is my personal swap space. One thing I learnt at Google was to not use loose paper for these kinds of notes - a bound book is way better in that it keeps all notes in one place. In addition you do not get into danger of throwing notes away too early or mis-place them.

The only thing missing is a real product backlog that keeps track of larger things to do and projects to accomplish - something like “I really do need to find a weekend to drive these >250km north to the eastbaltic sea (Thanks to Astro for pointing out the typo to me - hey, that means there is at least one guy who actually did read that blog post from beginning to end - wow!) and relax”

Free Software, Freetime, Hacking, Software Foundation Getting things done, Scrum

Probably not too unusual for people working on free software mostly (though no longer exclusively) in their spare time, the number of items that appear in my private calendar have increased steadily in the past months and years:

• Every three months I am organising the Apache Hadoop Get Together in Berlin.
• I have been asked (and accepted the offer) to publish articles on Hadoop and Lucene in magazines.
• There are various conferences I attend - either as speaker or simply as participant: FOSDEM, Froscon, Apache Con NA, Devoxx, Chemnitzer Linuxtag - to name just a few.
• For Berlin Buzzwords I did get quite a bit of time for organisation, still some issues leaked over to what others would call free time.
• I am mentoring one of Mahout’s GSoC students which is a lot of fun.
• At least I try to spend as much time as possible on the Mahout mailing lists keeping up with what is developed and discussed there.

There are various techniques to cope with increased work load and still find enough time to relax. Some of them involve simply remembering what to do at the right time, some involve prioritization, others deal with measuring and planning what to do. In this tiny series I’ll explain the techniques I employ - or at least try to - in the hope of getting your feedback, and comments on how to improve the system. After all, the most important task is to constantly improve ones own processes.

Freetime, Hacking, Scrum Free Software, Getting things done, Scrum, Software Foundation

“But Scrum involves so many meetings - we already have meetings like all day and don’t get to coding anything.” - “However we do need transparency and communication to build great software.” - “Actually scheduling and re-prioritising items during scrum planning takes so much time.” Does that sound familiar to you?

What if you could fit Sprint Review and Planning I for a team of three people doing three week sprints into one hour? Impossible? Well, not quite so. As always there is a very easy trick: Be prepared.

Before the review re-visit all items you have accomplished. Get the application into a state that makes it easy to demonstrate all new features to your product owner. If you are a team working on internal projects with many internal clients - get one of them to test our the new features early on (as in way before review) and get their input onto the table.

Get a list of all items up on a whiteboard. Then with the PO work you way through these items, either demonstrating them or referring to what the “real client” said about the feature. After that compute the velocity of your past sprint.

Then go over to the list of still to be done items. (You did estimate them in separate estimation meetings already, didn’t you? You also got the prioritised by your PO beforehand, didn’t you?) According to the computed velocity simply check out what you can do in the upcoming sprint.

After that team and PO are done. Guess what: Working with pen, whiteboard and paper did speed up our process considerably. After all, these are meetings of at least four people: Don’t want to waste working hours of four people by not using the fastest and most flexible planning method.

So - who’s responsible for getting all this information up? And - if using a digital planning tool, who is supposed to get it back into the tool? Trivial: It’s the scrum master’s job to provide all help and tools to the team to make it a high performing team. It’s way better to spend 2 extra hours preparing and “tidying up” the sprint planning than have four people spend 2 hours (total 6 vs. 8 hours) in a sub-optimal meeting.

Together with estimation meetings for me this means that each sprint one to two days go into organisational work. Still this is very low overhead compared to what the team is able to accomplish in that time.

Scrum Scrum

A few months ago I entered a new team of until then two software developers. Being so small and with a rather busy product owner, until then people had followed the rituals of Scrum only loosely. When starting to work on a new component the three of us decided to change a few thing several weeks ago:

• We would setup infrastructure to be somewhat similar to what we knew from Apache projects: All issues to be accomplished were to be tracked in our issue tracker. We would have a dev list that mirrors whatever goes to JIRA, a commit list to mirror whatever goes into svn and a user list.
• We would try to follow Scrum rituals more closely: Dailies were re-introduced, we setup estimation meetings and got a cooking timer to stick with 60min per meeting, review and planning was supposed to be prepared and done with paper and pens on a whiteboard. After each planning we would have a planning II as well as a retrospective to improve our processes.

After the first weeks of following these ideas we did notice several improvements that are going to be described in upcoming blog posts.

Lets start with the first (trivial) change we made: Introducing a commit mailing list. With developers sitting all together in one room, communicating openly and regularly this may seem like a huge overkill. However there are a few changes that brought to how we develop:

People would suddenly start to think about what goes into svn: Being very obviously publicly readable, commit messages became much more readable, explaining what’s going on. Changes would be checked-in only if they belong to one logical change set. In return others would review what was checked in sort of automatically - spotting problems or questionable code and configuration very early. Changes that got done were made transparent to other team members very easily.

Of course the information is available anyway. However to be honest - I never really closely check each change set that got committed after issuing an svn up. Getting the stuff pushed to my inbox hugely improved the situation while still keeping a faster development cycle than when working with a review-before-commit model. This is especially important for cases where only smaller adjustments are being made. Where larger refactoring steps were necessary we would still get the code reviewed by our colleagues before checking it in.

Scrum Scrum

After Berlin Buzzwords is over now, I thought it might be time to update a formerly published velocity graph. If you have been following this blog during the past few months you may know already, that we are using Scrum @ Home for several months already. I even published results of a Scrum Nokia test earlier this year.

Today I created another one of these nice velocity charts. What is interesting about this graph are two things. First of all: There are two spikes in the velocity graph. As our scrum board is used only for things done during our spare time, these spikes roughly correspond to German vacation days (Christmas and Easter).

More interestingly the work load shortely before Berlin Buzzwords happend was not much higher than usual. Weekend was totally free of any work - except for meeting with friends, going to town and attending the Barcamp. A sure sign of fantastic preparation and organisation with that few tasks left to do. Julia, thanks for helping with scheduling tasks such that no panicky late-night action was needed before, during or after the conference.

Scrum Berlin Buzzwords, Scrum

Today, the Scrumtisch organised by Marion Eickmann from Agile 42 met in Berlin Friedrichshain. Though no talk was scheduled for this evening the room was packed with guests from various companies and backgrounds interested in participating in discussions on Scrum.

As usual we started collecting topics (timeboxed to five minutes). The list was rather short, however it contained several interesting pieces:

• (6) Management buy-in
• (6+) CSP - Certified Scrum Professional - what changes compared to the practitioner?
• (4) Roles of Management in Scrum - how do they change?
• (13) Coaching self-organising teams - team buy in.

Team buy-in

As prioritised by the participants the first topic discussed was on coaching self organising teams - with a heavy focus on team buy-in. The problem described dealt with transforming water fall teams that are used to receiving their work items into self organising teams that voluntarily accept responsibility for the whole project instead of just their own little work package.

The definition of self organising here really is about teams, that have no (and need no) dedicated team leader. On the contrary: leadership is automatically transferred to the person who - based on his skills and experiences - is best suited for the user story that is being implemented at any given time.

The problem the question targets is about teams, that really are not self organising, where developers do not take responsibility for the whole project, but just for their little pieces: They have their gardens - with fences around that protect them from others but also protect themselves from looking into other pieces of the project. Even worse - they tend to take these fences with them as soon as work items change.

Several ways to mitigate the problem were discussed:

• Teams should work in a collaborative environment, should have clear tasks and priorities, whould get some pressure from the outside to get things done.
• Some teams need to learn what working in a team - together - really means. It may sound trivial, but what about solving problems together: Spending one day climbing hills?
• Committments should not happen on tasks (which by definition are well defined and small) but rather on Features/ user stories. Task breakdown should happen after the committment.
• There are patterns to break user stories that are too large into multiple user stories. (Marion: Would be great, if I could add a link here )
• Teams need to be coached - not only the scrum master should get education, but the complete team. There are people interested in management that tend to read up on the topic after working hours - however these are rather rare…
• Teams must be empowered - they must be responsible for the whole project and for the user stories they commit to. In return they must get what the need to get their tasks done.
• Newly formed teams inexperienced with Scrum have to get the chance to make mistakes - to fail - and to learn from hat.

A great way to explain Scrum really is as a two-fold process: First half is about getting a product done, reviewing quality by the end of each sprint during the review. Second half is about improving the process to get the product done. Meeting to review the process quality is called retrospective.

Management buy-in

The second topic discussed was on the role of management in scrum - and how to convince management of Scrum. To some extend, Scrum means loosing power and control for management. Instead of micro-manageing people it’s suddenly about communicating your vision and scope. To get there, it helps to view lean management as the result of a long transformation:

• First there is hierarchical management - with the manager at the top and employees underneath.
• Second there is shared management - with the manager sitting between his employees enabling communication.
• Third there is collaborative management - here the manager really is part of the team.
• Fourth comes empowering management - this time the manager is only responsible for defining goals.
• Last but not least there is lean management - where managers are merely coordinating and communicating the vision of a project.

To establish a more agile management form, there are several tasks to keep in mind: First and foremost, do talk to each other. Explain your manager what you are doing and why you are working in pairs, for instance. Being a manager, do not be afraid to ask questions - understanding what your developers do, helps you trust their work. Scrum is established, however there needs to be a clear communication of what managers loose - and what they win instead.

Scaling can only be done via delegation - however people need to learn how to delegate tasks. In technology we are used to learning new stuff every few years. In management this improvement cycle is not yet very common. However especially in IT it should be.

Being able to sell Scrum to customers is yet another problem: You need good marketing to sell Scrum to your customers. “Money for nothing change for free” is a nice to read on formulating agile contracts. Keep in mind, that the only way to really win all benefits is by doing all of Scrum - cherry picking may work to some extend, however you won’t get the full benefit from it. In most cases it works worse than traditionally managed projects.

After two very interesting and lively discussions moderated by Andrea Tomasini we finally had pizza, pasta and drinks - taking some of the topics offline.

Looking forward to seeing you in F-Hain for the next Scrumtisch in April.

Scrum Berlin, management, product owner, Scrum, scrum master, scrumtisch, team

At the last Berlin Scrumtisch, @AlanAtlas gave a presentation on how he introduced Scrum at Amazon (starting as early as back in 2004). Introducing Scrum at Amazon by that time seemed natural due to a few factors:

• Amazon was and is always very customer centric. The original methodology of working backwards in time - that is starting with the press release, from there writing the FAQ and manual and finally get to the code - really made people concentrate on the product.
• Teams were sized according to the two-pizza rule: Each team is supposed to be no larger than can reasonably be fed for lunch with two pizzas. Turns out that is about five to ten people, given regular american pizzas.
• Management didn’t really care exactly *how* the job of software development was done. They only cared *that* it was done. This proved as both - an advantage as it gave quite a bit of freedom - and a disadvantage - as indifference leads to impediments in the process that cannot be easily resolved.

The goal of Alan’s team was to build an infinitely scalable, zero downtime storage system that had a web service based interface - it was the S3 team. Given the task at hand, it was clear that the task wasn’t going to be anything even close to trivial. Alan’s idea: Try Scrum on that.

He himself came to the idea after attending an Agile conference and hearing about Scrum for the first time there. Alan requested a Scrum training from his manager, who approved it, provided it took place in Seattle - close to Amazon HQ that is. Turns out, the Scrum trainer available in Seattle happened to be Ken Schwaber.

The idea of Scrum basically was spread by word of mouth propaganda: In the hallways, in the smokers lounge, close to the coffee machine. People started adopting it - with some teams doing better, some worse. Allan himself got two days a quarter to give people an introduction to this funny new methodology called Scrum.

18 months later, S3 was shipped - as a side effect, the number of subscribers to the internal scrum mailing list had increased from three to 100, there were 150 CSM graduates, still three teams using XM, reputation of scrum was mostly positive.

In January 2007 others started giving their own introductions to Scrum. Developers generally liked it, there were significant failure cases, lots of resistance and misunderstanding mostly on the management side who sometimes confused it with lean production.

In June 2008 Allen became a fulltime internal Scrum trainer. First thing organised was a Scrum gathering - in an open spaces like setup people were invited to discuss their issues and questions on Scrum.

In January 2009, about 50% Scrum usage was reached, their were 600 subscribers on the Scrum mailing list, 450 CSM graduates, reputation of Scrum was as good (or bad) as months before. However it became more and more clear that further restructuring would only be possible against a lot of resistance.

There were a few lessons learned from introducing Scrum in other companies as well:

• You cannot introduce Scrum if there is no notion of comparably stable teams (as in for at least six months, not five projects at a time per developer).
• You need permission and ownership of committments to really get going.
• You need to know at least the basics of Scrum.

There are a few factors that make introduction easier: Community matters. People need to be able to talk to each other, exchange experiences and learn from one another. Coaching matters. More support, immediate success in lots of cases is the result of getting a coach on the team. Credibility for management increases, Scrum implementation is easier understood that way, skepticism and resistance reduced. Management matters. Middle management must be part of the process. They will mess up scrum if not educated correctly. Going bottom-up works up to a point - but to go the whole way, you do need management.

For Amazon, that is the point where implementation got stuck for Allan: Management was neither interested nor really involved in Scrum. However there are some impediments that cannot be fixed w/o. Still Scrum is working to some extend - teams are still trying to get better and improve the process. So it is not really “Scrum, but”. Even going only part of the way helped a lot already.

As for the questions: There were a few unusual ones - e.g. on what to do with a team that is itself skeptical about Scrum introduction - especially if that was done by higher management. There are a few ways to remedy that: Point out success to the negative team member. Make that member a Scrum master to let him go through the process and really understand what is going on. And above all make the reasons for going that way clear and transparent. Including promises and wishes from that change.

Another question dealt with how to convince management of Scrum. Clearly better performing teams with happy developers (”you cannot buy developers with money only”) are some valid reasons.

Yet another question dealt with convincing customers. Allan’s way is to sneak Scrum into the process: Speak the customers language. If he does not like spring planning, call it a project status meeting.

Asked for cases of developers feeling like they work in a hamster wheel when doing Scrum, the general consensus was that it needs to be made sure that people do not only get more responsibilities but get the benefits from Scrum as well. Otherwise Scrum with all its numbers and measurements can be perfectly abused and turned into an amazing micro management tool.

Asked for other bay area companies using Scrum - yes, apple does so, Microsoft at least tries to. Google certainly uses the ideas, without calling it Scrum. Facebook seems not to use it. Xing (not bay area) uses Scrum. There seem to be about 50% of all software development companies worldwide who are using Scrum.

After the talk there was time to gather and have some pizza and pasta, time for drinks and discussions. I really appreciated the comments and ideas exchanged after the talk. Hope to see you all next time around.

Hadoop, Scrum Amazon, S3, Scrum

I have started using Scrum for various purposes: It has inspired the way software is developed at my current employer. I use it to organize a students’ project at university. In addition we are using it at home to get all personal tasks (preparing breakfast, doing the laundry, meeting with friends…) in line for each week.

Constantly looking for ways to evaluate, refine and improve work - I am also looking for ideas on how to evaluate which aspects of the Scrum implementation can actually be improved. One pretty common way to do this evaluation is to do the so-called “Nokia-Test”. A set of questions on the project management that gives a possibility to judge your implementation of Scrum. As an example lets just have a closer look at our “Scrum Housework” implementation.


Question 1 - Iterations

• No iterations - 0
• Interations > 6 weeks - 1
• Variable length < 6 weeks - 2
• Fixed iteration length 6 weeks - 3
• Fixed iteration length 5 weeks - 4
• Fixed iteration 4 weeks or less - 10

Currently we are doing one week iterations - planning ahead for longer just seems impossible, except for events like going to conferences or regular birthdays. So that would be 10 points for iterations.


Question 2 - Testing within the Sprint

• No dedicated QA - 0
• Unit tested - 1
• Feature tested - 5
• Features tested as soon as completed - 7
• Software passes acceptance testing - 8
• Software is deployed - 10

Hmm. Admittedly there is no real testing in place except for smoke testing for stuff like emptying the dish washer.

Question 3 - Agile Specification
• No requirements - 0
• Big requirements documents - 1
• Poor user stories - 4
• Good requirements - 5
• Good user stories - 7
• Just enough, just in time specifications - 8
• Good user stories tied to specifications as needed - 10

We do not have big documents describing how to setup the christmas tree. But at the beginning of each sprint there is a set of user stories, if needed with acceptance criteria specified. So something like “Tidy up computer desk” would be augmented by the information: “To the extend that there are no items except for the laptop on the desk afterwards and the desk was dusted”. That might probably make a 10.


Question 4 - Product Owner

• No Product Owner - 0

• Product Owner who doesn’t understand Scrum - 1
• Product Owner who disrupts team - 2
• Product Owner not involved with team - 2
• Product owner with clear product backlog estimated by team before Sprint Planning meeting (READY) - 5
• Product owner with release roadmap with dates based on team velocity - 8
• Product owner who motivates team - 10

We are both familiar with Scrum. However, due to the nature of the tasks and due to lack of people in the loop we are exchanging the role of the product owner regularly. We are still missing a product backlog - currently it is loosely defined as a pile of post-it notes with estimates put beside each item that define its complexity. So I would give some 3 points on that one.


Question 5 - Product Backlog

• No Product Backlog - 0
• Multiple Product Backlogs - 1
• Single Product Backlog - 3
• Product Backlog clearly specified and prioritized by ROI before Sprint Planning (READY) - 5
• Product Owner has release burndown with release date based on velocity - 7
• Product Owner can measure ROI based on real revenue, cost per story point, or other metrics - 10

We only have one product backlog though it is very informal. So that would make 2 points.


Question 6 - Estimates

• Product Backlog not estimated - 0
• Estimates not produced by team - 1
• Estimates not produced by planning poker - 5
• Estimates produced by planning poker by team - 8
• Estimate error < 10% - 10

Naturally those doing the tasks are those producing the estimates. Thanks to Agile42 in Berlin we now even have a set of planning poker cards: Yeah! That makes 8 points. Just as an example: Getting returnable bottles back to the shop makes for 8 complexity points, going to cinema are 16 just like storing the christmas decoration back in it’s boxes, preparing breakfast is just about 3 points


Question 7 - Sprint Burndown Chart

• No burndown chart - 0

• Burndown chart not updated by team - 1
• Burndown chart in hours/days not accounting for work in progress (partial tasks burn down) - 2
• Burndown chart only burns down when task in done (TrackDone pattern) - 4
• Burndown only burns down when story is done - 5
• Add 3 points if team knows velocity
• Add two point if Product Owner release plan based on known velocity

Our we do have whiteboard with post-it notes on them that are checked out and moved to done as soon as they are done - there is no arguing about the laundry being done before it is cleaned, dried, ironed and back to the closet. So that would make for 5 points. In addition we know our velocity, which would make another 3 points:

Naturally we are pretty capable of telling what can reasonably be expected to be done within the coming sprints. That might add another 2 points for the release being based on that velocity.


Question 8 - Team Disruption

• Manager or Project Leader disrupts team - 0
• Product Owner disrupts team - 1
• Managers, Project Leaders or Team leaders telling people what to do - 3
• Have Project Leader and Scrum roles - 5
• No one disrupting team, only Scrum roles - 10

There are events and people interrupting running sprints: Say, NoSQL meetups that are planned spontaneously or new articles that get written and printed within less than a week. But usually these events are rather seldom and are kept to a minimum due to the short sprint length. So that might make for 3 points.


Question 9 - Team

• Tasks assigned to individuals during Sprint Planning – 0
• Team members do not have any overlap in their area of expertise – 0
• No emergent leadership - one or more team members designated as a directive authority -1
• Team does not have the necessary competency - 2
• Team commits collectively to Sprint goal and backlog - 7
• Team members collectively fight impediments during the sprint - 9
• Team is in hyperproductive state - 10

Currently we are in a state where we have identified and started emerging impediments - declining tasks that cannot reasonably be done within the given timeframe, getting a real product backlog up, tracking even minor tasks like writing e-mails to organize the Apache Hadoop Get Together. So that makes for 9 points.

In total that makes for 54 points (excuse for computing incorrectly: It is 23:34, I am a little tired but cannot sleep due to caffeine). How does your team score on the Nokia test?

Scrum Berlin, dish washer, Scrum

This evening Marion organised another successful Scrumtisch: Usually we either meet for timeboxed discussions on Scrum and agile development questions or a speaker is invited to present his favourite Scrum or Lean or Agile topic.

Today Markus Frick gave a presentation of how Scrum was introduced at SAP, a German software company. They started implementing Scrum in a “small” team of about 60 people, organised in about six to seven teams. The idea was to get people together who are already sort of familiar with agile technologies and let them evaluate what works in the companies context at what doesn’t. The conversion started with trainings, teams were organised by features as opposed to components. The main goal was to get people to learn Scrum and then spread the idea across the whole company.

Soon upper management were fascinated by the methodology - not shortly after that the goal was reset to converting 2500 employees working at four different locations (Bangalore, Berlin, Waldorf and Sofia/France) on diverse topics ranging from developers to managers to agile methods. The question thus turned from scaling Scrum to quickly scaling the conversion process: Where do we get enough trainers? Where does Scrum expertise come from? How should communication be organised? How do we adapt our sales and governance processes?

The way to do this chosen back than was to use Scrum itself for the conversion process. That is to introduce teams for training and conversion and let them work according to a backlog. Also managers were set up to participate by organising work according to a backlog containing management tasks. This first let to quite some confusion: Conversion does take time and working according to sprint backlogs makes it pretty much obvious how much time it actually takes and how much time people really spent on these tasks. On the other hand, the whole process was made very transparent for everyone - and open for participation.

The process started about two years ago - it has not finished to date and processes continue to evolve, get improved and refined as people go along. A very rough estimation was that it might take another three years to get to a stable, clean state. However most - if not all - problems were not caused by Scrum. They were made visible and trackable by Scrum.

The main take home messages were that Scrum does bring improvement:

• It makes goals transparent and communicates clearly the current state.
• You get a short feedback cycle so people actually see where problems are.
• It inherently allows for reflection and analysis of problems.
• As introduced here it also made the work of management people transparent by making backlog and velocity of managers accessible by everyone.
• Internal trainings helped to get feedback from teams who are already practicing what is introduced.

Among the people who were very skeptical there usually were quite a few people from middle management. Uncertain about how future development should work they usually feared a loss in influence. Most positive feedback came from developers themselves: After explaining what Scrum is all about, that is includes shore release cycles and fast feedback, most developers that were in the teams already for quite some time reacted by stating that this basically resembled development “in the good old days” with a bit of development process added on top.

If you are interested in hearing more stories on how Scrum is or was introduced in companies of various sizes, I would like to recommend visiting the German Scrum Day in Düsseldorf. The talk by Thilo Fromm gives a nice overview of how a transition from traditional Waterfall to Scrum can look like. And agile42 Andrea Tomasini will talk about the Scrum implementation in distributed teams at be2 ltd.

Update: This blog post was re-posted at the Agile42 blog.

Scrum Scrum, ScrumDay, Transition

Yesterday evening the Scrumtisch Berlin hosted a talk by Mary Poppendiek on Lean Development. Mary started the session with a talk on what lean development is all about and why it goes further than Scrum ever did. Some of the core principles she explained:

The first goal of every lean project should be to strive for customer satisfaction. The low hanging fruit is to do exactly what the customer wanted to have. The second step is to give features he took for granted as well - think performance, think extensibility. The ultimate goal should be to fulfill what the customer never knew he even wanted. Customers don’t want software - they want their problems solved, the only way they are aware of to solve their problem is through software. Show them how to really solve their problems: Before the iPhone was invented, no one could have predicted what a great smart phone could look like.

Show technical excellence: Testing is not optional. To be a good developer you should always be able to prove that your code is correct. As proving the correctness of software in the mathematical sense is hard, if not impossible today, the recommendation was to use unit testing and integration testing as a poor man’s proof for correctness. Without (automated) testing, any agile project is doomed to develop into a big ball of mud that cannot be easily extended.

The third principle is to deliver reliably, to design the system such that it meets its constraints. Constraints here are not only technical requirements - constraints include budget, time, features, stability and scalability.

The fourth observation was that no development process can fix the problems that Junior-level-only teams experience. Every lean organisation must provide for mentoring. The mentor’s job is to climb the same path as the mentee and pull him along - instead of pushing. In contrast to many setups, not only should new hires be mentored, but basically every employee should have a mentor. Only that way learning - which is essential in current project (not only it) environments - is made possible.

A very interesting observation came from the audience: Every single advise given above is well known and appreciated by any reasonably good software engineer. Problem is: Why don’t we adopt these rules in practice? The guy asking the question gave the answer himself: “The fish starts smelling from its head” (German proverb). So the goal of lean developers in the end would be to talk to their management: Do short iterations of a few weeks. Deliver early, deliver often, deliver in time. Usually that alone is enough to exceed expectations. Choose the best solution (both from business and technical perspective). Your results should speak for themselves to step by step change the way your organisation works.

Slides are online on the Scrumtisch blog.

Scrum lean, Scrum