The first process you hear about when you hear about agile software development is probably XP.

The second one you hear about is likely Scrum. And Scrum has had a large influence on how software companies work, not the least here in Sweden. Many people think that Scrum is newer than XP but actually it is older. Scrum was first tried at a software project back in 1994. Scrum actually differs quite a lot from XP although they both rests on the same fundamental ideas. XP is a complete process where all the different practices work together in a well functioning unity that supports each other. In XP we do not separate which practices are there for handling the actual development and which are for controlling the project. However, XP is quite week on project control practices and is therefore not applicable on its own for larger projects. We discussed this last time. Scrum on the other hand is a process for controlling software development projects in an agile way. Questions concerning the actual development are left open. Scrum does for instance not define the level of documentation needed or if one should do a real rigor design before coding like in heavier processes or if you shouldnt lik in XP. This makes it a l t easier t i t d h ld t like i XP Thi k lot i to introduce S Scrum i an in organization that already have a defined way of working and use for instance RUP or where laws demand that you work and document in a certain way as is the case with safety critical software.

If we lock at Scrum in the Cockburn diagram we see that it covers the complete diagram. Since we can add a development process that fulfills requirements from laws and standards to Scrum we can also use Scrum for safety critical software. This is at least what the Scrum people argues. I have jet to see an example of Scrum actually being used in such a project but since it is presently being adopted by companies that also do safety critical software it is maybe just a matter of time. Scrum recommend that you work in very small teams, ideally under 7 persons. But in difference to XP Scrum includes rules and methods for how to handle several scrum teams and their cooperation. This makes it possible to run scrum projects with quite many people involved. I have read about several successful examples with around 500 developers.

This is an overview picture of scrum. Explain the picture.

Scrum has 7 practices., or rather 7 concepts. Im not entirely sure that the word practice is correct for all of th tf ll f these, b t th t i j t my opinion. W will t lk a littl about each of th but that is just i i We ill talk little b t h f them.

The Scrum Master is a management role introduced by Scrum. The Scrum Master is responsible for ensuring that Scrum values, practices, and rules are enforced. The Scrum Master is the driving force behind all of the Scrum practices. He or she sets them up and make them happen. The Scrum Master is simply the project manager or team leader of a Scrum project. However, the duties of the Scrum Masters differs a bit from a normal project management role. The Scrum Master represents management and the team to each other and his job is to keep the team working at the highest possible level of productivity. He does so primarily by making decisions and removing obstacles. Since scrum teams are self-directing he does not plan or lead the teams work and tells them what to do; unless the team can not agree on something. Then it his job to step in and make a decision. When a decision needs to be made it is his job to do so immediately, even with incomplete information. It is very often so that a less then perfect decision is much better than none at all. If no decisions are made the teams is insecure on how to proceed and in the worst case they are stuck. A bad decision can always be changed. This is very often the role of the project manager in any p j project, to p point the way when the team cant agree on what is best. y g As for obstacles, the Scrum master either personally removes them or causes them to be removed as soon as possible. Anything the hinders productivity it is his job to make sure it goes away. If management makes the team members do work on the side that doesnt contribute to the progress of the project it is his job to take the battle with management and convince them that they are hindering the work. If the team needs better computers, he fixes that. If they want a coffee machine in their project room so they dont have to cross the building in order to get coffee he arranges that. And if there are problems between the members of the team he deals with it. He is basically a curling parent it of the team. The Scrum Master tries to observe the velocity of the team: is it stuck or is it making progress? If the team needs assistance, the Scrum master meets with it to see what he or she can do to help. For example, if somebody has been working on a trivial task for three days, he or she probably needs help.

