I am working on a large software development project. By my estimate, we have over one hundred teams working on this project. Since it is a significant financial client, we use Scaled Agile Framework for the Enterprise, or SAFe for short. It is a complex process with lots of moving parts and little room for error. I am also experiencing a common problem with large SAFe implementations, and I want to discuss it today.
SAFe is the de facto standard for large software projects. For executives, it helps standardize the process and is a reasonable attempt to coordinate numerous agile teams. Unfortunately, most business leaders do not understand how value flows through the organization. The larger the organization, the more difficult it is to know how the firm generates value for customers. Thus, teams are organized not around value but by technical specialty. Front-end developers work on one team, database specialists on another, and middle-ware experts on APIs are on a different team. It is a logical way to organize technical professionals, but it makes delivering software on large projects a headache.
Specialized teams are fantastic if you organize your business to embrace the status quo. Still, suppose you are attempting to innovate or build new services to help customers. In that case, you need cross-functional teams because specialization means no individual team is accountable for getting work finished. It becomes a deranged relay race where work passes to others, and no one is sure it has reached the finish line.
For instance, if you are a clothing company offering a new mobile application for customers to customize their styles. You could do the following: hire a design firm to build the mobile application and take an in-house technology team to hook into the current sales and invoicing system. Finally, you have a group of manufacturing engineers take that data to reconfigure the factories to address the customer demands. As an executive, it makes perfect sense, but the reality is that the mobile application developers do not understand how to communicate with the sales system. The manufacturing team does not have what they need from the mobile application or the sales system to create high-quality products on demand. They are traveling a logical path along a road to ruin.
What makes the situation more troublesome is that SAFe has the concept of release trains which says these three teams above should be able to work together, hand off work, and get things done. The trouble is the decision maker does not understand how the software and system should work, so they do not know how to construct the teams. A team of mobile specialists, a team of sales and invoicing specialists, and manufacturing engineers is a straightforward way to break down the groups. Alas, these teams will not work well together. Instead, reconstitute the units, so mobile developers, sales and invoice specialists, and manufacturing engineers work on the same team. Condense these three teams into two.
What will happen is when a mobile developer has a question about the data they receive from the sales and invoice system, an engineer with experience will be able to help on the spot. Likewise, the manufacturing engineers will understand what the sales and invoice system is doing because they will be working side by side with the necessary technical professionals. Finally, the three teams blended into two sections, one for standard sizes and the other for children's; they can share solutions to make each group more efficient. Instead of work being passed around like a hot potato, people work together to deliver value.
Some of the biggest problems in SAFe happen when work passes between teams. As a coach and agile professional, it is your responsibility to reduce this dysfunction as much as possible. Organizes teams around value to the customer instead of technical proficiency, ensuring work when assigned can be taken from beginning to end with zero handoffs between teams. It will make your release trains more efficient and save you from unnecessary headaches.
No comments:
Post a Comment