Six Levels of Agile Planning

Six Levels of Agile Planning

Definition

One of the misconceptions is that agile process doesn't do enough planning. In reality, Agile does lot more planning and risk mitigation than traditional processes. Agile focuses on planning very often instead of doing comprehensive and assumption based planning once. Agile Planning (a.k.a. planning onion) has 6 levels - Strategy, Portfolio, Release, Iteration, Daily, and Continuous.

Think of Agile planning a layers of an onion. We peel them back one a time to give you a thorough understanding about how to perform each step.

Agile Planning Onion Layers

1. Strategy
2. Portfolio
3. Release
4. Iteration
5. Daily
6. Continuous

Agile Strategy Planning

Projects and product development efforts ideally start with a vision associated with a business need or direction. This vision is then typically framed in context of a strategy and associated goals and objectives during a management team planning session. Strategy is the creation of a unique and valuable position, involving a different set of activities and it involves making choices throughout the value chain that are interdependent.

Agile Portfolio Planning

Goal of portfolio management (strategy execution) is to minimize value evaporation and maximize value retention. Strategy creates value but some of it evaporates due to poor execution and other organizational frictions. To understand Value Evaporation, assume that the strategy is right and, therefore, value creating. Thus, if there is any loss in value due to a poor strategy, it is not a part of Value Evaporation.

A good agile strategy cannot prevent the evaporation of value. Think of a tropical village that is perpetually short of water. So, the villagers come up with a strategy. It involves digging a big hole in the ground to create a reservoir of water from natural rain. The strategy works. The reservoir fills up. But the villagers forgot how mercilessly hot the tropical sun can be. The reservoir did not last very long. Evaporation returned its water to the atmosphere. For the villagers, what matters is not just how much water was there in the reservoir initially, but how much is retained after evaporation. 

The same is true for any organization. Its goal is to come up with a strategy that maximizes value retention by incremental and mutually reinforcing execution of value chain. Key for value retention is to manage portfolio by inspecting and adapting in small increments to utilize feedback from internal and external customers.

Agile Release Planning

Release planning is the third layer of Agile Planning Onion. Releases represent the large-grained delivery cycle in agile development. Releases typically range between one and six months, but may extend longer in some environments. Key for agile release planning is to continuously add value in small increments to utilize feedback from internal and external customers. Following diagram depicts how traditional execution differs from agile execution. In traditional execution, value is stacked and only delivered in the end. On the contrary, agile execution creates continuous value chains driven by agile portfolio management.

Releases begin with a release planning meeting where product owners (or product managers, project leads, etc.) work to define and prioritize a candidate set of features that are then estimated by the team.

Agile Iteration Planning

Iteration planning is the fourth layer of Agile Planning Onion. Also known as Sprints, iterations are short, fixed-length subsets of releases, generally in the 1-4 week time frame. Iterations represent the execution heartbeat of the project. During each iteration the team's goal is to deliver potentially shippable software. 

Iterations incorporate three key phases:

1. Ready (backlog grooming, iteration planning)
2. Remove impediments throughout the execution (daily standup meeting)
3. Done - usually agreed by the team as a definition of done (iteration review and retrospective)

Agile Daily Planning

This is the fifth layer of Agile Planning Onion. Every day the team is focused on completing the highest priority features in the form of working, tested software. As features are delivered within the iteration, they are reviewed and accepted, if appropriate, by the product owner. Each day a short, 15-minute stand-up meeting facilitates the communication of individual detailed status and any impediments or issues. Product is integrated and tested on a daily basis. Burndown charts are the key tool for the team to review progress on a daily basis. These charts help teams to take corrective actions quickly. 


Agile Continuous Planning

This is the final and one of the most critical layer of the Agile Planning Onion. Agile product development teams are constantly driving towards a state of continuous, adaptive planning, collaboration, design, development, testing and integration. This commitment fosters a dynamic, highly productive environment in which automation is critical and the output is always high-quality, valuable working software.

Visit Agile, LLC Today

Contributors:

Kanban - In a Nutshell

Kanban - In a Nutshell

Visit Agile, LLC Today

Definition

Kanban is a method for developing software products and processes with an emphasis on just-in-time delivery while not overloading the software developers. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and developers pull work from a queue.

Kanban can be divided into two parts:

