SOA based endeavors represent a good proportion of the projects we work on at Burnside Digital. A mix of reasons account for this: some being large enterprise implementations that require the scalability and flexibility of a SOA model, others being systems that service a multitude of clients for different purposes and thus lending themselves naturally to SOA. Regardless of the origins, all SOA projects seem to present familiar issues when it comes to compatibilities with Agile principles, and although these have presented challenges, they are challenges we welcome and are finding to be great opportunities for growth.
The core of the conflicts we see, arise when trying to accomplish our criteria for writing good user stories, while trying to define the work we want done on the SOA. For this example I would like to focus on just one of our criteria, that each story demonstrates value to the user. This is crucial to our agile process in that it allows the product owner to competently prioritize work done each sprint. To ensure that engineering is tied directly to business initiatives, it’s imperative that stories be tied directly to user or customer value, so that when prioritization is taking place, it’s entirely transparent in respect to how it relates to business objectives. This can be easily achieved when building a simple web application, however, as I will show, SOA projects propose some further complexities.
Let’s start with a simple web application example such as an inventory management system for a small business, this app will simply track inventory as it’s stocked and sold. The user in this case is the business person who needs to keep track of inventory. An example of a story for this application might be, “As a user I would like to delete a product from the inventory list so that It reflects the actual inventory correctly”. It’s easy to see here that the story demonstrates value to the user, this story allows the user to edit the inventory list so that it’s accurate.
Now let’s look at a SOA example, we can keep the web application from the previous example, but let’s add some services. Say the inventory app has to access three other services through an api service, in addition these other services are created with different languages and technologies. Now, let’s take the story from the first example, and let’s say in this example, implementing the functionality of deleting a product will require work on all five services. This is where SOA and Agile start to butt heads. Traditionally, SOA would suggest that you break this story down functional lines to encourage specialization. An agile team may be tempted to go this route as well. It’s easy to break stories along functional lines so that team members can focus individually on one area or technology of a project. This allows you to create a story for say, just the api service. The story would read much like “As the web application, I would like to get a list of available inventory from the api so that I can show it to the user”. The problem here is that we are not representing user value in this story, we are only demonstrating value to the web application. There is a better way however.
The solution lies in listening to agile’s persistence in cross-functional teams. When I say cross-functional teams, I’m referring to the level of interoperability across the team, how well the team can work together to solve problems. In our context, this is directly tied to the team members ability to work on all areas of a project, the cross-functionality of a team is limited by the individual team members understanding of the technology being used. This is important here for two reasons: first is that when team members specialize in one area of the project, they isolate themselves from conversations and decisions taking place in other areas of the project while isolating others from conversations and decisions around the area they are working, the second, is that specialization increases the risk that only one person will have knowledge of some area of the project, best known as the bus factor.
Encouraging cross-functionality across your team can be challenging. It requires that team members think more broadly about what they do. Whether it’s the frontend developer learning how the deployment scripts work, or the devops engineer grabbing some design implementation stories and writing some html. It challenges team members to expand their scope of development and thus scope of influence. The result however will allow us to create our desired stories that correspond directly with user value without having to work around functional lines because each team member is competent in all areas of the project. Team members will be able to grab any story from the sprint backlog regardless of the technical requirements. In addition this will allow for all the other benefits of cross-functional teams.
Allowing team members to grow in their expertise can be greatly enriching to both individuals and teams. Building cross-functionality encourages practices such as pair programming and peer code reviews which have been shown to increase code quality by decreasing bug rates, as well as increase team member happiness. Cross-functionality benefits product owners and other stakeholders as well. A team that is encouraged to broaden their scope can help in ways other than technology, such as market research, sales and strategy. In essence, a highly cross-functional team acts as a product development team, not just a development team, and this can mean the difference between a successful product and just a successful program.
More reading:
No Responses to “Agile Teams and SOA, Thoughts on User Stories and Cross-functionality”