Evolution of an Agile team
This is a story about how our project team managed without a Business Analyst/Iteration Manager (BA/IM) and how it changed us from a team of T-shape people to a team of Broken-comb people. Now T-shapes, they know their stuff backwards — so if I’m a Developer, I know Dev stuff — if I’m in QA — I know QA stuff. Meanwhile Broken-combs have more breadth of knowledge. We think of this as continuously striving to learn as much as we can about everything we can. You can also think of Broken-combs as wearing more hats then T-shapes. and we’ll be explaining how this worked — how we evolved to become a team with testers that can develop in the front-end and back-end, and also do the work of a BA. And it all came about because someone went on annual leave.
Here at SEEK our project teams face similar challenges to you — we want to deliver products in an efficient, competent and timely fashion. But we don’t have spare people and we don’t slow down or stop if someone is on leave, we need to be able to cover their tasks. Our team was based on the traditional model where skilled professionals work exclusively within their role (QA, Dev, BA, Iteration Manager) — we were mostly T-shapes. See the diagram on the right — “The vertical bar on the T represents the depth of related skills and expertise in a single field. The horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than on’es own. T-shaped skills — Wikipedia, Image by James Royal-Lawson
Our team had been delivering outcomes as expected until earlier this year when our BA/IM went on annual leave for 4 weeks. Now we were one person down and had to figure out how we were going to deliver a great business outcome during that time.This was the catalyst — when we realised the limitations of the traditional team model — and we embarked on change.
Time to smash the boundaries
“Broken Comb people are continuously striving to learn and improve and to go deeper than just the surface, whatever discipline they are learning about.” ~ Brittany Hunter, Software Designer.
First we approached our Delivery Manager, and ran the idea of working across multiple roles past him. A traditional manager would say that the role of a QA is just QA. However he wasn’t a traditional manager and encouraged me (Derrick) to learn and take on the duties of an IM. So I started watching other BA/IM’s & tried to get involved where I could. For me as a QA if I see something wrong, I want to fix it, I just want to organise stuff — it’s who I am.
So what did I do? I used all the collaboration channels we have at SEEK, to follow what our BA’s were doing. I studied all I could about iteration management & watched what other BAs did. I also got the chance to attend an Effective Facilitation training course, which really helped, and gradually I took on more IM tasks. In addition our Dev’s and QA’s started sharing tasks & we encouraged the whole team to think “This is MY team, and if I see something that needs doing, I’ll do it”. Our team was becoming more effective. Now, there are no longer QA story cards or Dev story cards e.g. if a card creates a bottleneck with coding, then a QA jumps onboard.
How did we find the time?
Here at SEEK they provide time for us to learn. I had the support of the Delivery Manager but more importantly I took the time to learn how IM works at SEEK — you need to be disciplined about blocking the time out in your calendar and not changing it. One of our BAs, Dave Pryce wrote a great post about this topic and explains how it may seem that you are taking time out of your job, but in the end it’s win-win. The business is always going to profit from a more qualified and useful member of staff.
Our Broken-comb team
Now we are no longer limited by a job title but can shift our roles to accommodate the project’s needs and goals at any particular time. Bottlenecks that used to frustrate us are a thing of the past. This cultural and individual shift in mindset and role has not been without difficulties and is an ongoing process, but for us the benefits have far outweighed the challenges. Breaking down these silos of operation has resulted in the team achieving targets at a rapid rate and we now have the satisfaction of seeing not only our professional skills grow but also our effectiveness as a team. This is what our team looks like now:
What did we learn?
There were many challenges along the way but here are the important lessons we learned:
- Don’t be afraid to challenge the status quo
- Managers and team members need to encourage each other to change, learn & up-skill
- Ask others to be open and share their knowledge
- Allow time to adopt this new culture and approach
- Conduct regular retros, learn from them and focus on continuous improvement
Where are we now?
We’re definitely on our way to being broken combs. And we’re standing by our decision to use existing resources and just see what happens. We’ll let you know how it goes…