On the ground with Agile: Enabling small teams to have a big impact

Agile is a “mindset” in five key ways:

• A mindset to deliver value to customers with each sprint/iteration.
• A mindset to accept change in daily working habits religiously. 
• A mindset to be transparent with stakeholders.
• A mindset to work out ways of improving as a team.
• A mindset to work as a cohesive unit to achieve a common goal.

To understand the phrase “small team, big impact” better, let’s consider a team that has to be accurate and precise every time, without fail: the military. They execute operations in small teams with defined roles and responsibilities given to each team member. If anyone in the team says, “I will not cover/support another team member, as I have been given only one particular responsibility” the whole team fails. This will impact not just the mission, but potentially also the lives of team members.

Taking this analogy to software development, although we don’t face the same threats as our military does, we may hear from team members that his/her responsibility is only to code or to test. Having this attitude increases the chance of failure, leading to team failure with all the spillovers and missed commitments that this entails. Organizations therefore, need to develop cross-functional teams with an Agile mindset, that succeed more and fail less. They can do this by making sure every team member is there to support each other during planning and execution – while also monitoring, and controlling for, deviations which might impact deliverables.

Agile helps us do this by providing different methodologies and techniques that help us work together as a team and deliver product incrementally. In the rest of this article, I will go through a couple of frameworks and methodologies prescribed by Agile and come up with an approach to help us create our own framework within Agile guidelines. From a product development standpoint, Agile recommends Feature-Driven Development (FDD). Feature-Driven Development is defined as a “practical Agile approach suited for long-term, complex projects. It is a suitable choice for development teams seeking a simple but structured Agile method that is scalable and delivers predictable results”.

FDD follows a 5-step process that guides businesses and teams to come up with a strong product backlog that delivers value to the customer.

1. Develop an overall Agile model

In this first phase, the team works together to develop detailed domain models, which should include artifacts and details of research. These details will then be merged into one overall model that acts as a rough outline of the system. As product development is incremental, the team adds details as they continue to learn over time. To transform the overall domain model into the software development lifecycle, the team should segregate the details under “epics”, which is a known term used in tools like Jira and VSTS that support Agile development.

2. Build a features list

Using the information assembled in the first step, business teams determine the list of features that will be part of the product backlog. Product owners play a critical role here, as they work with people from the business side to make sure that every stakeholder is on the same page and all the requirements are captured. It is worth noting that the features list may be long – it can capture the smallest details that the team have researched and could be helpful in planning the releases. The team categorizes these features under epics with feature labels/tags that are created under the tools, and which are then used for software development.

3. Plan by feature

This third step defines the way the team will build the product. It translates to the incremental releases and timelines for bringing a product to market. There are several steps here:

1. After creating the features list, the Product owner makes sure that the features are prioritized according to their return on investment. This is the value that will be obtained by investing in each feature.
2. Techniques like MoSCoW, Kano and artifacts like Parking Lot Diagram help business teams and Product owners to come up with the minimum marketable feature (MMF) and minimum viable product (MVP).
3. Once the features are finalized, they are put under different releases. These releases are labeled, as per the priority given by Product owner and business stakeholders. 
4. As team involvement increases throughout the first 3 steps in FDD, the features are broken down into multiple user stories. These stories are sized relatively with the help of different techniques like Fibonacci Series and T-Shirt Size estimations by the team, product owner and all the required stakeholders. This exercise provides the tentative size of the upcoming release. 
5. This helps the product owner to come up with the release end date (predicted / optimistic / pessimistic) with the help of the previous velocity of the team, if known, or with the help of capacity planning.

Following these three steps, when the development team is ready to start working on the product backlog, we can go ahead and introduce a framework that is commonly used these days in software development: Scrum. The Scrum framework absorbs the remaining 2 steps from FDD: Design By Feature and Build By Feature, as part of the iterative development to get the product increments and releases out to the market.

Scrum is divided into 3 steps, as highlighted in the above image. 

1. Pregame phase

This phase is mostly related to the product backlog, which was derived from the first 3 steps of FDD and makes sure the backlog is always refreshed and updated. The team does this with the help of product backlog grooming meetings that have to be planned at least once every sprint of two weeks. The updated product backlog helps to plan and derive a sprint backlog for every sprint during the planning meeting that takes place before we start any sprint.

During the sprint planning meeting, the team sits together to finalize the sprint backlog, which can be based on previous velocity or capacity planning that helps every team to take on work in the upcoming sprint. Once the sprint backlog is finalized the team jumps into the development phase to deliver the committed sprint backlog items.

2. Development phase

In the development phase, the team takes up the user stories/bugs that are planned and makes sure that each ticket that is committed is closed post QA validation and signoff during the sprint. There are a couple of key steps to keep in mind:

1. The team meets for 15 minutes every day, which is called the daily stand-up to give the current status on the tickets for each team member. Each team member answers 3 simple questions.
   • What did I do yesterday?
   • What do I plan to do today?
   • Any impediments.
2. The artifacts used here to track the progress during the sprint cycle are the sprint board with required swim lanes (which should be customized as per the project needs) and burndown/burnup charts that show the sprint progress to date and the amount of remaining work.

3. Postgame phase

In this phase, the team focuses on testing for sign offs. The team takes on the sprint demos and shows recent work to the project stakeholders. Sprint retrospectives allow the team to reflect on the things that went well and the things that can be improved in the next sprint. This helps the team to develop more confidence.

Conclusion: deliver high-quality products with Agile

Software development teams can approach the product development life cycle in multiple ways. What I have outlined and detailed here has helped me and my colleagues deliver high-quality products over the years. The approach helps us to work on the ground with the teams and coach them to become the Agile teams that every organization strives for.