Do you happen to encounter the following challenges in your agile delivery project?
- Issues are uncovered in the development phase or even after due to lack of communication between teams, which leads to a lot of waste
- The stories get blocked and the cycle time goes for a toss.
- The team tries to pull in new functionality from the backlog. This might also get stuck in any of the middle lanes(In Dev or QA or ready for Release).
- Thus time to release a piece of functionality increases significantly
I experienced such issues on a project and we tried to solve them by using the following methods.It was a learning opportunity which ultimately resulted in a very successful and enriching experience.
Kanban
We maintained a kanban board for stories in the software life cycle. We aimed to create small releasable stories. If the stories were too big, we split them into tasks.
Swarming - The devs swarmed on the tasks of the story. Swarming means that everyone in the team works of the same story at the same time. As a result, stories moved through the Development column faster. This ensured that we had releasable functionality before picking new features.
WIP limits - Each column in the swimlane had a Work In Progress (WIP) limit based on the number of people working on that stream. For instance the Quality Analysis (QA) lane had the WIP limit set to one as there was one QA on the project who could work on just one story at a time. If some column was full to capacity then the team shared the work and helped unblock those members.
Third party blockers - We also had a lane for third party blockers. Our application was dependent on other systems. This meant that stories we were planning on playing got blocked in Ready or even during development. We put these stories on the 3rd party blocked lane to ensure increased visibility. This helped us follow up and resume work once we were unblocked.
Expedite - The expedite column helped us work on priority feature requests or critical bugs. Each story takes some time to go through all the lanes before the story releases. Sometimes, a critical bug or feature request came through which took priority. Hence the bug/feature was critically analysed by the entire team before categorising it as a potential candidate for expedition. The team had to drop all other tasks and work on this story. At one time, only one story was allowed in that column. If all stories were expedited then the stories on the wall would be ignored for a long time.
User Feedback
It is important to seek user feedback as early as possible. In fact, by demonstrating prototypes to users, the team was able to receive feedback before actual development started. If the feedback was positive we went ahead with the designs. If not, we knew what changes were required. This reduced wasted development time. The prototypes also gave the team a clear picture of the feature that we were supposed to deliver.
The Four Amigos
In the A&D phase of the story, a developer, QA, Business Analyst (BA) and Experience Designer (XD) met to discuss the acceptance criteria (ACs) for the story. The BA would explain a happy path journey. The XD came up with the designs. The QA mentioned the ‘what if..’ scenarios and the expected outcomes were captured. The developer explained the implementation, what would be easier to include or exclude in the story and also gave inputs on how to split the story into tasks if needed. Only after this discussion, the story moved to the analysis and design done phase. This ensured that there was clear communication between all the parties involved. As a QA it helped me identify potential bugs before development. The developers ensured all the ACs worked as expected before passing the story to the QA. Ambiguities were resolved in this phase, saving the expense of making changes after development had finished. There is some investment, however, the benefits to the team were greater.
Cross functional teams
The four amigos flows into the concept of cross functional teams. A cross-functional team is a group of people with different functional expertise working toward a common goal. In this context, the developer, BA, QA and XD comprised the cross functional team. The members pick up new knowledge and skills by participating in tasks (like the amigos session) that lie outside of their previous expertise. As well as keeping the team motivated, it helped the team to be more resilient against the temporary or permanent loss of certain team members. The team was able to function when a member was absent. For instance in the absence of a BA, the XD/QA/dev added the functional requirements to the story. In the absence of a QA the other developer pair or BA tested the story and moved forward. This is very helpful in teams where there is a single QA or BA.
Multi team communications
Dependencies with other services proved to be a challenge initially. The project had geographically dispersed teams that we depended on. We stumbled into many blockers and had to wait for other teams came online and unblock us. This resulted in delays. To avoid this, the team aimed to resolve dependencies during analysis. We scheduled an online call during overlapping hours. This session, held at least weekly, helped build relations and understanding of what each team is working on. This enabled us to think consider possibilities of bugs in our system due to other team changes. We had contract tests written for each team, which flagged when changes would break things downstream or upstream.
All the processes that we introduced significantly improved our cycle time. The team had better collaboration , there were no surprises uncovered in development or after. We learnt a lot from each other and improved our own capabilities.