It is best to understand a little history behind the Agile Manifesto to comprehend what the intention of the seventeen authors of the original manifesto was. My link to one of the authors goes back to when I worked at Tektronix in Oregon. It was a great time to be in the software industry. Structured Analysis/Structured Design was the method of choice for most new development. As much organization as that brought to the software development process, people started to realize that software development should be more focused on delivering what people want and need instead of a massive amount of documentation. We were a very young team at the time given the task of developing the next generation of graphics terminal (Tektronix 4112/3/4). Because of all we learned on this project, the team started pushing for an even more interesting project for a stand-alone workstation that featured artificial intelligence (Tektronix 4404). My portion of both projects was to develop the Internal Diagnostics to help the field diagnose any problem that may occur with the hardware. Eventually, even manufacturing adopted my framework. Ward Cunningham was the Principal Engineer at Tektronix for our projects. The first language put on the Artificial Intelligence System was SmallTalk. With the merger of Object-Oriented programming and a desire for a more streamlined development process, Ward Cunningham developed Extreme Programming and eventually founded his own company. He was one of the software architects invited to the meeting in Snowbird, Utah to develop the Agile Manifesto.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Principles behind the Agile Manifesto
Each person who adopts the Principles behind the Agile Manifesto must internalize these principles. My internalization of these principles is:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software – To make a project successful, the customer must love the final product. The best way to do this is to have incremental “done” products that the customer can determine if the project is progressing towards the desired solution. Communication and demonstrable results are the key to completing the product to the customer’s satisfaction.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. – As customers see the results of your incremental implementations, they most likely will want “tweaks.” Changes between Sprints are far less costly than changes of specifications within a Sprint. The customer needs to be satisfied, but the team members need to also be protected from interruptions during each Sprint.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. – Work should be delivered at the end of each Sprint. This is why Sprint planning is so important. Have plans for each Sprint on what can be delivered and presented to the customer at the end of each Sprint.
- Business people and developers must work together daily throughout the project. – Daily meetings should be short and to the point. The Project Owner and the Team Members should be involved in the daily meetings, the Scrum Master runs them. If necessary, representatives of the Stake Holders can also be included. See the list of Scrum Roles for more details of who is involved.
- Build projects around motivated individuals. – Projects always progress better if the customers and the team are enthused about the project.
- Give them the environment and support they need, and trust them to get the job done. – No one likes to be “micro-managed,” so trust the engineers to do what they promised for each sprint. In return, the Scrum Master must provide all the needed tools needed so each team member can complete the promised stories for each Sprint.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. – True.
- Working software is the primary measure of progress. – Each Sprint needs to deliver incremental working software that the customer can see you team’s progress. Testing the code is essential before delivering the application.
- Agile processes promote sustainable development. – The Agile Process removes a great deal of the overhead associated with earlier processes, which frees the engineers to be more productive each week. Many studies show that working more than 45-50 hours per week actually decreases productivity and increases errors. As a team works together, they develop a good sense of how much they can accomplish each Sprint. People need to improve their productivity and take time to “sharpen their saws.” Without burning out, teams can be productive for long periods of time (many Sprints).
- The sponsors, developers, and users should be able to maintain a constant pace indefinitely. – See the answer above.
- Continuous attention to technical excellence and good design enhances agility. – Time has to be set aside for improving each team members techniques and knowledge of what tools are available to help each team member be more productive. One tool is code reviews so each team member can learn from the other members of the team.
- Simplicity–the art of maximizing the amount of work not done–is essential. – Do what is essential to produce an excellent product. Do no more.
- The best architectures, requirements, and designs emerge from self-organizing teams. – Each team member brings tremendous skill to the whole team. Use those skills. With a final goal firmly in place, teams can develop a superb architecture that meets the needs of the customer. All team members must be included from start to finish of each Sprint.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. – At the end of each Sprint it is good to review what went well and what can be improved and how it is to be improved. Reflection is needed to make the team better. The team is collective responsible for the quality of the product, therefore each member must continually improve and help each other team member to improve also.
What Agile is NOT!
“On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto.” – from History: The Agile Manifesto. At Hewlett-Packard, there was quite a bit of enthusiasm for this new “agile” methodology. Unfortunately, there was a tremendous amount of misunderstanding of what the Agile Methodology really was. When I first heard another engineer tell me about the new methodology, the engineer described it as “three or four engineers gathering around a computer and banging out code until it was complete, no more need for design, code reviews, or test.” This sounded more like seat-of-your-pants programming than anything I had done at either Tektronix or Hewlett-Packard. If I had know that Ward Cunningham, and eventually Rebecca and Allen Wirfs-Brock were involved, I know that I would have done a lot more research. This was nothing like what was developed at Tektronix. Good quality code that satisfies the needs of the customer is the key. There still needs to be a long-term and short-term plan, identifying what goes into each Sprint. The plans need to be flexible to meet the customer needs, but there needs to be a known direction to all development. Each Sprint includes planning, analysis, design, coding, testing, documentation, and customer acceptance. Each story is not implemented until all these steps are complete. The statement made about the agile methodology does not meet the criteria set forth by the Agile Manifesto. The purpose of the Agile Methodology is to produce the best possible solution for the customers with the least amount of unneeded requirements being placed on the development team. Enjoy your development.