Prediction #10: Agile rollouts increasingly driven from executive office, developer backlash follows

DZone 's Guide to

Prediction #10: Agile rollouts increasingly driven from executive office, developer backlash follows

· Agile Zone ·
Free Resource

This is a reposting from Mik Kersten's Tasktop Blog.  Look for more predictions in this series on his blog and on Agile Zone. 

Agile development is at a crossroads. Practices hardened around small teams of motivated enthusiasts are now being deployed at scale in the enterprise. Average professional software developers, far from the Scrum rock stars or Kanban aficionados, may remain inspired by their Agile training for a couple of months. Then the next release crunch comes, and too often the Agile process is perceived as yet another source of overhead that keeps the developer from coding. Agile practices which have not yet become engrained, even though they are recognized as beneficial, start to fall by the wayside. User stories are not broken down into tasks until the end of a sprint, release frequency drops, the Agile project tracking tool is only kept up-to-date at the insistence of the project manager masquerading as a ScrumMaster. The software development process is once again driven by managerial needs rather than those of the self-organizing team.

The unintended consequence is that the Agile process has degraded into a project documentation methodology. While managers who architected the large-scale rollout scramble to adopt even more cutting edge Agile and Lean practices to address these problems, upper management becomes concerned that they now have even less visibility into the development process than they did with waterfall. Arguments are made that teams’ velocity has increased, but the benefit is outweighed by the overall loss in predictability and increasing developer discontent. At this point, the expected ROI of Agile is looking more like a realized loss.

The frequency of stories like the above is increasing with the growing number of early adopters of Agile at scale moving beyond the initial honeymoon phase. For organizations scaling their Agile deployments into the thousands, it is not be feasible to train and motivate thousands of employees to do Agile as it is “meant to be done”. But complaining that developers are not doing Agile right is akin to telling iPhone 4 users that they’re “holding it wrong”. To scale to large enterprise, a new work process has to be encapsulated with tool support that embraces the individual contributors doing the actual work. To date, Agile vendors have done a very good job providing project managers and product owners with planning and tracking tools. However, the primary creators of project deliverables are software developers, and they have consistently been an afterthought in most Agile solutions and deployments and are in the process of being disenfranchised.

The crux of the problem stems from the inherent need for large scale adoptions of Agile to be mandated by management. Consider the previous technologies that followed this trend. The Unified Modelling Language (UML) seemed like a great way of getting business level requirements discussed as part of software design. Heavyweight Application Lifecycle Management (ALM) tools from a decade ago promised to transform the software delivery process. Both saw a backlash from developers who knew all along that they reaped more benefit more from lightweight tools that embrace coding and collaboration.

This decade-old backlash against heavyweight and management-driven ALM tool deployments was part of the inspiration for the Agile Manifesto’s call for “Individuals and interactions over processes and tools”. If we keep heading in the current direction of ignoring the need for tools that bring developers’ programming activity into the process and that provide them with a concrete and visible benefit to their day-to-day coding, we will witness the same kinds of failures with Agile that we saw with ALM tools. We have slid far enough down this slope that in 2011 we will start to witness both major hiccups and outright failures among early adoptions of Agile at scale.

To address this necessary move of Agile from early adopters to enterprise pragmatists, tools that focus on individual developers needs are the critical “last mile” of the Agile deployment. We need look no further than the Toyota Production System (TPS), the precursor of the Lean manufacturing trend which did much to inspire Agile development, for guidance on the role that software production tools need to play in the process. The TPS consists of three interlocked elements: the philosophical underpinnings that define what we deliver to the customer, the managerial culture that defines how teams collaborate, and the technical tools that get things done. Developer tools are as primary to Agile software production as assembly line automation is to cranking out Toyota Prius automobiles. The existing focus on the ALM and above layer needs to be extended down to the Integrated Development Environment (IDE).

Coding, deployment, source control, and continuous integration tools must be integrated as a key pillar of the Agile development process. The knowledge formed around development activities needs to be captured and linked within the plan and product backlog. User stories need to be automatically connected to commits, and the developer’s workspace focused away from the system as-a-whole and onto the task-at-hand. Developers need to be given powerful and efficient tooling which gives them a window into their part of the Agile plan and connects their workspaces to the delivery process as a whole. To avoid the backlash of a thousand developers complaining that the changes imposed by an Agile rollout are getting in their way, we need a new focus on the final and most critical gear in the Agile deployment—the developer’s workbench.

Mik Kersten, a good friend of DZone, gave us permission to post this series.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}