The importance of cross-functional teams on Lean-Scrum projects

by Esther Hibbard on 22/02/2013 03:42


This week I had the privilege of attending a Kanban/Lean-Scrum One Day Simulation training by Al-Shalloway, Martin White and Juliana Bennett.

The training involved a mix of theory and practical sessions. We got to simulate what a project might look like going through a Kanban board.

One of the key lessons I took from the training is how crucial cross-functional teams are. The first couple of weeks in our simulation did not allow our team to be cross-functional, e.g. our testers had to be testing, developers had to be developing etc. This created a rather large queue in our tester’s backlog, which resulted in our analysts and developers not being fully utilised. In the third week we were allowed to allocate our resources the way we saw best. We placed one of our developers to help out with testing and it didn’t take long to get everything flowing nicely.

Without cross-functional teams it would be difficult to make sure everyone is fully utilised without causing nasty backlogs. I have experienced being part of a project in the past that had something similar to what we saw in our simulation. The development backlog needed attending to whereas the analysts and testers were struggling to find work. In these cases it is handy to have the analysts and testers helping out the developers to reduce the queue.

One thing to note is that ‘helping out’ does not necessarily mean doing the actual work. It could also mean helping to remove any interruptions the developers may experience (i.e. when a support issue is raised, rather than the developer dropping their work to do the initial investigation, a tester can help out and do the investigation instead, leaving the developer to focus on the task at hand).

Something else I discovered during the course was placing a work in progress limit on the backlog. To me it made sense to have as many items on the backlog as you can, which means more choice for your team. However, I didn’t take into account the work involved in adding items to your backlog. One of the key ideas Al Shalloway teaches is that delays between work creates extra work. The faster you can get your work from one stage to the next, the better. Therefore, having more items in the backlog means some items may be sitting there for long periods of time, thus creating delays and as a consequence extra work is also created.

Thanks to Al, Martin and Juliana for a fun day out of the office. The simulation was a valuable experience and a great way to gain insight into using Kanban.

recorded webinar: how agile development teams succeed


Get blog posts by email

Wild Strait - Explore smarter, better ways to tackle the increasingly complex challenges of software performance