GeeCon - managing remote projects

2012-05-24 08:05
In his talk on visibility in distributed teams Pawel Wrzeszcz motivated why working remotely might be benefitial for both, employees (less commute time, more family time) as well as employers (hiring world wide instead of local, getting more talent in). He then went into more detail on some best practices that worked for his company as well as for himself.

When it comes to managing your energy the trick mainly is to find the right balance between isolating work from private live (by having a separate area in your home, having a daily routine with fixed start and end times) and integrating work into your daily live and loving what you do: The more boring your job is, the less likely you are going to succeed when working remotely.

There are three aspects to work remotely successfully: a) having distributed meetings – essentially: minimize them. Have more 1 on 1 meetings to clear up any questions. Have technology support you where necessary (Skype is nice for calls with up to ten people, they also tried google hangouts, teamspeak and others. Take what works for you and your colleagues). b) For group decisions use online brainstorming tools. A wiki will do, so do google docs. There's fancier stuff should you need it. Asynchronous brainstorming can work. c) Learn to value asynchronous communication channels – avoid mail, wikis, issue trackers etc. are much better suited for longer documentation like communication.

Essentially what will happen is that issues within your organisation are revealed much more easily than working on-site.

GeeCon - failing software projects fast and rapidly

2012-05-23 08:04
My second day started with a talk on how to fail projects fast and rapidly. There are a few tricks to do that that relate to different aspects of your project. Lets take a look at each of them in turn.

The first measures to take to fail a project are organisational really:

  • Refer to developers as resources – that will demotivate them and express that they are replaceable instead of being valuable human beings.
  • Schedule meetings often and make everyone attend. However cancel them on short notice, do not show up yourself or come unprepared.
  • Make daily standups really long – 45min at least. Or better yet: Schedule weekly team meetings at a table, but cancel them as often as you can.
  • Always demand Minutes of Meeting after the meeting. (Hint: Yes, they are good to cover your ass, however if you have to do that, your organisation is screwed anyway.)
  • Plans are nothing, planning is everything – however planning should be done by the most experienced, estimation does not have to happen collectively (that only leads to the team feeling like they promissed something), rather have estimations be done by the most experienced manager.
  • Control all the details, assign your resources to tasks and do not let them self-organise.


When it comes to demotivating developers there are a few more things than the obvious critizing in public that will help destroy your team culture:

  • Don't invest in tooling – the biggest screen, fastest computer, most comfortable office really should be reserved for those doing the hard work, namely managers.
  • Make working off-site impossible or really hard: Avoid having laptops for people, avoid setting up workable VPN solutions, do not open any ssh ports into your organisation.
  • Demand working overtime. People will become tired, they'll sacrifice family and hobbies, guess how long they will remain happy coders.
  • Blindly deploy coding standards across the whole company and have those agreed upon in a committee. We all know how effective committee driven design (thanks to Pieter Hintjens for that term) is. Also demand 100% test coverage, forbid test driven development, forbid pair programming, demand 100% Junit coverage.
  • And of course check quality and performance as the very last thing during the development cycle. While at that avoid frequent deployments, do not let developers onto production machines – not even with read only access. Don't do small releases, let alone continuous deployment.
  • As a manager when rolling out changes: Forget about those retrospectives and incremental change. Roll out big changes at a time.
  • As a team lead accept broken builds, don't stop the line to fix a build – rather have one guy fix it while others continue to add new features.


When it comes to architecture there are a few certain ways to project death that you can follow to kill development:

  • Enforce framework usage across all projects in your company. Do the same for editors, development frameworks, databases etc. Instead of using the right tool for the job standardise the way development is done.
  • Employ a bunch of ivory tower architects that communicate with UML and Slide-ware only.
  • Remember: We are building complex systems. Complex systems need complex design. Have that design decided upon by a committee.
  • Communication should be system agnostic and standardised – why not use SOAP's xml over http?
  • Use Singletons – they'll give you tightly coupled systems with a decent amount of global state.


When it comes to development we can also make life for developers very hard:

  • Don't establish best practices and patterns – there is no need to learn from past failure.
  • We need not definition of done – everyone knows when something is done and what in particular that really means, right?
  • We need not common language – in particular not between developers and business analysts.
  • Don't use version control – or rely on Clear Case.
  • Don't do continuous integration.
  • Have no code ownership – in contrast have a separate module modified by a different developer and forbid others to contribute. That leaves us with a nice bus factor of 1.
  • Don't do pair programming to spread the knowledge. See above.
  • Don't do refactoring – rather get it right from the start.
  • Don't do non-functional requirements – something like “must cope with high load” is enough of a specification. Also put any testing at the end of the development process, do lots of manual testing (after all machines cannot judge quality as well as humans can, right?), post-pone all difficult pieces to the end, with a bit of luck they get dropped anyway. Also test evenly – there is no need to test more important or more complex pieces heavier than others.

