Scalable Lean and Agile, QCon London 2011

qcon-londonToday was the first day of QCon 2011 in London that I attended. I thought about sharing what I remembered while it is still fresh in my head (and the head is buzzing with ideas).

Craig Larman spoke at opening note and at one of the sessions. Embarrassing that it is, I never heard about Craig before, neither I read any of his books. I did enjoyed the way he presented his material.

Craig was talking about scalable, distributed agile teams. Apparently he has a lot of experience working in this kind of environment, gathered throughout many years of his professional career.

Craig described a typical situation where delivery teams are physically located in different countries, working on the same project. In his presentation he provided practical tips for dealing with issues that rise in distributed environment.

The most important points that Craig delivered in his presentations are:

  • No disperse team – all the teams are sharing same goal and work as equal partners. There should be no hierarchy in teams.
  • Practices should be shared and guarded by Committees of Practice. Committee should have a leader that gets slack time to overlook the Practice and organize teams appropriately.
  • Software design should emerge as a collaborative work during workshops. Embrace open space in the office and lots of white boards.
  • Diverge and merge – teams should come out with design on their own sites, then they should hold Video, show and tell session with all the other sites.
  • When teams come with design on a specific part of the system, team leaders should work across all teams to have a common design for the whole system.
  • A documentation workshop after iterations embraces knowledge sharing and collective code ownership.
  • Avoid PowerPoint architects. Architects that are so far away from the code that they became architecture astronauts.
  • Component guardians are team members who look after code across all the teams, making sure that high quality is kept. If only one team takes care for only one component, the crap code is going to be maintained and accepted within. Teams needs to be cross component and cross-functional.
  • When components involve public interfaces, start with weakly typed, for example do ( aMap ). Once you know more and more code is stabilized you can make those more formal and strongly typed.
  • Continues integration is a must have.
  • There is a need to see the people across all teams. It builds trust and respect. Try to use cheap technology like Skype and web cams.
  • Team members should meet, rotate and travel to other sites.
  • Keep on thinking and adapting your methodologies and processes. Never retire.

Above points are mainly from the keynote Craig was giving. The second session was more about contracts and collaboration on “offshore” delivery model.

Some more interesting points:

  • Outsourcing development you will have to deal with culture, language, knowledge, domain, skills difference issues.
  • Address skills difference via internal education. Brown bag sessions or workshops made by more experienced team members.
  • Avoid single point of contact with the team. Visit teams before project kick-off. Physical contact is very important to create relationship.
  • Ask and rephrase questions in different way (or from different viewpoint) to test the answers.
  • Encourage team members to say no when needed, remove fear.
  • Don’t patronize teams capabilities by giving simple, disconnected tasks. This will reduce morale and make people leave, as they would think their job sucks.
  • Before project kick-off organize Domain Workshop (so the team can understand the domain) and Vision Workshop (so they can understand what to deliver).
  • Specification by example.
  • Make sure team is stable as much as possible (no leavers and joiners).
  • Make it clear that at the end of every sprint you are expecting a shippable product with the number of functionality developed.

Many of the things that Craig was talking about can be found in his book “Scaling Lean and Agile development”.

Many more info and a good introduction to Lean Software Development can be found at Crag’s web site. You can also enjoy a video of him telling a bad joke 🙂

Cheers, Greg