Velocity update

2010-06-14 18:34
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.

Coaching self-organising teams

2010-03-30 21:58
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.

Alan Atlas at Scrumtisch Berlin

2010-02-17 23:35
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.

The 7 deadly sins of (Java) software developers

2010-01-23 09:09
On Lucid Imaginations Blog Jay Hill published a great article on The seven deadly sins of solr. Basically it is a collection of his experiences "analyzing and evaluating a great many instances of Solr implementations, running in some of the largest Fortune 500 companies". It is a collection of common mistakes, mis-configurations and pitfalls in Solr installations in production use.

I loved the article very much. However, many of the symptoms that Jay described in his article do not apply to Solr installations only. In the following I will try to come up with a more general classification of errors that occur when your average Java developer starts using a sufficiently large framework that is supposed to make his work easier. Happy about any input on your favourite production issues.

Remark: What is printed in italic is quoted as is.

Sin number 1: Sloth - I'll do it later

Let’s define sloth as laziness or indifference. This one bites most of us at some time or another. We just can’t resist the impulse to take a shortcut, or we simply refuse to acknowledge the amount of effort required to do a task properly. Ultimately we wind up paying the price, usually with interest.

There is even a name for it in Scrum: Technical debt. It may be ok to take a shortcut, given this is done based on an informed decision. As with regular debt, you may get a big advantage like launching way earlier than your competitor. However as with real debt, it does come at a prize.

Lack of commitment

Jay describes the problems that are especially frequent when switching search applications: Humans in general do not like giving up their habits. A nice example described in more detail in a recent Zeit article is what happens each year in December/ January when the first snow falls: It is by no means irregular or not to be expected that it starts snowing in December in Germany. However there will be lots of people who are not prepared for that. They refuse to put on winter tiers in late autumn. They use their car instead of public transport despite warnings in public press. The conclusion of the article was simple: People are simply not willing to change habits they got used to. It does take longer and is a bit less flexible to get to work by public transport instead of your own car. It does require adjusting your daily routine, optimising your processes.

Something similar happens to a developer that is "forced" to switch technology, be it the search server, the database, the build system or simply the version control system: The old ways of doing stuff simply may not work as expected. New tools might be called for. New technologies to learn. However in not so seldom cases developers just blame the new tools: "But with the old setup this would always work."

Developing software - probably more than anything else - means constant development, constant change. Technologies shift as tasks shift, tools are improved as workflows change. Developing software means to constantly watch closely what you are doing, reflecting on what works and what doesn't and changing things that don't work. Accepting change, seeing it as a chance rather than an obstacle is critical.

If however change is imposed on developers though good arguments in favour of the old approach exist, it may be worth the effort to at least take the technical view into account to make an informed decision.

Not reviewing, editing, or changing the default configuration files.

I have extended this one a bit: Developers not changing default configuration files are not that uncommon. Be it the default database configuration, default logging configuration for your modules or default configuration of your servlet container. Even if you are using software pre-packed by your distribution, it is still worth the effort to review configuration files for your services and adjust them to your needs. Usually they are to be used as examples that still need tweaking and customization after roll-out.

JVM settings and GC

If you are running Java application there is no way around to adjust GC settings as well as general JVM settings to your particular use case. There are great tutorials at that explain both the settings themselves as well as several rules-of-thumb of where to start. Still nothing should stop you from measuring your particular application and its specific needs - both, before and after tuning. Along with that goes the obvious recommendation to simply "know-your-tools" - learning load testing tools shortly before launch time is certainly no good choice. Trying to find out more on Java memory analysis late in the development cycle just because you need to find that stupid memory leak like *now* is no good idea neither.

There are several nice talks as well as several tutorials available online on the topic of JVM tuning, debugging memory as well as threading issues, one of them being the talk by Rainer Jung at Frocson 2008.

Sin number 2: Greed

Running a service on insufficient hardware (be it main memory, harddisks, bandwidth, ...) is not only an issue with Solr installations. There are many cases where just adding hardware may help in the short run, but is a dead-end in the long run:

  • Given a highly inefficient implementation, identifying bottlenecks, profiling, benchmarking and optimization go a long way.
  • Given an inappropriate architecture, redesign, reimplementation and maybe even switching base technologies does help.

However as Jay pointed out, running production servers with less power than your average desktop Mac has does not help neither.

Sin number 3: Pride

Engineers love to code. Sometimes to the point of wanting to create custom work that may have a solution in place already, just because: a) They believe they can do it better. b) They believe they can learn by going through the process. c) It “would be fun”. This is not meant to discourage new work to help out with an open-source project, to contribute bug fixes, or certainly to improve existing functionality. But be careful not to rush off and start coding before you know what options already exist. Measure twice, cut once.

