Archives

• Adopting Agile in the Enteprise - The QuickStart Workshop

  Wednesday, April 28, 2004

  Agile

  No Comments

  If you're having difficulty adapting agile development at your workplace or just need a helping hand this document might help out. This is an outline that I've prepared at my work to do just that. It outlines a proposal and plan for hosting an Application Development QuickStart Workshop. Feel free to adapt it for your use but it's been generalized enough so that it should fit into any IT departement.

  Introduction

  The QuickStart Workshop is meant to get development teams up and running with new application development quickly and easily and down the path to success. This is accomplished through:

  • Creating an agile development environment for the team
  • Engaging the team in an intense development session
  • Practicing best of breed attributes of Agile Development. This includes eXtreme Programming, Iterative Development, and Test Driven Design
  • Creating a solid application design and reference architecture to start from
  • Producing the first iteration of an application to continue growing it throughout the development lifecycle

  The workshop is customized to fit each project teams needs. By utilizing a series of options, you will leverage each members time for the greatest benefit.

  Why Not?

  The big question is why wouldn’t you adopt this workshop and practice it? The big reason is that the benefits listed below will be immediately recognizable in your project and your team dynamics. In comparison to traditional development you can see the differences below:

  Traditional Development	Agile Development
  Long, “big-bang” delivery cycles	Short, frequent delivery cycles
  Process-driven	Business value-driven
  Comprehensive documentation	Working software with minimal documentation
  Contract	Collaboration
  Minimize change	Embrace change
  Specialization	Empowered teams

  What does the Workshop provide?

  • An understanding of the agile processes and methodology, emergence, self-organization, and adaptation
  • An understanding of how to manage emerging requirements and unstable technology and still provide guaranteed business value within a fixed cost and time.
  • A preliminary product backlog of project requirements to drive the first several iterations and an understanding of how to manage the product backlog.
  • An understanding of how to plan and initiate iterations from product backlog.
  • An iteration plan for the first iteration.
  • An understanding by the team of how to self-organize and work with emerging requirements, architecture, and design.
  • An optimized work environment and infrastructure for the team.
  • An understanding of the theory, practices, and values that underline agile processes. At the end of the workshop, the team will be well on its way to its first iteration to create an increment of user functionality for the project.

  Practices Experienced During the Workshop

  The Workshop is focused on delivery and collaboration. It helps teams get to know and follow most of the 12 core practices of the eXtreme Programming model (XP). These practices are not necessarily followed to the letter, but the intent is to provide the exposure to them where it makes sense. These are:

  • The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:
  • Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards.
  • Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).
  • Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.
  • Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.
  • System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.
  • Simple Design: Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements.
  • Continuous Testing: Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.
    Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework, such as NUnit
  • Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very least, an acceptance test could consist of a script of user interface actions and expected results that a human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.
  • Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.
  • Pair Programming: Code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
    Collective Code Ownership: No single person "owns" a module. A developer is expected to be able to work on any part of the codebase at any time.
    Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
    40-Hour Work Week: Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
  • On-site Customer: Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.
  • Coding Standards: Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.

  Benefits

  The benefits of participating in the workshop come to bear quickly for each team. They are tangible and measurable and include:

  • Understanding the application design and architecture process and how a team fits in
  • Collaborating as a highly effective team working towards a single goal
  • Learning new practices and technologies like .NET, Agile and iterative development, and Test Driven Design
  • Managing change successfully by not fearing to change code in the system or completely throwing away concepts that don’t work
  • A working and fully tested system at all times which delivers and evaluates the business value on an on-going basis
  • Creation of re-usable components and services that other projects, teams, and the enterprise can leverage to reduce future development cycles

  In addition to the benefits above the workshop adheres to the following practices which are tied to direct benefits:

  Development Practice	Benefit
  Capturing business requirements in a form that can be estimated and prioritized within the overall product development.	Provides the business with control over the cost and scope of the project, while encouraging an iterative release cycle that puts the highest priority features into production first.
  Test-Driven Development describes the practice of writing unit-tests for a product feature before writing the code for the feature itself. The growing suite of unit-tests forms a regression test framework that is run tens if not hundreds of times per developer per day, during the development lifecycle.	Unit testing is required for production quality code, hence writing unit tests before writing code ensures that all code is production quality at all times. Regression suite ensures that new features cannot break existing functionality, giving developers the courage and confidence to make major technical or business changes without fear of failure.
  Continuous Integration describes the practice of integrating each developers code changes into the overall project, as soon as their unit tests are passing and their code is complete. Continuous integration involves running the full-suite of unit tests, tens of not hundreds of times a day, alerting the team instantly should a previous piece of working functionality be compromised development lifecycle.	By putting integration and testing into the heart of the development process, the financial cost of integrating and testing code at the end of a development cycle is reduced. Furthermore, since this testing cycle typically occurs immediately prior to a fixed milestone such as a product launch, it is often omitted through necessity - by integrating and regression testing continuously, this quality compromise does not occur.
  Refactoring describes the agile practice of changing the design of existing code to a more elegant solution.	Rather than invest in a period of "big up-front design", an agile software development only ever implements the functionality that is required by the business, reducing time to market, reducing cost, whilst dramatically reducing the opportunities for software failure. The existence of a comprehensive regressive test framework supports this practice of refactoring.

  The mixing of quality practices and quality methods ensures that the risk, cost and scope of a software project are visible and manageable by the client. In software development, escalating costs, slipping timescales and poor quality are establishing themselves as the norm, rather than the exception.

  Engaging the Workshop

  The Workshop is a part of the application development kick-off and the first thing that happens with the project team. The requirements to engage the workshop are:

  • Use Cases or requirements around the basic goal of the system. These do not need to be completed to perfection but there needs to be some kind of idea in mind of the goal for the project. These can be as simple as the high level Use Cases that come out of the concept phase of a project.
  • A team or core group of developers with an eagerness to deliver
  • 3 to 10 contiguous days of time allocated by the group. No meetings should be booked during this time. The length depends on the size of group and project but will not exceed more than 2 weeks (10 days).
  • If possible a customer/business user or representative who is comfortable with defining requirements for a system

  Workshop Schedule

  The workshop schedule will vary from project to project but basically it kicks off with the following activities:

  1. Project Initiation and Charter
  2. Iteration Planning
  3. Shape Architecture
  4. Monitoring and Reporting
  5. Requirements Gathering
  6. Delivered-feature Contracts
  7. Facilitating Change
  8. Peer-to-peer collaboration: paired programming, test-driven development and design, unit testing, daily Scrum meetings

  How Do I Start?

  The big question would be how do you start this practice, get a workshop going and continue the practice with your team. Here’s a possible suggestion:

  1. Setup a ½ or 1 hour session to determine the size and scale of the workshop. You can orchestrate this yourself or contact a group that might help you facilitate this like a core Development Services team.
  2. Allow for 1-2 weeks lead time to orchestrate the facilities (room bookings, software installations, etc.). Have the team clear their calendar for the duration of the workshop. The workshop may finish early, but be prepared for the entire length of the workshop.
  3. Setup a 1 hour kickoff meeting prior to the first day of the workshop. This will set expectations of the workshop, discuss any questions about how things will progress, and lay the ground rules during the workshop. This ensures everyone is comfortable with the process and knows what success means to them.

  Like any journey, everything begins with a first step. It is not, however, the last step. Each project will engage the workshop differently and as teams become familiar with the practices being engaged here, the duration of future workshops will become shorter. You should provide “booster” workshops as a refresher from time to time. Not only will teams change, but the underlying practices will as do the projects and technologies involved. This will evolve as time goes on and help keep your development teams running smoothly and be effective units of work.