Scaling Software Agility
I’ve had this sitting on my bookshelf since 2008 after Dean Leffingwell came to speak at my firm and now wish that I had read it sooner. (Thanks to my ScanSnap, iPad and Readmill I finally got around to it!) Offers both a solid introduction to agile as well as recognising the inherent problems of applying the techniques across many teams in a large organisation. Has given me lots to think about.
Note: The graph above shows only your linear progress through the book. In this book, you also browsed around for an additional 5 minutes.
Understand your context, compare it with what Leffingwell presents, understand the relative objectives, project scope and scale, and culture and commitment to improvement of your enterprise. And then adjust, adapt, and modulate Dean's recommendations to fit your needs.
You do not "do agile," you "are agile." If you only do agile without being agile, you will fail and not know why, and you will be left blaming some book.
After a short time, I was so won over by these methods that I soon refused to engage with any business or any team that did not have a strong sense of agility. The risk to the business was too great otherwise!
the specific methods themselves are less important than what we have learned from them in practice.
The Agile Manifesto reads, in part:
Andrew Doran
Always worth rereading.
We do not assume that we can develop new, state-of-the-art, unproven, innovative, and risk-laden software projects on a fixed functionality and fixed-schedule basis. Indeed, we assume that we cannot.
any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed
In retrospect, it appears that we made at least four key assumptions with the model that simply turned out to be incorrect
Andrew Doran
This is brilliant.
requirements decay
Andrew Doran
Great phrase! How requirements set in stone at the start of a project are less relevant as time passes.
Quality is fixed. Time and its associated partner, cost, are fixed (short iteration boundaries). Only scope can be adjusted.
Requirements are mandatory and rigid; stories are flexible.
An XP team should be able to automatically build the whole system and run all the tests in 10 minutes.
Time value of requirements
Andrew Doran
Excellent chart.
multiplexing across projects is prohibitive in XP. After all, how can any one person be depended on by more than one team, each of which has a near-term deliverable? And how many high-intensity, interactive communities can an individual be involved in at one time? Answer: about one.
In Scrum, the lines between product definition, design, code, and test are blurred. Product definition drives design, which affects product definition; testability drives design, which drives product definition.
software development is inherently a complex and unpredictable process.
Scrum teams, therefore, will constantly surface the organizational impediments that must be addressed to continue to improve. This topic is so important to software agility that we devote Chapter 21, Changing the Organization, exclusively to its discussion, using the Scrum model as its basis.
UML, a language used for specifying and documenting the architectures of software systems that was published by the OMG (Object Management Group).
Andrew Doran
UML! OMG!
Attack major risks early and continuously, or they will attack you.
RUP has been applied to large-scale projects supporting over a thousand simultaneous developers.
Open Unified Process (OpenUP)
Andrew Doran
I had never heard of this.
Open UP can be seen as a hybrid of RUP and a number of agile methods. Given the popularity of RUP and these other agile methods, this combination may receive some acceptance in the marketplace.
Andrew Doran
Did it? Does anyone have any practical experience of OpenUP?
Lean Software Development is a set of principles derived from a combination of lean-manufacturing thinking, which was pioneered by the Japanese in the 1980s, and the Six Sigma quality initiatives a l so applied by many innovative manufacturers in their efforts to reduce nonvalue-added activities such as inventory costs, rework, waste, and scrap
almost all inventory and its " redheaded stepchild," work-in-process, was ftmdamentally bad
In lean manufacturing, workers are cross-trained to be able to play multiple roles
DSDM is based on nine core principles
DSDM is the European parallel to the Agile Manifesto and the practices that it has spawned in the United States
A tenet of DSDM is the belief th at requirements cannot trul y be fixed and that when they are, only a s mall portion of them will deliver the bulk of the value to the u ser. Focusing on th a t portion delivers the most value b y prioritizing and severely managing scope
With DSDM, the assumptions are clifferent: date a nd resources are fixed, so in order to meet the date, requirements must be variab l e
DSDM turns the traditional assumption on its head
Andrew Doran
Useful diagram.
in DSDM, models are designed to b e lightweight and user oriented, so a more detailed domain model with ge neralization/specialization and message sequence diagrams, such as one might find with FDD or RUP, might be overkill unless the model is constructed in such a way that it could be readily vetted and understood by the actual u sers
In FDD, a feature is a much smaller ch un k, as defined below [Palmer a nd Felsing 2002]: A small, client valued function ex pressed in the form of <act ion > <resu lt > <object> . . . features are small enoug h to be implemented in two weeks
As opposed to XP and its mantra of shared owners h ip, FDD recommends that each class have one owner who is ultimately responsible for its development and maintenance
it would not be too extreme to say that when it comes to software development and software project management in general, agile changes eve rything
Figure 7-1 Changing paradigms in agile
Andrew Doran
Great table.
all agile methods have one thing big thing in common, and that may we ll be the quintessentia l difference between agile methods and the waterfa ll . That is, all development proceeds by creating sma ll chunks of working code in a time box (fixed date.) This new skill is the heartbeat of agi l e, and when teams master this skill, many other thi ngs agile will fall naturally into place
The size of the chunks of work that are sc heduled into the iter at ion ha s a dramatic effect on the visibility of their status
Small Chunks Foster Ownership and Accountability
With agile, progress and job sa tisfaction are constant, frequent, and in real time
It is not unusual for teams new to agile to achieve only 25 to 35 percent of the scope of work they set out for themselves in the first iteration
Barriers to agile adoption at the enterprise arise from two sources: the apparen t limitations of the methods themselves and the impediments that exist within the enterprise. Both must be addressed to achieve en t erpr is e agility
the apparent limits of the methods th emselves must be addressed. These limits include small team size, close customer involvement, collocation, emerging architecture, l ack of requirements analysis and documented specifications, and culture and physical environment
At scale, all development is distributed development, and the methods and organization must evo l ve to address this challenge
Since agile generally does not coach how to approach architecting l arger sca l e systems, that apparent limitation is often a real impediment for agile adoption. In addition, the role of system-level architects is not prescribed by agile, and that is a cause for concern for those (including real system-level architects) who understand th at systems of sca l e cannot be successfully built without so lid architectura l underpinnings
Can building an enterprise application, one story at a time, possibly work? Well, perhaps not exactly that way
the enterprise is a living organism, and as such, it l ong ago learned how to defend itself
It is quite common to see stage gates such as "design comp let e" and "design review sign off" in the published product and system development process guide l ines . These formalized, published, and adopted guidelines are not so easy to change. And yet many of these policies and procedures must be amended, changed, or eliminated to facilitate agile . These documented policies cannot simp l y be ignored, and they can create real impediments for agile adoption
Agile is not a trivial fix, or tune-up, for what we have been doing. It is a radical change in practice and culture
seven agile best practices that natively scale
If there is one single practice that characterizes the agile methods and differentiates them from the sequential waterfall processes that have been applied in the past, it is the ability of the team to create a holistic set of tested, working code in a small time box
At enterprise scale, release . cycles typically move from as long as 12 to 18 months to as short as 3 to 4 months
In agile, all code is tested code. There is no other kind.
in our experience, at scale , components are indeed the best organizing metaphor , and they often do develop into sufficient scope to warrant a team
How could such a process work in a traditional environment where the product owner may be called away on another mission? How could it work if the developer is multiplexed across multip l e projects? How cou ld it work if the test resources are not assigned and available at the same time that the code is written? The answer: it doesn't
the test organization may even be located in India or some other remote region different from where the coding activ it y occurs. While this ma y appear to make good sense to the organization on the surface, the fact is that experience h as shown that the m ode l is not very effective
With agile, the organi za tion must be reorganized so that each team has all the skills-p roduct definition, software development, and testingnecessary to define/build/test and deliver each story.
The rules of agi l e are lightweight and fle xi ble, but they are rules nonethe l ess, and the agile team leader is responsible for constantly teaching people how the agi le proc ess works an d illustrating by examp l e, such as by not making decisions for the team
Since it is difficult to add product owners with the necessary domain expertise in the company, it is typical that additional team members, usually developers and testers with accumulated domain expertise and some communication skills, will step into this role to assist
It is therefore likely that the agile team has a ke y interface to one or more architects who ma y li ve o ut side the team
In many cases , QA personnel will live outside the team entirely and may have dispatched many of their former resources to liv e with the product team and to assure quality on a real-time basis. At t h e system level, how eve r , the role of QA re ver ts to the types of review and qualit y monitoring that were originally intended for the role
Figure 9-4 A define / build / test component team with interfaces to other teams .
Andrew Doran
Good diagram.
in addition to ass u ring that the right roles are present on the team, the high- performance team se l f-po l ices to help assure that the right peopl e are on the team
the Agile/Scrum Master must interface to those outside the team's boundarie s-e x ecutives, product managers, business analysts, and the likewho are the key stakeholders in steering the team in the proper direction.
team members must communicate furiously
Trust is the foundation of collaboration, and meeting ones commitments is the core to building trust.
Agile plans at two l evels: a series of course-grained release plans and a series of fine-grained iteration plans
Design sp i kes are sma ll r esearc h or design act iviti es id e ntified to resolve an area of ri sk o r to d eterm in e a co ur se of t ec hnical actio n
While the priorit i es shou ld be weig ht ed heavily to va lu e-delivery stories, most iterations have a var i ety of story types that must be included to keep the project moving forward. Beca u se the product owner is integral to the team, h e or s he wi ll understand the nece ss ity for infrastructure work and refactoring an d therefore ca n make the appropriate trade-offs in priorities. (Prod uct owners and teams under s tand that all customer va lu e stories, all the time, with no refactors or infrastructure work, will eventually produce a brittl e system
Figure 10-2 A natomy of an i te r a ti on
Andrew Doran
Another great diagram.
A release is a series of iterations that accomp l ish some u seful, newsworth y , and significant objective in the marketp l ace or in the interna l customer ' s environment. A release is defined first by its theme and release date (more on rele a se planning and the critical topic of setting the re l ease date i n Chapter 12), and the n by its set of prioritized features (the release backlog
Releases may often be described and imp l emented only in terms of the stories the iteration contains, but most find that level of granularity difficult to work with at the release level, and the y more typically increase their level abstraction to that of featur e s. Features (services provided by the system that address a user need) are easy to state in a sentence or two and describe the re l ease's objectives in terms the stakeho l ders can readi l y understand
release plans are neither comprehensive nor guaranteed. Instead, they are updated as often as nece ssary to reflect changing business priorities and needs. Nevertheless, release p l ans serve to set goals and expectations internally and externally, a n d they guide and constrain the follow-on iteration p l anning activities
The iteration is the heartbeat of agility. Master that, and most other things agile tend to naturally fall into place.
In practice, h owever, all but a very few teams we have worked with h ave come to the same conclusion over time: a week may be too short and 30 days is too long. The conclu s ion the y typically arrive at i s to standardize on it erations of 2 weeks in length, and this is our general recommendation
Because the iteration planning meeting is short and time-boxed, the team has to enter the meeting in a prepared state, and all team members have some responsibility to prepare for iteration planning
it is usually a rule that only the development team can change the scope of the iteration
the product manager owns the story priorities, and the development team owns the tasks and the estimates for those stories
When first implementing agile practices, consider setting a "code freeze" a few days prior to the end of the iteration, because the team is likely still practicing waterfall within the iteration
Even within the course of a short iteration, scope m u st be a managed, and deviations from plan will occur. The tracking and adjusting activity i s focused on getting an o b jective, real-time picture of where the software development effort is and whether the team is likely to " land " (complete on time) the iteration in process
the tota l of the estimates for all backlog items that are not yet started and the estimated remaining effort for any in-progress back- l og item . The sum of those two amounts represents the estimated remaining work to be comp l eted during t h e iteration. P l otting this va l ue each d ay of the iteration produces what is ca ll ed a burn-down chart
The a b i lit y to re l ease so ft wa r e more f r equ en tl y has two primary bu s in ess b ene fi ts: increased responsiveness to t h e custome r amidst changing marketing cond i tions an d reduced r i sk to t h e ente r prise
since every iteration is a potentia ll y shippab l e increment of software, many opport uniti es wi ll be availab l e for a customer to install, deploy , and evaluate the work in progress . This is one of the key benefits of software agility, the positive impact of which should not be underestimated
our lack of ability to predict dates is one of the prime motivator ' s behind agility
In a model in whic h resources, dates, and quality are fixed, then the feature set must be variable
it is far better for the organization to have a dependable schedule and a variable feature set than the reverse.
th e word r e l e a se, in thi s co ntext, is ov e rloaded becau s e not every release pl a nned b y a team on a frequent rele ase c alendar is necessarily delivered to the custom e r or constitutes a " product laurich
agile teams have learned to avoid the expectation-filled terms such as version 1.0 and 2.0 and have grown to simply sequentially numbering the releases
The historical production rate tells us how much work the development team can do in a given period of time
the l ower priority features are suspect in any particular re l ease, and teams should be car efu l to communicate this reality, as Figure 12-2 shows
The release planning meeting is a seminal event in the agile process, and everyone who will directly affect the product outcome should attend the release planning meeting
For a single team, the release planning meeting may often follow this process:
Andrew Doran
Useful
While daily stand-ups help individua l teams focus on the progress th ey are making within an iteration, the weekly stat u s review meetings are u s uall y applied to help component teams working on the sa me product assess ho w the y are doing with reg ar d to the overa ll release plan
Product managers, development team managers, and execut ive managers shou ld meet twice a year to collaborate on the development and revision of the release roadmap
The r e l ease planning eve nt is a n even m ore critical event now , becau se it is an infrequent sy n c hr o ni za tion pulse w hi c h must align all component teams to a common objective
When co ll ocatio n i s n ' t fe as ibl e for teams with staff spread across continen t s, distant t ea m m e mbers s h ou l d a tt en d a t l eas t th e first pa rt of th e r e l ease p l a nning meeting via t e l econference . It i s durin g thi s time that th e vision is shared, the f eatures d i sc u ssed, a nd th e det a ils of re l ease date, iterat i on dates, and vel ocity are d ec id e d. If a t a ll pos s ible , attending the release plannin g meeting in person shou l d be conside r ed the high e st priorit y for time and travel budgets
for many, TDD is an assumed part of agile development
The FIT approach mirrors the unit testing approach in that the tests are created and run against the system under test, but they are not part of the system itself. (However, some special methods may well be required in the code to make the system testable.)
some amount of time at the end of the release, typically an iteration or less, is devoted to what the teams call hardening, which is a catch-all name for all the activities necessary before the system can be finally readied for distribution or deployment
much of the project risk is deferred until later integration phases, and problems that are discovered that late cause substantial rework that takes significant time. This is one of the most significant risks of the waterfall model-and one that agile (and/or continuous integration) is designed to address.
All source code must be checked into the repository at least daily
Do not l eave the building until you are SURE your last check-in built successfully and the unit tests all ran
the team is new to agile and much is different; it is unreasonable t o expect that the first few iterations
the team is new to agile and much is different; it is unreasonable t o expect that the first few iterations be winners
There is no canned format for iteration retrospectives (other than that the meeting is time-bo xe d to absolutely 1 hour or less), but most agile teams proceed along two distinct paths. The first, a quantitative assessment, establishes the key metrics for the iteration, and the second, a qualitative assessment, determines what went well and what didn't go so well
Table 15-1 Sample Iteration Assessment Metrics
Andrew Doran
Very useful.
it can be hard for the Agile/Scrum Master to avoid having the team "boil the ocean" and instead must remind the team that they have a full lo ad of stories ahead of them, and they had better pick just one or two small things to improve for next time
it can be hard for the Agile/Scrum Master to avoid having the team "boil the ocean" and instead must remind the team that they have a full lo ad of stories ahead of them, and they had better pick just one or two small things to improve for next time
This team keeps a list of refactors posted conspicuously in the work area, and with concurrence from product mana gement, logically slips them into the iteration and release cycle as well
Although refactors cannot contribute directly to value delivery near term (as the refactor alone may have no near-term customer impact), smart teams measure and prioritize refactors just as though they did, doing so recognizes and encourages keeping the software current and resilient. This is yet a nother reason why product owners are integral to the team; they come to understand the inevitable trade-offs between features now and b e tter features later, and can help guide the team to the proper amount of investment in refactoring versus new feature development over the course of each release
The most agile teams use their ability to code quickly and efficiently as a requirements discovery process and avoid the overhead of formal specifications. This practice can work effectively because a small team can write and rewrite code at a rate faster than many organizations can attempt to determine and codify their customer requirements anyway
a number of l arger- scale agile teams have converged on a l ean requirements pattern that has three main elements: a vision , a roadmap, and just-in-time requirements elaboration
The vision carries the common objectives for the teams and serves as a container for key nonfunctional requirements that must be imposed on the system as a w hol e
a fixed, inviolate sched- . ule-a release train , if you will
If dates, themes, and quality are all fixed, then functionality must be variable, but the software train must lea ve the station on time
Taken together, the seven agile team pradices that scale and the seven agile enterprise practices that can be mastered over time will substantially improve the performance of the software enterprise
In Boe hm 's view, requirements p lu s architecture define the express i on of a software system
A day without refactoring is like a day without sunshine.
many Scrum Masters recommend XP as a companion process to Scrum
many of these same teams have come to rely on a simple but effective visual representation of the domain model as the primary architectural construct for the project
The larger and more complex the system and the higher the critica li ty of failure, the more the teams will need to base their daily decisions on an agreedupon and intentional architecture
A component is a non-trivial , nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture . A component realizes and conforms to a set of interfaces
Architecture should be implemented, not just modeled. Test cases can be developed to test the resilience and scalability of the planned application so that system performance testing is available from project initiation
A bias for action (try it, test it , try something different), rather than deliberation and debate, characterizes agile teams
if it is a new project, agility training will also typically be provided to th ese team s during their formulation and orientation stage. Time for this t raining must be accounted for in establishing the team 's initial velocity and workload
A system that h as architectural runway contains existing or planned infrastructure sufficient to allow incorporation of current and anticipated requirements without excessive refactoring
Actively addressing the refactor list improves the produc t q u a l ity and the team's mora l e at the same time
Design spikes are activities intended to address design challenges, architectural extensions, and the impact of new technologies or to explore critical problems with the existing solution. As such, while design spikes do not directly deliver end user value, they are critical to the long-term ability of the team to do so, and they are therefore treated just like user stories in the iteration. In other words, they take resources and they are therefore defined, prioritized, estimated, completed, and demonstrated like any other story in the iteration. They are not refactors in that the application code may be completely unaffected-the spikes just serve to extend the architectural understanding by some small amount in a specific technical direction
In one such te x t, Leffingwell and Widrig [2003) provide a "map of the requirements territory" in the form of a requirements pyramid, as illustrated in Figure 1 7- l.
Andrew Doran
I love it when an author references his or her earlier work in the third person. So unnatural.
Beck [ 2005) goes on to explain why he didn ' t use the word requirements. Because requirements, by their generally accepted definition, are mandatory, the expectation is that they must be implemented as specified. In XP and agile, the key insight is that requirements represent intent, not mandatory behavior, and taking them too literally will lik ely not produce a system that meets the user's real needs. Worse, the requirements will overconstrain development such that simpler ways of achieving "almost the same functionality" cannot be considered. In XP and agile, stories are pliable, malleable things, negotiated as necessary until they truly reflect the needs of all parties. Or, as Cohn [2004) reflects, stories represent a "promise for a conversation" between the development team and the product owner
While the spirit of agility causes us to document only that which is immediately necessary, the needs of our larger scale systems lead us to somewhat more formal constructs. Even then , however, we must remember to provide only the minimum degree of specificity so as not to overconstrain the teams and to allow the teams to a pply their local skills and interpretations to realizing these common requirements in their specific components
These common requirements can be integral or appended to the vision document, carried as special requirements or architectural constraints in a permanent section of the backlog, captured in an agile project management or requirements management tool, or perhaps called out in a supplemental specification document. But in any case, they must be understood and documented across all component teams to which they apply
Remember, in the battle of date versus functionality, the date always wins
While agile teaches us that simpler is better, at scale, avoiding large-scale refactoring is a constant consideration, so experienced agile teams work within a range of possibilities to define the stories that will achieve the optimum result
there comes a time when it is necessary to understand the specific functionality that the product owner must, subject to negotiation, see implemented. In agile, this is performed on a just-in-time basis, no matter the scale
The conversation part of the story reminds us that the story is not a specific set of requirements but rather a promise to discuss the intent of the story with the product owner. That discussion may or may not be elaborated in text, but it becomes the basis for understanding during implementation
the user acceptance test is an integral part of the story
When possible, ho wever, it is best to keep technology assumptions and constraints out of the user stories
More rigoro u s an d analytica l than stories, use-case m et hods pro v ide a sema nt ica ll y co nsi ste nt representation for the behavior of a system from ilie perspective of the user
management must put a s take in the ground and mandate to t he teams: We will ship this often, and we will meet these dates . However, in so doing, management must also recogni z e that specific decisions regarding indi v idual component functionality must be left to the teams. Otherwise, everything is fixed: functionality, resources , and schedule. The result cannot be an ag ile process, and the teams are likely to fail to deli ver
In this model, all component teams are synchronized to the same iteration schedule. While this is not absolutely mandatory, it is extremely beneficial
a team must exist to take responsibility for planning and managing the agile release train
interfaces among the te a m s, ambiguities among interface specifications, and assumptions that went into those interfaces, will likely create blocking issues that will appear on the release train tracks. These blocking issues must often be addressed b y the RMT bec a use they typica ll y fa ll between component teams, affect multiple component teams, or even affect or impact teams outside the development organization
Andrew Doran
Using the RMT abbreviation for ‘release management team’ is taking the railway analogy a bit far!
BMC Software's reported results include the following:
Andrew Doran
Useful list of benefits of going agile.
In stead of relying on indirect metrics describing degrees of our software ' s quality and progress, or whether we simply released by a certain date, we ask, "What percentage of critical functiona l ity is included in t hi s release?"
Over a period of many months, the teams built a continuous integration and test environment that reduced the time it took to produce a system-level build and smoke test from two months to one hour
BMC Software engaged team coaches from Rally Software to help train the initial teams and to "tra in the tra in ers" for wider adoption and rollout . The company a l so engaged Rally's executive coaches to help prepare the organization for the changes ahead a nd identify and eliminate potential impediments to adopting and scaling agile.
communication is the key to successfu l agi l e developmen
Human beings are the most effective carriage of information and the best way to transfer information between organizations or social systems is to physically transfer a human carrier .
Agile eschews up- front and detailed project plans, but the tactic al day-to-da y project management natur e of agile i s intense and unremittin g
as the teams grow and scale, applying some additional thought to relea s es beyond the immediate horizon helps avoid architectures that require substantial refactoring later on.
Agile's recommendation is to define and execute backlog items for infrastructure in early iterations.
Agile's recommendation is to define and execute backlog items for infrastructure in early iterations.
it usually takes hard work from a number of committed executives to evolve the organization to perform as the ultimate agile enterprise
it is impossible to predict in advance exactly how an agile release train will evolve
it is impossible to predict in advance exactly how an agile release train will evolve
Roadmaps s h ould generally be communicated in theme and high-level features.
Roadmaps s h ould generally be communicated in theme and high-level features.
Don ' t go to press on every release . Create a rolling thunder in which you test some ear l y concepts against the theme with the customers w hil e building up to the big concepts. This gives you not only market validation but customer comments to include with your launch, which gets more press attention.
" A CIO' s Playbook for Adopting the Scrum Method of Achieving Software Agility" [Schwaber, Leffingwell, and Smits 2005]
Andrew Doran
Note to self to look this up.
evolving organizations to new levels of productivity and effectiveness is hard work, and it cannot be done with a book or lecture or even one motivated exec u tive. It must be implemented with a combination of topdown leadership, bottom-up adoption and expansion, and empowered mangers in the middle, all of whom are harnessed to a common vision. And that vision includes the need to change
evolving organizations to new levels of productivity and effectiveness is hard work, and it cannot be done with a book or lecture or even one motivated exec u tive. It must be implemented with a combination of topdown leadership, bottom-up adoption and expansion, and empowered mangers in the middle, all of whom are harnessed to a common vision. And that vision includes the need to change
The laws of software physics are unproven and uncertain. (One line of code can crash a system consisting of millions of lin es of code? One programmer can write 10 times as much code as another?)
The laws of software physics are unproven and uncertain. (One line of code can crash a system consisting of millions of lin es of code? One programmer can write 10 times as much code as another?)
Moreover, software development is primarily innovation, not a manufacturing-like reproduction process at work. We are inventing a new thing, not reproducing an existing one.
Moreover, software development is primarily innovation, not a manufacturing-like reproduction process at work. We are inventing a new thing, not reproducing an existing one.
The hierarchicaltechnical-management-directive approach is essentially eliminated with Scrum. The product owner now sets the objectives and priorities, the team figures out how to achieve them, and no one need tell the team how to do that along the way. Management helps by eliminating the impediments that prevent further productivity gains
The hierarchicaltechnical-management-directive approach is essentially eliminated with Scrum. The product owner now sets the objectives and priorities, the team figures out how to achieve them, and no one need tell the team how to do that along the way. Management helps by eliminating the impediments that prevent further productivity gains
Since Scrum i s all a bout team empower m ent and " l etting the team decide ," a top-down implementation can be effective only wit h thoughtful consideration and preparation
Since Scrum i s all a bout team empower m ent and " l etting the team decide ," a top-down implementation can be effective only wit h thoughtful consideration and preparation
a f ull Scrum implementatio n may take up to 2 years. No matter th e inten sity or commitment by management, this timetab l e cannot be rushed because of the need for ba sic organizational change .
a f ull Scrum implementatio n may take up to 2 years. No matter th e inten sity or commitment by management, this timetab l e cannot be rushed because of the need for ba sic organizational change .
the Scrum Master is responsib l e for making sure a Scrum team lives by the values and pract i ces of Scrum .
Scrum requires that senior management be vita ll y involved in impediment triage and removal and become the leading agent for change
Impediments will generally be encountered in four areas:
Andrew Doran
Useful list.
Agile methods can be adopted "bottom up" to a point, with individual teams taking on the pilot projects and leading by example. But there is a point at which the organization cannot be effective without executive leadership taking a role
One agile company uses the daily stand-up as a routine communication mechanism among the executives.
Andrew Doran
Why would we not do this?! Great idea.
the Organizational Impediment Backlog
Andrew Doran
We need to keep one of these!
These release dates would make excellent time-boxed milestones for the release of substantive organizational changes as well. Since much of the work is incremental and likely already in place, these milestones may serve as forcing functions for internal announcement dates, final resolution of a particular impediment epic, or completion of reorganizations or policy changes that affect multiple departments
In this section, we describe a typical process of how a larger enterprise might implement Scrum, a "playbook" if you will, that gives sample techniques you can apply to accomplish the requisite change.
Andrew Doran
Excellent
Information radiators.
Andrew Doran
What a lovely phrase.
Agile is inherently measurable
The primar y metric for agile software development is whether or not working software actually exists and is demonstrably suitable for use in its intended p urpose . In agi l ity, that key indicator is determined em pirically, by demonstration, at the end of every iteration and every release.
management's best approach is to simp l y require periodic self-assessments from the team on its agile projects, perhaps s u ch as using the metrics in Table 22-1
Forrester Research [Barnett 2005] suggests a balanced scorecard ( BSC) approach to measuring IT and product team performance for both traditional and agile approaches
the product owner provides a measure of from 1 to 5 value points r e flecti ve of the inherent va lue a customer would receive from the feature . This also provid es the product teams with the ability to make intelligent trade-offs in scope m a nag e ment, because a feature with a value of 5 t hat can be done with relatively little effort would far outweigh a difficult and risky fea tur e with a value of l
I have never (yet!) worked on an agile project but for a few years now I have known it inside me that without a doubt this is the future. We just need to get honest with ourselves and start diving in—trying, succeeding, failing and learning.