• Kanban – A visual process management system that tells what to produce, when to produce it, and how much to produce.
• The Kanban method – An approach to incremental, evolutionary process change for organizations.

The Kanban Method

Kanban - Signboard

The name 'Kanban' originates from Japanese, and translates roughly as "signboard". Kanban traces back to the early days of the Toyota production system. Taiichi Onho developed the Kanban system between 1940-1950 to control production between processes and to implement Just In Time (JIT) manufacturing at Toyota manufacturing plants in Japan. The Kanban method as formulated by David J. Anderson is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. One example of such a pull system, is a Kanban system, and it is after this popular form of a work-in-progress, limited pull system that the method is named.

The Kanban method is rooted in these basic principles:

Start with what you do now

• The Kanban method does not prescribe a specific set of roles or process steps. 
• There is no such thing as the Kanban software development process or the Kanban project management method. 
• The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system.

Agree to pursue incremental, evolutionary change

• The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. 
• Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. 
• The Kanban method encourages continuous small incremental and evolutionary changes to your current system.

Respect the current process, roles, responsibilities and titles

• It is likely that the organization currently has some elements that work acceptably and are worth preserving. 
• We must also seek to drive out fear in order to facilitate future change. 
• By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban initiative. 
• Perhaps presenting Kanban against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.

Leadership at All Levels

Acts of leadership at all levels in the organisation from individual contributors to senior management should be encouraged.

Six Core Practices

Anderson identified five core properties that had been observed in each successful implementation of the Kanban method. They were later relabeled as practices and extended with the addition of a sixth.

Visualize

• The workflow of knowledge work is inherently invisible. Visualizing the flow of work and making it visible is core to understanding how work proceeds. Without understanding the workflow, making the right changes is harder.
• A common way to visualize the workflow is to use a card wall with cards and columns. The columns on the card wall representing the different states or steps in the workflow.

Limit WIP

• Limiting work-in-process implies that a pull system is implemented on parts or all of the workflow. The pull system will act as one of the main stimuli for continuous, incremental and evolutionary changes to your system.
• The pull system can be implemented as a Kanban system. The critical elements are that work-in-process at each state in the workflow is limited and that new work is “pulled” into the new information discovery activity when there is available capacity within the local WIP limit.

Manage Flow

• The flow of work through each state in the workflow should be monitored, measured and reported. 
• By actively managing the flow the continuous, incremental and evolutionary changes to the system can be evaluated to have positive or negative effects on the system.

Make Policies Explicit

• Until the mechanism of a process is made explicit it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. 
• With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.

Implement Feedback Loops

• Collaboration to review flow of work and demand versus capability measures, metrics and indicators coupled with anecdotal narrative explaining notable events is vital to enabling evolutionary change. 
• Organizations that have not implemented the second level of feedback - the operations review - have generally not seen process improvements beyond a localized team level. As a result, they have not realized the full benefits of Kanban observed elsewhere.

Improve Collaboratively, Evolve Experimentally

• The Kanban method encourages small continuous, incremental and evolutionary changes that stick. 
• When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus.
• The Kanban method suggests that a scientific approach is used to implement continuous, incremental and evolutionary changes. The method does not prescribe a specific scientific method to use.

Contributors:

Scrum - In a Nutshell

Scrum - In a Nutshell

Visit Agile, LLC Today

Definition

Scrum Is an Innovative Approach to Getting Work Done

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.

The Scrum Framework in 30 Seconds

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wishlist, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Scrum - A Thorough Description

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Scrum focuses on project management institutions where it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loops that constitute the core management technique are used as opposed to traditional command-and-control management. Its approach to planning and managing projects is by bringing decision-making authority to the level of operation properties and certainties.

Core Roles

The core roles are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project). They represent the scrum team.

Product Owner

The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the development team, it is recommended that this role not be combined with that of ScrumMaster.

ScrumMaster

Scrum is facilitated by a ScrumMaster who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the Development Team and keep it focused on the tasks at hand. The role has also been referred to as a servant-leader to reinforce these dual perspectives.

The ScrumMaster differs from a Project Manager in that the latter may have people management responsibilities unrelated to the role of ScrumMaster. The Scrum Master role excludes any such additional people responsibilities.

Development Team

The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing, even though they may interface with project management organizations (PMOs).

Ancillary Roles

The ancillary roles in Scrum teams are those with no formal role and infrequent involvement in the Scrum process - but nonetheless, they must be taken into account.

