- Cross functional teams – A team must contain all skills required to take a feature from ideation to deployment. This avoids the need for handoffs to other teams and communication overhead.
- Iterative development – Develop features in bite sized chunks and aim to deploy every sprint (A sprint is a timeframe between 1-4 weeks)
- Transparency – Break silos by brainstorming ideas and planning for Sprints together as a squad
- Limit WIP – Productivity improvement due to decreased multitasking and opportunity to spot improvements
Agile borrows heavily from the lean methodology in manufacturing and aims to avoid waste. Waste could be due to picking up features that not required, inefficient processes, communication overhead, quality issues etc. During the initial training, I recognised several similarities to concepts that I has learned during the Operations Management MBA course.
My squad (teams in Agile are called squads) has made several improvements over the last year which have increased our development velocity. While some of the changes (avoiding handoffs, iterative development) came part of the process, others (continous integration, test automation) were a a result of the squad embracing the need for continous improvement. Here’s how we went about it.
Agile does something similar to drive improvements. It makes work visible by ensuring that large features are broken down into bite sized user stories and tracked using a too such as JIRA. The sprint ceremonies also a vital role in in improving transparency.
- Sprint planning – At the start of the sprint, the squad estimates which features will be deployed at the end of the sprint. This is entered into JIRA and it is visible to everyone throughout the sprint.
- Daily stand ups – Update the squad on what we are currently working on. We use the Kanban board to track the current status of user stories and be reminded of the sprint goals.
- Backlog grooming – Gain visibility into what is coming up in the next few sprints and collectively brainstorm.
Sprint Retrospective – During the retrospective the squad identifies what prevented them from achieving the goals. This feedback is then prioritised and we figure out the best way to address it. It was feedback that led us to embrace continious integration, mock testing, and increased test automation.
One important point here is to keep the number of features taken up each sprint down to a minimum. Only features that you think will be shipped should be taken up. Why? First, it reduces multitasking which is a known productivity killer. Secondly, “Inventory is Evil”. Having buffer, prevents you from identifying bottlenecks in the process. In lean manufacturing, inventory is compared to a lake that hides sharp rocks underneath it.
Imagine that your code reviewer falls sick. If you maintain a buffer of code reviewed features, then the QA engineer would never waste time waiting for a new feature to test. This seems good in the short term, but may hurt you at a critical time. In Agile you face the delay and then introspect on how to prevent this. For example, you could set up a process to ensure that there are multiple engineers who can code review a feature.
The retrospective is critical as transparency by itself will not drive change just as keeping track of you expenses by itself will not make you save more. You need to act on the information and make changes i.e. Adapt.