(Note that this meeting is on the second Wednesday of the month!)

Since their arrival on the scene in the late 1990s, agile processes have gained widespread visibility, interest... and controversy. With the successes achieved by early adopters and the increasing attention of the development community, agile processes have generated the extremes of both fanatical support and vocal opposition.

For more information, as well as Paul’s publications and presentations, please visit Agile Logic’s website at www.AgileLogic.com.
prepared by Paul Schmidt
 

Paul said his presentation would lay a foundation to explain agile development. He asked the audience if they knew anything about agile development and some people raised their hands, more when he asked for those who had heard about it. He asked who had read a book on it. A few people raised their hands and the same people indicated they had worked with it. Paul then introduced his company, Agile Logic, and his own experience. He said he had been actively involved in doing agile development for six years but that he had become involved in it during the 1990's before agile development really got started.

What is an "Agile" process? Agile is a focusing set of values, it is not so much a cook book as it is focusing set of values that imply core strategies. They don't tell you to tear up the things the way you are doing things now. Agile practices may be similar or different than your current processes. Specific agile processes are starting points and consist of a collection of practices that have been found to be effective to implement the core strategies. Practices will vary depending on the context of the project varying from industry to industry. The set of practices used are usually tailored to meet the situation and evolve over time. This may seem a bit fuzzy and it is. They don't lay out specific goals although some agile processes are more prescriptive than others. You can get benefits from them. Agile development can provide faster release cycles and better productivity. They can provide better quality including the quality of code and the design as well as the desired functions provided by the software. There is a tighter focus on delivering value by providing a better Return on Investment (ROI) and agile processes are more responsive to change. The most successful transitions to agile are driven by clear, compelling goals. Don't do agile programming just to do an agile process; you should be doing it for a good reason.

Agile processes emerged in 1995 and have matured since 2000. Some practices, such as pair programming, were around before being defined as part of agile programming. Early developments had trouble getting funding. It has been used on quite a number of different projects including financial, Federal Drug Administration (FDA) life-critical processes, shrink-wrap, enterprise workflow, biotech, embedded real-time and internet e-business. Many well known businesses, including Yahoo!, SAP, Microsoft, Fidelity, Kelley Blue Book, Primavera, Symantec Lloyds Bank, Verizon, Motorola, PayPal, Nike and Capital One have used agile processes successfully.

Agile processes consist of a number of building blocks that focus on collaboration across an entire development team. It is a cross-functional team working closely together and usually has daily “standup” meetings. We want to have a working process after every iteration. Some of the building blocks are Travel light (don’t carry things along with you that you really don’t need), Remove waste (find ways in the process to get rid of unnecessary activities), Emergence (Allow changes during development as opposed to complete “Up front” requirements and design), Adaptive planning (Empirical, responding to actual conditions), Self-organization, Iterative, Incremental, Frequent delivery, shared vision, focusing goals, collaboration and Whole team involvement. Iterative things are done concurrently and in parallel to speed things up and to get feedback as quickly as you can. There is a tool box of agile practices, not all of which may be used on a particular project. Many of the practices are not new and can be recognized as parts of other development processes. Components of the tool box are User stories (Very small chunks of requirements), Product Backlog (prioritized list of user requirements), Unit Tests, Story tests (small chunks of functional testing of what we want to build), Automated tests, Release planning(looking ahead months at a time), Iteration planning (shorter term), Velocity (the ability to take results and feed them back into the planning), Test-Driven development (driving the development process by responding to test results), Refactoring (balancing and clearing things up), Collaborative working, Co-location (Sometimes virtual co-location has been accomplished by telecommunication), Pairing (two or more people working on the same problem), Continuous integration, Automated Builds (make certain we can keep an updated and working system), Frequent deployments, Daily stand up meetings, Information Radiators (information made available to everyone), Retrospectives (make sure you are where you want to be) and Continuous improvement.

There is a world of various agile processes. Scrum (a rugby term for a huddle-getting your people together on a regular basis) is a key characteristic of most agile processes. Extreme Programming (XP) is a set of 12 very specific processes. There are two versions; the original version used very strictly applied rules. There is a new more relaxed version of XP that has a set of very strongly recommended practices and selects agile tools that are determined to be applicable to the particular project. There is Feature-Driven Development (FDD) that does more modeling and upfront design. There is the Crystal Family of Processes named after colors that indicate the level of formality down to Crystal Clear, a lighter weight version with smaller and less formal teams. Other agile systems include Lean Software Development, Adaptive Software Development (ASD), MSF Agile, Agile UP/RUP, Evo and Win-Win Spiral. In 2001 the Agile Alliance was formed consisting of organizations advocating agile processes and has a set of principles listed in the Agile Manifesto.

