Instilling Change in Development Teams
In this day and age of internet and computing, things move really fast. Innovation requires you to constantly reinvent yourself. Staying still will get your company killed. Change is the only constant.
We’ve all heard variants of these cliches over and over. They do however hold the key to longevity in business — adapt to change and avoid the status quo.
On the other hand coding for a developer is similar to writing for a novelist — it requires continuous and uninterrupted time of deep concentration and productivity. Getting in the zone like we say. It isn’t possible to do that with constant interruptions. From an eager sales executive distracting your dev team with feature requests for example. Or a manager wanting to stir things up in the middle of a sprint.
Fortunately agile development provides us with some mechanisms to introduce change in a controlled manner. Over the years at Amilia we have put in place mechanisms to introduce change in development teams. These are change management tools available at different levels of an organization:
- Company-wide via feedback in sprint reviews
- Across the dev department through communities of practice and continuous integration
- Within a dev team through sprint retrospectives by adding to the definition of “Done”
- Between developers themselves via code reviews
Let’s start bottom up.
Code Reviews
Every improvement, new feature or bug fix goes through a code review — an occasion to review a functional or non-function changes to Amilia. The developer first commits their code and creates a Pull Request against the master repository. Other developers can then review the new or modified code.
We use GitHub for source control and the pull request workflow has really enabled us to collaborate. Developers comment a lot on PRs in order to improve each other’s code.
We have one rule regarding PRs at Amilia: you can’t merge your own. Another developer must review your changes and merge them. We strongly encourage reviews across teams as well. This provides a human safety net.
Continuous Integration
At Amilia we have a very sophisticated Continuous Integration system built upon Jenkins. Its also fully integrated with GitHub and JIRA. For a growing company, CI is crucial. It builds and runs tests on code changes introduced by developers automatically. Its the automated safety net we continually improve to catch bugs and failures to follow best practices. As Michael, a member of the DevOps team, points out:
As we grow, it’s not really effective any more to say “Hey, we do it this way now” in a Slack channel where there is almost 40 devs and growing compared to when it was ~10. It’s easier to onboard new devs if their build fails when they don’t follow a best practice.
Case in point, along time ago we decided as a dev team that controller methods should always run inside a database transaction. Its a best practice that unfortunately wasn’t always followed. Developers, especially new ones, tend to forget.
It took some boilerplate to implement but was a small price to pay to ensure database integrity. The DevOps team made it simpler by introducing a few dedicated attributes. For instance, the[TransactionFlushOnCommit] method decorator removed the boilerplate.
As easy as it was to add the attributes before class definitions and methods, developers kept on forgetting. The DevOps team had to constantly comment on PRs that it was missing.
Michael got tired of this. He added an automated test to enforce the constraint. Today when a new controller method gets added without the required attribute, the automated tests fail. The PR shouldn’t get merged. Brilliant and simple idea. Change was introduced and an automated fail-safe was put in place to enforce it in our build system.
Other developers, even outside of the DevOps team, have started adding more of these best practice checks into our builds. Our CI improves daily and this allows us to keep introducing code changes rapidly while ensuring quality remains high.
Sprint Transitions
Like many tech companies we introduced SCRUM years ago. As any young dev team, it took some time to properly get SCRUM up and running. Two years ago Alexis, an avid SCRUM disciple, joined Amilia and really helped to grow SCRUM within teams. Sprint planning, reviews and retrospectives are now religiously well executed. Sprints typically last 2 weeks and are uninterrupted. This allows the team to focus on the tasks at hand.
The Sprint Review is the time for stakeholders to look at what’s been done and provide feedback and guidance. Its the time to make sure the dev team is going in the right direction.
The Sprint Retrospective occurs after the sprint review and provides a “formal opportunity to focus on inspection and adaptation”. Its also the perfect time to introduce change through the famous Definition of “Done” also know as DoD.
Last year developers identified quality as something to improve. Automated testing was the means to that end. Writing more tests was deemed crucial and Code Coverage became the way to measure that. Developers therefore added automated testing to their definition of “Done”. It took a few sprints for each team to add automated testing to their DoD.
During sprint reviews, developers would showcase the improvement in test code coverage. Over the course of the last year, we managed to augment coverage from 28 to 37% even though the code base grew by 20%. This has dramatically reduced the number of bugs on new code we release. Quality has gone up.
Another change we introduced was around capturing metrics to help the Product team make data-driven decisions. One of Product’s 2018 goals was to make decisions based on data more than intuition. Product asked developers to find solutions to that problem. Developers decided to add logging to their definition of “Done”. This helped the team to produce graphs of feature usage and adoption. Like this one:
These metrics not only helped the Product team in their decision making process, they also encouraged and guided developers. Stakeholders as well benefited greatly — they could see the adoption rate of a feature. It gave them confidence the team was going in the right direction. It also backed by data pivot decisions.
Community of Practice
Amilia now has 6 developer teams working on different parts of the platform. It was apparent that inter-team communication was crucial to ensure everybody was coding the same way. We had to avoid building silos.
Developers quickly identified that as a problem. In response, they created groups called Community of Practice or COPs around common themes: testing, front-end and back-end. A COP is composed of one delegate from each team. They meet once a week to discuss problems and propose solutions. Delegates introduce change in each team.
Increasing quality was one thing identified by the Test COP. The solution was to write more tests. As described above, the COPs used the sprint transitions to gradually introduce testing to their DoD.
The COP is a grass roots movement. Organized and run by developers. Its a beautiful mechanism allowing self organization. Bottom up, not top down.
Collaboration Across the Entire Company
The mechanisms of Code Review, Community of Practice and Continuous Integration are really internal to the dev/product department. Sprint transitions however span across the entire company. We make sure everyone in the company gets to be a stakeholder and attend a Sprint Review at one point. The teams identify stakeholders during sprint planning.
For example recently the Goal Diggers team worked on improving the Client Import Tool so important during onboarding of new clients. Internal users of the Import tool were interviewed before sprint plannings. They were also invited to attend sprint reviews to provide feedback and help guide the team in building the right thing.
Goal Diggers had great ideas on how to reinvent the Client Import Tool to simplify the process. But it would have taken many sprints to get there. Stakeholders guided them towards improving the existing tool instead. The team was disappointed, understandably so. However time to market here trumped exploration.
Taking a step back I see this episode as a great example of collaboration across departments. It would not have been possible without the “stop and inspect” step offered by sprint transitions.
In my mind the Sprint Transition is the most valuable development process a company has to introduce change. Sprint Reviews allow every interested party to get involved in a controlled manner. At the same time, Sprint Retrospectives allow the dev team to change the way they work and improve themselves. A well executed Sprint Transition paves the road to success. A great tool to fend of Day 1.
Thanks to Michael Broadbent, Vincent Asselin, Nathalie Parmentier and Isabelle Carrier for examples and draft review of this blog post.