Stakeholders

The stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefit[s] that justify its production. They are only directly involved in the process during the sprint reviews.

Managers

People who control the environment.

Sprint

A sprint is the basic unit of development in Scrum. The sprint is a "timeboxed" effort, i.e. it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month.

Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

During each sprint, the team creates finished portions of a product. The set of features that go into a sprint come from the product backlog, which is an ordered list of requirements. Which backlog items go into the sprint (the sprint goals) is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed (the ones with the highest priority). The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog. The sprint backlog is property of the development team, i.e. during a sprint, no one is allowed to edit the sprint backlog except for the development team. The sprint goals should not be changed during the sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

Like other agile development methodologies, Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the sprint backlog. There are also open-source and proprietary packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools, and maintain their artifacts in hard-copy forms such as paper, whiteboards, and sticky notes.

Meetings

Daily Scrum

Each day during the sprint, a project team communication meeting occurs. This is called a daily scrum, or the daily standup. This meeting has specific guidelines:

• All members of the development Team come prepared with the updates for the meeting
• The meeting starts precisely on time even if some development team members are missing
• The meeting should happen at the same location and same time every day
• The meeting length is set (timeboxed) to 15 minutes
• All are welcome, but normally only the core roles speak

During the meeting, each team member answers three questions:

• What have you done since yesterday?
• What are you planning to do today?
• Any impediments/stumbling blocks?

Any impediment/stumbling block identified in this meeting is documented by the ScrumMaster and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.

Backlog Grooming

The team should spend time during a sprint doing product backlog grooming. This is the process of estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking larger stories into smaller stories.

• Meetings should not be longer than an hour
• Meeting does not include breaking stories into tasks
• The team can decide how many meetings are needed per week

Scrum of Scrums

• Each day normally after the Daily Scrum (larger companies can choose to have these once per week)
• These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
• A designated person from each team attends.

The agenda will be the same as the Daily Scrum, plus the following four questions:

• What has your team done since we last met?
• What will your team do before we meet again?
• Is anything slowing your team down or getting in their way?
• Are you about to put something in another team’s way?

Sprint Planning Meeting

At the beginning of the sprint cycle (every 7–30 days), a “Sprint planning meeting” is held.

• Select what work is to be done
• Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
• Identify and communicate how much of the work is likely to be done during the current sprint

Eight-Hour Time Limit:

• (1st four hours) Entire team: Dialog for prioritizing the Product Backlog
• (2nd four hours) Development Team: Hashing out a plan for the Sprint, resulting in the Sprint Backlog

At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”

Sprint Review Meeting

• Review the work that was completed and not completed
• Present the completed work to the stakeholders (a.k.a. “the demo”)
• Incomplete work cannot be demonstrated

Sprint Retrospective

• All team members reflect on the past sprint
• Make continuous process improvements

Two main questions are asked in the sprint retrospective: 

• What went well during the sprint? 
• What could be improved in the next sprint?

Artifacts

Product Backlog

The product backlog is an ordered list of "requirements" that is maintained for a product. It contains Product Backlog Items that are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. The features added to the backlog are commonly written in story format. The product backlog is the “What” that will be built, sorted in the relative order it should be built in. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the stories on the backlog for the Development Team. The product backlog contains rough estimates of both business value and development effort, these values are often stated in story points using a rounded Fibonacci sequence. Those estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return on Investment) is higher.

The Product Backlog, and business value of each listed item is the responsibility of the Product Owner. The estimated effort to complete each backlog item is, however, determined by the Development Team. The team contributes by estimating Items and User-Stories, either in Story-points or in estimated hours.

Sprint Backlog

The sprint backlog is the list of work the Development Team must address during the next sprint. The list is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. This is done by the Development Team asking "Can we also do this?" and adding stories/features to the sprint backlog. The Development Team should keep in mind the velocity of its previous Sprints (total story points completed from each of the last sprints stories) when selecting stories/features for the new sprint, and use this number as a guide line of how much "effort" they can complete.

The stories/features are broken down into tasks by the Development Team, which, as a best practice, should normally be between four and sixteen hours of work. With this level of detail the Development Team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed during the daily scrum, according to the set priority and the Development Team member skills. This promotes self-organization of the Development Team, and developer buy-in.

