The next principle of Disciplined Agile to discuss is the principle to “Optimize Flow”. If you are like me, our first take on this is to view this in light of the team, making sure the team is tightly integrated together and working at an optimal, but sustainable, pace. While this holds true, the point of this principle is much broader than the team. In fact, we will want to look at flow from an enterprise perspective before we can truly say we are working optimally. This is because of an all too common situation we may find ourselves in.
At one point in my project management career, I was asked to help rescue a software system implementation which had gone extremely poorly. The business was literally brought to its knees as shipments were not going out, servers were crashing, EDI documents were failing, and the user’s security access scheme was so convoluted people were going back to spreadsheets just to take orders. Yes, the stories of failed enterprise system implementations are real, and this was one of them. But what was interesting about this particular project is that the business leaders recognized the IT delivery managers for their “success” at working extremely hard! In fact, the bonuses they received were substantial, even as that segment of the business was bleeding cash until we could do major surgery to stabilize the system.
This is an illustration of how it is possible to be very good at doing the wrong things. The teams had put in extraordinary efforts to …. effectively break the order to cash cycle for the business. In the Disciplined Agile world, we would say that they broke the organization’s Value Delivery System. This is familiar not to just Agilists, but to PMs as well, we know that scope management is not just delivering the requirements as expressed by the stakeholders, it is also ensuring no value-added work is included (i.e. out of scope).
You may be thinking the situation I described is just a dysfunctional project team and, more importantly, foolish and capricious project leadership. Yes, it was all that and more. But the most important aspect that was missed is that they weren’t there to do a bunch of work, they were there to ensure the deliverables enhanced the ability of the organization to deliver value through their people, processes and tools.
It is this flow, as customer demand is fulfilled through the value-added goods and services provided by the organization, that makes the business viable. And the level of process and product quality builds profitability and sustainability.
Optimize to the greatest value – One of the key concepts in Disciplined Agile is how organizations provide value for their customers through the value stream. From the customer’s perspective they receive value in the organization’s products and services, and if the customer perceives they have received greater value than previously they will grow their loyalty and, sometime, even pay more for the products and services. This is referred to as value delivery. The organization can also focus on value realization, which is the optimization of the value stream to increase the return to the organization (revenue, profitability, ROI, etc).
As project managers we may think, “what does this mean to us?”. When we are involved in a project we are typically doing so as a means of delivering value to an internal or external customer that increases the customer’s loyalty to the project team, and by way of the project team to the project manager as well. Therefore, our primary concern should be what is the value that is expected from the project objectives and build delivery processes accordingly.
When it comes to value realization, we may be only doing so to realize a greater benefit to the project team rather than the organization. Or we may be simply delivering the expected benefits management plan as a scope item in the project as the case may be. But, doing all the right processes and filling out all the appropriate forms, and even having the most well-coordinated project management plan will not matter as much if the customer isn’t perceiving an increase in value in what is being delivered.
In truth, most people do not care about how well you managed the project or how robust your process knowledge is, or even that you are certified in a myriad of practices (as in you have a long list of alpha characters after your name – guilty as charged!). What they care about is that value that we have been discussing. From that perspective we continuously communicate and facilitate and visualize all the things that contribute to customer value in order to ensure the customer is satisfied and well taken care of in the end.
That is not to say that the processes and knowledge about team leadership skills and capabilities don’t matter. They very much matter and I would say it’s near impossible to truly deliver value effectively without having a well-used agile and project toolkit at your disposal. But, since most people don’t care about practices, one of the best compliments I receive is when I hear something like, “we don’t like all the project management processes and overhead, but we like what you do”. Well, what I do is all that project management processes and overhead, just in a way that they walk away feeling they have received value!
This is one of the reasons I’m so sold on the Disciplined Agile toolkit. It has expanded my capabilities, and I have a number of tools to now choose from that were not previously at my disposal. The step-through of the decisions that lead the team to the right project delivery solution, delivering value to our customers that results in a high degree of satisfaction!
Optimize to the benefit of the enterprise – “Dan, you’re making haste slowly”, said my Dad. As was typical in my younger days, I was trying to finish my work up without consideration for how the work I was doing fit with others. I was so focused on my tasks I didn’t realize that what I was doing didn’t fit with what others were needing and so I was at a high risk of a “do-over” or, as we would call it, rework. In fact, I was more often than not focused on what I wanted to do next (like get out of there) rather than what was truly needed. Again, it’s very possible to be working extremely hard and efficiently delivering something that won’t work for the purpose it’s intended.
We will discuss this more thoroughly in the next article in the series covering the principle “Enterprise Awareness”. However, these two principles are related in that we should maintain our focus on what works best for the team, which then should be evaluated as to what fits best for the enterprise. If what we’re delivering isn’t delivering value for the whole, we will be left with mismatched deliverables, in other words, making haste slowly.
Optimizing flow for the enterprise in the Agile context relies heavily on product ownership that is thoughtfully created against the organization’s value stream, and that represents the interests of the organization as their primary concern. There are few product owners that are able to appropriately balance the needs of the customer and the system. Too often the product owners focus on system needs and stability over the needs of the customer. I have yet to see an organization that truly gets product ownership “perfect” but have worked with some great individual product owners that can comfortably sit astride the needs of the value stream and the product to deliver optimized solutions for the enterprise.
If we were to take a project view, this requires the team delivering within not only the requirements of the project, but also with a plan for transition from the heavy work in delivering the project to the consumers of the project deliverables. This will come when we are all pulling together to deliver across all the actions that need to be accomplished from customer request to customer usage of the value we’re delivering (definition of value stream).
Optimize, then measure what matters – I once worked with a team where they were interested in implementing Agile practices. When I discussed what that would mean for their development teams, we began speaking of concepts such as Test Driven Development (TDD) and refactoring. As we spoke, I noticed the development team and their manager were starting to become a bit agitated. Naturally, that piqued my interest, so we explored this a bit further. Come to find out, the development team member’s individual incentive plans were based on reducing the number of times the developer checked out a component to refine the code!
Noble concept maybe? The idea was that the incentive would reduce the amount of rework, which was rightly considered “waste”, by ensuring the developer “got it right” the first time. However, what that incentive produced was behavior that resulted in very non-Agile like practices. The developers wouldn’t touch any code until the specifications were so thoroughly documented that it seemed they could simply copy and paste from the specifications into the code itself. Not very efficient, and very wasteful in practice.
If you have been around Agile for any amount of time, you begin to realize that your team is working in the code a considerable amount of time. Running null tests, exclusion tests, writing to fail the test conditions and so on are sound practices that Disciplined Agile embraces. In this way we learn how to succeed sooner, always refining as we go.
This story illustrates the importance of incenting the right behaviors. In every organization where we have brought in Agile practices, we find the champions of Agile hadn’t really thought of involving Human Resources in their discussions. HR loves individual incentives, but those can sometimes work contrary to team behaviors as well.
In Disciplined Agile, when the customer wins, we all win. Measuring the effectiveness of our value stream in moving the customer request through the organizational actions with a minimal gap between actions that delight our customers is our primary measurement. And in this way, we can also optimize the return of that value for the organization. Measure these things and you will see a fresh energy and focus on how the organization interacts!
Our focus with Optimize Flow has been to seek to ensure work is flowing not only within the team, but primarily across the organization. The unique characteristic of Disciplined Agile, when compared to Scrum, Kanban, Lean or other Agile schools of thought, is that the Disciplined Agile Delivery (DAD) toolkit brings the best of all these practices together, while not dictating that everyone work exactly the same way. In DAD we work as to what is best for the situation. Let’s talk more about this in our next blog, coming soon, for the DA principle “Enterprise Awareness”.