This post reviews the Twelve Agile Principles
and provides some evaluation, opinions and additional information, from experience, about the Principles. In addition, where applicable, this post ties these Principles back to the relevant industry best practices.
Agile supports a continuous cycle of planning, requirements, design, development, testing and deployment by delivering agreed upon software (i.e., every couple weeks or months) using an incremental approach. Keep in mind prior to the requirements being implemented they should have been approved by the stakeholder(s). Once requirements are approved they should be assigned a release or sprint and completed as outlined in the project plan. In addition, the quality of the software and whether or not it contains the functionality asked for all play a role in the customer’s satisfaction. As I mentioned in an earlier post, you can give the customer quick turn-around times and even software with a savvy user interface. However, if the software doesn't provide the functionality the stakeholder needs; the stakeholder won't be satisfied. Lastly, using a software design that meets industry best practices also ties into customer satisfaction. Here are a few points to keep in mind:
This principle directly ties to the first principle. If a stakeholder voices a need for a requirement change; it is definitely up to the technical team to meet that need. Although, keep in mind, the technical team typically cannot tell the stakeholder whether or not a requested change provides a competitive advantage. And, a stakeholder may not stop to assess whether or not a change provides a competitive advantage. Most often, when a stakeholder wants a change implemented--it's implemented. Interestingly, over the years I have seen requirements change for many reasons. For example, I was hired by a company whose entire technology team told me the stakeholder couldn’t make up his mind. They said the requirements never made it to development. I met and talked with the stakeholder knowing the problem couldn't possibly be as bad as they said. I documented the requirements as he stated. Then I created the requirements document. The stakeholder reviewed the document. He then changed everything we had discussed. We went through about four revisions of the document when I finally decided to try something different. Instead of continually rewriting the documents I decided to create UML (unified modeling language) diagrams, navigational flow diagrams and user interface (UI) mockups for the software product. I showed him the diagrams and the UI mockups. He made his changes on the diagrams and the mockups. I updated the diagrams and showed everything to him again. He approved them. I then used the diagrams and mockups to update the requirements documents. He signed off on the requirements documents and development began. In this situation, the stakeholder was more of a visual learner and the text wasn't giving him the clarity he needed to make a firm decision. Lastly, if requirements are changing it is possible that the Business Analyst will need to generate an impact analysis report. The impact analysis report can then be used to see whether or not dates will need to shift because of the changing requirements.
I supported a project where the Information Technology Department went through the entire cycle and completed a software product. During the walk-through (where the IT team showcased the system features) the IT team was told the software was not what was needed. Millions of dollars were just wasted building something the organization didn't need--all because the requirements were wrong. There is certainly value in implementing a business application using an incremental approach. Keep in mind that the team still performs the planning, requirements, design, development, testing and deployment. However, the team picks a much smaller scope of works for the Business Analyst to work on. Once the BA has completed the smaller scope of work that work is then passed on for design and so on. The BA then starts working on gathering requirements for the next scope of work. A continuous cycle is followed until the project is completed. By focusing on completing smaller scope of requirements, the team completes a smaller scope of work iteratively so the customer is continuously seeing updates to the product. These updates may be every two weeks or more; but should not be more than two months.
Depending on everyone’s workload this Principle may or may not be feasible. At a very large agency where everyone is very busy we met daily for about ten minutes. However, we only did this once development started. Project planning was limited to the people needed to plan the project including the technical team and the product owner. Requirements gathering sessions included the stakeholders and the technical team. The daily ten-minute status meetings were held once development started. The objectives of the daily 10-minute status meetings were to accomplish the following:
a. Understand what issues technical team members were having,
b. Understand what barriers needed to be removed, and
c. Assign action items to those who could fix the stated problems.
Every decision most organizations make is done so with their overall business objectives in mind. For example, an organization has a Time Keeping System that three departments use for billing and cost management. The Time Keeping System supports business objective 3. Manage costs and implement projects within budget. On the other hand, everyone uses the corporate intranet to read the latest news about the company. The corporate intranet meets a lower business objective that aims to keep everyone informed. The organization will approve the Time Keeping System project. To execute this principle, the organization would look for its most highly motivated people. These are the people that always get things done with little or no prompting. They always meet their timelines. These people also initiate solving problems without being asked. If an organization seeks to build its projects around these types of people, the project will most certainly meeting its timelines.
Face-to-face is the best way to communicate because you can "see" if someone is puzzled or doesn’t understand a question. And, I've seen quieter individuals gain motivation to speak up from the more talkative participants. However, if face-to-face is not always feasible (because people live in different parts of the world or schedules are too hectic) meet face-to-face as often as you can. When it isn't feasible to have an in-person meeting there are two other approaches that can be used as follows:
It is a good practice not to get excited when the documents are written or the software is in testing. The real measure of progress is when the working software has been delivered. And, any release notes, training, user documents, etc. agreed upon are also delivered along with the working software. Again, the software should have been developed from stakeholder-approved requirements assigned to the release or sprint.
For those of you who have ever implemented the complete Rational Unified Process (RUP), you probably can appreciate this Principle. Although, for some projects the complete RUP is needed because of the software project and the organization's business. For other software projects the complete RUP may be too much. If this is the case, the organization may implement a customized version of RUP, which I helped many organizations do. Or, the organization may benefit from a different Agile methodology that enables the project team to define and implement small scopes of functionality. If the project does implement an Agile methodology the activities should not be so intense and the scope of work so big that it takes over two weeks (or two months) to complete. Instead, the activities should encourage the team to do exactly what is needed to complete the work accurately and remain within budget, timeframe and scope. This approach should enable the team to consistently complete a scope of work within the given timeframe. And, the team should always be able to deliver quality work because the work processes have been simplified as much as possible.
A poorly designed software product is more difficult and costly to maintain than a software product with a good design. One of the most popular features of a good software design is reuse. Software reuse enables teams to accomplish more in a shorter period of time because code is reused. However, to reuse code takes planning from an organizational stand point. This is because code must be designed and developed properly for it to be reused. Many organizations are turning to using web services because developers can easily discover and reuse components. And, a web service can be shared across any platform. A second popular feature of good software design is usability. Microsoft says a software product has a good design if it is both simple and powerful. The article titled Power and Simple says an application is perfectly designed when there is the right balance of features and all unnecessary elements have been removed.(Microsoft's Simple and Powerful software design article can be accessed from the following link: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511332.aspx)
This Principle speaks for itself. Basically, use the simplest and most efficient way to complete the work that remains (after all, there is nothing you can do about work already completed). Most organizations looking to shorten the work cycle will most likely find a more practical way to perform project planning and requirements management (looking at ways to efficiently and effectively manage requirements without writing lengthy documents). Most organizations do not want to cut development or testing because of the inevitable consequences. Deployment is usually straight forward, if it pertains to a web application. Notifications are sent to the end users; the web application files are uploaded to the web server; and, the database is updated.
The self-organizing team concept empowers people to do their jobs and make decisions about how they do their job. If you are a Business Analyst, for example, and the project manager is telling you how to gather requirements and manage them you are not part of a self-organizing team. The following link provides a great article on self-organizing teams: http://scrumalliance.org/articles/466-selforganizing-teams-what-and-how
Ongoing self-improvement really should be every team member’s goal to become the best at what they do. A very effective concept used to help IT teams improve is called Lessons Learned. Through Lessons Learned sessions the team looks at its processes including what it did well and what it did not do well. The team also looks at areas in which it could have performed better. In addition, the team determines if the product met the stated requirements and if not, why not. And, the team assesses whether or not the customer was happy with the delivered product and if not, why not. These are just a few of the areas reviewed during a Lessons Learned session. Following is a useful link outlining best practices for Lessons Learned: Https://confluence.cornell.edu/display/CITPMO/Facilitation+of+Lessons+Learned+Discussions
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile supports a continuous cycle of planning, requirements, design, development, testing and deployment by delivering agreed upon software (i.e., every couple weeks or months) using an incremental approach. Keep in mind prior to the requirements being implemented they should have been approved by the stakeholder(s). Once requirements are approved they should be assigned a release or sprint and completed as outlined in the project plan. In addition, the quality of the software and whether or not it contains the functionality asked for all play a role in the customer’s satisfaction. As I mentioned in an earlier post, you can give the customer quick turn-around times and even software with a savvy user interface. However, if the software doesn't provide the functionality the stakeholder needs; the stakeholder won't be satisfied. Lastly, using a software design that meets industry best practices also ties into customer satisfaction. Here are a few points to keep in mind:
- Add requirements to a tool that enables the Business Analyst (or Systems Analyst) to indicate whether a requirement is approved or not approved. User stories can and should be traced just like use cases so they are grouped by feature.
- For software to satisfy the customer it must be sufficiently tested. Testing should verify that the requirements are implemented as stated. And, testing should also verify that the software product works. In other words, does the software have defects that will make users complain and cause the primary stakeholders to, ultimately, be unhappy?
- The software design must be scalable and maintainable. This aspect of software is so important. I supported a project once where the software design for the reporting component of a business application was far more complicated than it should have been. Instead of using Crystal Reports or other similar reporting software the vendor wrote lines and lines of code that took months to complete. Needless to say, it was very difficult for the customer to maintain and update the software, which made the customer very dissatisfied.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
This principle directly ties to the first principle. If a stakeholder voices a need for a requirement change; it is definitely up to the technical team to meet that need. Although, keep in mind, the technical team typically cannot tell the stakeholder whether or not a requested change provides a competitive advantage. And, a stakeholder may not stop to assess whether or not a change provides a competitive advantage. Most often, when a stakeholder wants a change implemented--it's implemented. Interestingly, over the years I have seen requirements change for many reasons. For example, I was hired by a company whose entire technology team told me the stakeholder couldn’t make up his mind. They said the requirements never made it to development. I met and talked with the stakeholder knowing the problem couldn't possibly be as bad as they said. I documented the requirements as he stated. Then I created the requirements document. The stakeholder reviewed the document. He then changed everything we had discussed. We went through about four revisions of the document when I finally decided to try something different. Instead of continually rewriting the documents I decided to create UML (unified modeling language) diagrams, navigational flow diagrams and user interface (UI) mockups for the software product. I showed him the diagrams and the UI mockups. He made his changes on the diagrams and the mockups. I updated the diagrams and showed everything to him again. He approved them. I then used the diagrams and mockups to update the requirements documents. He signed off on the requirements documents and development began. In this situation, the stakeholder was more of a visual learner and the text wasn't giving him the clarity he needed to make a firm decision. Lastly, if requirements are changing it is possible that the Business Analyst will need to generate an impact analysis report. The impact analysis report can then be used to see whether or not dates will need to shift because of the changing requirements.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
I supported a project where the Information Technology Department went through the entire cycle and completed a software product. During the walk-through (where the IT team showcased the system features) the IT team was told the software was not what was needed. Millions of dollars were just wasted building something the organization didn't need--all because the requirements were wrong. There is certainly value in implementing a business application using an incremental approach. Keep in mind that the team still performs the planning, requirements, design, development, testing and deployment. However, the team picks a much smaller scope of works for the Business Analyst to work on. Once the BA has completed the smaller scope of work that work is then passed on for design and so on. The BA then starts working on gathering requirements for the next scope of work. A continuous cycle is followed until the project is completed. By focusing on completing smaller scope of requirements, the team completes a smaller scope of work iteratively so the customer is continuously seeing updates to the product. These updates may be every two weeks or more; but should not be more than two months.
4. Business people and developers must work together daily throughout the project.
Depending on everyone’s workload this Principle may or may not be feasible. At a very large agency where everyone is very busy we met daily for about ten minutes. However, we only did this once development started. Project planning was limited to the people needed to plan the project including the technical team and the product owner. Requirements gathering sessions included the stakeholders and the technical team. The daily ten-minute status meetings were held once development started. The objectives of the daily 10-minute status meetings were to accomplish the following:
a. Understand what issues technical team members were having,
b. Understand what barriers needed to be removed, and
c. Assign action items to those who could fix the stated problems.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Every decision most organizations make is done so with their overall business objectives in mind. For example, an organization has a Time Keeping System that three departments use for billing and cost management. The Time Keeping System supports business objective 3. Manage costs and implement projects within budget. On the other hand, everyone uses the corporate intranet to read the latest news about the company. The corporate intranet meets a lower business objective that aims to keep everyone informed. The organization will approve the Time Keeping System project. To execute this principle, the organization would look for its most highly motivated people. These are the people that always get things done with little or no prompting. They always meet their timelines. These people also initiate solving problems without being asked. If an organization seeks to build its projects around these types of people, the project will most certainly meeting its timelines.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Face-to-face is the best way to communicate because you can "see" if someone is puzzled or doesn’t understand a question. And, I've seen quieter individuals gain motivation to speak up from the more talkative participants. However, if face-to-face is not always feasible (because people live in different parts of the world or schedules are too hectic) meet face-to-face as often as you can. When it isn't feasible to have an in-person meeting there are two other approaches that can be used as follows:
- Microsoft Office Lync supports video conferencing, desktop sharing and chatting.
- Microsoft Office SharePoint 2013 includes an updated My Site component that delivers a much stronger collaboration experience to help teams work more closely together regardless of location or schedule. Microsoft Office 365 offers SharePoint Online, which can be less costly to implement than the non-cloud version of SharePoint.
7. Working software is the primary measure of progress.
It is a good practice not to get excited when the documents are written or the software is in testing. The real measure of progress is when the working software has been delivered. And, any release notes, training, user documents, etc. agreed upon are also delivered along with the working software. Again, the software should have been developed from stakeholder-approved requirements assigned to the release or sprint.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
For those of you who have ever implemented the complete Rational Unified Process (RUP), you probably can appreciate this Principle. Although, for some projects the complete RUP is needed because of the software project and the organization's business. For other software projects the complete RUP may be too much. If this is the case, the organization may implement a customized version of RUP, which I helped many organizations do. Or, the organization may benefit from a different Agile methodology that enables the project team to define and implement small scopes of functionality. If the project does implement an Agile methodology the activities should not be so intense and the scope of work so big that it takes over two weeks (or two months) to complete. Instead, the activities should encourage the team to do exactly what is needed to complete the work accurately and remain within budget, timeframe and scope. This approach should enable the team to consistently complete a scope of work within the given timeframe. And, the team should always be able to deliver quality work because the work processes have been simplified as much as possible.
9. Continuous attention to technical excellence and good design enhances agility.
A poorly designed software product is more difficult and costly to maintain than a software product with a good design. One of the most popular features of a good software design is reuse. Software reuse enables teams to accomplish more in a shorter period of time because code is reused. However, to reuse code takes planning from an organizational stand point. This is because code must be designed and developed properly for it to be reused. Many organizations are turning to using web services because developers can easily discover and reuse components. And, a web service can be shared across any platform. A second popular feature of good software design is usability. Microsoft says a software product has a good design if it is both simple and powerful. The article titled Power and Simple says an application is perfectly designed when there is the right balance of features and all unnecessary elements have been removed.(Microsoft's Simple and Powerful software design article can be accessed from the following link: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511332.aspx)
10. Simplicity--the art of maximizing the amount of
work not done--is essential.
This Principle speaks for itself. Basically, use the simplest and most efficient way to complete the work that remains (after all, there is nothing you can do about work already completed). Most organizations looking to shorten the work cycle will most likely find a more practical way to perform project planning and requirements management (looking at ways to efficiently and effectively manage requirements without writing lengthy documents). Most organizations do not want to cut development or testing because of the inevitable consequences. Deployment is usually straight forward, if it pertains to a web application. Notifications are sent to the end users; the web application files are uploaded to the web server; and, the database is updated.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
The self-organizing team concept empowers people to do their jobs and make decisions about how they do their job. If you are a Business Analyst, for example, and the project manager is telling you how to gather requirements and manage them you are not part of a self-organizing team. The following link provides a great article on self-organizing teams: http://scrumalliance.org/articles/466-selforganizing-teams-what-and-how
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Ongoing self-improvement really should be every team member’s goal to become the best at what they do. A very effective concept used to help IT teams improve is called Lessons Learned. Through Lessons Learned sessions the team looks at its processes including what it did well and what it did not do well. The team also looks at areas in which it could have performed better. In addition, the team determines if the product met the stated requirements and if not, why not. And, the team assesses whether or not the customer was happy with the delivered product and if not, why not. These are just a few of the areas reviewed during a Lessons Learned session. Following is a useful link outlining best practices for Lessons Learned: Https://confluence.cornell.edu/display/CITPMO/Facilitation+of+Lessons+Learned+Discussions
