Scattered team, swarming experiment failed
Hi there
I took over a team in which there was absolutely no planning of work in any way. Just emailing one another, some adhoc teams calls, etc.
This was one of the reason they hired me (as a team lead), so last year I've introduced Scrum. It was a quite chaotic, but organic process with a lot of struggles, some wins and some setbacks.
Currently we have a quite messy, but working product backlog. But there is one particular problem arising over and over again, which I've tried to tackle numerous times: too much WIP.
Without going into the details, I think this has had a lot of reasons: No major aligning focus from the CEO and management (a LOT of moving target), resulting in them hiring developers randomly and assigning to them some work (usually entire products which they decided on a whim is THE most important right now, just that is moved again to something different a few weeks later...) on which they worked on their own, without much organisation, collaboration or even alignment with one another.
The result: We don't have a TEAM, just a collection of devs with different backgrounds. I tried a lot of stuff to foster knowhow transfer, team building, pair programming, swarming in general, limiting WIP, etc., but it doesn't seem to hold, and if I'm not there or if I'm not constantly almost enforce this, everyone just works on "their" backlog item.
So our velocity is bad, very bad. A lot in progress, few is done at the end of the sprint.
Another experiment I started is to create business-driven sub-teams (which I called Squads) which are responsible for entire products (and, unfortunately, for such a small team of 6 devs, we have a lot of products...). Within these sub-teams now I foster swarming, but still, it doesn't seem to fit into the company DNA and so everyone is working on their own again.
So my big question: Given this background, do you have experience in actually creating a collaborating team, in which swarming is possible?
Thank you a lot!
I didn't see any mention of a Product Owner, or commitment to a Product Goal and Sprint Goal. Having a Sprint Goal may provide the team with the focus it needs. Without focusing on the Sprint Goal, you are just a group of individuals, not a team. The Sprint Goal is the glue that binds them together as a team.
A Product Backlog isn't very effective unless it is ordered and focused on one Product and one Product Goal. Scrum is more effective when a Product Owner has full authority to make decisions, say no to stakeholders, and order a Product Backlog by cohesion. The cohesion will help the Scrum Team develop a Sprint Goal in Sprint Planning.
The Product and Sprint goals aren't optional in Scrum, and there's a good reason for that.
All the best!
This was one of the reason they hired me (as a team lead), so last year I've introduced Scrum
You've introduced it...but have senior leadership made it clear that they want it? What conversations are you having with them?
From what you describe, there seems to be little sponsorship to overcome the status quo, despite the pain-points you mention. Remember that it isn't your company to change. Right now the message being communicated and reinforced by the higher-ups is that the reactive, fire-fighting and mole-whacking day job takes priority over any suggestions you may have.
You mention the company DNA. When struggling to introduce Scrum, we fall back on the values of Commitment, Focus, Respect, Openness and Courage. These have to be in the organizational DNA for Scrum to gain traction.
The Scrum framework is much more than a Product Backlog and a Sprint. Unfortunately those are the only parts that most people understand. @Chris and @Ian have both hit on things I had floating in my mind as I read your post. Swarming is not mentioned in the Scrum Guide as part of the Scrum framework. It IS a useful technique for spreading knowledge and can sometimes help to get things done. But it doesn't provide the focus you seem to think is needed.
You mentioned that you are the "team lead" but you didn't mention what responsibilities mentioned in the Scrum framework (Product Owner, Developer, Scrum Master) you have taken on. Those are not job titles that are mentioned in the Scrum Guide. They are areas of focused responsibilities that need to be covered in order to be successful with the Scrum framework. Are you sure that you introduced Scrum or did you introduce a few of the concepts?
I have never worked in an organization that was successful with introducing the Scrum framework unless there was executive management involved and supporting it. Whether we like it or not, most organizations still operate in a way that encourages an organizational chain of command much like militaries do. Without the support of the upper levels, low level change is seldom successful. Using the military terminology more, trying to change things at the low levels is more like a coup or revolution and history shows how hard those are.
As a team lead you are having to take on some management roles. One management role that is hard to learn, hard to do, and is very often not recognized is the ability to manage up. If you really want to influence change, you should work upwards first to get support from the top, then go downwards from the supporting level.
The Scrum framework is much more than a Product Backlog and a Sprint. Unfortunately those are the only parts that most people understand.
@Daniel makes a very good point here and in many organizations Scrum is used only to execute activities which are planned.
Coming to your question regarding WIP below points can help
- Having a good sprint goal
- Set up WIP limits for the team and if you see rising WIP tasks it indicates there is a bottleneck somewhere and team is not able to move tasks to done. As a Scrum master you need to ask these questions.
The result: We don't have a TEAM, just a collection of devs with different backgrounds
You don't have a team but a workgroup. In a work group, group members are independent from one another and have individual accountability but they report to same manager. On the other hand, in a team, team members share a mutual accountability and work together. These dynamics inform the way tasks are handled and overall collaboration. When there is no team I am wondering why there is need for team lead ? I think you have to reassess your responsibilities with current organisational structure or situation.If the expectation from you is to make the individual persons work as a team, there should be a common goal to achieve. Otherwise you can only be a single man army fighting for change.
No major aligning focus from the CEO and management (a LOT of moving target), resulting in them hiring developers randomly and assigning to them some work
Do the management getting the results by working this way ? What is the reflection from developers ? Agile is more about People over process. So first team needs to buy-in any process you introduce. At this point of time, What I think you can only do is to make problems "Transparent" to the management and team by using any number of information radiators. Only if they understand and accept the need for change, they will coordinate with you.