Like many business leaders, you are probably being challenged to do more with less. Since the early 1990’s, I recall Jack Welch and GE management telling us to work smarter, not harder. The first step in working smarter is to fully understand how your organization moves an idea from concept to cash. The first two questions you need to answer are:
1. Where are you today?
2. Where do you want to go?
As Yogi Berra once said, “If you don’t know where you are going, you might wind up someplace else.”
Next, don’t make the mistake of sub-optimization by focusing only your software development team. In geek speak, this is sometimes called “optimizing the inner loop”; that is, a lot of effort is spent on shaving a millisecond off the time when minutes can be saved by looking at the entire program. I have worked with numerous companies that fall into the trap of sub-optimization by assuming that they can transform into an agile enterprise by introducing only their software development teams to an agile framework such as Scrum without looking at all of the activities that occur before and after software development. In most large enterprises the development team activities take up only a fraction of the cycle time when measuring concept to cash in a value stream map.
To achieve business agility, we need to periodically reassess opportunities for reduction of cycle time, as this allows for improved return on investment and nimble response to competitive threats. Lean/Agile theory suggests that removing impediments to work will shorten cycle time, lower cost and improve quality. Eliyahu Goldratt wrote a very readable book in 1984 titled, “The Goal” that describes a methodology for identifying the most important limiting factor or constraint that is slowing the cycle time and systematically improve that constraint until it is no longer the friction point. Lean theory’s view of these impediments is that they are types of “waste” in that they do not add value to the end product yet they slow cycle time. Remember that the road to hell is paved with good intentions. Many of the impediments that you find are slowing your cycle time are activities that were added over time in the name of process and “best practices”. Are they truly needed or are they artifacts of a command and control company culture?
Allan Shalloway states in his article titled, “Where to Begin Your Transition to Lean-Agile”, that there are four critical areas to examine when trying to improve your cycle time:
1. Business: Often annual budgets and forecasts cause new feature requests to go on the back burner until budget time, resulting in backlogs that are probably not well prioritized or well understood.
2. Management: As a response to smaller budgets and fewer development resources, teams are often organized by specialty, causing many handoffs and wait time for resource availability.
3. Team agility: Because resources are organized by specialty and are often only timeshared among many efforts, it is almost impossible for teams to form in many organizations.
4. Technical skills: When management views their technical team members as “heads of lettuce” that can be replaced or reallocated as needed, it often neglects to invest in training and adoption of better technical practices. While pair programming, acceptance test-driven development (ATDD) and test-driven development (TDD) practices have been successfully employed in the technical community for over a decade, still less than 50% of the companies that I have worked with actually embrace these practices.
The question still remains, “Where I should start my agile enterprise transition?” The answer is to start where the largest gains can be made. A detailed value stream map showing the lead and lag time for all activities in the chain between idea/concept and cash/product delivery is required to understand where your value traps are located. An easy place to start is your software development teams. Introducing the Scrum framework to the development teams while you map out your enterprise value stream is an acceptable approach, as long as you understand that your biggest game changers are likely to be found outside of the actual development process. Forming dedicated and appropriately staffed delivery teams while beginning to employ technical best practices will without a doubt improve this part of the equation.
One final note to think about – there are four critical areas to address in your enterprise agile transition. However, most organizations only focus on team agility by introducing Scrum to their development team, despite that they are often not using dedicated teams or best practices in agile software development. So it should not be surprising that co-founder of Scrum Ken Schwaber was quoted as saying, “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.”
Increase your odds for success in your lean/agile enterprise transition by focusing on all four of these critical areas – business objectives, management, team agility, and technical skills.