"I recently read an article that does a great injustice to the practical implementation of the Agile process in software development. In an attempt to describe the Agile process, the author of this article, apparently the "Head of the Software Development Department", inadvertently described exactly how NOT to do it. This person actually said, "If it was possible to construct a home using the Agile approach, one could go into the kitchen on the second floor of the house under construction and look out the window, even before all the walls were installed on the ground level. If you didn't like the view from the window, then next week the kitchen could be moved to the first floor." I was flabbergasted!! It's as insane in the world of building a house as it would be in the world of writing software. Many people incorrectly think that this is how Agile should be implemented, room-by-room.
I am a BIG believer in the Agile process when done correctly. But when done incorrectly, as is described by many in industry, it is by far worse than the Waterfall method. I also love the use of the house building analogy, because the analogy works. If it makes sense in building a house, it typically makes sense in building software. If it doesn't make sense in building a house, it won't make sense in building software. Clearly, the example I read does not make sense! By the way, I tried to reply to this guys article, but when I submitted my comment, the site broke.
Agile does NOT mean that we don't plan. Agile does NOT mean that we don't determine requirements before implementing. Agile does NOT necessarily take less time to complete a project; it may even take more time. On the other hand, Agile software development, unlike the Waterfall method, DOES mean that the determination of requirements, design, implementation, and delivery is iterative. Successfully implemented, Agile DOES result in better customer satisfaction. However, it does NOT sacrifice good solid engineering principles to do so. Successfully implemented, Agile PREVENTS us from ripping out major functionality before we get too far along in the process.
From a practical standpoint, how do we marry the ultimate goals of customer satisfaction and solid software engineering design in the Agile process? Although many people understand that Agile is iterative, much of the misunderstanding lies in what is to be done at each iteration. The key is working from high-level requirements and refining the details at each step of the iteration.
Let's go back to the analogy of building a house. Let's build a house that the customer will love to live in because it's exactly what they want, and a house that is solid and can be added on to without fear of it collapsing. Let's assume the customer has picked out a site location and a builder. The site comes with a certain set of utilities like city water or a well, and electrical hookups. That's us with our hardware and software infrastructure. Since this is a Drupal based website, I will use the building of a Drupal website on a LAMP stack in our analogy, but the Agile process described applies to any hardware and software infrastructure out there. The sprints presented are simplified, especially Sprint 2, and should be broken down into more steps depending on the the complexity of the build, but the concept of going from high-level to detailed-level should always be adhered to; it's the key.
Sprint 1: (House)
Planning: We sit down with the customer and discuss high level requirements which involves the layout. How big does the customer want the house to be in relation to the lot size; which way should the house face; how many and what kind of rooms will be needed; what is the desired layout of those rooms; how do you want to navigate from room to room; where should the windows, doors and stairs be?
Requirements: From this initial sprint discussion and planning with the customer, we can provide the customer with a general floor-plan. Floor plans are visual, provide a great vehicle for discussion and clarification of high-level requirements, and are easy to change. This gives the customer many opportunities to change the layout without actually ripping out walls.
Delivery: The foundation can be poured and the framework can be built. This includes the framework for the exterior walls, as well as the interior walls, window framework, and doors. This does not include the actual windows, doors, or drywall. The customer should be able to walk through the house and confirm that the rooms and flow meet expectations.
Sprint 1 (Software):
Planning: We sit down with the customer and discuss high level requirements which involves the layout. How big does the customer want the site to be; what should be on the home page; how many and what kind of inner pages will be needed; how do you want to navigate from page-to-page; what's the flow?
Requirements: From this initial sprint discussion and planning with the customer, we can provide the customer with a general wire-frame. Wire-frames are visual, provide a great vehicle for discussion and clarification of high-level requirements, and are easy to change. This gives the customer many opportunities to change the layout without actually ripping out code.
Delivery: We can create an empty home page with placeholders for larger layout elements such as global headers, global footers, landing page columns and blocks built on our software infrastructure of LAMP and Drupal, or whatever software infrastructure you and your company use. We can implement a functioning main menu and navigation to each of the pages on the site with similar placeholders for larger layout elements. This does not include the actual themed buttons, graphics or background. The customer should be able to click through the site and confirm that the pages, layout and flow meets their expectations.
Sprint 2: (House)
Planning: We sit down with the customer and discuss the next level of details which is more functional in nature. What appliances would the customer like and where should they be installed. For example, where should the refrigerator, dishwasher, sinks, showers, and cabinets go. What about ceiling lights, outlets, and switches?
Requirements: We can add these details to the floor plan. This again provides everyone with a visual vehicle for discussion and clarification of the next level of requirements and are easy to change. This gives the customer many opportunities to add and remove appliances and change the layout without actually ripping out plumbing and wiring.
Delivery: The wiring for the appliances, ceiling fixtures and appliances can be installed, The pipes and plumbing for the showers and sinks and toilets can be installed. The drywall, windows and doors can be installed. The bathroom and kitchen appliances can be picked out by the customer and installed.
Sprint 2: (Software)
Planning: We sit down with the customer and discuss the next level of details which is more functional in nature. What major functionality would the customer like and where should it be implemented. For example, where should forums, blogs, reports, forms, slideshows and blocks of dynamic content go? How do they relate to each other and what are the dependencies?
Requirements: We can add these details to the wire-frame. This again provides everyone with a visual vehicle for discussion and clarification of the next level of requirements and are easy to change. This gives the customer many opportunities to change the required functionality, how it should relate to each other, and where it should be located without actually ripping out any code.
Delivery: The basic entities and objects that will form the foundation for this functionality can be created. In terms of software this equates to the database schema and classes, and can be extended in Drupal to be content types and entities. As software developers we are often tasked with actually building the analogous household appliance. Therefore this phase would actually take many more sprints depending on the amount and complexity of functionality required. The key is to go from basic, general functionality to more refined, detailed functionality at each step. Adhere to strong software engineering principles by defining the objects first and the relationships second. Adhere to Agile by refining these iteratively. Once objects and their relationships have been defined and refined, we can then generate dynamic content such as reports and lists of most recent content based on these solidly engineered "appliances".
For example, suppose we had a requirement for some blog functionality and some user functionality. If we adhere to strong software engineering principles, we will first independently define the blog object and the user object. Applying Agile we will iteratively refine these objects by adding fields as identified by the customer until we see the necessity for a relationship between the two. During the first iteration we build an object to create and hold blog content such as Title and Body. We also build an object to hold Username and Password. We deliver that to the customer where upon seeing it, realizes that he wants to display the blog's author and date posted. During the second iteration we add the Date Posted field to the blog; we add First Name and Last Name to the user; we relate the blog to the user that created it; and deliver the new refined functionality to the user and so on. It is only when we are finished defining the blog entity, the user entity and their relationship that we can confidently create a list of blogs or a list of users that can be sorted and filtered by the very fields and relationships that define them.
Sprint 3: (House)
Planning: We sit down with the customer and discuss the next level of details which is more decorative in nature. What color scheme do they want? What kind of look and feel? Contemporary? Traditional?
Requirements: We can provide paint and fabric swatches.
Delivery: We can paint the walls, hang up pictures, add crown molding etc. The customer can even start to move in.
Sprint 3: (Software)
Planning: We sit down with the customer and discuss the next level of details which is more decorative in nature. What color scheme do they want? What kind of buttons? What kind of look and feel and theme.
Requirements: We can provide the customer a full color mockup with suggested fonts, designed buttons, icons, and images.
Delivery: The colors, theme and fonts can be added. Initial content can be added.
The customer can move in!!
There are several things to note here. As the "expert" it is the builder's job to tease out the big picture requirements from the customer first. It behooves us to educate the customer as to why we work from high level requirements down to more detailed requirements. The customer will clearly see the benefit of not having to rip out walls and code in the spirit of saving, time. money, and effort. Because they are vested in the outcome, customers are motivated to understand and stay engaged in the process. Educating the user on the process also helps to set up expectations. They shouldn't expect to see paint on the walls, fonts or colors until the last phases of the project. They shouldn't expect to have a full fledged functioning kitchen on the second floor in the first phase. They should expect to be able to navigate though the site early on. They can then expect to have running water, electricity, and basic functionality. They can then expect to have refrigerators, sinks, content holders, and more detailed functionality. Lastly they can expect to see it all come together quickly at the end as walls are painted and the final flourishing touches added.
I felt compelled to write this because of my frustration in the industry in failing to implement Agile wisely. It's a loss for everyone involved. I hope that you will spread this message and turn the tide around. Agile can be great, if done right; a nightmare if not. Thanks for reading."