Making Agile work in Travelstart Development
If you know Travelstart, then you know that it is a company with plenty of vision, passion & drive. The company loves reinventing itself and very quickly responds to challenges. Development had already adopted Agile, but for some reason, it didn’t quite work yet. In this article, I want to address the biggest changes we made to become successful.
Focus
Travelstart is a fantastic place to work as there is always something going on. The office is buzzing because of campaigns, action days, issues and new initiatives. Being a technology company implies that development gets a fair share of that action. Issues need to be resolved a.s.a.p. and new ideas often need attention today rather than tomorrow.
It takes a developer 45 minutes to get into a zone where he or she is effective. You want to avoid that developers are disturbed when they are concentrating. This does not only result in lost time but also increases the risk for quality issues.
You also want to limit the number of items in progress. The more items someone has in progress the more context switching is required. Context switching is also an important reason for delays or quality issues.
We try to keep the development area quiet for a few hours a day to allow teams to concentrate. Our building also has plenty of lounge areas, where developers can sit away from the team. To ensure that we can act when real emergencies occur, each team keeps a small buffer available in their sprints.
The Team
Being a growing organization meant that Travelstart relied on a number of experts, each with their own skills and experience in their own domain. This obviously creates problems when the experts are going on a well deserved holiday, are sick or decide to move on to other challenges. People were organized according to their skills and deliverables moved from one team to another (e.g. back-end to front-end to QA).
Agile works best when you have teams that have a clear focus, that are self-sufficient (i.e. multiple skills in the same team) and that are organized to continuously improve. To have well-performing teams is sometimes a real challenge as you have to carefully consider personalities, skill levels, and each team member’s personal preferences.
In Travelstart we aim to have teams that feel empowered to make a difference. Teams focus on specific business areas and work close together on estimations, planning & delivery. At the end of every sprint, the team does a retrospective where everyone’s opinion counts and contributes to continuous improvement.
Separate the Why from the How
In Travelstart, but pretty much any other company I’ve worked for so far, people pride themselves in finding solutions to problems so all you have to do is implement the solution.
While thinking in terms of solutions instead of challenges is a very positive thing in general, it doesn’t always help in software engineering. We truly believe in finding ways for Product Owners to come with a business issue or challenge (the why) and identifying the critical success factors that are going to result in a positive change. Good developers are able to understand those opportunities and think of the technical challenges involved (the how). What follows is a good negotiation where Product Owner and the team agree on scope (the What) and a solution where most of the why is achieved. Quite often you will find that 20% of the effort will result in 80% of the result or at least a good start to get feedback on the potential of the solution.
Visualization & Transparency
For nearly one year I’ve had the privilege to be coached by Menno van Eekelen and I remember so well how he introduced post-it notes, brown paper roles & whiteboards. After initially getting a lot of push-back, everyone soon converted because of the positive effect of visualization. When I joined Travelstart I saw the same issues I saw before i.e. lack of visibility of progress and planning and lack of clarity on the solution to everyone involved. Having seen how Menno solved this I did the same in Travelstart.
Visualization is key to good collaboration. White boards, Post-It notes and diagrams are all good tools, each with their own use. Post-It notes with clearly written keywords are very useful:
- Prioritization sessions are more effective by having participants rank different work items by changing the order of the Post-its
- They allow you to make retrospectives more effective by giving everyone time to write their own notes and present them to the group
- They allow for more democratic decisions by using dot voting i.e. have everyone give votes (dots) on their preferred item (e.g. an action or piece of work to be prioritized or a retrospective item that needs further discussion.
- They make standups more transparent as people have to physically move their work items on the board from one status to the next.
Save time by doing relative sizing
A lot of experienced engineers pride themselves in being able to provide reliable estimates that are ultimately related back to absolute numbers (e.g. a number of man-days. These sizings need to consider all requirements, technical complexity, resource seniority etc.
There are a few issues with absolute sizings; often the estimates are wrong because the real complexity & requirements are discovered as the work progresses. The second even more important reason is that this kind of sizings don’t include the whole team i.e. only the person estimating might feel the commitment to ensure that the real effort matches the estimate.
Relative estimates are a lot easier than absolute estimates. To start, take some work items recently delivered and ask the team to rank them in order of complexity. Take out items that are similar in size and now label these items for example with a t-shirt size (XS, S, M, L, XL). This baseline is very useful to compare new work items with. The next improvement is to use points instead of t-shirt sizes. This allows us to measure over time how much a team can deliver. In Travelstart we use the Fibonacci series to size all work items. This has some advantages over agreeing on a precise number. As the complexity of item increases, we can afford to be less precise and the team doesn’t have to worry about it. This allows us to move on over having to have endless discussions over every little detail.
These are the 5 biggest learnings for Travelstart Development. Agile & Scrum work well now which means we can focus on the real challenge: making travel simple!
