Enterprise Agility

Enterprise Agility Often, organizations invite us in to help them think about how to bring Agile into their development practices. The initial focus is often at the local team level. Our experience is that this is not the best place to start. Instead, we prefer to look for pain points that the organization is feeling in their development work, and we talk with local teams to get indicators of these points. What is stopping you from delivering the value to customers that you feel you should? What opportunities do you see and what waste is there? We can predict some of the answers depending on whether it is an IT organization or a product organization. IT organizations tend to have people working on more than one project at a time whereas in product organizations, people usually focus on one project. This means that IT organizations often have less connection to the business and have more contention for resources. These are all opportunities for improvement that may or may not involve changes at the local team level. Enterprise Agility, Systems Thinking “Enterprise Agility” focuses on helping the overall development organization be more able to respond to the needs of the business. It starts by looking at what needs to be done and then on how to do it. Probably, this will involve Agile at the local team level, but that might not be the best place to start. There is a maxim that “Good people in bad systems still cannot produce.” It is always best to take a systems-view of process improvement, to focus on the systems that people work in. Otherwise, you can end up with sub-optimization – one part of the system doing well but overall, it still under-performs. Doing what is best for the enterprise involves optimizing the whole. Too often, consultants want to start at the local team level just out of habit. Then, they try to “scale up Scrum to the enterprise.” Beyond the problem with sub-optimization, there is a great danger that you may never even be given the chance to start. Why? If upper management has not already bought into the idea of Agile, then one failed experiment in Scrum can leave a permanent bad impression. Starting with a focus on the challenges of the enterprise – reducing waste and delay, improvements in the value stream – helps them see what they will be getting out of it. An experiment with a local team, then, becomes one of several things you could be trying as a start. Look for the Pain Points Chances are that the size of the organization will impact the issues we address, but that is not certain. Rather, it is complexity of process and connections between teams and organizational culture that leads to waste and inability to work with the business. For example, stove-piping, over-burdening processes, a disconnect between business and IT. What are the underlying lean principles that are being followed and what are being violated. The biggest challenge is that pain-points are not always recognized and we tend to think that it is just the way things have to be… that things cannot be improved. Do the SIPOC When it comes to analyzing where to start in helping a development organization, it often makes sense to talk to the Business, which is the customer of the dev group, as well as upstream to the Operations, which supplies the dev group. A standard lean technique is to do a simple SIPOC (Supplier-Input-Process-Output-Customer) to be explicit about who and how the organization interacts with the system. All too often, this simple step is forgotten as we are focused on building product. For example, a local team might already be reasonably productive, even without Scrum. But they are thrashing because their Business customer is not ready to work with them when they need answers. Or the change management system takes weeks to schedule a user acceptance test. These are structural issues dealing with upstream inputs and downstream outputs over which the local team has no control. Attack these root causes of thrashing and