Better Software - March 2009 - (Page 29) Figure 3: The lean portfolio—prioritized feature set, staged and decomposed into user and system stories (yellow cards) approach. Status reviews are no longer based on tasks completed but instead on validation of technical results. At first glance, the often-made assumption is that a premium must be paid—in terms of resources utilized and quality sacrificed—to deliver sooner. The promise of lean, seen as this article unfolds, is that you don’t have to pay a premium but, in fact, just the opposite. By focusing on small, releasable features with the goal of getting software completed all the way through development, an agile team quickly exposes impediments to delivering rapidly. These impediments are normally hidden in large waterfall projects, as processes to transform handoffs create illusions of control. A common misunderstanding in agile methods such as Scrum is that teams should not look ahead but instead should focus only on the work for the current iteration. This pattern is a leading cause of failed agile teams. Scrum doesn’t say, “Don’t do product planning or release planning.” Similarly, lean tells us that it is important to look ahead, just not too far ahead. The lean product portfolio allows priorities to be set and elaboration of details to occur at the right respon- sible moment. Agile methods allow a learning organization to emerge, which results in predictable estimation of features described at the capability level. These features can be decomposed in advance of the iteration in which they are actually implemented by establishing lean flow that is conceptualized by the planned release of features. Let the Value Lead Driving from business value means that IT is focused on rapid, high-quality delivery of the highest-value features. A clear violation of this pattern often occurs when a project is undertaken to rewrite an existing system using a new technology. Often, misguided intentions of strategic technology changes result in long, drawn-out projects that, in the end, deliver no new business value. Entire IT organizations can get drawn into these black hole projects that put business in the backseat with IT driving. The cost-minimization argument helps justify technology conversion projects, since no new requirements have to be gathered. Unfortunately, a very common outcome is that many of the unused product features—as well as system errors—are converted, also. www.StickyMinds.com The right way to do conversion (or any) projects is to utilize and empower cross-functional teams to build incremental slices through the system so that the business stakeholders can validate realizable features as the technology is converted. This allows business value to drive and allows the development team to focus only on high-value, required features and not to waste time converting the unneeded features—or worse, bugs—of the system. It also allows the business to embrace market changes and opportunities that will arise during the conversion project. However, it requires an investment in training the technology organization in the use of agile design patterns and test-driven development. These agile engineering practices allow teams to create change-tolerant architectures that give them the confidence to make aggressive design changes, and suites of automated regression tests allow verification that nothing existing is broken as changes are implemented. Organizational structure will indicate if IT is driving the business clients [3]. A clear indication of this is when an IT organization is structured around technical or functional areas, such as enterprise data, interfaces, or requirements. MARCH 2009 BETTER SOFTWARE 29 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.