WIXLIB

Manifesto for Agile Software Development“We are uncovering better ways of developing software by doing it andhelping others do it. Through this work we have come to value: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.That is, while there is value in the items on the right, we value the itemson the left more.”In March 2001, 17 software professionals were convened by Kent Beck, who hadpublished a couple of years earlier the book on the new Extreme Programmingmethodology (Beck 1999). They all had one thing in common: they were critical ofprocess-based production models.They met in Salt Lake City to discuss the processes employed by theprogramming teams.The meeting coined the term ‘agile methods’ to define those that were emergingas an alternative to formal methodologies, such as CMM-SW (precursor to CMMI),PMI, SPICE (initial draft of ISO 15504, wich in turn was the precursor to ISO 33000) They considered these excessively heavy and rigid due to their normative natureand strong dependence on detailed pre-development planning.The attendees summarized their ideas in four postulates, the Agile Manifesto,which are the values behind these methods. They are the ones that open and aredeveloped in this section. They also established 12 principles, which we’ll mentionat the end.15

Individuals and interactions over processes and toolsThe most important postulate. There is no doubt that processes help: they serve as anoperation guide, and having the right tools improves efficiency.In process-based production, the aim is for the quality of the result to be aconsequence of the processes. In agile development, processes only serve as help.The defense of processes at all costs leads to the assertion that extraordinaryresults can be achieved with mediocre people. But the truth is that this is not the casewhen creativity and innovation are needed. These tasks require talent and motivatedpeople to provide it.16

Working software over comprehensive documentationThe Agile Manifesto does not consider documentation to be useless: onlyunnecessary documentation. Documents allow recording and communicatingrelevant information for the project. Furthermore, for legal or regulatory reasons,they can be obligatory. But their relevance must be less than that of the product.To be able to anticipate how the final product will work by observing prototypesand finished parts provides stimulating end enriching feedback. It serves to reachideas that were inconceivable at first. More often than not, preparing a very detaileddocument of requirements before you start is a waste of time. It can be argued thatdetailed documentation facilitates sharing information about the project among thepeople involved. But this is rarely the case. It lacks the richness and value that canbe achieved through direct face-to-face communication and interaction with productprototypes. In fact, not only does it lack these advantages, but it also createsbureaucratic barriers between departments and individuals.Therefore, whenever possible, the use of documentation should be reduced to theminimum necessary. The ideal is to eliminate all those that consume work withoutadding direct value to the product.17

Customer collaboration over contract negotiationThe goal of an agile project is not to control the execution to ensure that the initialplans are met, but to provide the highest possible value to the product continuously.As mentioned earlier, when developing continuously-evolving products (such asa web app), it is not possible to define in a closed requirements document what thefinal product should be. It is more efficient to take direct feedback while developingthe product, and consequently redefine and improve the requirements of theremaining parts.18

Responding to change over following a planThe central values of agile management are anticipation and adaptation, differentfrom those of orthodox project management (planning and control to ensurecompliance with the plan).Responsiveness is much more valuable than monitoring and assuring plans whendeveloping products with unstable requirements. If the original idea does not workanymore, it has to be possible to change it.19

The 12 principles behind the Agile ManifestoIn addition to the four postulates we have just seen, the Agile Manifesto establishesthese 12 principles:1. Our highest priority is to satisfy the customer through early and continuousdelivery of valuable software.2. Welcome changing requirements, even late in development. Agile processesharness change for the customer’s competitive advantage.3. Deliver working software frequently, from a couple of weeks to a couple ofmonths, with a preference to the shorter timescale.4. Business people and developers must work together daily throughout theproject.5. Build projects around motivated individuals. Give them the environment andsupport they need, and trust them to get the job done.6. The most efficient and effective method of conveying information to andwithin a development team is face-to-face conversation.7. Working software is the primary measure of progress.8. Agile processes promote sustainable development. The sponsors, developers,and users should be able to maintain a constant pace indefinitely.9. Continuous attention to technical excellence and good design enhances agility.10. Simplicity–the art of maximizing the amount of work not done- is essential.11. The best architectures, requirements, and designs emerge from selforganizing teams.12. At regular intervals, the team reflects on how to become more effective, thentunes and adjusts its behavior accordingly.20

Origins of scrumScrum is an agile development model characterized by: Autonomous and self-managed teams that share their knowledge openly andlearn together. An ‘incremental’ development strategy rather than complete product planning. Basing the quality of the result on the tacit knowledge of people and theircreativity. Not on the quality of the processes. Overlapping the different phases of development, instead of carrying them outone after the other in a sequential or ‘waterfall’ cycle.The origin of the term is far removed from that of project management: it comesfrom rugby. ‘Scrum’ defines the formation in which both teams, crouching andclinging to each other, push for the ball without touching it with their hands.But for our purposes, we have to go back to 1980s Japan when researchers IkujiroNonaka y Hirotaka Takeuchi gave the term a polysemic dimension.They identified a novel form of development in the industrial manufacturingcompanies that were obtaining the best results in innovation and time to market: FujiXerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka 1986).They compared their way of working in self-managed teams with the way rugbyplayers advance when in scrum formation, hence the term.Although this way of working emerged from technology product companies inindustrial manufacturing, it started to be also applied to the software industry from1995 onwards. That year, Ken Schwaber presented in OOPSLA (the Object-OrientedProgramming, Systems, Languages & Applications annual conference) a softwaredevelopment methodology based on a scrum environment, using that same term(Schwaber 1995). This first framework presented a series of phases and ‘artifacts’:pregame, game, postgame, planning, sprints, wrap Some of them are still in use,and we will see them. But in general, the rules of the game have changed a lot sincethen.21