All needed changes to the software being built is listed in a product backlog. The product backlog represents everything that anyone interested in the product has thought is needed or would be a good idea in the product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product. Anything that represents work to be done on the product is included in the product backlog. Product backlog is sorted in order of priority. Top priority items are next in line to be developed in the next iteration. These should also be clearer and have more detailed specification than lower priority iteration backlog. A lot of fuzzy thoughts and ideas can exist on the backlog but when they start to climb in priority work should be done to define them in more detail. Since we are talking about an agile process here the backlog is anything but a static document. It is changed all the time, items are added and removed, priorities are changed, and work effort estimates are updated. The person responsible for doing this is called the Product owner. In difference to XP, Scrum puts an emphasis on that it is seldom one single stakeholder or customer that wants to influence the look of the product but there are often many competing wills If all these wills. people simultaneously puts pressure on different members of the team to put priority to there needs it is hard for the team to stay focused and work productively. Therefore Scrum has a product owner that is a single person who is the only one that decides what should be on the backlog and how it should be prioritized. A stakeholder that wants to have a feature must convince the product owner that it is needed instead of bothering the development team. If you run Scrum on top of the XP process the onsite customer and the product owner can be the same person, but it is more common that the product owner is a management person from the own organization. You should notice here that a very fundamental thought of Scrum is that the development team should be protected from outer disturbances so that it can focus on its job. This is the main purpose of the Scrum Master and it is also the job of the product owner. The backlog also include estimates on how much time is needed for implementing the different items on the log. These estimates are done and updated by the product owner. However, he doesnt do it on his own but consults with the team and anyone else he needs to talk to in order to make a good estimate. Also these estimates are only good guesses. A point from which to start, and they are and should be constantly updated as knowledge increases. As with XP these are not input to any binding increases long term planning. In addition to product features, backlog items include issues. Issues is something that require resolution before one or more backlog items can be worked on. Issues are prioritized just as regular product backlog. The product owner is responsible for turning issues into real work that the scrum team can select to work on. As long as this is not done the issue is marked as s unworkable in the backlog. The purpose of this is to have such things of the teams mind. When issues arise they are put on the backlog so the team can focus on the concrete work at hand. g

The scrum Master meets with the Scrum team and reviews the product backlog. The team commits to turn a selected set of Product Backlog into a working product. This is done at the beginning of every iteration. The team has full authority to do whatever is necessary to complete the work. It is only constrained by organizational standards and conventions. The philosophy here is: show the team what to do, and they will figure out how to do it. The team is thus what is called a self-organizing team. The scrum master does not tell them how much work they should do and who should do what. The team can pick from the top priority items on the backlog as much as they think they will be able to do in an iteration and then agree themselves on who should do what. what The size of a Scrum team is 7 people, plus or minus two. Larger teams dont work out well. Team productivity decreases and the control mechanisms of Scrum become cumbersome. For instance, it is hard to lead the daily scrum meeting if the team is larger. More importantly, large teams generate too much complexity for an empirical process. If more than eight people are available for the project they are organized in multiple Scrum teams. Scrum teams are vertical teams and shall include analysts, designers, quality control, and coding engineers. It can also include other people like technical writers or domain experts. These different competences are brought in to the team and everybody contributes with their expertise. However, the titles are left outside. When you are part of the team it is your job to contribute in the best way you can, not only in your field of expertise. Scrum just as XP is not for software architects that are not willing to contribute by writing code. In order for the team to be flexible and always on maximal productivity everybody must contribute in the best way they can, even though the problem at hand does not utilize their special domain of knowledge knowledge.

Each Scrum team meets daily for a 15-minute status meeting called the Daily Scrum. During this meeting the team explains what it has accomplished since the last meeting, what it is going to do before the next meeting, and what obstacles are in its way. Daily scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision making, and improve everyones level of project knowledge. By attending a Daily Scrum meeting, managers can get a sense of what a team is doing and how likely it is to succeed. Because the reporting interval is only 24 hours it is easy to continuously monitor succeed hours, a team. A scrum master can quickly see if a team member is up to his or her ears trying to get a piece of technology to work. Has a team member lost interest in the project? Is someone not working because of family problems? Is the team quarreling over something? What attitudes are demonstrated during the meeting? Chicken and Pigs. There is some sort of well known joke in English speaking countries about chicken and pigs. Scrum has adopted the term from this joke and talks about chicken and pigs at the scrum meeting. The ones that are p of the scrum team are p g everybody else are chickens. At the g part pigs, y y meeting only the pigs are allowed to speak, anyone else like managers or other stakeholders can participate at the meeting but only as listeners. They are not allowed to disturb, or contribute, to the meeting in any way. Normally a scrum meeting room is arranged so that there is a round table in the middle and a chair for each team member. Some teams dont use chairs and a table but stands in a circle. This is a way to make the meeting short. You speak quicker if you must stand the entire meeting. This is the inner circle that is actually holding the meeting. Everybody else sits or stands behind their backs in the outer circle. The reason is to signal to these people that they are really not part of team but should stay quite. It is much harder to keep the spectators from interfering if they are physically in the inner circle. During the meeting only one person (a pig) speaks at the time. One by one each team member reports on his or her status. This is done by answering three specific questions: -What have you done since last Scrum? -What will you do between now and the next scrum? -What got in your way of doing work? All other discussions not related to these questions should be taken outside the meeting. Remember that we are talking about a 15 minute daily status reporting meeting. It should be quick. If any discussion is needed other than the status provided by answering the three questions, a follow-up meeting may be requested. After a team member gives his or her status, another team member can interject, Id like to talk more about this after the scrum. Anyone who is interested should hang around afterward. In this way the scrum that everybody must participate in can be as quick as possible and hard problems that requires time and a lot of discussions can be taken with only interested parties. If there are multiple scrum teams on the project the scrum masters then meet f their own d il h li l h j h h for h i daily scrum meeting afterwards. This meeting is referred to as the scrum of scrums. And of course there is a top level scrum master that leads this meeting.