Disclaimer for those who do not understand irony: The speaker Thomas Sundberg is very much into the agile manifesto, agile principles and xp values. The fun part of irony is that you can turn around the meaning of most of what is written above and get some good advise on not failing your projects.

February 2012 Apache Hadoop Get Together Berlin

2012-01-31 20:34
The upcoming Apache Hadoop Get-Together is scheduled for 22. February, 6 p.m. - taking place at Axel Springer, Axel-Springer-Str. 65, 10888 Berlin. Thanks to Springer for sponsoring the location!

Note: It is important to indicate attendance. Due to security restrictions at the venue only registered visitors will be permitted. Get your ticket here: https://www.xing.com/events/hadoop-22-02-859807

Talks scheduled thus far:

Markus Andrezak : "Queue Management in Product Development with Kanban - enabling flow and fast feedback along the value chain" - It's a truism today that fast feedback from your market is a key advantage. This talk is about how you can deliver smallest product increments or MVPs (minimal viable products) quickly to your market to get fastest possible feedback on cause and effect of your product changes. To achieve that, it helps to provide a continuous deployment infrastructure as well as all you need for A/B testing and other feedback instruments. To make the most of these achievements, Kanban helps to limit work in progress, thus manage queues and speed up lead times (time from order to delivery or concept to cash). This helps us speed through the OODA Loop, i.e. Eric Ries' (The Lean Startup) Model -> Build -> Code -> Measure -> Data -> Validate -> Model. The more we can go through the loop, the more we have a chance to fine tune and validate our model of the business and finally make the right decisions.

Markus is one of Germany’s leading Kanban practitioners - writing and presenting talks about it in numerous publications and conferences. He will provide a brief view into how he is achieving fast feedback in diverse contexts.
Currently he is Head of mobile commerce at mobile.de.

Martin Scholl : "On Firehoses and Storms: Event Thinking, Event Processing" - The SQL doctrine is still in full effect and still fundamentally affects the way software is designed, the state it is stored in as well as the system architecture. With the NoSQL movement people have started to realize that the manner in which data is stored affects the full stack -- and that reduction of impedance mismatch is a good thing(TM). "Thinking in events" follows this tradition of questioning what is state-of-the-art. Modeling a system not in mutable entities (as with data stores) but as a stream of immutable events that incrementally modify state, yields results that will exceed your expectations. This talk will be about event thinking, event software modeling and how Twitter's Storm can help you process events at large.

Martin Scholl is interested in data management systems. He is also a Founder of infinipool GmbH.


Fabian Hüske : "Large-Scale Data Analysis Beyond Map/Reduce" - Stratosphere is a joint project by TU Berlin, HU Berlin, and HPI Potsdam and researches "Information Management on the Cloud". In the course of the project, a massively parallel data processing system is built. The current version of the system consists of the parallel PACT programming model, a database inspired optimizer, and the parallel dataflow processing engine, Nephele. Stratosphere has been released as open source. This talk will focus on the PACT programming model, which is a generalization of Map/Reduce, and show how PACT eases the specification of complex data analysis tasks. At the end of the talk, an overview of Stratosphere's upcoming release will be given.

Fabian has been a research associate at the Database Systems and Information Management (DIMA) group at the Technische Universität Berlin since June 2008. He is working in the Stratosphere research project, focusing on parallel programming models, parallel data processing, and query optimization. Fabian started his studies at the University of Cooperative Education, Stuttgart, in cooperation with IBM Germany in 2003. During that course, he visited the IBM Almaden Research Center in San Jose, USA, twice and finished in 2006. Fabian undertook his studies at Universität Ulm and earned a master's degree in 2008. His research interests include distributed information management, query processing, and query optimization.


A big Thank You goes to Axel Springer for providing the venue at no cost for our event and for paying for videos to be taped of the presentations. A huge thanks also to David Obermann for organising the event.

Looking forward to seeing you in Berlin.

Scrumtisch Berlin

2012-01-26 23:10
After quite some time off I went to the Scrumtisch Berlin. The event was incredibly well visited - roughly 50 people filled the upper floor at Cafe Hundertwasser. Today's event was organised such that participants first collected discussion topics, prioritised them together and then discussed the top three items in a timebox of 15 minutes each.

Topics collected were:

  • Best tricks to make teams self organised (20 votes)
  • What is QA doing fulltime in a team (13 votes)
  • Ops and planning in a team (15 votes)
  • PO disappears and takes backlog and vision with him - what now? (7 votes)
  • Working with non-Software teams (17 votes)
  • Pimp up my retrospective (12 votes)
  • Multiple teams on one projects and vice versa (4 votes)
  • IBM doing Scrum/ massive Scrum (9 votes)
  • Feature knowledge vs market knowledge - what is more important in a PO if you have to choose due to people constraints (9 votes)
  • How to convince a team to do more (3 votes)
  • Why is agile good (10 votes)


