Meeting Unique Challenges for Delivery Faster and Smaller in IT

One of the first principles in lean is delivering faster and in smaller batches of work. Delivering faster means we learn quicker (more information) and releasing in smaller batches helps us get more predictable and minimizes a lot of complexity. More information, more control and less risk. All good things.

However, despite these benefits I often encounter clients that are skeptical whether this is realistic with the real world challenges they have to deal with. The domain my clients (IT) tend to live in are often large enterprise organizations that spend most of their energy maintaining legacy systems or modernizing them to newer platforms. Enabling the business is their purpose. Unlike product vendors that focus on pushing out new products for others to instantiate, IT has to transform and integrate products into solutions that work with their business (people, process, technology). This tends to bring out a set of unique challenges specific to IT that is often not discussed in detail in the agile and lean communities. Some of their typical key challenges when trying to deliver fast and release in smaller batches are:

• Data Dependencies - enterprises tend to deal with large amounts of data (often with strict regulations), need to guarantee integrity and carry data with them as they evolve (data conversion is a big task and cut-over planning is essential)
• Integration Dependencies - systems don't sit in isolation within enteprises and often there is a large sprawl of integration between systems with inflexible interfaces (often point to point with legacy techniques and not documented) resulting in a complex network of dependencies
• Enterprise Governance - running a large enterprise is complex and CIOs often want to instill some sense of order in how things are implemented and governance is one way of doing that which often becomes a significant transactional cost when running through the SDLC process for every small release
• Infrastructure Provisioning - often the infrastructure group is detached from the delivery teams resulting in a silo-effect where the request process for environments is long, inefficient and error-prone (project start-up and iterative scaling is hard in this environment)
• Change Management and Training - fast system releases means the business users need to deal with frequent changes in their business process and this results in the training teams needing to deal with an increased workload and a business culture that needs to integrate changes into their BAU (business as usual)

While these are all tough problems to solve and are largely dependent on context and environment, I think there are some good potential solutions out there. Too often the first response is to give into the challenges above when the answer should be "yes we recognize the real-world is ugly" and "let's figure out how to better manage our dependencies and be more efficient and streamlined in how we work". Reduce dependencies and reduce transactional costs. Based on some of my real-world experiences, readings and thoughts here are some potential solutions I have cobbled together from various sources:

• Domain Driven Design Team Patterns - this is probably one of the most powerful ideas in Eric Evans book that still hasn't penetrated into the general IT vocabulary and is one of the first tools I use when dealing with integration dependencies
• Lean Governance - one way of removing the bottleneck of enterprise governance is to focus on "enablement" and "flow" vs "command and control"/"endorse, review, approve" and "policing", some folks like Scott Ambler have written some articles on this topic but additional effort in this area aligning agility and lean with some of the other more traditional groups (e.g. TOGAF) out there would be interesting
• Platform as a service (PAAS) - one easy way to move infrastructure provisioning along is to move away from providing "boxes" and "wires" to offering end-to-end dev/test/prod application environment stacks to delivery teams using shared environments, some organizations are offering this externally as a business (e.g. Amazon) and internal IT shops should look at how they can bring their own variant of this into their infrastructure groups (my current public sector client is doing this today)
• DevOps - another common problem is the silos between operations and development and there is an active community looking to solve this by pushing the DevOps paradigm (development + operations) and making it work in their environments, some organizations (e.g. Facebook) have really pushed the boundaries here and merged the roles into one with "developers" actually implementing patterns in their code (e.g. Gatekeeper pattern) to help solve release management challenges
• Change Management and Training - there is an increased awareness today that usability experts need to be engaged in the delivery process early on and getting them to work in an agile and lean way is something that is starting to be discussed but good usability can only go so far and there has been little discussion about how to embed change management and training resources in the team and getting them engaged in the iterative release process, new releases without users doesn't deliver much value to the business at the end of the day