After the Web Services team released a brand new API in early April, we’ve been examining our processes (along with developing new API endpoints!), looking for ways to work smarter, faster, and better. We learned a lot along the way to our successful launch, and needed to turn them into actionable items. This post discusses some of our findings, and how we addressed them.
We held a two-part retrospective meeting shortly after launch. The team used a starfish diagram to frame the discussion and generate a list of actionable items to work on. A starfish diagram uses 5 categories to capture feedback on:
In order to gain velocity and make a measurable impact quickly, we agreed to take on no more than 3 action items to implement during the next sprint cycle. Here are 2 action items that we identified, and how we addressed them.
Improve the Daily Stand-ups
This issue: Stand-ups are too long, and the information shared is often of low quality.
The team wanted shorter, more focused stand-ups where useful information relevant to the project and features was shared, quickly. We wanted to make sure we were sharing any information that impacted other team members in that meeting. For example, if the development team changed the order in which features were being delivered because they were blocked, the QE team needed to know this so they could re-prioritize the order they developed their tests.
What we did:
- Review and reestablish the guidelines for stand-up discussions – what I did yesterday, what I’m doing today, where I’m blocked.
- Keeping focus – quickly identify if a topic needs to be taken offline.
- Raise the general awareness of dependencies – whose stuff am I dependent on, who’s dependent on my stuff.
- Honor WIP (work in progress) limits – We came up with WIP limits of 1.5 tasks per developer. When a column was over the limit, the team agreed to stop what they were doing, and dig in to get it back under the limit. Typically the Ready for Test lane is where our backups occur, due to limited QE resourcing at times.
- Simplified the Jira Task board view – simplified the workflow structure with fewer states, and reduced the number of swim lanes (see next topic)
Better Top-down View of the Sprint
The issue: We can’t easily see/know our progress during a sprint.
There was no way to view our progress on features and the overall sprint commitments the way our tracking tools were set up. We wanted something that showed progress at a glance, with the ability to drill down to details.
What we did:
- Simplified our Jira task board – use only features/elements relevant to how we work
- Dismantled and reconstructed Jira workflows to reflect how we actually do our work
- Reduced the number ticket stages or swim lanes to 7 from 12
- Reduced the number of issue types we use
- Redefined how features are ticketed out
- Created multiple task boards:
- A feature-based view, showing all features with their sub features, tasks, and WIP defects
- An individual-based view, showing all issues for each team member
- Constructed classic burn down chart showing the amount of work left-to-do versus time.
The team is satisfied with the changes made in both of these of processes. Now we feel that the Jira board represents how we work, and managing tickets is intuitive, with minimal overhead involved. It does not get in the way of getting things done. Stand-ups rarely last more than 12 minutes (with a team 12!), and the information shared is very concise and relevant.
Making Incremental Improvements
At the end of each sprint, we hold a retrospective meeting. These meetings are much shorter than the meeting referenced in the beginning of this post. It’s more of a maintenance activity now, finding ways to make 2 or 3 incremental improvements that fine tune things each sprint.
Process for process sake impedes and discourages smart people; making processes that work with you, for you, now that’s the way to go.
Your turn – Have you been stuck using processes that get in the way? What did you do to fix them – temporarily or long term? How have you made things work better for you – process, tools, or whatever? I’m interested to get your perspective- join in the discussion!