I start this post with a metaphor “Your Sprint is like your Ice cream bowl“. You generally fill ice cream in the bowl, and also add some toppings on top of it, why? Just to make it taste “awesome“. I am going to apply this metaphor to the Scrum Teams to make them “High Performance Teams” through adding engineering practices on top of your backlog items delivery in a sprint.

What happens in Scrum? Teams have limited capacity in the sprint. During the sprint planning meeting, they pull items from the product backlog based on the items’ priority, team’s capacity, try to convert them into potentially releasable product increment at the end of the sprint, by following the Scrum events (Daily Scrum, Sprint Review and Sprint Retrospective).

But is this enough? Do all teams always deliver potentially shippable product increments just by following Scrum events? Perhaps not always. It’s just that you are like a plain ice cream in the bowl, that tastes normal. However, if you want to call yourself as a high performance team (just like toppings added ice cream taste), you have to include some important engineering practices.

Why engineering practices? Engineering Practices make your Development Team’s life easy and happy, trust me! Reason – It helps to keep your design simple, you can keep your code base maintainable, anyone can make changes in anyone else’s code without any issues, not only that you can release high quality product increments frequently into production seamlessly.

Okay, where do I start and what practices I need to consider for my teams? My suggestion would be to begin the engineering practices as soon as possible in your Scrum journey. The early, the better. Just find what suits your team well and add value. Pick them up and start implementing them one or two at a time.

Here are some engineering practices that you can try with your teams.

  1. Pair Programming:

Pair Programming is one of the wonderful practices that helps your team to write code with high quality. Reason being, one person writes the code (driver) and the other reviews then and there (navigator). This avoids any design, performance, defect related scenarios while the code is getting produced. So this helps to reach “POKA YOKE” (mistake proof) from the beginning. Not only that, your team gets familiar with the entire code base if you keep encouraging the pair programming practice with moving people around. Doesn’t it cost me more? Of course yes, but the amount of testing time, code review time, bug fixing time you save is much higher than this cost. So you need to see trade off and make a decision.

  1. Test Driven Development (TDD):

TDD helps the teams to create a safety net around their code. If you practice TDD in your teams, they get a high level of confidence to make changes as and when there are code changes needed. TDD helps keeping the cost of changes low and also to handle the technical debt. How? The automated tests will help your code as a safety net and whenever you make any change in the code, if any of these tests fail that means your code changes causing the failure so you can immediately fix the code. But make a note, you will never start your code first, rather you write your first test, make it fail, then write code to fix the test, then refactor and then continue with the next test. If you write your entire code first, then write corresponding tests, it is not useful and vice versa also not useful. Tests and code must go hand in hand. Also make another important note, when you find a bug at any point of time, add it as a test to the test cases. This helps arrest the repeated defects. Make sure to create your test suite in such a way that they satisfy: Isolated, Automated, Decisive, Repeatable etc principles.

  1. Simple Design:

Agile principle #11 says “The best architectures, designs and requirements emerge from self-organized teams“. Yes, it is true, but it depends on how really self-organized you are! Make sure your design and architecture progressively elaborated and keep them simple but scalable using design patterns. Follow YAGNI, DRY etc principles. I suggest keeping your system design visible using lego blocks. This helps your team to come up with optimal solutions when they need to develop new features. During backlog refinement or discussing the design changes during sprint, the team can stand around the lego block design table, discuss which layer gets affected for the new features and what should be the best approach to keep it simple. Keep your modules loosely coupled through API/Web service based communication. Challenge complexity and try to simplify through architectural and design principles. Less is more!

  1. Refactoring:

XP (Extreme Programming) recommends “Mercilessly Refactor”. So you need to encourage your teams to refactor your code often. How often? In fact it should be part of your TDD’s third step (RED, GREEN, REFACTOR).  What happens if I do not refactor? Simple, you may hit roadblocks in future and your team’s velocity drastically goes down. You will be fire fighting rather than delivering new features. Who should refactor the code in my team? It’s everyone’s responsibility to refactor their code as and when they write. Any code your team creates, it should have automated tests and should be refactored. This will help to deliver high quality and easily maintainable code.

  1. Coding Standards & Code Review:

This is the simplest practice your team can follow immediately. All you need is to agree as a team on what standards you want to follow and corresponding guidelines. Just make a habit of following those standards whenever you write code. At the same time get the code reviewed by someone in the team so that it helps to see if it has any issues, two more pairs of eyes is always better. You can use tools such as SONAR for finding the code review, dead code, optimization related issues and this will also save a considerable amount of time. Manual review helps to enhance the knowledge on the code to the whole team over a period of time.

  1. Feature Toggles:

Feature Toggles (aka: Feature flippers, switches, bits, flags) help you with hiding the partially implemented features when you work in a continuous integration environment. If you are working on 2 weeks sprints cycles and one of your features takes more than 2 weeks to complete and you want to release only after the entire feature is complete, then you can hide the feature related stories using this toggles concept. How does it work? Very simple, it works through configuration files. You create a configuration file with a set of toggles for different features that are pending or you don’t want the end user to see them. Most of these toggles will be used in the user interface layer. While using this practices, you need to make sure to do a few things that include: Test your code with toggle on and off, maintain these toggles in configuration file and remove the unwanted toggles.

  1. Continuous Integration:

Continuous Integration helps you to be able to reach Continuous Delivery and you can make more frequent releases of your software. Encourage your teams to integrate their code into a single code base every day multiple times. Why should I care? It saves a lot of time in terms of addressing integration issues. Imaging, your team is developing code in their local laptops/desktops and their code works fine in their machines. When they integrate it after huge amount of code is developed, does it guarantee that all the combined code works fine? Not always. Hence integrating often will help you to get feedback on integration issues so you can save effort and ensure your code is really potentially shippable. Remember: Agile principle #1 says “Our highest priority is to satisfy the customers with early and continuous delivery of valuable software“. Watch the two key words in the above principle: EARLY and CONTINUOUS. Also, principle #7 says: “Working software is the primary measure of progress“. How much code works fine in my local laptop does not matter, how much integrated code (features) work fine in the integrated/production environment is key. So, if you want to achieve these principle and delight your customers, you need to adopt the continuous integration practice.

  1. Small Releases:

I read somewhere, if release is a pain, do it often. So do not be afraid with the release of your software into production. In the beginning you may get issues but I am sure the above principles will help you to achieve daily multiple releases as easy as eating a butterscotch ice cream 🙂  Automation of the build process, automated sanity and functional test cases etc also will help you to release often painlessly.

So why late, go ahead and add the above toppings to your scrum teams and start enjoying the awesome taste and become high performance teams.

If you are a Scrum Master or Agile Coach, try to help your teams understand the “Why” (Purpose) of implementing the above engineering practices. When they understand the purpose, it will be easy to drive these practices through implementation by the teams easily.