The sprint backlog is the property of the Development Team, and all included estimates are provided by the Development Team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.

Contributors:

Ferret out systemic issues during Sprint Retrospective

Ferret out systemic issues during Sprint Retrospective

Sprint Retrospective

The retrospective meeting is held at the end of every sprint, and it is the time to discuss what went well, and what could be improved in the next sprints. I feel the Product Owner should be in attendance. The PO is a part of the team, and should be present. 

I handle my Sprint Retrospectives by the book with a minor exception.

My Retrospectives

It usually only lasts 20-30 minutes then we start planning for the next Sprint.

The two basic questions are asked of each team member:

• What went well during this Sprint?
• What are aspects of this Sprint you feel could have been improved on?

I add in a third question:

• Not thinking of this Sprint in particular, what is keeping you up at night with this project?

What this third question does it takes them out of the Sprint mindset and force them look at the big picture. This is where systemic issues are brought to the surface.

Some responses I have received:

• The Technical Leads are overworked and we end up waiting hours for assistance.
• The QAs are not dedicated so we are building up technical debt.
• Why can't we embed the QAs within the teams?
• It seems every time we ask Web Operations to get their tasks done that we are dependent on we get push-back.

These four points would never come up in retro if the third question wasn't asked. Now the ScrumMaster and PO can put their heads together and tackle the systemic issues.

Visit Agile, LLC Today

Sprint Planning - Eliminate Technical Debt

Sprint Planning - Eliminate Technical Debt

Definition

As a software project manager or product owner, the term ”technical debt” may not ring a bell. Over the last several years managing Agile teams, I have come to realize that lurking technical debt introduces risk and represents unplanned work that impacts schedules and ultimately the long-term health of projects. I believe that project managers and product owners should make technical debt a priority and factor a “re-payment” program into project schedules as a regular part of planning.  Over the course of a project, it is tempting for an organization to become lax regarding software quality. This may be for a number of reasons: the primary ones being that the team is expected to complete too much functionality in the given time; or quality is not considered a high priority characteristic of the software.

How it Accrues

There are a few different reasons that come to mind:

• QA is not brought in early enough in the sprint. Usually because they are shared resources.
• Too many stories are being worked on at once

How to Avoid It

Addressing the two point above:

• QA is not brought in early enough in the sprint:
   - I prefer to have a dedicated QA resource in each team
   - When QAs are brought in late they cannot approve all stories in time
   - The QAs need to be side-by-side with developers from the start.
     Working together the QA and developers can establish testing early
• Too many stories are being worked on at once:
   - If all stories are worked on simultaneously then they will all hit QA at the same time
   - I recommend tiering your Sprint Backlog into 3 tiers, 3 equal divisions
     The top tier is worked on first. Developers cannot take stories from tier 2
     until tier 1 is done or approval is granted by the Product Owner
     When a tier is done it goes to QA as each story is completed.
     Then next tier is started.
• If "Task Inflation" is causing technical debt then the PO needs to work with the business unit in order to break down the stories as smaller units

Visit Agile, LLC Today

Definition of Done

The Definition of Done (DoD)

I find that having the Product Owner specify specific acceptance criteria (AC) per story helps the developers and quality analysts understand exactly what is expected from the feature to determine whether is is ready to be accepted.

The team agrees to a list of criteria which must be met before a product increment (often a user story) is considered "done". Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity. The DoD should be displayed prominently in the team room (stand-up room).

Things to Consider

• Obsessing over the list of criteria can be counter-productive; the list needs to define the minimum work generally required to get a product increment to the "done" state
• Individual features or user stories must contain specific AC
• If the DoD is merely a shared understanding, rather than spelled out and displayed on a wall, it may lose much of its effectiveness; a good part of its value lies in being an explicit contract known to all members of the team
• The team uses the DoD at the end of a sprint to justify the decision to count work towards velocity or not
• The DoD must be practical or it will fall by the wayside. You can always expand it once you are consistently meeting the basic criteria

Expected Benefits

• The DoD provides a checklist which usefully guides pre-implementation activities, such as discussion, estimation, design, and AC specifications
• The DoD limits the cost of rework once a feature has been accepted as "done" - If the business unit wants to modify the feature after completion the modification is to be written as a new story and placed in the Product Backlog
• Having an explicit contract limits the risk of misunderstanding and conflict between the business unit and development team

