5 Myths of Agile Explained

8/6/2019 5 Myths of Agile Explained

http://slidepdf.com/reader/full/5-myths-of-agile-explained 1/5

CONTENTS

Introduction .....................................................................................................1

Myth #1: Agile Development is Undisciplined ...................................2

Myth #2: Agile Teams Do Not Plan ......................................................2

Myth #3: Agile Development is Not Predictable ............................ 2

Myth #4: Agile Development Does Not Scale .................................4

Myth #5: Agile Development is Just Another Fad .........................4

Summary ........................................................................................................5

As more and more organizations

turn to agile development, thereality o what agile really is o tengets obscured.



MYTH #1: AGILE DEVELOPMENT IS

UNDISCIPLINED

Some have re erred to agile development as hacking,others as “code-and-x”. Anyone who has seen anexperienced agile development team in action would

likely reconsider. Continuous integration, test-drivendevelopment, re actoring and even the controversial pairprogramming are not practices or the undisciplined.Even more indicative o the discipline required, thecontinuous delivery o running, tested so tware every ewweeks could be characterized as the ultimate so twareindustry discipline.

Many o the practices associated with agile developmentare not only demanding o the individual, but typicallyrequire a signicant shared commitment to the successo the entire team. Within agile development, teams are

constantly delivering benet to the organization anddemonstrating their value – not once a year, but everymonth, every week, and in some organizations, everyday. While some so tware development teams may neverachieve this level o delivery requency, almost all canbenet rom the practices that automate and acilitate thistype o delivery discipline.

Interestingly, most o the practices associated withagile development have been around or decades. Thereal diference is that it is only more recently that thepractices have been packaged together as collections

o interdependent practices. These practices, whetherincorporated within Extreme Programming, Scrum,Feature-Driven Development, or any other agilemethodology, really help dene the innovation whichhas taken place. Since their inception, a high degreeo developer, team and management discipline has notonly been promoted, but demanded by all o the variousagile methodologies. The more agile a team, the morediscipline they typically exhibit.

MYTH #2: AGILE TEAMS DO NOT PLAN

This misconception generally relates to a lack ounderstanding o an agile, or incremental, planningapproach. Most agile teams spend as much, i not more,time planning their projects. The diference is that thisplanning efort is spread throughout an entire project asopposed to being compressed into the beginning o aproject. As opposed to extensive, up- ront planning, agiledevelopment simply ollows an incremental approach toplanning, which allows or initially planning at a high-level

and iteratively planning at lower levels as more and moreknowledge is gained.

I we look at the actual results o many traditional projectplans, detailed, task-based project plans created at thebeginning o a so tware project o tentimes quickly all

out o synch with the technical and business realities oa project. Over time, signicant energy is expended inreconciling the original plans to these current realities. Onthe other hand, agile development accepts this volatilityand instead replaces detailed, up- ront planning with“continuous planning” – or example, quarterly at therelease level, monthly or weekly at the iteration level anddaily at the task and team-member level.

Given that the technology, requirements, businessdemands, people, issues, risks, etc. are almost alwaysin ux. In virtually all so tware projects, this type o

continuous planning approach provides the team with thenecessary process-based ammunition to much more easilyand e ciently adapt to the changes. In addition, teamsare also able to incrementally optimize their plans as newin ormation emerges.

What is just as important is that as teams begin to learnwhat they can deliver on a daily, weekly and monthlybasis, they become more accurate at longer rangeplanning. Many o the agile teams I’ve worked with havebecome much more condent in both their short- andlong-term planning abilities than they ever were with

traditional planning approaches.

MYTH #3: AGILE DEVELOPMENT IS NOT

PREDICTABLE

As with planning, agile development methods promotea undamentally diferent approach to metrics and

orecasting than traditional development. Theapproach o traditional development is one o creatingdetailed, activity-based plans upon which to evaluateprogress, deviation rom plan and the ability to predictprecise outcomes. Plans created in this manner haveun ortunately o tentimes only ofered the ‘perceptiono predictability’. A ter decades o experience, theresults associated with this type o planning on so twaredevelopment projects have proven dismal at times. Justas important, the predictions associated with theseplans rarely improve over time because there is nosimple mechanism in place or evolving the plan as newin ormation becomes available.



Agile development instead replaces detailed, speculativeplans with high-level, eature-driven plans thatacknowledge the inherent complexity and uncertainty oso tware development projects. Ongoing reconciliation oactual efort to original plans is replaced with incrementalplanning and re-planning at a more and more granular

level throughout the development process. Becauseagile development operates in a rapid, iterative ashion,valuable historical data quickly emerges or supportingboth short- and long-term planning.