Don’t re-invent the wheel.

As described in Jay's post, there are developers who seem to be actively searching for reasons to re-invent the wheel. Sure, this is far easier with open source software than with commercial software. Access to code here makes the difference: Understanding, learning from, sharing and improving the software is key to free software.

However there are so many cases where improve does not mean re-implement but submitting patches, fixing bugs, adding new features to the orignal project or just refactoring the original code and ironing out some well known bumbs to make life easier for others.

Every now and then a new query abstraction language for map reduce pops up. Some of those really solve distinct problem settings that cannot (and should not) be solved within one language. Especially if a technology is young, this is pretty usual as people try out different approaches to see what works and what does not work out so well. Good and stable things come from that - in general the fittest approach survives. However, too often I have heard developers excusing their re-invention by "having had too few time to do a throughough evaluation of existing frameworks and libraries". The irony here really is that usually, coding up your own solution does take time as well. In other cases the excuse was missing support for some of the features needed. How about adding those features, submitting them upstream and benefitting from what is already there and an active community supporting the project, testing it, applying fixes and adding further improvements?

Make use of the mailing lists and the list archives.

Communication is key to success in software development. According to Conway's law "Organizations
which design systems are constrained to produce systems which are copies of the communication structures of these organizations." I guess it is pretty obvious that developing software today generally means designing complex systems.

