From scrum to agile – Agility in practice from the trenches (in a scaled agile organization)
The need to grow local #Agile change agents
February 16, 2018
100% user story completion vs 100% productivity?
March 10, 2018
“From scrum to agile”, that was the statement given by Rony, one of the R&D leaders, when describing the journey of his team made in the past few months.
We can create agile teams, working in a large scale agile organization, performing as self-organized units, delivering fast ongoing value, without tools, with the right motivated individuals. Want to know how?
“I always felt I was stuck, dealing with dependencies, waiting for priority, always having the feeling that in the scrum framework we worked with, I am not as fast as I think I could be. Now, starting from days after we went through this journey I am fast, flexible and have a team of highly motivated, multidisciplinary, proactive engineers. By cutting out the administration and the middleman, the team is more focused and more in touch with the business owners, enabling them to deliver higher quality, faster than they could beforehand. This is a change I want to keep.”
Let’s cut right to the chase. Here are Rony’s team practices:
The structure:
We have this agile team, one example out of 23 agile delivery teams…
Team: 4 engineers (“We are all engineers no matter what the task is – whether coding or testing.”).
The team has its own space, with good tools for strong visibility.
All the team activities take place in this space: retrospectives, dailies, grooming….
The team backlog, roadmap, goals and tasks (whatever we want to call them) are all managed on a whiteboard located in the team’s space. Without additional tools, just a large board and sticky notes.
Who decides what to do?
Rony acts as a proxy product owner to the business, to the product unit and to any other stakeholders. Why? Because this team receives requirements from more than one unit. it can be a business requirement, an internal R&D technical requirement or any other sort of requirement. Rony realized that the fastest way to deal with these multiple sources, would be by taking this role upon himself.
A product/feature owner can anyone that understands the business statistics and client behavior, who can define and become the owner for business requirements. Alternatively, requirements may be initiated by R&D, especially when it comes to technology or strategic/infrastructure oriented projects.
In some cases others may take the role of a product owner, as long as we realize the value of this kind of agile decision – everything goes. This way of working makes the team’s day to day work and product functions much more easy and flexible.
We have a 3 month (and no more) high level roadmap. Those are the pink cards you can see on the board. We keep the roadmap 3 month ahead all the time.
No sprints – We run on a weekly timeline.
We do have a 1 hour team weekly meeting, we call it “weekly grooming”. In this meeting we draw out our weekly goals from the road-map. We also look at our “Kanban” board (to the left and decide what the scope of next week’s work will be.
**Note: this is not a typical Kanban board and it is not intended to be.I It just looks like it and uses some of Kanban’s principles.
Each team member knows his/hers capacity and the tasks are selected according to that.
We don’t estimate by hours, we “guestimate” if the task will take a day or half a day, that’s it.
Each goal is small, and has a clear definition of done for this coming week.
The goals are located also on the white board.
We do not update any other tools, just the cards on the white board – this saves us a lot of time!
What do you do when you have dependencies with other agile teams?
Each team member is an owner of a goal or part of it and they make sure that all the loose end are closed whether before, during or after our work. It works great. Also, we work with other teams using an open source methodology, meaning, if we need other teams’ code to change, we change it and submit our changes to their review. This minimizes our dependencies on other team’s schedules – enabling us to deliver faster.
The board:
It looks like Kanban but it’s not
The team understands the board and this is what is really matters. They own the board. Others, from outside of the team may or may not know how to “read” the board, however, that is less relevant.
We a swimming lane for expedited tasks and also a swimming lane for things that we plan to accomplish this week. The priority is from top to bottom and tasks are move from the left (requirement discovery) to the right (done/handover).
The cards colors have no strict rule about them. There are card colors that represents a project and colors that represent the person responsible for them. As long as it works…
Impediments:
Impediments are located at the top-right corner of the white board. We take them very seriously and address them each daily. In fact, we place issues in this area even if they are only at risk of becoming an impediment, enabling us to preemptively handle them.
We retrospect a lot! Sometimes twice a week. We deal with many different, complex projects from a machine learning project involving compliance and risk requirements, to new infrastructures that will enable our business to scale. We continually need to try out and experiment with new technologies and new work procedures, so we can rapidly learn what the right are wrong directions are, then decide how to proceed and move on to the next challenges. Retrospectives are the driving force behind the ability to continuously improve. We may conduct a small retrospective after the daily meeting, if needed – we don’t wait until the “end of the cycle” for the official retro. Even so, we don’t skip the formal retros, as we value them a lot
KPI – we deliver value!
Do you know your Velocity? Sure, we calculate it every week. We measure what the delivered value is.
We calculate value using the cycle time – from the time we started working on a task, until it has been delivered.
Each week we summarize the following:
- The estimated days of work of the completed task divided by the availability that week (sum of actual work days per person) – we call this our velocity.
- The percentage of weekly goals completed. These goals are milestones within our roadmap goals.
In addition, we check for impediments:
- Aged task – tasks that were stuck in the same place in the board. We discuss whether these tasks are blocked, should be advanced in priority or perhaps are actually no longer relevant.
- Blocked tasks – are there tasks waiting for external resources that we could not push forward? Is there anything further that can be done to unblock these?
For example :
Velocity = 17/19.5 , 87%
Weekly goals
- XXXXXXX and SB – 70 %
- XXX engine XXXXX – 100 %
- Y XXXXXXX – finished Parsing still running 100%
- XXX Holder XXX – 100 %
- XXXXXX template – 0%
- XXXXX E2E – In QA ??
- Start XXXXXXX – Not Relevant
As a team leader, do you have time to code?
Yes, enabling me to stay hands-on.
Team motivation? Great! The team is proactive, highly motivated team and innovative! The team is self-organizing and in a state of constant discussion and constant improvement.
Innovative?
Innovation is one of the core principles of our team, we strive to create breakthroughs in both business concepts and in technological abilities and approaches and have success in doing so.
And here they are … The team!
About tommy quit – This team coach
WeChange helps enterprises as well as startups build the needed mindset and process to deliver on time, frequently and with better value. We are a group of leading experts in Agile/Lean/Business solutions.