Using this historical in ormation upon which to base utureplanning, the quality o plans quickly begins to improve.As speculation is replaced with historical act, teams areable to predict with much greater accuracy what they willbe able to deliver over time. Agile teams replace PERTand Gantt charts with simpler concepts such as Velocityand Burndown charts.

As shown in Figure 1, a Velocity chart (lower le t), typicallymeasured in terms o story points, ideal days or hours,displays the volume o eatures a team delivers eachiteration. Over a short period o time, a team’s Velocitywill stabilize, resulting in a very reliable planning metric

or uture iterations.

The Burndown chart in Figure 1 (upper le t) reects boththe amount o work remaining as o each day during aniteration as well as the overall change in scope o thework within the iteration. I the slope associated with theremaining efort, represented by the red bars, is not suchthat the work will be complete by the end o the iteration,

this is immediately apparent to everyone on the project.Not only can the team act on this now, they can use thisin ormation to calibrate the amount o work put into theirnext iteration plan. Simple charts and metrics such as theVelocity and Burndown charts convey as much or morein ormation than PERT and Gantt charts, but do so in avery visual and actionable manner.

As opposed to planning once a year and executingagainst that plan or the remainder o a project, agileteams are constantly planning, estimating, prioritizingand delivering against the plan. As teams continue to

plan and re-plan throughout the development process,each individual’s planning skills continue to improve. As aresult, a team’s condence in its plans increases, providingall stakeholders with a much better sense o where theproject actually is and what can be accomplished.

This type o accurate, black-and-white visibility into thedevelopment process also helps build trust throughoutthe organization.



MYTH #4: AGILE DEVELOPMENT DOES NOT

SCALE

Generally speaking, so tware development itsel hasscaling issues. There is plenty o evidence that wouldsuggest this is clearly not a methodology-specic

problem. The larger a project’s scope, the greater theprobability or ailure; the greater the number o peopleinvolved in a project, the greater the communicationrisk and complexity. Agile development simply acceptsthese realities and recommends smaller projects, shorterdelivery time rames and smaller teams. Smaller teamshave been proven time and time again to be much moreproductive than large teams.

This does not mean organizations should avoid solvinglarge problems. Agile simply suggests that there is adiferent approach to solving the same problems. Agile

methods promote taking large projects and breakingthem down into a coordinated series o smaller projectsstafed by smaller, cross- unctional teams. The variousteams’ work is integrated at least every iteration inorder to reduce risk and ensure unctional and technicalcompatibility. There are clearly other processes thatneed to be instituted in order to acilitate communication,integration, architectural design and standards anddecision-making amongst the teams, but these challengeshave been solved be ore by many organizations.

Over the last decade, enough agile projects involving

hundreds o people have been per ormed by multipleteams, in multiple locations, across multiple time zonesto have a high degree o condence in the ability o agiledevelopment to scale.

In act, i a company has a very large, complex problemto solve, there are many reasons to pre er the use oan agile process in order to rapidly expose risks, provebusiness value early and to quickly institutionalize ahighly disciplined approach to so tware development andtesting.

MYTH #5: AGILE DEVELOPMENT IS JUST

ANOTHER FAD

Fads typically involve a great deal o hype with littlesustained substance. In a span o less than veyears, agile development has become the pre erred

development approach or many o the world’s leadingtechnology companies. Many o the industry’s leadingvisionaries and practitioners have embraced andpromoted agile development. And while ve years agoagile development was primarily being adopted by small,collocated teams, many o today’s adopters include largedivisions and so tware organizations o enterprise IT.

A Forrester 1 report on agile development discusses thesecond wave o adoption that’s now underway, withenterprise IT shops taking the lead. Results compiledwithin the report indicate that agile development

processes are already in use in 14% o North American andEuropean enterprises, and another 19% o enterprises areeither interested in adopting agile or already planning todo so. Enterprise IT shops have ound that by turning toagile processes they are better able to cut time-to-market,improve quality and strengthen their relationships withbusiness stakeholders.

The broad-based acceptance o agile development isclearly a signicant shi t in the industry over the last ewyears. In a recent survey o VersionOne’s own customers,the results corroborate those ound by Forrester. The top

three reasons noted or transitioning to agile developmentincluded accelerating delivery, aligning business andmarket needs with IT and improving visibility into theso tware development process. These are not theevaluation results o a ad, but instead business criteriabased on real business results.

Finally, understanding agile team dynamics andcollaborative decision-making techniques is importantin part because agile requirements denition involvesmore than just the Business Analyst and the productowner. These skills enable the BA to accept input rom all

the team members, speci y a more robust solution thatmeets the evolving needs o the business and help createa strong sense o condence that the solution can bedelivered to market.

5 Myths of Agile Explained

Documents

Transcript of 5 Myths of Agile Explained