Add toppings (Engineering Practices) to your Ice cream (Scrum) to make it even tastier

I start this post with a metaphor "Your Sprint is like your Ice cream bowl". You generally put ice cream in the bowl, and also add some toppings on top of it, why? Just to make it tastes "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 shippable product increment at the end of the sprint, by following the other Scrum events (Daily Scrum, Sprint Review and Sprint Retrospective). Of course they also perform product backlog refinement activity.

But is this enough? Do all teams able to deliver potentially shippable product increments always? In my opinion, not really. 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 inculcate some good engineering practices.

Why engineering practices? Engineering Practices make your "Developer and Tester" life easy and happy, trust me! Reason - It helps to keep your design simple, you can keep your code maintainable, anyone can make changes in anyone else's code without any issues, not only that you can release frequently into production seamlessly.

Okay, where do I start and what practices I need to consider for my teams? My suggestion would be first taste the plain vanilla ice cream for a few sprints and get the taste of it. Then identify what engineering practices will help you to get to the next level. You don't need to implement all of the practices. Just find what suit your team well and add value. Pick them up during the next sprints. Remember! whatever practices you pick up, don't try to start all of them at once, you have to be iterative and incremental in this also, after all we are talking about Agile.

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 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.

2. 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 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 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 arresting the repeated defects. Make sure to create your test suite in such a way that they satisfy: Isolated, Automated, Decisive, Repeatable etc principles.

3. 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 elaborates and keep them simple but scalable using design patterns. Follow YAGNI, DRY etc principles. I suggest to keep 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, 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 simple through architectural and design principles. Less is more!

4. 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 road blocks 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.

5. 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 pair 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 considerable amount of time. Manual review helps to enhance the knowledge on the code to the whole team over a period of time.

6. 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 few things that include: Test your code with toggle on and off, maintain these toggles in configuration file and remove the unwanted toggles.

7. Continuous Integration:

Continuous Integration helps you to be able to reach Continuous Delivery and you can make more frequent release 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.

8. Small Releases:

 I read somewhere, if release is a pain, do it often. So do not be afraid with 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 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.

Thank you for your time to read this post...hope you enjoyed reading this. Please provide your feedback and comments on this post...Thank you.