Agile Engineering practices are essential for succeeding with Scrum and ensuring that teams are capable of delivering a Product Increment at the end of every Sprint. Let’s walk through an 8 step approach to guide your team to adopt these practices and make them easier to learn and apply. Some of these steps you’ll be able to facilitate on your own. For others, you are going to need the help of a technical coach to help guide your team to technical excellence.
1. Train
In order for teams to adopt these practices, we must first start with training. Training like the Certified Scrum Developer – Agile Engineering Practices class exposes team members to these practices via hands-on coding exercises. Over 70% of the class involves building applications using these practices.
Now training is important for 2 reasons. The first is exposing team members to these practices. Yes, that is key.
However, what is more important is to get those aha moments. That is when team members truly understand how this can be beneficial. Typically in my CSD classes this happens on the second day. On the first day, we cover the core concepts and go through some exercises but participants might not see how this is applicable. On day two, these aha moments start to sink in. Team members now get it and are now trying to figure out how they can apply these practices with their own code base in their work environment. Without these aha moments there is zero chance of adoption.
However, training on its own is obviously not enough. Change is hard and there has to be follow up technical coaching. My approach is a variation of the Samman coaching method as described in the next steps.
2. Dedicate time
Developers are expected to go to training and then come back and spend all their time building the Product Increment.
On a day to day basis, developers on a Scrum team do spend their time building the Product Increment, but also spend time on Product Backlog Refinement. This is a key activity that happens throughout the Sprint. Developers are not only working on the PBIs to deliver on the Sprint goal, but are also spending time prepping for future Sprints. If the team finds itself regularly reaching the end of the Sprint without completing what they planned and keep rolling things over to the next Sprint, then it is likely because the team is not spending enough time on Product Backlog Refinement.
The other activity is continuous improvement. Scrum is not magically going to solve all the team’s problems. What Scrum will do is put a spotlight on all organizational and team disfunctions. And then via continuous improvement the team will slowly solve these problems. And that means the team must dedicate time to solve these problems. Things are not magically going to get better unless the team invests in continuous improvements. This falls in 2 categories, working on retrospective action items and working on T shaped skill sets. That is, expanding individual expertise so that team members can help out in other areas. For example, if a team member has back end development expertise, she works on getting better in front end development and vice versa. It’s not about becoming an expert in other areas, but becoming functional.
These won’t be split up equally. It will vary based on the maturity of the team. When things first start, the team will likely be spending a lot more time doing Product Backlog Refinement and continuous improvement. As the product backlog gets in good shape, the amount of time spent on Product Backlog Refinement will decrease and the team spends more time on building the Product Increment. Note that it will never go down to zero. As things get better, the team will likely spend about 10% to 15% of their time on Product Backlog Refinement to keep the Product Backlog in good shape. The team might spend another 10% to 15% on continuous improvement. So working on the Product Increment might start out at just 30% and slowly ramp up to 70% to 80% but never actually get to 100% because there will always be a need for Product Backlog Refinement and a need for continuous improvement.
The team can’t go from a training class to building Product Increments. It is just an unrealistic expectation. The team has to ease into it.
3. Improve via the Definition of Done
The Definition of Done often gets confused with acceptance criteria. Acceptance Criteria tells us when a requirement is complete. The Definition of Done is about the team’s quality checklist. How do we as a team build a quality product?
Ask the team what are all the activities that are needed to take all the code that is sitting on a developer’s machine and get into production or ship it to the end customer. What environments are needed? What kind of testing is required? What kind of approvals? Each team and each organization will be different.
From this list, ask the team which ones can be done per Product Backlog Item. That is, when an item is moved from in progress to done, which activities from this list can get completed. There will be items that are too expensive to do per Product Backlog Item, too time consuming, or too resource intensive, so those will be done just once per Sprint. There are other items that are going to be too expensive, too time consuming, too resource intensive to do per Sprint and have to get done later, maybe, once every 4 or 6 Sprints. This is considered Undone work.
This list is the team’s Definition of Done. It is transparent, clear, and grounded in reality. It highlights that based on the team’s current environment and current constraints, this team cannot deliver a shippable Product Increment at the end of the Sprint because there are additional tasks that still need to be done. So if the Product Owner is satisfied with the output of the Sprint, it is going to take another 2 weeks or 2 months to get the Product Increment delivered (depending on how long the activities in the release/undone work section take).
Now the Definition of Done is not static. The team is grounded by their current reality, yet they will continuously improve. Every 4 retrospectives or so, the team needs to pull up their Definition of Done and figure out how to improve on it by pulling items from the bottom and try to move them up so that they are included within the Sprint. These continuous improvements need to keep going until there are no longer any activities left in the release section. Once that is the case, then we have a high functioning Scrum team that can actually deliver shippable Product Increments at the end of the Sprint. There are other teams that go even a step further and try to push everything into the Product Backlog Item section and have nothing left in the Sprint section. Those teams are capable of releasing multiple times per Sprint or even multiple times per day. If teams get that far great! However, at a minimum teams have to get to having nothing in the release/undone work part, and have all the quality activities done by the end of the Sprint. Obviously, this won’t happen overnight. It will take time, but via the continuous improvement of the Definition of Done, teams tackle it one step at a time.
Check out the Definition Of Done Canvas for more on this topic.
4. Practice with Dojos
Dojos are dedicated learning hours for practice. This is needed because the production code is likely a big mess. For a team to take concepts they just learned in training and apply them to a messy production code base is unrealistic. With Dojos, we dedicate an hour a day to practice and reinforce what was covered in training in a safe environment. This builds up the skills learned in training. It might be pairing, TDD, design principles, code smells, refactoring, working with legacy code, etc… Dojos are a way to prepare for the future for when the team runs into these situations with the production code.
5. Set Sprint goals
Many teams do not create a Sprint Goal in Sprint Planning. This leads to teams being just a group of people sitting next to each other working on unrelated items. A Scrum team works on things collaboratively.
Each Sprint should have a Sprint Goal. The goal should lead to a Product Increment that gets the team one step closer to the Product Goal or product vision. With a goal in mind, the team becomes focused on working together on a cohesive set of Product Backlog Items. Scrum team members help each other to deliver on a goal that delivers value instead of focusing on unrelated PBIs that have no value on their own.
6. Ensemble
With a Sprint Goal set, the team can start doing ensemble programming. This will be mandatory for 2 hours per day and done collectively on production code. In Sprint Planning, the team picks a candidate Product Backlog Item to work on. Ideally it represents a vertical slice of work that delivers end to end functionality and can be built without hand-off since the entire team is involved. Team members start learning from each other. There is sharing of domain expertise, design expertise, technical expertise, team norms, code conventions, etc. This also re-enforces the point that we are all in this together and working collectively towards achieving the Sprint goal.
7. Pair
Pair programming is also done on production code, however, this will be voluntary. In Sprint Planning, ask for volunteers to pick good Product Backlog Items suitable for pairing. Encourage pairs to have a mix of skill sets, senior with junior, mix of domain expertise, mix of technical expertise. Again, more knowledge sharing to improve quality and further breakdown silos within the team.
8. Own Continuous Integration and Deployment
The key for Continuous Integration & Continuous Deployment is that it should be setup by the team. Agility was all about bringing business and development together. When that happened operations was left behind. DevOps came about to address this gap and bring developers and operations to work together. So now we have the business, development, and operations all working and collaborating together.
Today there is this notion of a DevOps team. This is contrary to what DevOps is all about because now there is a handoff from developers to the DevOps team. DevOps is about people working together, developers and operations on the same team, side by side, not a separate team on its own.
The team needs to own the pipeline. If they don’t have the expertise, bring in the expertise, but don’t have them doing it for the team. This is about a transfer of knowledge so the team can own and maintain the pipelines. The team needs to be able to build, deploy, run, and maintain their own applications.
Slowly have the team build up the pipelines instead of relegating to another team. Bring in expertise, pair and rotate so its not just one person working on it but the entire team gets exposure and knowledge spreads across the team.
These are the 8 steps to guide your team to technical excellence. Over time, these practices will change. In the beginning, it’s an hour of Dojo each day along with 2 hours of ensemble programming and voluntary pair programming for the rest of the day. This is the schedule for 4 days of the week in a 2 week Sprint as having these also on planning days or review and retro days will be too much.
Over time, with dojos, we move to 3 times a week, then maybe twice a week and then once a week. I don’t recommend we go down to zero as there will always be something to learn and practice on.
With ensemble programming, I recommend eventually moving from mandatory to voluntary. By that time, the aha movement has sunk in, the team is used to collaborating instead of working in silos, and they will want to work in this way based on the upcoming work ahead.
