In preparation for a presentation to Senior Executives on Silver Tree IT Consulting & Services (STS) Lean IT Practice I was struck with Wikipedia’s definition of DevOps (the final mile of the end-to-end Lean IT Process from software capability ideation to putting it in the hands of the customer). What struck me is that the definition leads with “DevOps is a culture”. When I presented that slide, a COO of a national organization challenged me, saying it was hard to buy into anything having to do with IT as a culture.
I may not have convinced him at that moment that adopting Lean IT and DevOps requires a cultural transformation, but as I explained how each and every player must take on the perspective of eliminating work-in-process and continuous improvement, it became evident to me Lean IT will only be adopted successfully by those willing to embrace the cultural challenge.
We might wish for some prescriptive approach to follow, but the reality is that we can’t direct our team to a solution. If an organization is looking for significant cost reductions through Lean IT, the organization must accept that a command and control management style can’t drive the change required where everyone is responsible for quality and delivery of value to the customer.
Consider waterfall requirements gathering. An analyst meets with the business to collect requirements up front. The business recognizes that this is their one chance to get what they might need in the software. The human tendency is to propose every contingency possible. Most likely without prioritizing what is essential. The developers then systematically build each and every requirement, probably not realizing any value for the customer until all is complete.
The command and control style dictates “Plan the work and work the plan”. But what have we accomplished? Hopefully some good and useful features. However, often we have invested considerably to build features that rarely or never get used. These are the “what if” features tossed in just in case they will be useful. It is important to realize that not only do we incur a cost to develop rarely used features but in the case of a waterfall approach we delay the release of useful features because everything goes in one Big Bang. These rarely needed features require ongoing maintenance and negatively impact the team’s ability to add new useful features.
So consider – before you think it’s time to go Lean – are you ready for the cultural skirmish required to get there? My next blog will cover what cultural changes move us to Lean IT.