Inductive Bias

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.

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.

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.

Last week I attended a discussion meetup with Ken Schwaber in Berlin/ Kreuzberg. The event was scheduled pretty shortly - still quite a few developers and project managers from various companies in Berlin showed up.

Ken started with a brief summary of the history of Scrum: Before there was such a thing as an IT industry programming actually was a lot of fun. But somehow the creative job was turned into something people tend to suffer from pretty quickly as people tried to apply principles from manufacturing industries to software "production". Suddenly there was a distinction between testers, programmers, architects... People tried to plan ahead for months or even years noticing only very late in the process that the outcome was by no means what was needed when the product finally was ready.

In contrast to waterfall Scrum comes with very short feedback loops. It comes with developers working with very strong focus on one task at a time. Change is not hated but embraced and built into development.

Some features of Scrum that are often forgotten but never the less essential that were discussed that evening:

• Scrum is all about transparency - it's about telling your customers what is going on. It is about telling your customer honest estimations. It is about telling development to the best of your knowledge all that can makes up for a feature.
  
• Scrum is neither easy nor a solution in itself. It is simply a way of uncovering problems very quickly that are easier to hide in waterfall processes. You have one person who is an isle of knowledge in your company? At every sprint planning this problem will become obvious until you find a way to solve it.
  
• Scrum is about giving developers a box of time that is not to be interrupted. Developing software asks for a lot of concentration. Getting interrupted and resuming work on the task again is so expensive that there is close to nothing this can be justified with.
  
• A nice way of doing Scrum is to use Scrum for management and XP for development. Scrum does not provide any solutions on how to reach the goals set - it does not tell you exactly how to arrive at a stable release by the end of your sprint. It just sets the goal for you. On the other hand XP holds quite a few development best practices that can help achieve these goals.
  
• It needs time to change how customers and developers are working: Yearlong experience has trained them to think in certain ways. So at the beginning Scrum is all about teaching and training people. It takes time to learn a new way of getting things done.
  

There are ways to do fixed price contracts with Scrum. You just have a few more freedoms to offer to your customer:

• Tell your customer that your clients usually change their mind underway. Give them the freedom to change anything not yet implemented. An item can be exchanged with an item of equal cost for no increase in prize. An item can be exchanged with a cheaper item with a decrease of cost, it can be exchanged with a more expensive item for a rise in cost.
  
• Tell your customer that you already have pre-priorized items. The client is free to re-prioritize items as he wishes - as long as the item was not implemented already.
  
• Tell you customer that as you are implementing those items at first that have a high priority you may come to a point where those items not done are not important for release so he could eventually stop early and pay less.
  

In summary the evening was very interesting and insightful for me. It helps to talk about Scrum implementation problems. To learn which problems others have and how they attack these problems.