A sprint is the name of an iteration in Scrum. A scrum sprint is always 30 days. In difference to XP the customer (or anyone else) is not allowed to change his mind during the Sprint. If it was established during the sprint planning meeting that some features should be implemented this sprint, those features are what the team will be working on. If the customer suddenly thinks of a new feature that he wants asap he has to wait to the next sprint. This is because the team need some stability and peace in order to be productive. Just to be clear, the team cooperates with the customer during the sprint to resolve questions and uncertainties and to be sure that they are building what the customer meant them to build. This is just as in XP. The difference is that the customer cant change which stories he want.

Scrum teams meet with the scrum master and others to plan each sprint. The sprint planning meeting actually consists of two meetings. At the first meeting, the team meets with the product owner, management, and users to figure out what functionality to build during the next Sprint. At the second meeting, the team works by itself to figure out how it is going to build this functionality into a product increment during the Sprint. Input to this meeting is the product backlog, the latest increment of product, and the capabilities and past performance of the team. Having selected a set of items from the backlog to be implemented during the next sprint, a sprint goal is crafted. The sprint goal is an objective that will be met through the implementation of the product backlog. It is sort of the main motivation for why the backlog items are needed. The reason for having a sprint goal is to give the team some wiggle room regarding the functionality. If the team doesnt manage to implement all of the functionality it has signed up to do because of that it takes more time than expected it should focus on the sprint goal and reduce the functionality implemented during the iteration in such a way that the sprint goal is still meet. The decision on what functionality to drop and in what way are made by the team, the scrum master, and the product owner together. y y p g When the sprint goal is defined the team compiles a list of tasks it has to complete to meet the sprint goal. These tasks are the detailed pieces of work needed to convert the product backlog into working software. Tasks should have enough detail so that each task takes roughly 4 to 16 hours to finish. This task list is called the Sprint backlog. The team self-organizes to assign and undertake the work in the sprint backlog. The team modifies the Sprint backlog throughout the Sprint. As it gets into individual tasks, it may find out that more or fewer tasks are needed, or that a given task will take more or less time than had been expected. So as with the product backlog the sprint backlog is a dynamic document that at every moment reflects the status of the work.

The Sprint review meeting is a four-hour informational meeting. During this meeting, the team presents to management, customers, users, and the product owner the product increment that it has build during the sprint. Management comes to the Sprint review to see what the team has been able to build with the resources that it has been given. Customers come to the sprint review to see if they like what the team has built. The product owner comes to the sprint review to see how much functionality has been built. Other engineers and developers come to the meeting to see what the team was able to do with the technology. Everyone wants to see what the team has built, what the sprint was like, how the technology worked, what shortcuts had to be taken, what things it was able to add, and its ideas as to what can be done next. The meeting normally starts with the scrum master holding a short introduction giving an overview of the sprint. The sprint goal and product backlog are compared to the actual results of the sprint, and reasons f differences are discussed. A t for diff di d team member th di l and review a simple architecture b then display d i i l hit t diagram explaining the parts added and changed during the sprint. The product functionality is then demonstrated to the audience. No one should prepare extensively for the meeting. In order to enforce this rule, PowerPoint presentations are forbidden. A rule of thumb is that the team should never use more than a couple of hours in preparation.

DSDM is more of a framework than a method. It says nothing about how things should be done in detail, but provides a process skeleton and a description of artifacts that can be tailored to fit a given project or organization. As such it is very compatible with XP and it works fine to use XP as the detailed description for how a development team should work. But it can also be combined with other processes as for instance RUP. What DSDM does that XP doesnt is to give a structure to how the project shall be handled on a higher level. XP is focused on the technical development work while DSDM is more about management. A bit simplified you can say that XP is the developers view of the project and DSDM is the project leader and management view view. The principles that DSDM is founded on is that nothing is built perfectly the first time, but that a useful and to 80% ready application can be produced in 20% of the time it would take to build the complete system. One of the nine principles of DSDM is that provision of the business requirements is the foundation for a system to be accepted by the customer. This means that all gold-plating that is specified during the requirements work has to stand back for the requirements that come from the business needs. DSDM assumes that all previous steps can be revisited as part of its iterative approach. Therefore, the current step need be completed only enough to move to the next step, since it can be finished in a later iteration. The premise is that the business requirements are likely to change anyway as understanding increases, so any further work would have been wasted! y g pp Systems built using the DSDM approach address the current and imminent needs of the business rather than the traditional approach of attacking all the perceived possibilities. The resulting system is, therefore, expected to better fit to the true business needs, be easier to test and be more likely to be accepted into the users' working practices. Since the development cost of most applications is only a small part of the total lifecycle costs, it makes sense to build simpler systems that are fit for purpose and easier to maintain and modify after their initial development. The latter is possible since maintenance can be treated as a further incremental delivery towards the total solution.

