Many organizations create teams by their architectural part: front end, back end, middleware. That may have worked back in the waterfall days. It doesn't work well when you want to implement by feature. (For better images, see Managing the Stream of Features in an Agile Program.)
Pierce Wetter wrote this great article on LinkedIn, There is no “front end” or “back end.” Notice how he says, referring to the yin/yang picture,
Your product isn't just the white part or the black part above. It's the whole circle.
That has implications for how you structure your teams.
If you have front end, back end, or middleware teams, you lose the holistic way of looking at features. You can't produce features—you produce components, parts of features that work across the architecture. Even if everyone does their job perfectly, they still have to knit those pieces together to create features. Too often, the testers find the problems that prevent features.
Instead, you want a product development team, a feature team. That team has someone from the back end, someone from the front end, someone from middleware, and a tester, at minimum. Your team may have more people, but you need those people to be able to create a feature.
You might call these teams product development teams, because they produce product chunks. You can call them feature teams because they can create features.
Whatever you call them, make sure—regardless of your life cycle—that you have feature teams. You can have feature teams in any approach: serial, iterative, incremental, or agile. What differentiates these teams from functional or component teams is that feature teams can produce features.
Features are what you offer to your customers. Doesn't it make sense that you have teams that create features?
In our “software intensive systems” (SIS) domain, this “wonderful” and very important idea is the realm of Systems Engineering
http://herdingcats.typepad.com/.services/blog/6a00d8341ca4d953ef00e550709f4b8834/search?filter.q=systems+engineering
SE’s are many time missing in IT and SWDev for all the wrong reasons. In our domain of SIS this is the paradigm
http://www2.cs.uni-paderborn.de/cs/ag-schaefer/Lehre/Lehrveranstaltungen/Vorlesungen/SoftwareEngineeringForSoftwareIntensiveSystems/WS0506/SEfSIS-I.pdf
Great post
Glen, way back when I first started as a developer, we had “systems engineers” on the project. I wish I could say they were in our teams, but they were not. However, they understood the system. If I had a problem, my first job was to ask a systems engineer. He helped me understand the requirements, and we discussed how to engineer the system.
This is partly why my Masters is in Systems Engineering. My degree was in how to understand a system and engineer it. My degree is not about requirements, per se. Many systems engineers are now just requirements people, and that’s not adequate.
Thank you for the links.
Pingback: Johanna Rothman : What Model Do Your Estimates Follow? | Project Management Buzz
Great article Johanna. We are currently one team that has grown too big to stay as one team and we are looking at splitting into 2 to 3 smaller teams. We support 2 products and 2 brands so we looked at splitting by product but currently 1 product represents about 80% of our workload. We look at splitting by brand but we have several shared services and the distribution of work across is not equal. Currently managing work itself is pretty easy as we only need to consider business priorities but once we are split into smaller feature teams we need to take into consideration how to keep all team busy as well. We are not sure exactly how we are going to do it but intend to start and refine.
HI Isabelle, starting and refining is a great approach. I can imagine several experiments you might want to try:
– separating into equal-size teams, maybe even organized (primarily) by product, and then splitting the backlog so each team works on the 80% product, but the backlog dictates what to do.
– keeping one big team and using kanban to really see your flow. Separate based on what you see.
– something else the team selects to try.
Fun times ahead! If you have a chance, please let me (all of us?) know what you decide to do and how it works.
Hello Johanna,
We talked in through with the team and decided on splitting into equal-size teams and then splitting the backlog as per your first suggestion. We have been running like this for 3 sprints and everyone is very happy. The main feedback from the 3 teams was that they understood their sprint goals a lot better and the team communication was a lot better.
Cheers,
Isabelle
Isabelle, congratulations on finding a solution that works for you for now. I’m delighted this worked! Thanks for letting me know.
Pingback: Agile Quick Links #30 | Agile Pain Relief