There is no single authority that determines what ‘scrum’ is and is not. It has changedover time, and it will continue to evolve with the input of the professionalcommunity, which defines the most useful practices. The original spirit, however,remains: practices should help teams to self-manage and maintain a continuous flowof progress, producing results iteratively and frequently.Among the ‘events’ and practices that have been added over the years, we canfind, for example, retrospective meetings, refinement product backlog meetings,DoR (Definition of Ready), story maps.Scrum Manager uses the term ‘scrum’ with its original meaning, the one givenby Nonaka and Takeuchi.22

A breakdown of project managementSince 1980, companies have developed so many models and practices to improve thequality and efficiency of their projects that it can be overwhelming to study them. Inthis section, we will go beyond labels and summarize the principles behind theseframeworks, to better understand different management strategies.We will use three concepts and two management models as coordinates: The first three are development, work, and knowledge. The models, which have already been mentioned, are predictive managementand evolutive management.We can simplify the apparent labyrinth of frameworks using these five ideas. In theend, every management model can be understood in this diagram:23

1. DevelopmentThe development of the project can be complete or incremental. In a complete development, the description of what the client desires isavailable at the beginning of the project. The plan is complete and detailed, andit serves as a basis for estimations. It serves to organize tasks, resources, andwork schedules. During the execution, the team manages the fulfillment ofwhat has been planned. In the case of incremental developments, the complete description of what theclient wishes to obtain is not available at the beginning of the project. Itincreases and evolves during development. This type of development can bemanaged using two different tactics: Continuous incremental development: using techniques to achieve acontinuous flow of development of the product’s functionalities or parts.They are delivered at irregular but continuous intervals to the customer. Iterative development: using techniques of prefixed time or timeboxing tomaintain the production of product increments at a fixed rate. This is howthe standard scrum framework works, which sets the ‘sprint’ ( Events) asthe measure for each development iteration. At the end of each ‘sprint,’ anew ‘increment’ of the product is obtained: that is, a deliverable, ready-touse part.2. WorkThe way of working can be sequential (‘waterfall’) or concurrent. Sequential work is divided into consecutive phases. A new phase starts whenthe previous one is finished. The most common example is the waterfall cycledefined in software engineering, which consists of definition of requirements,analysis, design, coding, testing, and implementation. Concurrent work overlaps the different phases in time. Following the sameexample from software engineering, this would mean that all the phasesmentioned in the previous paragraph would be reviewed simultaneously andcontinuously.24

3. KnowledgeThe different models can place knowledge either in processes or in people. In a process-based production: knowledge is explicit. The quality of the resultis found, to a greater extent, in the process and technology used. In people-based production: knowledge is tacit. The quality of the resultdepends on the experience of the members of the organization. It isn’t aboutfollowing processes and protocols correctly, but about making sure that peopleare motivated and talented.An example of explicit and tacit knowledge could be the difference between a foodprocessor and a cook making dinner. Anyone can prepare a meal using the foodprocessor by following the instructions. The result will always be the sameregardless of the skill. In thesecond case, however, thetalent of the person isparamount. An amateur cookwill not prepare the same thingas an haute cuisine chef. Bothwill benefit from having propertools, such as non-stick pansand sharp knives, but thesetools are just a help.“Tacit knowledge is personal, context-specific, and therefore difficult toformalize and communicate. Explicit or ‘codified’ knowledge, on theother hand, is knowledge that can be transmitted with formal andsystematic language.” (Nonaka 1995)25

Predictive management: sequential engineeringSequential engineering, also known as traditional engineering, is intended to providepredictable results. A successful project, according to these models, will develop theexpected product without exceeding the agreed time and resources. The type ofdevelopment is, therefore, ‘complete,’ and it employs traditional planning practices.In the world of software, the main references developing knowledge for this typeof management are PMI e IPMA y the process models CMMI, ISO 33000, SPICE All of them use sequential engineering and process-based production.Evolutionary management: concurrent engineering andagilityEvolutionary management aims to deliver a viable product as soon as possible andto increase its value continuously. It employs a strategy of overlapping work phasesand incremental development. This can be achieved by maintaining a rhythm ofshort, cyclical iteration, or a continuous flow of development.Knowledge marks the difference here. This strategy can be carried out withprocess-based production (concurrent engineering) or people-based production(agility). This distinction is important to avoid confusion, such as considering that‘agility’ is equal to the simple application of standard scrum ‘rules’ (iterativeincrement cycles with defined ‘roles’ and ‘artifacts’), or visual kanban techniques fora continuous flow of tasks.Concurrent engineeringAgilityIt uses strategies that are typical of agilemanagement: overlapping developmentphases, multidisciplinary teams, andfrequent improvement iterations.It reduces or eliminates administrative andbureaucratic tasks that do not add value tothe product or the development system.It’s typical of knowledge enterprises.It focuses on the quality of processes.It focuses on the tacit knowledge ofpeople, culture, and talent.26