I.Active user involvement is imperative DSDM is a user-centered approach. If users are not closely involved throughout the development lifecycle, delays will occur as decisions are made and users may feel that the final solution is imposed by the developers and/or their own management. Users are not outside the development team acting as suppliers of information and reviewers of results but are active participants in the development process. II.DSDM teams must be empowered to make decisions DSDM teams consist of both developers and users. They must be able to make decisions as requirements are refined and possibly changed. They must be able to agree that certain levels of functionality, usability, etc. are acceptable without frequent recourse to higher-level management. III.The focus is on frequent delivery of products A product-based approach is more flexible than an activity-based one. The work of a DSDM team is concentrated on products that can be delivered in an agreed period of time. This enables the team to select the best approach to achieving the products required in the time available. By keeping each period of time short, the team can easily decide which activities are necessary and sufficient to achieve the right products. Note: Products include interim development products, not just delivered solutions. IV.Fitness for business purpose is the essential criterion for acceptance of deliverables The focus of DSDM is on delivering the necessary functionality at the required time. The computer system can be more rigorously engineered later if such an approach is acceptable. Traditionally the focus has been on satisfying the contents of a requirements document and conforming to previous deliverables, even though the requirements are often inaccurate, the previous deliverables may be flawed and th b i fl d d the business needs may h d have changed since th start of th project. h d i the t t f the j t V.Iterative and incremental development is necessary to converge on an accurate business solution DSDM allows systems to grow incrementally. Therefore the developers can make full use of feedback from the users. Moreover partial solutions can be delivered to satisfy immediate business needs. Iteration is inherent in all software development. DSDM recognizes this and, by making it explicit, uses iteration to continuously improve the system being developed. When rework is not explicitly recognized in a development lifecycle, the return to previously "completed" work is surrounded by controlling procedures that slow development down. Since rework is built into the DSDM process, the development can proceed more quickly during iteration. VI.All changes during development are reversible To control the evolution of all products (documents, software, test products, etc.), everything must be in a known state at all times. This means that configuration management must be allpervasive. Backtracking is a feature of DSDM. However in some circumstances it may be easier to reconstruct than to backtrack. This depends on the nature of the change and the environment in which it was made. The ability to reverse changes is limited to within the development of an increment. VII.Requirements are baselined at a high level Baselining high-level requirements means "freezing" and agreeing the purpose and scope of the system at a level that allows for detailed investigation of what the requirements imply. Further, more detailed baselines can be established later in the development, although the scope should not change significantly.Changing the scope defined in the baselined high-level requirements usually requires escalation. VIII.Testing is integrated throughout the lifecycle Testing is not treated as a separate activity. As the system is developed incrementally, it is also tested and reviewed by both developers and users incrementally to ensure that the development is moving forward not only in the right business direction but is technically sound. Early in DSDM, the testing focus is on validation against the business needs and priorities. Towards the end of a project, the focus is on verifying that the whole system operates effectively. IX.A collaborative and co-operative approach between all stakeholders is essential The nature of DSDM projects means that low-level requirements are not necessarily fixed when the developers are originally approached to carry out the work. Hence the short-term direction that a project takes must be quickly decided without recourse to restrictive change control procedures. procedures The stakeholders include not only the business and development staff within the project but also other staff such project, as Service Delivery or resource managers. When development is procured from an external supplier, both the vendor and the purchaser organizations should aim for as efficient a process as possible while allowing for flexibility during both the precontract phase and when the contracted work is carried out.