Compared to previous meetings quite some topics repeat. About half of the attendees were there for the first time - so it seems there is a common set of questions people usually run into when rolling out Scrum.

Self organising teams



Seems like this is one of the most common questions run into when rolling out Scrum - how to really get to self organising teams. The question can be answered from two positions: What are the pre-requisites it takes to enable teams to become self organising? How to actually transform teams that are used to a command and control structure and are reluctant to transform?

The discussion, mainly led by Andrea Provaglio, CSM trainer focussed mainly on the first part of the question. Even when limiting discussion that way, the answer will still depend heavily on the organisation structure, number of management levels, team sizes.

Marion made the topic a bit more concrete: Given the flexible vacation planning approach of Netflix, her question was whether that sort of loose approach could work in a typical German company (after all we have 30 instead of

  • Clearly setting a goal (in that case: Everyone needs to have a vacation plan at a given date.)
  • Provide the team with all resources, information and with the environment they need to accomplish their task.
  • Define constraints ("there must be at least one guy in the office on any given working day")
  • Check back regularly
  • Make yourself available to answer any questions


The discussion on teams reluctant to adopt self organisation was separated out and deferred. His point was mainly about enabling and encouraging self organisation. Enforcing self organisation however is not possible.

Scrum in non-Software teams



Though phrased very broadly the topic quickly turned into a "how to do Scrum for hardware" discussion. Main problem here is that the further down you go the longer design generally takes. Even just routing lines on one decently sized circuit board can take several weeks. Mainly three possible ways out of the problem emerged from the discussion:


  • Loosening the definition of done - "potentially shipable" may not mean sellable or even really shipable. I don't think one should go down that slippery path. Only by actually shipping can I get the feedback I need to improve my design. So instead of loosening the definition of done we should instead start thinking about ways to get faster feedback, reduce risk and introduce shorter iterations.
  • Another way is to look for ways to reduce iteration length, even though we might not get down to software release cycles, and align releases such that integration can happen earlier.
  • The third way out could be to realize that maybe Scrum does not quite fit that way of working and use a different process instead that still provides the transparency and fast feedback that is needed (think Kanban).


Overall the most important result of the discussion was that within 15min discussion the issues cannot be solved. After all the solution will depend on what exactly you are working on, who your suppliers are and what your team looks like. Most important is to recognize that there is a problem and to work on removing that impediment - most important is to identify issues and to improve your process.

Operations and planning in Scrum



The last question discussed involved operations and Scrum planning: Given a team that does software development but is interrupted frequently with production issues - how should they work in a Scrum environment.

There are multiple facets to that problem: When it comes to deciding whether to deal with something immediately or not it makes sense to weigh size of the issue against amount of work it takes to resolve it. "Getting things done" states that the minimum size of an issue to deal with instantly is 2min of work. Issue with that is that the assumption of GTD was that issues flow into and inbox that is dealt is when there is time. In production environments however these issues usually trickle in instantly interrupting developers over and over again incurring a huge cost due to task switching.

One way out might be to have an event queue and assign developers (on a rotating basis) to deal with the issues and leave time for others to work in a focused way. Make sure to rotate frequently instead of by sprint - otherwise you run into the problem of making the team unstable thus delivering no stable amount of business value each sprint.

Another obvious way is to account for frequent interruptions and include a buffer for those in your plan. The most important benefit of that approach is to make the cost of this working mode clearly visible to management - leaving the decision how to deal with it up to them.

Other simple fixes include introducing some level of indirection between the actual developer and the customer raising the issue, documenting solutions as well as incoming issues for better visibility, introducing a single point of contact capable of prioritising.

Coming back to vanilla Scrum however there is one interesting observation to be made: The main contract with iterations is for developers to be able to work in a focused way. Instead of having their tasks switched each day they are promised a fixed period of time to solve a given set of stories. In the end a sprint is a compromise between what management may need (change their mind on what is important frequently) and what developers need (working on a set of defined tasks not interrupted by re-priorisation). If the assumption of focus does not longer hold true, Scrum might be the wrong model. If what needs to be done changes daily, Kanban again might be the better option. Still making sure that the cost of task switching is visible is vitally important.

To sum up a very interesting Scrumtisch - in particular as agile methods really seem to become more and more common also in Berlin. Speaking of challenges: As user groups grow sometimes their character changes as well, in particular when built around participation and discussion. It will be interesting to watch Scrumtisch deal with that growth. Maybe at some point splitting the audience and having separate breakout sessions might make sense. Admittedly I'd also love to know more on the background of the audience: How many are actually using Scrum in the trenches vs. teaching Scrum as coaches? How long have they been using Scrum? In what kind of organisation? Maybe a topic for next time.

Scrum done wrong

2012-01-22 06:39
“Agile and Lean have a single purpose: to continually challenge the status quo. If you’re not doing that, you’re probably an impediment to it.”
agile42.com

Judging from the way some people become overly careful when discussing agile in general and Scrum in particular in my presence I seem to slowly have built up a reputation for being a strong proponent of these methods. Given the large number of flaky implementations as well as misunderstandings it seems to have become fashionable to blame Scrum for all badness and dismiss it altogether - up to the point where developers are proud to finally having abandoned Scrum completely - so that now they

  • can work in iterations,
  • accept new tasks only for upcoming but not for the current iteration,
  • develop in a test-driven way,
  • have daily sync meetings,
  • mark tasks done only when they are delivered to and accepted by the customer,
  • have regular “how to improve our work” meetings,
  • estimate tasks in story points and only plan for as much work per iteration as was done in the past iteration


… my personal take on that: Add in regular releases and you end up with a pretty decent scrum/agile implementation, no matter what your preferred name for it may be. Just for clarification: Though very often I write about what I call Scrum, I don’t use that particular method just because it is the latest fashion. It simply is a tool that has served me well on multiple occasions and given me working guidelines when I had no idea at all what software development in a professional setting should look like.

So where does all that friction with anything Scrum, agile, lean or whatever you call it come from? Recently I came across a blog post that jillesvangurp.com nicely identified some grave issues with current Scrum adoption. Unfortunately the blog post only lists the failures without going into a deeper analysis of the actual defects causing those failures.

First of all, lets assume as working hypothesis that Scrum in itself does not solve any issues in your organisation but is a great tool to uncover deficiencies. The natural conclusion should be to use it as a tool to discover problems, but search for solutions for these problems elsewhere.

With that hypothesis, lets discern the the issues discussed in the post above and assign them to one of three defect categories.

Category one: Issues with the team

Problem: You have a team of all-junior developers, or of all-mediocre developers.

Goal: Turn them into a high performing team.

Solution: Imagine you were not using Scrum at all, what would be the ideal solution? Well the obvious route probably is to re-adjust the team, add several seniors so that you end up with the right mix of people that have experience and share a vision - juniors than can learn and adapt what works from them.

Comparing that to our hypothesis: Scrum is all for short delivery cycles. You will uncover teams that perform badly much faster than in methods with longer iteration periods. So it should be reasonably simple to figure out teams that have a dysfunctional configuration. Changing that configuration however no longer is dictated by Scrum.

Category two: Bugs introduced during Scrum roll-out

The failures discussed in the blog post include people following Scrum mechanically: Only because your developers are moving post-it notes from left to right does not mean they are doing anything agile. It’s perfectly possible to do waterfall in Scrum. Whether that helps solve any of your issues is a different matter.

Instead of mechanically going through the process what is more important is to understand the reasons and goals of each of the pieces that form Scrum. To make a rather far fetched comparison:



When introducing Scrum without a deep understanding of why each piece is done, what you end up with is people following that process without understanding the meaning of each step. They end up mimicking behaviour without knowing the real world: To some extend seeing only the shadows of good development patterns without understanding the real items producing these shadows.

As a general rule: Understand why there is a retrospective meeting, remember why you need estimations, think about why there are daily stand-ups (instead of weekly meetings, instead of daily sit-togethers, instead of hourly stand-ups). Figure out why there is a product owner, what the role of a scrum master does. Pro-Tip: As soon as you really have understood Scrum, you don’t need a checklist of all meetings to hold for a successful iteration - they will just fit in naturally. If they don’t, you are probably missing an important piece of the puzzle - rather than rely on a pre-fabricated checklist, go bug your trainer or coach with questions to better understand the purpose of all the different bits and pieces.

One very grave bug on roll-out is the general believe that Scrum is equal to a little bit of fairy dust you spread over your teams and all problems will automatically be solved afterwards. It is not - it’s not a silver bullet, it’s not fairy dust, it’s no magic - such things exist in fairy tales but have been seen nowhere in the real world. According to our working hypothesis above however Scrum does something really magical: By shortening delivery cycles it introduces short feedback loops which make it very easy to uncover problems in your organisation way faster than people are able to cover them up and hide them. Finding a solution on the other hand is still up to you.

The last roll-out issue mentioned is that of crappy certification - current certification programs are designed such that the naive organisation may believe that after two days of training their employers will magically turn into super heroes. Guess what - as with any certification training is just the very first step. Actual understanding comes with experience. Compare that to learning to drive: Only because you managed to get a drivers license does not turn you into a formula one winner. Instead that requires a whole lot of training. Same applies for any Scrum Master or Product Owner.

Category three: Organisation specifics

All other issues with Scrum mentioned in the blog post are either specific to the broken structures in the organisation under investigation or due to general Scrum mis-conceptions. Leaving these aside here.

To sum up: Scrum to me is nothing but a term to summarize good, proven development practices. I don’t care how you name them - however having any one name that is well defined makes it way easier to communicate. Scrum is not silver bullet - it does not solve all the issues your organisation may have. However it is a very effective debugger uncovering the issues employees and managers are trying to cover up. If you know all those issues very precisely already or you are certain that you don't have any, chances are you don't need Scrum.

Design Thinking @ Scrumtisch Berlin

2011-09-26 21:38
This evening Mary Poppendieck gave a presentation on Design Thinking in Berlin. "What does the US Military have in common with Apple?" In her talk Mary went into more detail about how increasing complexity calls for a need to rethink design. Slides are available online. Thanks for sharing them.

Mary started with a question for the audience on who in your company decides what is to be developed: Is it the PO? Is it a "them" or is it "us"? In a world of growing complexities and faster innovation cycles, thinking of them doing the design more and more becomes a huge business risk. It's time to start thinking of development teams as groups of people solving a business need - forgetting about the "that's none of my business" attitude.

Lets first dig deeper into the three steps of design (according to the book The design of design) the three steps of design are:


  • Understanding the problem: Actually finding out what is the problem, what is to be designed is the hardest part. It's best done in a small team as opposed to by a single person.
  • Design the solution: This step involves uncovering specific requirements and identifying alternative solutions - before actually being able to judge whether an alternative is a viable way of solving a given problem, the harder part is identifying possible alternative solutions.
  • Implementing the design: This step must involve getting users and developers of the resulting system work closely together.


To come up with a truly successful design these three steps most likely need to be iterated as what we learn in later steps has to influence earlier steps.

When it comes to design, at traditional corporations there are various job titles for people involved with design. The graph distinguishes teams developing products vs. supporting internal processes. It makes a difference between software and hardware development. In addition there is a difference between people deciding on what to design (denoted in red) and those deciding how to develop (denoted in green). When looking at Scrum all of these roles are combined in the role of the product owner. When taking a closer look this seems to be a large over-simplification - especially when taking into account that the product owner in general is realized not as a role that has to be provided for but as a job description of one single person. It seems like this is too much work and too many hats for one single person.

In contrast Mary advocates a far more hollistic definition of the designers role: In current teams design is mostly being done up-front, in a very detailed way with results in the form of small user stories being handed over to the team afterwards. In contrast to that developers should be integrated in the design process itself - they need to participate, provide their input to come up with really innovative solutions.

Step one: Understanding the problem



The presentation went into more detail on three different approaches to solving the first step in design - that is understanding the problem. The first way was coined as the military approach. In the The operations process a chapter on design was added to cope with complex situations that do not match the expected configuration.



In such situations a combination of collaboration, dialog, critical thinking and creative thinking seems more important than blindly following command. According to the US military's procedures design again is an iterative three step process: From framing the problem, to experimenting and building prototypical solutions, to making sense of the situation and possibly going back to earlier steps based on what we have learned. One important feature of successful design teams is that the are composed of people with diverse backgrounds to not miss details about the situation.

The second approach to design is the Ethnographic approach. Mary showed a video introducing design company IDEO. The interesting take away for me was that again teams need to be diverse to see all details, that designers need not only find statistics on existing products but also go out to the customer using the product and listen to those "experts". The need to work under time constraints, work in a very focused manner, build prototypes - not to deploy them but to learn from them, merge them and throw away what does not work early in the process.

Coming from a data driven, Hadoop-y background, the third approach was the one most familiar to me: The data based approach focuses on finding success metrics and optimising those. When going back to the "Mythical man month" example of IBM building the IBM PCjr - the team spending 2 years developing a product that was a horrible failure, a product that was judged very badly in common it magazines: What could they have changed to do better? Well the solution almost is in the question: If there are people writing articles to judge products, people that have criteria for judging product success - why not optimise for their criteria? Another example would be Toyota developing the Lexus: Early in the process they decided to optimise for a top score on each of the car magazine reviews. Turned out though hard it was, it was not impossible. And lead to huge success on the sales side.

So instead of being caught in our little development bubble maybe it's time to think bigger - to think not only about what makes our project successful but to think about what makes business successful. And while at it - why not measure success or failure of a piece of software by how successful it is monetarily? This leads to a whole new way of thinking about development:


  • Instead of a product roadmap we start thinking about a business model canvas: What metric gives us information on the business success of a new feature? How can we measure that? This can be as easy as click conversion rate. It's closely tied to the way you make money.
  • Instead of a product vision we turn to measuring a product to market fit.
  • Instead of a release plan we start thinking about the minimal viable product: What is the least you can do to generate more revenue?
  • Instead of an on-site customer we start having a on-site developer. This is about getting developers out of the building, get them to talk to your users and get this experience back in. Note: To some extend this is even possible by looking over the user's shoulder by analysing your log files. Ever thought of taking a closer look at your search engines queries that return no results? Maybe instead of cursing the users that are too stupid to use your interface it's time to re-think your interface design or add more features to your search engine.
  • Instead of iterations we have a loop of building - measuring - learning about our product.
  • Instead of an iteration backlog at the end of each loop we have to decide about whether to preserve the current development direction or pivot it a bit.
  • Instead of a backlog of things to do we have a list of things to learn about our users.
  • Instead of detailed tiny user stories we have hypothesis of how our product is used that are validated or falsified by actual data.
  • Instead of continuous integration you have continuous deployment that is much more interesting.
  • Instead of acceptance tests we may have split tests, A/B tests or similar.
  • Instead of a definition of done including only development it suddenly also comprises validating the data - did we actually convert more users?
  • Instead of costumer feedback we are having a cohort-based metric, we start watching our users to learn - they are rarely willing to give explicit feedback, but their actions are very telling.
  • Instead of a product owner we have entrepreneurs that have the business as a whole in mind.


Design a solution



Good industrial design is made up of ten principles: It's innovative, makes the product useful, understandable, aesthetic, unobtrusive, honest (does not fool users), long lasting, thorough through, environmentally friendly - and most important of all there is as few design in there as possible.

As one example Mary mentioned the flight booking site Hipmunk.com that gives users the chance to sort flights by least agony. It optimises for the best flying experience - not the best buying experience.

In the end it's all about building what the user needs - not selling what your build. It's about watching your users and learning about their needs.

Implementing design



One grave warning: Do not divorce design from development: Ford was a driver and racer himself, making him a great car designer. Wright flew the aircrafts he designed. Tom Edison thought through the whole process. Also in the tech industry the companies that are nowadays most successful were founded by people who are or at least were themselves very actively using the stuff they are building - think Bill Gates, Steve Wozniak and Steve Jobs, Sergey Brin and Larry Page. Takeaway is to do the job you are trying to automate, to have incremental development and delivery.

In the end it all boils down to how fast a learner you are: Not the most intelligent nor the strongest will survive. It's the one that is fastest to adapt to change that will be successful. One commonly used analogy for that is the so-called OODA cycle coming from John Boyd: The tighter your cycle of observing, orienting, deciding and acting is, the likelier you are to be successful among your competitors.

Speaking of release cycles Mary gave a very nice graph of various release cycle lengths.



In her experience teams that have deployment cycles of six months and above are likely to spend one third of their time hardening their software. If you are down to a quarter it's likely that the bottleneck is your business model. Maybe it is weird contracts or business partners expecting support for the exact version you shipped years ago. When you are down to a month per release you likely are running a software as a service model. As clarified later after a question from the audience for Mary this does include setups where customers basically buy a software including all future updates for a set period of time - including an automated roll-out. If you are down to daily or even just weekly releases you are likely running the product yourself. Mose likely then everyone is part of the team.

After her talk Mary answered various questions from the audience: According to her experience Scrum defines the team way too narrow by focusing on development only - with Scrum we are possibly getting perfect at doing the wrong thing very well - forgetting all about design and business.

One very general advise that leads to an interesting conclusion is to not waste your life, to not spend years of your life working on projects that are not needed by anyone. In the end this leads to realizing that failed projects are also caused by the developers not raising concerns and issues.

Mary is a huge proponent of trusting your team: Do not hand them detailed lists of user stories. You have hired great, senior people (or haven't you??) - give them an idea what you want and let them figure out the details by talking to the right people.

When asked for tools to support the lean startup process in a startup Mary emphasized the need for communication. Tools are likely to only slow you down: Get people to communicate, to sit at one table. Have a weekly or bi-weekly meeting to get everyone in sync. Otherwise let developers figure out their way to collaborate.

The talk was kindly hosted by Immobilien Scout, organised by agiliero with some tickets handed over to the Berlin Scrumtisch. Thanks guys.

Berlin Scrumtisch - February 2011

2011-02-24 21:33
The February Scrumtisch Berlin featured a talk by Lyssa Adkins, famously known for her publications on Coaching Agile teams. A mixture of fifty developers, scrum masters, coaches and product owner as well as one project manager followed Marion Eikmann's invitation. Thanks for organising the event, as well as thank you to Hypoport for providing the venue.

In her one-hour presentation she mainly focussed on two core topics: On the roles agile coaches have to fullfill as well as on the skill set needed by agile coaches. Being an agile coach (as well as being a scrum master, really), entails four very basic roles:

  • Being a bulldozer - that is getting impediments out of the way. That can be as easy (or hard) as getting appropriate equipment for your developers or teaming up with the product owner to communicate with anyone trying to break the sprint.
  • Being a servant leader - for a coach that means to work for the team, to ask the right questions and enable the team, to listen during dailies - instead of asking for additional reports: Most tools are already within the Scrum toolbox. The hard task is to identify them and use them correctly and efficiently.
  • Being a shepherd - that may be as easy as getting people to attend the dailies, or as complex as communicating common values, a common goal.
  • Being the guard of quality and performance - as a coach that means making degrading quality visible - and letting the Scrum team take the decision on how to deal with it.

However in reality each team is different, each sprint is different. So coaching really is similar to bing the river guide: Each trip is different. It is your task to make the team succeed and adapt to differing situations. To get to team to high performance - over and over again.

When talking about coaching what people need is a very specific skill set:

  • To become a successful agile coach it helps to have coaching skills to be able to understand the client, to see their impediments and help the team become better by listening and asking powerful questions.
  • Be a facilitator who organises sessions, meetings, conversations and may mediate in meetings.
  • Have business domain expertise - that is to know process designs, figure out a companies strategy options.
  • Be a great teacher to help people understand the basic concepts. That entails knowledge on course design, most likely design of exercises.
  • Have mentoring skills to guide a team in the process.
  • Know about lean and agile processes and stay up to date.
  • Have the technical skills on what makes development successful, know the extreme programming techniques to help team excel.
  • Have transformational skills - that is be familiar with change management, transformation leadership, knowing how to change organisations.


However being a coach remember that people are influenced not only by what you teach - but mostly by what you do. Most of what being a good coach means is invisible to the uninitiated outsider. It's about living the process you teach, staying true to the principles you want others to implement.

To get there it helps to get inspired, to talk with others in local meetups (just as with any coding practice: Try to find a common forum to exchange ideas and get fresh input). It may help to keep a value journal - not only to track your accomplishments and be able to prove them to higher management, but also to track where to improve yourself.

The talk provided several interesting starting points for exploring further. However with an added exercise sixty minutes covered only the very basic ideas. Especially for the skill sets needed to successfully coach teams it would be very interesting to learn more on what books to read or what courses to attend to learn more on each topic. Ultimately not only agile coaches benefit from being great teachers, mentors or facilitators.

Christmas Scrumtisch

2010-11-29 22:59
Today the last Scrumtisch Berlin in 2010 took place in Friedrichshain. Thanks to Marion Eickmann and Andrea Tomasini for organising the Scrum user group regularly for the past years.

Though no presentation had been scheduled ahead of time the Scrumtisch was well attended by over twenty people, mostly from companies based in Berlin who are either using Scrum already or are currently in a transition phase.

We went straight into collecting and voting on topics for discussion. In total we ended up having eight potential topics listed, including but not limited to


  • Scrum and non-feature teams, does it work - and if, how?
  • Transitioning to Scrum - what are the stake holders that must be convinced first in a company?
  • Scrum with teams made of people buying into Scrum and those that don't - does that work?
  • Can Scrum be combined with people who want to telecommute?
  • Scrum and platform development - how does that get combined?
  • Scrum in systems engineering, embedded development - how to setup teams?


After voting we had the two clear winners discussing Scrum in teams that don't buy into the method completely as well as telecommuting with Scrum teams.

Scrum with broken teams


The situation described: The attendee proposing the topic has the problem of being Scrum master at a team that does not completely buy into Scrum. There are a few developers who like being self-organising, who love short feedback cycles. However there are a few others who would rather stick with their technological niche, get tasks assigned to them and avoid taking over tasks from others.

During discussion we found out that in this company Scrum had been introduced as a grass-roots movement little over a year ago. The introduction of the method led to success clearly visible in the company. In turn the method was tried on a larger team as well. However at the moment the team is at a point where it is about to break apart: Into developers happy with change, flexible enough to adapt to shift in technology and a second half that would rather continue developing the old way.

One very important point was raised by one of the attendees: With Scrum getting introduced so fast, compared to the length in time the company had been living before, it may well be time to slow down a bit. To sit down with the team in a relaxed environment and find out more on how everyone is assessing the current situation. Find out more on what people like about the new approach, and about what should be changed and still needs improvement. In the end it's not a process issue but a people problem - there is a need to get the team on-board.

Team-building activities might help as well - let the team experience what it means to be able to rely on each other. What does it mean to learn new things in short time, to co-operate to solve tasks so far untackled?

If team-members start ignoring the sprint backlog working on other tasks instead there is a question about whether there is enough trust in the product-owner's decisions. On the other hand with pressure resting on the team's shoulders there might be a need to stop the train, fix all open issues and continue only after the project is back in shape. However also this needs all team members working towards a common goal - with everyone willing to take up any open task.

Scrum and telecommuting


Basically the question was whether it works at all (clear yes from the audience) and if, which best practices to use. To be more precise: Does Scrum still work if some of the team members work from home a few days a week but are in the office all other time. The risk of course lies in loosing information, in the team building common knowledge. And thus becoming less productive.

There are technical tools that can help the process: electronic scrum boards (such as Greenhopper for JIRA or Agilo) as well as tele-conferencing systems, wikis, social networking tools, screen sharing for easier pair programming. All tools used must entail less overhead then the provide in benefit to the team however. Communication will become more costly - however if and to what extend this translates to a loss in productivity varies greatly.

There must be a clear commitment from both sides - the telecommuter as well as the team on-site - to keep the remote person in the loop. Actually it is easier with teams that are completely remote. This experience is sort of familiar from any open source project: With people working in different time zones it comes naturally to take any decision on a mailing list. However with some people having the chance to communicate face-to-face suddenly decisions become way less transparent. At Apache we even go as far as telling people that any decision that is not taken on the mailing list, never really was taken at all. A good insight into how distributed teams at Apache work has been given earlier by Bertrand Delacrétaz.

For team building reasons it may make sense to start out with a co-located team and split off people interested in working from home later on. That way people have a chance to get to know each other face-to-face which makes later digital-only communication way easier.

Thanks again to Marion and Andrea for organising today's Scrumtisch. If you are using Scrum and happen to be in Berlin - send an e-mail to Marion to let her know you are interested in the event, or simply join us at the published date.

Scrumtisch November

2010-11-03 04:31
Title: Scrumtisch November
Location: Berlin
Link out: Click here
Description: Next Scrum meetup - Scrumtisch - is scheduled to take place end of November in Berlin FHain. See you there (that is at La Vecchia Trattoria) if you are interested in agile development. Please make sure to register with Marion first.
Start Time: 18:30
Date: 2010-11-29

Part 4: Constant evaluation and improvement: Finding sources for feedback.

2010-10-24 08:13
In recent years demand for shorter feedback cycles especially in software development has increased. Agile development, lean management and even Scrum are all for short feedback cycles: Coming from the dark ages when software projects would last for months or even years before any results could be delivered to customers we are transforming development into a process that integrates the customer in the design and evolution of his own product. Developers have learned that planning ahead for years does not work: It's not only customers changing their mind so fast, it's requirements changing quickly. The only achievement from months-long cycles is getting input on your work later, being able to hide deficiencies longer.

However not only for planning and management does it make sense to install fast feedback loops. A few days ago I finished reading the book "Apprenticeship patterns". A book that gives an overview of various patterns that help improve software development skills.

One major theme was about getting fast feedback constantly. On the (agile) development side, automated tests (unit and integration) and continuous integration systems are technical aids that can help. Pair programming and code review take the idea of fast feedback one step further by having humans give you feedback on what cannot possibly be evaluated automatically.

There is just one minor glitch: With really short feedback loops any mistake you make gets revealed instantly. This is not particularly special to agile development. Another area with these kinds of fast feedback loops are projects developing free software - see also the last paragraph in Bertrand's blog on This is how we work at Apache.

There are developers who have a hard time living with exposing their work to a wider audience quickly. However it has the huge benefit of revealing any errors as early as possible - ideally at a point in time where fixing them is still cheap. Examples for options spotting mistakes early in various environments are listed below:


  • Open source development: Mistakes are revealed during code review of patches (or checkins).
  • Scrum: Speeding up error spotting can be implemented by closely integrating the product owner during each sprint. As soon as a feature is done - according to the developer team - it gets reviewed by the product owner this way reducing risk of features getting rejected during the sprint review.
  • In the team: Get each change set either mailed to all developers allowing for fast review of incoming code.


These are all good ways for feedback, however what about non-coding areas? Are there ways to build fast feedback into tasks that do not involve coding? I'll pick just one example to highlight some ways that facilitate fast feedback in a non-coding environment.

From time to time even hard-core coders have to meet face-to-face to discuss new designs, learn more about customers' requirements. This may involve going to conferences, giving talks, organising internal workshops, public meetups or even conferences.

Usually people doing the organisation are too busy to "watch what happens": They already drown in tasks to do and have no time (and are in no good position) to objectively evaluate the conference's quality.

Still there are ways to build feedback loops even into this kind of setup. Most of them have to do with communication:

  • Ask people to give you feedback in an official feedback form: Don't expect more than a fraction of the actual attendees to answer that form. Still it can be a source for honest feedback when done correctly. Include a few open questions, don't ask people to rate each and every task - they'll never find the time to do that anyway. Read the free-form comments - usually they provide way more insight than any rating question anyway.
  • Talk to people, ask for proposals on what you should do differently next time.
  • Watch what people are telling on the net - however keep in mind that those statements usually are a bit biased showing only the extreme ends of the spectrum.


The same applies to people giving presentations: Talk to people from the audience after your presentation is over. If your talk was video-taped, you are in a really great situation, as now you can judge for yourself what should be improved and where there are glitches in your arguments.

According to my experience people very rarely give explicit feedback - except when being really disappointed or extremely positively surprised. However when asked for precise feedback on specific aspects people are usually more than willing to share their experience, tell you where to improve and what to change. Usually it turns out to be a good idea to actively seek out people for evaluation of your projects to get better at what you do, to encourage peers to tell you what you do wrong or even where you could get slightly better.