How we improved our velocity commitment from 40 to 85%
A lot of stuff has been written about how to do scrum and why it is the best (or worst, it depends ☺) framework for organizing teams working on a web product. But actually, I rarely see a lot of people sharing their success or failure with scrum, I mean with concrete data.
That’s why I wanted to make a retrospective about the actions we took at iAdvize in the last 12 months, leading our team from failure to it first successes.
The beginnings
During the first months of 2014, our velocity was far (far) away from our commitment: only 40% of our sprints scopes were shipped.
We were promising amazing feature releases to our Sales team in times we didn’t respected, creating frustration for everyone in our company.
Yet, we were doing scrum as it’s taught in the books: cutting things in small pieces, making quick estimations for future projects, defining in a much more precise view the tasks of a new sprint, and using the burndown chart pretty well.
Something was wrong. We identified two main reasons :
- Ours estimations weren’t accurate at all (I mean, not at all)
- Sometimes, we were overloading some sprints
Want to improve something?
Start tracking it.
We have a great culture of measurement at iAdvize, so one of the first things we started doing was to track our estimation accuracy (= time spent to complete a task / original estimated time) and to review it during our Sprint retrospectives or cross-team meetings, every week.
Thus, we were able to analyse what were the task types we failed the more often and how we could have made a better estimation, as a team.
These discussions were priceless because it removed a lot of misunderstanding about our real failures (lack of technical expertise for such app component, not enough detailed design requirements about that, identify developers who tend to be overconfident, etc…).
By working on each issue (doing some internal formations, creating a new design and tech requirements format, help some developers in one-to-one…), our accuracy became better months after months, reaching an average oscillating between 80 and 120%.
Improving your workflow
The way we iteratively improved our development workflow was also essential to improve our delivery and the quality of what we push to production.
Having a good QA process improve directly your velocity because you spend less time fixing bugs, and more building stuff your customers needs.
I don’t even remember all the modifications we made to our JIRA workflows & agile board in the past 12 months, but we switched from the basic “Todo / In Progress / Done” to that current one:
At iAdvize, the QA is made by the same team which build the features. We believe that deliver functional stuff is everyone responsability.
Also, a developer who performed a task can not realize its own QA.
But it is the developer job to motivate its coworkers to give their :+1: or make the QA of the issues he made, in order to ship it A.S.A.P.
Benefits:
- QA and code review are never zapped,
- we have a much better confidence in our deployments,
- we create less bugs,
- when a lot of issues are waiting in a particular stage, we know it immediately and are able to focus on our bottlenecks,
- by defining clear rules, our workflow is much more fluid.
NB. I would recommend to not exceed 6 or 7 different statuses if you want to keep it simple.
Finding the right pace in a growing environment
Scrum is all about finding your team pace: a constant rhythm that provide you a clear view about what your team is able to ship in one sprint, with confidence.
As a fast growing company, it requires a lot of energy to find its pace, because the variables of the formula are constantly moving.
Our engineering team grew from 5 to 15 developers in 2014, making it very difficult to appreciate our real velocity. And if you don’t know your real velocity, you are not able to plan things.
To fight that and improving ourselves at Sprint planification, we did two things that helped a lot:
- Start tracking our Sprints focus factor (explained in that book), giving a better view of our “real velocity”, excluding off-days or vacations
- Do not count new developers in our velocity goal calculation, during their first month.
Boom! Problem solved ☺
Create a culture of deadline
Every project must have a clear deadline.
Some managers try to animate their team around some deadlines they (or the CEO) define. Obviously, it’s a one-way ticket to failure, and probably the best way to demotivate your designers and developers.
At iAdvize, each team working on a project is accountable for the estimations they made. The global deadline is defined according to their estimation and we remind that principle at every team meeting.
Another thing we do to keep our team focused on meeting deadlines is to present the big picture of a new project before working on it (including other teams dependency), during a kickoff meeting.
The aim of our project kickoff is to be sure that all R&D team is aware of the other departments workflow concerning a new feature.
- When do we need to have some production data about a new feature to build a cost model?
- When do the sales will be trained to this new feature?
- What will be the impact on our Marketing team agenda?
(video shoots of customers using the feature, emailing & landing planning, PR work, translation workflow…)
NB. Even if personnaly, I think it’s more challenging, I forgot to mention that setting deadlines on projects isn’t (only) for our own pleasure: as mentioned above, we work in a global company where multiple teams have to coordinate in order to deliver some happiness to their customers ☺
So, what about the results?
In 12 months we have made significant progress, reaching an average between 75 and 90% of target achieved.
We are still learning a lot and trying new things about the best way to organize our Research & Development team.
In 2015, our next goal is to stabilize that pace at 90% with a technical team which will grow by x2 (by the way, we’re hiring ☺).
I would love to hear about your feedbacks about our stuff or the way you work in your team, so feel free to ping me.
Photo credit: Pixel Fantasy