The mechanism for handling flexibility of requirements in DSDM is the time box. In any project, there is a fixed completion date, which provides an overall time box for the work to be carried out. DSDM refines the concept of time boxing by nesting shorter time boxes of two to six weeks within the overall time frame. Time boxes can overlap in time and be carried out by different teams. Each time box will typically pass through three phases. Investigation - a quick pass to see whether the team is taking the right direction Refinement - to build on the comments resulting from the review at the end of investigation Consolidation - the final part of the time box to tie up any loose ends It is these nested time boxes that are the focus for monitoring and control activities. Each time box has an immovable end date and a prioritized set of requirements assigned to it. Some of these are mandatory and some of a lesser priority. The mix is essential, since if all the requirements that are to be satisfied in a time box are mandatory there will be no room for maneuver when things don't go mandatory, don t perfectly to plan or when new requirements surface that relate to the work being addressed at the time. The requirements of any DSDM project are prioritized using the MoSCoW Rules. The MoSCoW rules provide the basis on which decisions are made about what the project team will do over the whole project, and during any time box within the project. All the priorities are reviewed throughout the project to ensure they are still valid. It is also essential that not everything within a project or a timebox is mandatory. It is the less critical elements that enable the teams to deliver on time, by omitting less critical requirements, if problems do arise. This ensures the project is delivered on time without loss in quality.

XP is limited to around 20 developers but combined with DSDM it can be used for projects with more people involved. Apart from being build on the same ideas DSDM and XP works well together since they are synergistic, for example DSDM focuses on the whole lifecycle whereas XP is stronger on the detailed disciplines of programming. Combining XP with the rigorous yet Agile approach of the DSDM framework addresses limitations of XP through: Recognized Recognized project governance Fundamental pre-coding activities Project risk management Recognition of technical and business organizational standards Team dynamics Team collaboration Extended roles and responsibilities Quality management above and beyond code quality

FDD is an agile process and the people behind FDD is part of the agile alliance. FDD also have some things in common with the rest of the processes like focusing on customer value and small dynamically formed teams of developers. But FDD also has parts that are more in common with classical processes such as well separated development phases and individual code ownership. Another special thing about FDD is the strong focus on the domain model. The first thing you do in a FDD project is to develop a domain model, like you have learnt if you have taken a course in modeling with UML, and use it to create a common picture of the world that the program is to function within. The domain model fills to some extend the same function and purpose as the metaphor in XP but in XP, my opinion it is much better at it. The domain model becomes the fundament of the project and also as you continue you work in a model driven way and create different diagrams in order to model the program. Another difference to XP is that FDD also has techniques for monitoring how the project progresses, that is a higher level of control. You also have organized inspection meetings that are common in p pair-programming. g classical processes instead of p p g

When you read about FDD it feels at the same time very agile and very traditional. The reason is that FDD has grown from the perspective of larger projects. The processes that we have talked about earlier either focus on small projects like XP or is management processes like DSDM that leave the concrete question of how the development work is to be done open. FDD on the other hand is an agile process created for bigger projects that is a real development process that defines the actual development techniques that should be used. This results in that some practices that are recognized from heavy duty processes also has a place in an agile environment, since they provide more than they restrict when many people are involved in the project. project

FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results. FDD consists of five processes or activities. 1. Develop an Overall Model For the first activity domain and development members work together, under the guidance of an activity, together experienced component/object modeler (chief architect). Domain members present an initial highlevel, highlights-only walkthrough of the scope of the system and its context. The domain and development members produce a skeletal model, the very beginnings of that which is to follow. Then the domain members present more detailed walkthroughs. Each time, the domain and development members work in small sub-teams (with guidance from the chief architect), present sub-team results, and merge the results into a common model (again with guidance from the chief architect), adjusting model shape along the way. 2. Build F t 2 B ild a Features List Li t Using the knowledge gathered during the initial modeling, the team next constructs as comprehensive a list of features as they can. A feature is a small piece of client-valued function expressed in the following form: <action> <result> <object> For example, Calculate the total of a sale Existing requirements documents, such as use cases or functional specs, are also used as input. Where they don't exist, the team notes features informally during the first activity. Features are clustered into sets by related function, and for large systems, these feature sets are themselves grouped into major feature sets. 3. Plan by Feature The third activity is to sequence the feature sets or major feature sets (depending on the size of the system) into a high-level plan and assign them to chief programmers. Developers are also assigned to own particular classes identified in the overall object model model. 45. Design by Feature / Build by Feature Activities four and five are the development engine room. A chief programmer selects a small group of features to develop over the next 12 weeks and then executes the "Design by Feature (DBF)" and "Build by Feature (BBF)" activities. He or she identifies the classes likely to be involved, and the corresponding class owners become the feature team for this iteration (see Figure 2). This feature team works out detailed sequence diagrams for the features. Then the class owners write class and method prologs. Before moving into the BBF activity, the team conducts a design inspection. In the BBF activity, the class owners add the actual code for their classes, unit test, integrate, and hold a code inspection. Once the chief programmer is satisfied, the completed features are promoted to the main build. It's common for each chief programmer to be running 23 feature teams concurrently and for class owners to be members of 23 feature teams at any point in time.