In Open source, mailing lists (and bug trackers, the code itself, release notes etc.) are all ways for communication. (See also Bertrand's brilliant talk on open source collaboration tools for that). With in-house development there is even added benefit as face-to-face communication or at least teleconferencing is possible.

However software developers in general seem to be reluctant to ask questions, to discuss their design, their implementation and their needs for changes. It just seems simpler to work-around a situation that disturbs you instead of propagating the problem to its source - or just asking for the information you need. A nice article on a related topic was published recently it-republik.

However asking these questions, taking part in these discussions is what makes software better. It is what happens regularly within open source projects in terms of design discussions on mailing lists, discussions on focussed issues in the bug tracker as well as in terms of code review.

There are several best practices that come with Agile Development that help starting discussions on code. Pair programming is one of these. Code reviews are another example. Having more than two eye balls look at a problem usually makes the solution more robust, gives confidence in what was implemented and as a nice side effect spreads knowledge on the code avoiding a single point of failure with just one developer being familiar with a particular piece of code.

Sin number 4: Lust

Must have more!You’ll have to grant me artistic license on this one, or else we won’t be able to keep this blog G-rated. So let’s define lust as “an unnatural craving for something to the point of self-indulgence or lunacy”. OK.

Setting the JVM Heap size too high, not leaving enough RAM for the OS.

Jay describes how setting the JVM RAM allocation too high can lead to Java eating up all memory and leaving nothing for the OS. The observation does not apply to Solr deployments only. Tomcat is just yet another application where this applies as well. Especially with IO-bound applications giving too much memory to the JVM is grave as the OS does not longer have enough space for disk caches.

The general take-away probably should be to measure and tune according to the real observed behaviour of your application. A second take-home message would be to understand your system - not only the Java part of it, but the whole machine from Java, the OS down to the hardware - to tune it effectively. However that should be a well known fact anyway. For Java developers, it sometimes helps to simply talk to your operations guys to get the bigger picture.

Too much attention on the JVM and garbage collection.

There are actually two aspects here: For one, as described by Jay it should not be necessary to try every arcane JVM or GC setting unless you are a JVM expert. More precisely, simply trying various options w/o understanding, what they mean, what side-effects they have and in which situations they help obviously isn't a very good idea.

The second aspect would be developers starting with JVM optimization only to learn later on that the real problem is within their own application. Tuning JVM parameters really should be one of the last steps in your optimization pipeline. First should be benchmarking and profiling your own code. At the same stage you should review configuration parameters of your application (size of thread pools, connection pools etc.) as well your libraries and frameworks (here come solr's configuration files, Tomcat's configuration, RDBMs configuration parameters, cache configurations...). Last but not least should be JVM tuning - starting with adjusting memory to a reasonable amount, setting the GC configuration that makes most sense to your application.

Sin number 5: Envy


Wanting features that other sites have, that you really don’t need.

It should be good engineering practice to start with your business needs and distill user stories from that and identify the technology that solves your problem. Don't go from problem to solution without first having understood your problem. Or even worse: Don't go from solution (that is from a technology you would love to use) to searching for a problem that this solution might solve: "But there must be a RDBMS somewhere in our architecture, right?"

Wanting to have a bigger index than the other guy.

The antithesis of the “greed” issue of not allocating enough resources. “Shooting for the moon” and trying to allow for possible growth over the next 20 years. Another scenario would be to never fix your system but leave every piece open and configurable, in the end leading to a system that is harder to configure than sendmail is. Yet another scenario would be to plan for billions of users before even launching: That may make sense for a new Google gadget, however for the "new kid on the block"? Probably unlikely, unless you have really good marketing guys. Plan for what is reasonable in your project, observe real traffic and identify real bottlenecks once you see them. Usually estimations of what bottlenecks could be are just plain wrong unless you have lot's of experience with the type of application you are building. As Jeff Dean pointed out in his WSDM 2009 keynote, the right design for X users may still be right with 10x the amount of users. But do plan a rewrite at about the time you start having 100x and more the amount of users.

Sin number 6: Gluttony

“Staying fit and trim” is usually good practice when designing and running Solr applications. A lot of these issues cross over into the “Sloth” category, and are generally cases where the extra effort to keep your configuration and data efficiently managed is not considered important.

Lack of attention to field configuration in the schema.

Storing fields that will never be retrieved. Indexing fields that will never be searched. Storing term vectors, positions and offsets when they will never be used. Unnecessary bloat. Understand your data and your users and design your schema and fields accordingly.

On a more general scale that might be wrapped into the general advise of keeping only data that is really needed: Rotate logs on a schedule fit to your business, operations needs and based on available machines. Rotate data written into your database backend: It may make sense to keep users that did not interact with your application for 10 years. If you have a large datacenter for storage that may make even more sense. However usually keeping inactive users in your records simply eats up space.

Unexamined queries that are redundant or inefficient.

Queries that catch too much information, are redundant or multiple queries that could be folded into one are not only a problem for Solr users. Anyone using data sources that are expensive to query probably knows how to optimize those queries for reduced cost.

Sin number 7: Wrath

Now! While wrath is usually considered to be synonymous with anger, let’s use an older definition here: “a vehement denial of the truth, both to others and in the form of self-denial, impatience.”

Assuming you will never need to re-index your data.

Hmm - don't only backup. Include recovery in your plans! Admittedly with search applications, this includes keeping the original documents - it is not unusual to add more fields or to want to parse data differently from the first indexing run. Same applies if you are post-processing data that has been entered by users or spidered from the web for tasks like information extraction, classifier training etc.

Rushing to production.

Of course we all have deadlines, but you only get one chance to make a first impression. Years ago I was part of a project where we released our search application prematurely (ahead of schedule) because the business decided it was better to have something in place rather than not have a search option. We developers felt that, with another four weeks of work we could deliver a fully-ready system that would be an excellent search application. But we rushed to production with some major flaws. Customers of ours were furious when they searched for their products and couldn’t find them. We developed a bad reputation, angered some business partners, and lost money just because it was deemed necessary to have a search application up and running four weeks early.

Leaving that as is - just adding, this does not apply to search applications only ;)

So keep it simple and separate, stay smart, stay up to date, and keep your application on the straight-and-narrow (YAGNI ;) ). Seek (intelligently) and ye shall find.

How much of Scrum is implemented?

2010-01-06 22:36
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?

ScrumTisch Berlin - November

2009-11-26 23:03
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.

Scrumtisch with Mary and Tom Poppendiek

2009-10-12 15:07
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 Day Düsseldorf

2009-10-06 05:24
On 01. to 02. December the Scrum Day is going to take place in Düsseldorf.

If you are working in a non-Scrum company and would like to use agile methods both for development and management, I would like to recommend going to the talk by Thilo Fromm: Scrum in a waterfall. He explains how he transformed his project to an agile way in a waterfall environment.

Scrum Tisch

2009-09-23 18:30
Title: Scrum Tisch
Description: The Scrumtisch on October 11th will feature a talk by Mary

She will join that extraordinary Scrumtisch at 6pm.

The location is not yet defined yet, because Marion first needs to know how many
of are coming.
Start Time: 18:00
Date: 2009-10-11

Scrum Tisch

2009-09-23 18:30
Title: Scrum Tisch
Description: The Scrumtisch on October 11th will feature a talk by Mary

She will join that extraordinary Scrumtisch at 6pm.

The location is not yet defined yet, because Marion first needs to know how many
of are coming.
Start Time: 18:00
Date: 2009-10-11