Why do agile processes work? They maximize the power of the team, demonstrate concrete progress, relentlessly focus on business goals, are responsive to feedback and learning and have a continuous improvement culture. Paul presented a typical agile process structure. First comes the vision that is made part of the business planning cycle, typically on a quarterly or yearly basis. Management decisions are made to go forward with a project based on the expected ROI and establishing releases and milestones. A desired product is defined and a desired product release schedule is set up (typically from 1 to 6 months). A product backlog is set up with emerging, prioritized requirements and one of the products is selected and moves to a sprint (actual development) backlog for the team. The sprint iteration cycle (typically 1 week to 1 month) ends at a benchmark that demonstrates some desired functionality. There is a daily development cycle that features daily builds and daily “scrum” all-hands meetings of the team. The product and its functionality is reviewed at the end of each iteration and then recycled to add the next desired set of functions. The product will be released when the entire function set has been demonstrated to work satisfactorily.

The project community consists of the business community which includes the Product Owners and Stakeholders. The Product Owners are the manager and business analyst responsible for the project. The Stakeholders are end users, management, market/sales, customer support, and training and technical people affected by the product. The Team is composed of people who work directly on the development tasks. It can be composed of programmers, architects and designers, technical leads, QA/testers, IA/UI designers, database designers and database administrators (DBAs), technical writers, network engineers and hardware designers. These are the people who meet in the daily “Scrum” that is directed by the Scrummaster. He is responsible for the administrative process and also for making certain that Product Owners and Stakeholders are kept in the loop. He is a “coach” who makes certain that things are working correctly and monitors the interactions with external groups.

The core development team consists of the programmers who produce the software product. They are in close collaboration with QA, Architects, User Interface designers, DBA’s and other disciplines that are an integral part of the team and who should be included in the daily scrum. There is a wider stakeholder group who must be given good visibility on product features and required inputs during development so that they can determine that it meets their needs and give feedback early enough to improve the product. The business management and planning community must be continually updated on the project schedules and costs. Agile teams are usually on the order of 7 to 15 people in size. Larger projects with more people, more diverse products that have to be integrated and possibly separate locations require an overlying structure to coordinate the products of the teams.

A product initially comes from an idea that is developed into product plans and strategies at a high level. Features for the product are determined and defined as product backlog items. They become development tasks that are sprint backlog items. Prior to delivery there will be various project artifacts such as source code, documentation, tests, database schema, executables and many other possibilities. These are very project dependent. The end result is a potentially shippable increment of the product.

Mr. Hodgetts presented a set of charts and provided me with charts containing statements about agile processes and answers that he did not show at the meeting. Most of these were quite thoroughly discussed during the body of his talk, but there was not sufficient time to cover them at the end. They are interesting.

Agile processes don’t produce any documentation.    False.

Using an agile process will give you a 6 to 30 times increase in productivity.    Half-truth.

Agile processes don’t scale.    False, with some caveats.

Refactoring dramatically reduces the need for up-front architecture and design.    Half-truth.

Agile processes produce better designs and better code.    Mostly false, some practices help.

Agile processes shortchange architecture and design.    False, but they do it differently.

Agile processes require us to work as a team.    True.

Agile processes don’t create long term plans – it’s done when it’s done, and you get what you get.    False.

Agile processes don’t work with QA, UI, DBAs, operations.    False.

With agile processes the team self-manages itself. In agile processes, no one is in charge.    Half-truth (both of them).

It’s possible to do agile wrong and fail, therefore agile processes are a bad idea.    Odd reasoning.

We’ve been doing unit testing (or some other practice) for years. We’re already agile.    Missing the point.

We can pick and choose the agile practices we want to do.    Be careful!

We want to save time by planning out our agile process and choosing our practices before we start.    How will you know?

For more enlightenment than is presented in this article you can contact:

Paul Hodgetts
phodgetts@agilelogic.com
www.agilelogic.com
(714) 577-5795

Mr. Hodgetts recommended the Agile Alliance as a source for more information on agile development.

www.agilealliance.org

I reached the website, but a lot of my requests were answered with “page not found.” There is a place to logon, requiring a password and a place to sign up for membership. The result of my attempt to sign up was an error message. A few things worked on the website, but not too much. I assume this is temporary.

I had better success at www.agilemanifesto.org.

This has a link to www.agilealliance.com.

This worked very well and provided much interesting information and links to other resources. Perhaps the .org website is still a “work in progress”.

This was an excellent presentation that answered quite a number of my questions about agile programming. Like most good answers they raised some more questions. One thing Mr. Hodgetts did not answer was “How do I apply agile development” to my project? As Mr. Hodgetts explained, many aspects of agile processes are project dependent. You may need either some education on the subject or quite possibly could use assistance provided by an expert.

This was another of the regularly scheduled meetings of the Los Angeles Chapter of ACM. Our next regular meeting will be held on April 5, 2006. This was the sixth meeting of the LA Chapter year and was attended by about 22 persons.
Mike Walsh, LA ACM Secretary