|Past Meeting Archive||Los Angeles ACM home page||National ACM home page||Click here for More Activities this month|
|Check out the Southern California Tech Calendar|
Regular Meeting of the
Wednesday, March 8, 2006
"The Myths and Legends of Agile Development"
(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.
In this talk, well explore some of the common beliefs and opinions about agile development and specific agile processes such as Extreme Programming and Scrum. Do agile processes really shun documentation? Are they only good for small, expert teams? Where does architecture and design fit in? Can they really deliver a 30 times improvement in productivity? We’ll draw on the presenter’s extensive experience with agile processes to see what actually takes place on an agile team, and where reality crosses the line into hype and misconceptions.
Paul Hodgetts helps teams adopt and improve their agile development processes. He has more than 22 years of experience in all aspects of software development from in-the-trenches coding to executive engineering management, on a wide variety of projects from embedded real time control to distributed internet business applications. Paul has served as a coach, mentor and team member of agile development teams for more than six years. Paul has successfully worked with many clients, including Yahoo!, Microsoft, SAP, Kelley Blue Book and a host of others, across a wide range of sectors and industries. His recent focus has been on large cross-organizational agile initiatives, and applying agile processes to multi-product, multi-team projects in challenging enterprise, regulated and legacy environments.
Paul is a published author and recognized expert and authority in agile development, a Certified ScrumMaster Trainer, and actively contributes to the evolution of the Scrum process. He is a frequent and popular presenter at conferences, professional organizations and user groups, serves as a Program Director for the Agile Alliance, and is active on the program committees of industry conferences.
For more information, as well as Paul’s publications and presentations,
please visit Agile Logic’s website at
LA ACM Chapter March Meeting,
The presentation was “The Myths and Legends of Agile Development” by Paul Hodgetts of Agile Logic. This was a regular meeting of the Los Angeles Chapter of ACM.
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 only work with senior-level teams. Half-truth.
Agile teams can release at any time, on demand. Can be true, but not always.
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 do pair programming. False.
Agile processes can be used on any project. Agile processes can’t be used on my project. Probably false (both of them).
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?
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.
|And coming March 8th. . . Paul Hodgetts, CEO of Agile Logic, will speak about the exciting field of agile programming.||
Directions to LMU & the Meeting Location:
This month's meeting will be held at Loyola Marymount University, University Hall, Room 1767 (Executive Dining Room), One LMU Dr., Los Angeles, CA 90045-2659 (310) 338-2700.
From the San Diego (405) Freeway:
Dinner will be in the Faculty Dining Room, UHall 1767: To get to the Roski Dining Hall, where you may purchase your food, take one of the elevators in the bay at the west end of the parking structure to the Lobby level. Exit the elevators, then walk straight ahead through the glass doors and into the atrium. Turn right. The entrance to the cafeteria is on the right before you reach the cafeteria seating area at the west end of the atrium. (The cafeteria entrance is room 1700 according to the building floor plan).
To enter the Faculty Dining Room from the cafeteria:
After paying for your food, head back to the area between the grill and the sandwich bar. Turn toward the exterior windows (north side of the room), and walk toward the windows. Before you reach the windows, there will be an opening on the east side of the room, which leads to a hall along the exterior north wall of UHall. Walk down the hall until you come to the faculty dining room. Alternatively, leave the dining area through the doors on the south side of the dining area and walk east (left) through the lobby until you reach the Executive Conference Center (ECC). Enter the double glass doors to the ECC, continue straight down the hall to the end, then turn left and you will be in the faculty dining room.
The meeting will also be in the Faculty Dining Room, UHall 1767. From parking Lot P2 or P3 under University Hall, take one of the elevators in the bay at the center of the parking structure to the Lobby level of University Hall. When you exit the doors into the atrium, the next set of doors a short distance to your right says ECC Center. Enter those doors and walk straight down the hallway. Room 1767 is on your left hand side.
Directions to LMU & the Meeting Location:
The Schedule for this Meeting is
5:15 p.m. Council Meeting
6:00 p.m. Networking/Food
7:00 p.m. Program
9:30 p.m. Adjourn
No resevations are required for this meeting. You are welcome to join us for a no host dinner in Room 1767. Food can be bought in the Cafeteria. Look for the ACM Banner.
If you have any questions about the meeting, call Mike Walsh at (818)785-5056, or send email to Mike Walsh .
For membership information, contact Mike Walsh,
(818)785-5056 or follow this
Other Affiliated groups
Return to "More"
Please visit our website for meeting dates, and news of upcoming events.
For further details contact the SIGPHONE at (310) 288-1148 or at Los_Angeles_Chapter@siggraph.org, or www.siggraph.org/chapters/los_angeles
Return to "More"
|Past Meeting Archive||Los Angeles ACM home page||National ACM home page||Top|
Last revision: 2006 0317 [Webmaster]