ScrumSumming up, we come back to the characteristics of scrum ( Origins of scrum)and see how they fit into the characteristics of agile management: It uses an incremental development strategy (which can be iterative, throughtimeboxing, or continuous) It overlaps the different phases of development. It bases the quality of the result on the tacit knowledge of the people and theircreativity. In addition, scrum is also characterized by working in autonomous and selfmanaged teams, which share their knowledge and learn together. Hence thename and the metaphor of moving forward as a scrum.27

Differentiating scrum practices from principlesand valuesWhen you start working with scrum, as with any other tool, it is advisable to read themanual and follow the instructions; that is, to adopt the standard framework. We aregoing to explain it in the first part of this manual: its ‘roles,’ ‘events,’ and ‘artifacts.’But it’s pointless to try to deceive ourselves: if our focus is on the process insteadof the tacit knowledge of people, we won’t be doing ‘agility,’ but ‘concurrentengineering.’ When an iterative flow of progress is achieved, one can try to gobeyond it. It is time then to unlearn the practices and rely on the principles and valuesof scrum, adapting it, and other techniques and frameworks to the specificcharacteristics of the project or team. In most agile companies, these companies canbe adapted and, indeed, they are.The first part of the book explains the most widespread scrum techniques, whichcan be found here, on the Internet and in other manuals. In the second part, we willexplain how to remove those ‘stabilizer wheels’ from the bike, which come in handyat first but can hinder us in the long run, so we can keep moving forward.28

PART 1: THE SCRUM CYCLELEARNING THE STANDARD PRACTICES29

30

The scrum cycleAs to the date of publication of this manual, the components of the standard scrumcycle are: Scrum team, composed of the following roles: Developers Product owner. Scrum master. Artifacts: Product backlog. Sprint backlog. Increment. Events: Sprint. Sprint planning meeting. Daily scrum. Sprint review. Sprint retrospective.We start with a broad, general vision of the desired result, and from there, we specifyand detail the functionalities we want to obtain first.Each development cycle or iteration (‘sprint’) ends with the delivery of anoperational part of the product (‘increment’). A sprint can last from one to six weeks,although ideally no longer than than one month.In scrum, the team monitors the progress of each sprint in daily short meetingswhere they review the work done the day before and the work planned for the currentone. These meetings have a 5-15 minute duration and take place near a board whichfeatures information on the tasks of the sprint. They are often referred to as ‘standup meetings,’ ‘daily scrum,’ or ‘morning roll call.’Scrum manages the evolution ofthe project empirically, with the following tactics:31

Review of iterationsAt the end of each sprint, all those involved in the project review the functionalitiesof the result. Therefore, the duration of the sprint is the maximum amount of time todiscover approaches that might be wrong, improvable, or misinterpreted.Incremental developmentYou don’t work over designs or abstractions. Incremental development offers aworking product part at the end of each iteration, which can be used for testing,inspections, and evaluations.Phase overlapDuring development, the team refines both design and architecture, instead of settingthem fixedly at the beginning of the project. Waterfall development overlaps thedifferent phases, carrying them out one after the other. Scrum overlaps them, so theyadvance simultaneously.Self-managementPredictive management assigns the responsibilities over the project’s managementand results to the project manager. In scrum, teams are self-managed. They havesufficient decision power to adopt the measures they consider necessary andappropriate. It speeds up the decision-making process and allows a quick responseto unforeseen events.CollaborationAll team members collaborate openly with others, according to their abilities and notto their role or position.Through self-management and collaboration, the work that would otherwise be doneby a project manager can be done efficiently by the team members.32

Committed and involvedDuring the project’s development, many people get involved and add value to it.They do so at different levels of commitment and responsibility, which leads tomaking a distinction between ‘committed’ and ‘involved’ people.Committed: they contribute directly, building the product or developing theservice.Involved: they play functions that don’t involve directly building the product.They may be managers, or work in marketing or customer support.***A hen and a pig were walking downthe street. The hen asked the pig:“Would you like to open a restaurantwith me?”The pig considered the proposal andresponded:“Sure! What would we call it?”“Ham and Eggs!”The pig reconsidered:“Forget about it I’d be reallycommitted, while you’d be just involved.”***In scrum circles, it’s common to call thosewho are committed (without any pejorative connotation) ‘pigs’, and those involved‘he

9 Preface This guide contains the materials for Scrum Manager ’s official Scrum Master certificati