How much, or what type of a common purpose do Agile teams need to be in order for Agile to work properly?
I think we can all imagine an Agile team comprised of cross-functional team members working together on a product, executing sprints, with everyone working towards a common goal. Perhaps that's the ideal situation, and when we have that it can be wonderful. And, I bet that those of you who believe strongly in Agile also believe that it can be applied to a very wide variety of situations. But I am wondering if my organization is trying to stretch it too far and apply it in a situation where it's not the best fit.
I'm in IT and I've been asked to stand-up a cross-functional Agile team (which we launched 4 weeks ago) supporting one of our Line of Business IT groups. That organization does have a ton of work - many products and over 100 projects. Our team supports them by taking tickets and fulfilling them, doing things such as ordering new servers, setting up new network connections, building new databases and provisioning many terabytes of storage for them.
The high level mission for the team is to "Provide infrastructure hardware and software for their partner line of business team using Agile." This originally seemed to be a suitable mission to me. I envisioned the agile team partnering with their line of business team, gaining a deep understanding of their needs, prioritizing them in a backlog and working as a team to get through the higher priority needs as quickly as possible. But it's not really working out that way.
Since the work comes in as tickets, we decided to use Kanban instead of Scrum. Our Agile coach is struggling since we can't define a MVP. Another Agile center of excellence person told me that our Agile Coach is wrong to want that...they said that Kanban doesn't have MVP.
Regardless of MVP or not, it seems that we have simply created a cross-functional team that sits in the same room working on tickets. Each person works on the tickets for their area so they don't collaborate much. For example, when a database ticket comes in, the only person in the team who can work on it is the database person. Similarly, when a network ticket comes in, the Network person works on it.
Although all work comes into the team in the form of tickets, there are really two categories: (1) projects and (2) ad hoc tickets. I don't think there is much we can do with the ad hoc requests since they are isolated and unrelated to anything else the team is working on (e.g. update firewall rule). With the project work, my goal is to rally the team around the projects, make sure that they understand the projects and then have them work together on the project as much as they can (i.e. instead of seeing these as independent tickets, they would maintain context and group the tickets associated with that project together in order to get the feeling that they have a common purpose). I know that Agile teams are supposed to focus on products instead of projects, but in this case our organization is just beginning the agile transformation and we still have many projects and I though that this was something that we could latch onto.
I am concerned that this Agile team isn't going to gel as a team the way a team would if they were all focused on the same product generating incremental improvements every sprint. But I can envision the team sitting in the room, working on tickets, minimizing WIP, focusing on increasing velocity and removing impediments and as a result doing a much better job than what they did before. But is this really a good application of Agile?
I would love to hear your thoughts on this.
Thanks!
- Steve
Steve,
Scrum is just one option for a team choosing Agile - Kanban is another. I would therefore defer to the Agile Manifesto and the 12 Agile Principles to measure how "Agile" your team is becoming.
How knowledgeable are you, the team, and your Agile Coach in Kanban though? Have you implemented WIP limits on your work process phases? Have you begun to look at Kanban metrics such as measuring Continuous Flow and Cycle Time?
The one item that did jump out at me in your message was the specialization within the team. What are some of your (and your team's) thoughts about knowledge transfer and cross training, so that you begin to mitigate specialization dependencies within the team?
Do you have any evidence that “teams” are in place at all? Do the groups you refer to exhibit teamwork? If not, what forces are in place which are causing them to be thought of as teams? Does someone see a need for them to self-organize and collaborate in some way?
One approach may be to visualize the value streams, understand how value is added at each point, and then look for waste in the system and at potential optimizations. A team may crystallize from those interests which can then inspect and adapt to serve them better. However, it is more likely to be a lean team rather than an agile one unless they have a clearer sense of business purpose.
Thanks for your thoughts and comments so far. I am looking for more people in this forum to provide comments and thoughts on this.
The agile coach and scrum master are very knowledgeable about Kanban and they are putting WIP limits in place.
And the team specialization has been a big concern from the beginning. On the one hand we want to form cross-functional teams, right? But on the other hand, we know that there is no way that a Cisco certified network engineer is going to be able to work on a Microsoft SQL Server database, or vice versa. So, I have a dilemma...the team needs these very specialized skills in order to fulfill the team mission, but because a high level of expertise is required, team members can't really cross train or help each other out. The alternative, having an agile team of all network people and another agile team of all database people doesn't sound very appealing either. Those would definitely not be cross functional, and their tickets would come from a much wider pool of requestors, thereby making the product owner's job almost impossible.
Regarding this notion of "team", perhaps you are correct in asserting that we do not have a team at all, but instead we have a group of people working in the same room. They do have the same high level purpose, but they don't really work together since their skills are so specialized and the work is done independently.
Maybe what we are creating should be Lean teams instead of Agile teams. That's the first time someone has suggested that to me. I still like the idea of agile coaches (or maybe we need a lean coach), scrum masters and product owners being on the Lean team, as well as using the Kanban model. We still need a scrum master, at least for a while (even if we're not doing scrum) to help the team adjust to a new way of working and we still need a product owner type person to create the backlog, groom it and prioritize it.
Please keep the good ideas coming. This is an excellent forum and I'd love to hear additional feedback on what others have done in situations like mine.
I have coached in service and infrastructure delivery. The issues were very much the same as you describe. It did indeed resolve into more of a lean coaching engagement than an agile one, although ITIL standards were referenced. If you haven’t done so already I suggest doing a search for agile and ITIL since there is quite a bit of material out there, and some of it may be useful even if ITIL doesn’t directly apply in your case.
NB If you visualize the value streams first and start looking for optimizations, you are likely to find that the cross-functional skilling demands are not quite as onerous as they appear. If each team member is cross-trained in just one additional skill, preferably to the right or left of their station, then they will be able to even out flow, reduce bottlenecks, improve throughput and so on. From a lean perspective, “overtraining” in skills team members would be unlikely to apply might be seen as waste. This is less of an issue in agile practice where team members are more likely to swarm in order to meet a shared goal.