An Example of a DoD

Definition of Done for Team "Scrum-cious"

• The Developer claims all acceptance criteria has been satisfied through Unit Testing
• Unit Testing was verified by a peer
• QA tested and approved the story based on the AC
• The PO has approved the story

Quick Start for Scrum Projects

Quick Start for Scrum Projects

The Basics

Initiating a Scrum project should not be difficult. If a team has not had any training in Scrum it is a good idea to initiate the project with a two-days training session where training is combined with practice. Exactly how you would define the agenda for this is something that should be defined when considering the participants and the project. A good approach is to practice planning mixed in with the training.

This is done using a series of steps, see below.


Proposed Agenda

• If non-Agile; hold training session educating staff in the specifics of Agile
• Teach Scrum concepts, theory, practices
• Present project vision, goals, timelines
• Teach Sprint planning
• Define Product Backlog for at least three months
• Brainstorm about overcoming impediments
• Brainstorm about Product Backlog for next Sprint - team commits
• Team defines the first Sprint Backlog
• Teach Daily Scrum, Sprint review, and management
• Discuss engineering tools and practices

Dramatically increase your LinkedIn Connections

Dramatically Increase your LinkedIn Connections

Explode your LinkedIn Connections

I went from 200+ connections to over 2000 in two months.

Click Here to Learn How

Adopt Agile or Improve your use of it!

Adopt Agile or Improve your use of it!

Curious about benefits of Agile and Scrum?

Agile and Scrum enable you to:

• Respond to market changes while controlling risk
• Increase ROI (return on investment)
• Continuously improve your process
• Increase quality of your products
• Work at a sustainable pace

What are the Statistics?

• Accelerating time to market is again the number-one reason for agile adoption (22%).
• In 2010 there was an increase in productivity (74%)
• In 2011 productivity improved to 75% (but included the two following benefits) - Manage changing customer priorities (84%) - Project visibility (77%)

Tools

Tools currently being used (or planned) include: 

• Automated Acceptance Tools (20%)
• Release Management Tools (16%)
• Continuous Integration Tools (16%)

When you have multiple people working on one or more projects all at the same time, good communication is critical. Using the right agile project management (APM) tools for the job can mean the difference between monumental success and utter frustration.

Various Software Tools

• Rally/RallyDev
• VersionOne
• Atlassian – JIRA w/GreenHopper
• Assembla
• Pivotal Tracker
• ScrumDo
• Agilo Software
• Basecamp
• Gemini
• Mingle
• ScrumWorks Pro

Source of Statistics:

Rally Software

Continuous Integration and Automated Builds

Continuous Integration and Automated Builds

Continuous Integration - Definition

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

Use: Building a Feature with Continuous Integration

The easiest way for me to explain what CI is and how it works is to show a quick example of how it works with the development of a small feature. Let's assume I have to do something to a piece of software, it doesn't really matter what the task is, for the moment I'll assume it's small and can be done in a few hours.

I begin by taking a copy of the current integrated source onto my local development machine. I do this by using a source code management system by checking out a working copy from the mainline.

The above paragraph will make sense to people who use source code control systems, but be gibberish to those who don't. So let me quickly explain that for the latter. A source code control system keeps all of a project's source code in a repository. The current state of the system is usually referred to as the 'mainline'. At any time a developer can make a controlled copy of the mainline onto their own machine, this is called 'checking out'. The copy on the developer's machine is called a 'working copy'. (Most of the time you actually update your working copy to the mainline - in practice it's the same thing.)

Now I take my working copy and do whatever I need to do to complete my task. This will consist of both altering the production code, and also adding or changing automated tests. Continuous Integration assumes a high degree of tests which are automated into the software: a facility I call self-testing code. Often these use a version of the popular XUnit testing frameworks.

Once I'm done (and usually at various points when I'm working) I carry out an automated build on my development machine. This takes the source code in my working copy, compiles and links it into an executable, and runs the automated tests. Only if it all builds and tests without errors is the overall build considered to be good.

With a good build, I can then think about committing my changes into the repository. The twist, of course, is that other people may, and usually have, made changes to the mainline before I get chance to commit. So first I update my working copy with their changes and rebuild. If their changes clash with my changes, it will manifest as a failure either in the compilation or in the tests. In this case it's my responsibility to fix this and repeat until I can build a working copy that is properly synchronized with the mainline.

