Tag Archive for Agile

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.

Understand Scrum in a simple metaphor (Medicinal Agility)

I and my colleague Madhavi were discussing in general about Agile and Scrum last week. During the discussion she has suggested that it will be nice if there is a simple explanation about Scrum framework using a common language that makes the concepts easy to anyone. During the discussion we had come up with below explanation.

This article is also published in scrum alliance website:

The Metaphor:

Assume that if some falls sick, he/she visits a doctor for clinical check-up and follow the doctor advice to get well soon. So considering this scenario, we tried to explain the Scrum concepts.

1. Find out which medicine suits your body? [Which framework should I use? Scrum or Kanban?)

Which flavour of Agile is suitable to your team should be analysed first. It is as simple as just like we have various flavours of same drug like paracetamol, Colpol, Crocin for curing fever and not every medicine suits you. So what do we do? We first try with one flavour and experiment with it for some time and if it suits your body, then we continue with it until you are completely recovered.  Else we would try a different flavour.

Exactly similar, is the case with Agile. We do some initial study, start using scrum or Kanban and see how it works for a sprint and then decide whether we want to continue with it or use a different method. Of course if you clearly know you cannot plan at least for one week then you better go with Kanban model, else Scrum.

2. Find out what dosage suits your body? [What is the Sprint Cycle]

Based on various factors like age, weight and intensity of fever, we decide on the dosage of the medicine to be used. Similarly based on factors like how long backlog can be fixed, how often requirements can change etc., the sprint cycle duration needs to be worked out.

If we haphazardly vary the dosage i.e. if we take one dose of medicine today and two doses next day and skip the does in between, the ailment that we are trying to cure becomes worse and the situation goes out of control and our body may develop resistance to that medicine. Similarly, if we try to vary the sprint cycle haphazardly from 1 week, to 2 weeks and back to 2 weeks etc. frequently without having any rhythm, it would be very difficult to see the results and the project would become unpredictable and may end up in a chaos.

You may experiment for a couple of models and fix to one model.

 3. Planning and Execution as per the dosage: (Sprint Planning/Daily Scrum)

After the flavour and dosage of the medicine is decided, doctor (Product Owner) advices the exact medicine names that need to be taken and in what order as per the priority i.e. may be a multi vitamin tablet first followed by an antibiotic etc. We go ahead and take the medicines that is consume them in however way we want, i.e. some take them with water, some may make it a powder and dissolve and drink, sometimes you mix it in food and give to kids. So if you observe the scenario here, the WHAT part is being decided by the doctor and the HOW part is decided by the person taking the tablet. Similarly, in the sprint, WHAT to achieve is decided by the Product Owner and HOW part is decided by the team.

4. Re-check and Feedback on how did the medicine work (Review & Retrospective):

After the completion of the medicine course for the given period, we go to the doctor for re-check up to evaluate how the medicine worked and if the tablets or dosage needs to be changed for the next cycle if needed.

In a similar fashion at the end of the sprint you will give a demo to the Product Owner and the team will conduct a retrospective to inspect and adapt.

5. Daily alarm for the consumption of medicine (Daily Scrum Meeting):

In order to have effectiveness, you take medicine at same time and same dosage every day. For this, you may have some mechanism like mobile alarm to remind you. You might check the progress in your health day by day.

Similarly, in Scrum you will have daily scrum meeting for timeboxed duration (up to 15 minutes) and share everyone’s update and the by-product of this meeting is the status of the work progress.

Conclusion: The scrum framework is very simple common sense which we really practice day in and day out in some or the other way, so maybe we just need to make a good quick short experiment to figure out what suits our nature of the project and execute it the right way and it would really work wonders. However, do remember that it is really hard to master in Scrum unless you have thorough understanding on Scrum Values and follow the framework with a high level of discipline and passion.