Being Agile, The Efficient Way

Introduction

A lot of software development teams follow the Agile Methodology for their day to day development but only a few of them do it the correct way. You ask any developer, most of them don’t know why they are following Agile apart from their company or the customer telling them to do so.

Being agile in software development is a great thing, but only when you do it right. There are a lot of success stories available to get inspired with, but getting inspired is a lot different than getting productive.

In the upcoming content, I discuss on what you should do to be efficient while being Agile in your development process.

Background

If I would have to give you a quick overview of what Agile is, we normally follow development cycles generally called as a sprint, of a fixed amount of weeks. This is on a continuous basis and the target is to implement, test and deploy a particular unit of work at the end of every sprint.

What Agile Should Be for You

Efficient Planning, Segregation and Accountability

These are the 3 cornerstones of our Agile philosophy. We plan for our work before-hand. We break down the work into appropriate tasks which could be implemented, tested and deployed in one sprint and encompass multiple tasks into a user story. A user story normally spans across sprints. We track the progress of every task individually with the accountability for end to end completion being the onus of the Assignee.

Stages of Agile

Typically, there are 3 stages to an Agile software development life cycle.

• Before the sprint
• During the sprint
• After the sprint

It is really important to understand what exactly should be done, and when, to yield maximum results. According to me, tweaking the traditional scrum processes according to your project/product needs is very important given the above 3 cornerstones are properly maintained.

Before the SprInt

The only activity related to a new sprint that we follow right before the start of the sprint is the sprint planning which consists of following activities:

Capacity Planning

This activity is all about how much work can we do in a particular sprint.

What We Do

• Clearly articulate the team/ individual capacity by bringing into account planned vacations and public holidays.
• Decide the optimal split of work based on the team’s collective availability. And not manipulating the availability by cancelling leaves / rescheduling important trainings based on the total work.

How It Helps

• This gives us a holistic view of what the team can complete in a particular sprint and helps in proper segregation of work.

Task Estimation

When we start with this activity, we make sure that we have already decided on what must be achieved in this sprint (also called as grooming).

What We Do

• We go through all the predefined tasks and try to provide kind of an estimation on how much hours would it take to complete. We follow a planning poker kind of a system where we anonymously take estimates of a task from everyone and move ahead with the majority.
• At the end, we assign tasks to team mates based on individual capacity (not on technical prowess) and move stuff to backlog (place where we keep all planned but unsegregated work) if the overall work is more than the collective capacity.

How Does It Help

• It makes sure that we prevent creation of future technical dependencies to particular resources and everyone gets to do good work.
• This also helps us to maintain a positive team decorum by promoting work life balance.

During the Sprint

Normally, you would think that this time is only to work on estimated tasks and complete the planned work. But believe me, you could not be more wrong. This is the time where major heavy lifting should happen.

Grooming

Here, we introduce the role of a Scrum master / Team lead (aka Tech Advisor) and a Project / Product/ Program manager (aka the Stake holder). What we do here will decide on how the next sprint would go.

What We Do

• Tech advisor and the stake holders would get together and plan on what work has to be delivered as part of the next / future sprints based on the project / organization’s goals and priorities.
• The stake holder helps in setting an acceptance criteria of every individual work item and Tech Advisor takes care of segregating them into isolated tasks which can be delivered as part of the sprint.
• The Tech advisor takes care of adding a proper description to a task and also capturing the mentioned acceptance criteria.

How It Helps

• This gives us a holistic view of the upcoming work and helps in its proper segregation.
• As we have everything planned, we can avoid acceptance of ad-hoc / mid sprint tasks which usually are collaboration requests from other teams or urgent unrealistic customer requirements (normally for a customer, every requirement is pretty urgent).
• It gives a chance for the team to ramp up on new technologies before actually taking up the work as they would have a vision of what they might have to work on in future.

Daily Stand-Up meeting

A repetitive but quite essential part of Agile methodology, particularly Scrum.

What We Do

• Every day, before starting work (ideally around 9 – 10 AM), the entire team gets together and talks about the current progress on their work items.
• Three points are covered here.
  • What I did yesterday?
  • What I’m planning to do today?
  • Are there any blockers?

How It Helps

• Keeps everyone updated on the overall sprint progress and gives out early indications of work which might get delayed for delivery due to whatever reason.
• Helps the team by giving a forum to collaborate on resolving dependencies of one developer with another.

After the Sprint

This is the time when we look back on what we did last in the Sprint and how can we better ourselves.

Sprint Demo

As the name suggests, this is where we get together and demo stuff that we have worked on. This part is especially important when we have multiple higher-level stake holders like Product Owner, Engagement managers, etc. involved deeply in the venture. For smaller teams and isolated teams, I would suggest this to be an optional activity, but it is still recommended that the team goes through the demo.

What We Do

• Tech Advisor nominates the work that should be demoed at the end of the Sprint. Individual developer takes the responsibility for his demo able part.
• The entire meeting would not be more than 1 hour for multiple demo able features and 30 mins for a single big feature.

How It Helps

• Everyone is aware about what has been accomplished as part of the agreed upon work. Developers get to know about any re-usable code implemented as part of the demoed task that they can leverage.
• Higher management gets a picture of where the delivery of a project / product stands as of that time and provides them confidence to market the same.

Sprint Retrospective

Retrospective is like the step child of the Agile process for almost every development team. It gets ignored the most. Retrospective is another important part which should never be skipped. Normally, we take 3 types of inputs from every team member. What went well, what can be done better and any immediate action item. A typical retrospective should not be more than 1 hour.

What We Do

• Go through the work items of the Sprint and see if there is anything spilling over to the next Sprint. We capture reasons for the spillage and make sure it doesn’t happen again.
• Open the points on what can be done better from the previous Sprint and discuss if we had any progress on it.
• Next, we go across the table and ask every developer their thoughts on what went well, what can be done better and any immediate action item.

How It Helps

• This makes sure that we are on the right track with our process as well as development. Calling out what did not go well, particularly helps us in avoiding the same issues in future.
• Helps us in identifying continuing trends and external factor which might be pulling down the overall velocity of delivery.

To Conclude

Essentially, the whole Agile process is like weight loss. When you begin, everything looks difficult and the goal looks quite unachievable. You have to sacrifice on a lot of things to stay on track but once you start seeing results, you know you are heading in the right direction.

There are multiple things that I didn't cover here like discussions on the Velocity and Burn Down charts or teams having sessions quantifying team morale, motivation and other parameters. I just believe that spending time there is not very productive.

If you have been working in Agile model from some time, you would already be following a bunch of the above stuff but are still here as you don’t see proper results .If your team follows everything mentioned above dedicatedly, you will surely witness the miracle of work getting done on time every time.

History

• 20^th January, 2019: Initial version