Once I have made my own build of a properly synchronized working copy I can then finally commit my changes into the mainline, which then updates the repository.

However my commit doesn't finish my work. At this point we build again, but this time on an integration machine based on the mainline code. Only when this build succeeds can we say that my changes are done. There is always a chance that I missed something on my machine and the repository wasn't properly updated. Only when my committed changes build successfully on the integration is my job done. This integration build can be executed manually by me, or done automatically by Cruise.

If a clash occurs between two developers, it is usually caught when the second developer to commit builds their updated working copy. If not the integration build should fail. Either way the error is detected rapidly. At this point the most important task is to fix it, and get the build working properly again. In a Continuous Integration environment you should never have a failed integration build stay failed for long. A good team should have many correct builds a day. Bad builds do occur from time to time, but should be quickly fixed.

The result of doing this is that there is a stable piece of software that works properly and contains few bugs. Everybody develops off that shared stable base and never gets so far away from that base that it takes very long to integrate back with it. Less time is spent trying to find bugs because they show up quickly.

Automated Build - Definition

The "build" in developer parlance consists in the process which, starting from files and other assets under the developers’ responsibility, results in a software product in its final or "consumable" form.

This may include compiling source files, their packaging into compressed formats (jar, zip, etc.) but also the production of installers, the creation or updating of database schema or data, and so on.

The build is "automated" to the extent that these steps are repeatable and require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository.

Tools

Make, Ant, Maven, rake, etc.

Expected Benefits

Build automation is a prerequisite to effective use of continuous integration. However, it brings benefits of its own:

• Eliminating a source of variation, and thus of defects; a manual build process containing a large number of necessary steps offers as many opportunities to make mistakes
• Requiring thorough documentation of assumptions about the target environment, and of dependencies on third party products

Contributors:

ATDD - What is this all about?

Acceptance Test Driven Development (ATDD)

Definition

Acceptance test driven development, or ATDD, is a collaborative practice wherein application developers, software users, and business analysts define automated acceptance criteria very early in the application development process.

In the ideal situation (though rarely attained in practice), the product owner, customer or domain expert is able to specify new functionality by writing new acceptance tests or test cases, without needing to consult developers.

Acceptance test driven development, or ATDD, is a collaborative practice wherein application developers, software users, and business analysts define automated acceptance criteria very early in the application development process.

Benefits/Advantages

Just as TDD results in applications designed to be easier to unit test, ATDD favors the creation of interfaces specific to functional testing.


Acceptance tests have several key advantages over lower-level tests:

• As a design framework prior to coding, they focus the developer on the user's needs. This is an important benefit. It is much easier to design functions correctly, when you can see them holistically, rather than the bottoms-up approach of TDD where the focus is on tiny steps developed within the scope of a single function.
• The developer validates the code at the level of the user experience. If the previous benefit was important, this one is crucial. It is entirely possible to write software that enjoys 100% code coverage, where every unit tests passes, but whose functionality is still broken. Even if the functionality is correct, the software still might not do what the user requested. In counterpoint, if the code is defined by acceptance tests, it is no longer possible to pass all the test and not work or not do what the user requested. Passing all acceptance tests (presuming they’re correctly written) guarantees satisfaction with user needs and validates the software.
• Acceptance tests document the software. This last point gets at what is one of the most pervasive misconceptions about unit tests: that they document the code. This is a canard that keeps being tossed about as a good reason for writing unit tests. It is, in a word, nonsense. If you’re looking at unit tests as documentation for the code, something upstream is seriously broken.

Tools

Fit/FitNess, HP's Quick Test Pro, Cucumber or others.

Team Velocity - Importance & Definition

Team Velocity - Importance & Definition

Importance of Team Velocity

Without team velocity you cannot adequately plan your sprints. What this usually causes is the team pulling too many stories from the backlog.

There are numerous problems with this:

• It makes it difficult to establish an accurate release plan
• It is demoralizing to the team to push stories the next sprint
• It destroys stakeholder trust in the teams ability to meet deadlines

Establishing team velocity allows for accurate release planning, understanding the weight of story to pull into each sprint, and maintains stakeholder confidence that the team can deliver.

Definition of Team Velocity

In Scrum, velocity is defined by how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant.

Once established, velocity can be used to plan projects and forecast release and product completion dates.