This post is one of many from the series of Stuck Fermentation – Converting to Agile Stalls and it will focus on helping you address ownership and process issues by leveraging SOA based principles.
In order to be truly successful in Agile, you must give each team the autonomy, empowerment and desire to own the work they commit to. Agile is about making small teams effective and you make agile scale by enabling many small teams in parallel. Waterfall leverages a different technique for scale – one based on structured hand-offs were more often than not, the skilled architects lead the design and planning aspects of development. This creates an ownership and accountability issue because the teams planning the work don’t own the implementation of the work. When you are able to convert an entire organization from waterfall to agile, the transformation is easier because everyone is involved in the change and you can address the ownership and process issues at the same time.
But what if you can’t convert the entire organization to agile? Perhaps part of the overall system is mainframe based. Perhaps you have a culture that is predominantly not accepting of agile. Perhaps you don’t have the executive support to do a full switch. There are many reasons why an entire organization can’t convert to agile all at once.
For this post, I am going to declare a few key assumptions:
- For whatever reason, the entire organization can NOT convert to agile – you are stuck with a waterfall process and an agile process
- The work the agile team is doing IS important and is NOT a prototype or side project. The work must be integrated into the main system and it must be production quality
First and foremost, no mater how hard you try, waterfall and agile don’t mix. It’s not the methodology itself but the life cycle that’s the issue. If you had a “waterfall” process that went from start to finish in 4 weeks, you would be able to manage it with an agile process based on 4 or even 2 week cadences. It’s the life cycle that causes the issue – not the “methodology” itself.
Now for the SOA part. Service Oriented Architecture is the latest buzz word in the software industry. The reality is that good architects have been designing software like this for 10s of years. The difference now is that focus on a well defined XML based contracts that if done right are truly agnostic. A well implemented SOA based system in theory supports interchangeable implementations for the same interface contract. SOA enables loose coupled systems that actually work well together.
What does this have to do with waterfall and agile? Everything – because it’s actually the solution to two major obstacles people face when converting to agile. Here’s how SOA based thinking can be leveraged to make the agile transition much easier;
- You can decouple yourself from complex integrations by managing to a well defined contract. This gives you the ability to stub out functionality until you have the opportunity to integrate with the external system. This is important because the external system may follow a different life cycle
- Teams are given full ownership of the “black box” behind each component. They must abide by the contract of the interface but how they implement the work behind the interface is completely in their control
- You can scale agile more effectively by defining teams for each component. You can leverage the contract definitions to manage the dependencies and relationships between the teams
- Finally, you have the ability to mitigate life cycle discrepancies between methodologies by using the interface itself as the mechanism to allow different methodologies. The process each team uses to develop within their black box is irrelevant to the other teams.
The last point is key. If you try to leverage two processes within a single component boundary or for two or more components that are tightly integrated, you will fail. In order to implement agile effectively, you must have the ability to remain loosely coupled from components that leverage other processes such as waterfall. If you don’t, you will fight every obstacle that makes the processes distinctly different including
- Life cycle discrepancies
- Resource management differences including availability and skill set
- Environment availability
- Inability to have a feedback loop due to lack of availability of edge systems
- Politics related to design reviews, design approvals and even statistical measurement such as the number of design changes within a release (remember – in waterfall, a change means a bad design more often than not)
