Inductive Bias

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 <20 vacation days, we have fixed holidays, she as a C?O of course wants to avoid customers being left alone when the whole team is on vacation.) Andrea re-phrased agility a bit here. His proposal was to not allow people to take their time off just anytime but to give them the freedom to figure out when to take time off. He identified five principles for leadership:

• 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.

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.

Just seen it - the next Scrumtisch Berlin has been scheduled for 25th August 2010 at 18:30 Uhr. So far, no official talk has been scheduled, so please expect two topics on Scrum and its application to be selected for discussion according to Marion's agile topic selection algorithm.

Please talk to Marion Eickmann if you would like to attend the next meetup.

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.