Chapter 2: Implementing Agile Principles  The Agile Manifesto came together in Snowbird, Utah. It certainly wasn’t a tech innovation hub or the unlikely town of eager entrepreneurs. It was a vacation town where the leaders of Lightweight – what would eventually be- come known as Agile – software development came together in 2001 to write the Agile Manifesto. The Manifesto itself reads as a type of Declaration of Independence. The Manifesto itself has a short opening about the intent of software developers around the world, four core values, and the signatures of the leaders who came together. However, the Manifesto is not complete without the 12 principles of Agile Software Development. These twelve principles were put together at the same meeting and have guided software development since 2001. The principles and values feed into one another and lend themselves towards creating a productive and suc- cessful team. However, it’s up to the team and project manager/champion to understand how to implement these principles. Within chapter two, you will get the opportunity to dive into each principle and learn how to imple- ment it within an Agile Team.  Principle One: Highest Priority is to Satisfy the Customer through Early and Continuous Delivery of Valuable Software  One of the most commonly misunderstood principles is the very first one. The first principle of Agile Software Development is to place the highest priority on customer satisfaction and to execute that priority early and through ongoing software delivery. Unlike other teams such as research and development, or manufacturing teams, it is possible to deliver software in chunks. Agile teams will often deliver software in functional segments. That means that as soon as the software is func- tioning, it goes through a release. Then when an additional function or feature is available, it undergoes another release. This continues for the life of the product. Even when all features are available and working to the best of the developer’s ability, the product will need updates and patches. For project managers and the team, this can become an overwhelming task to take on. It is very easy for teams to become disheartened, knowing that there isn’t a finish line or an end date for this project. However, it also al- lows the team to better focus on quality and value because they aren’t rushing to meet one deadline that deter- mines success or failure. Application within the Team This first principle is what largely allows Agile teams to be self-organizing. What the champion or project man- ager should go through with the team is the expectations, functions, and current demands of the software. It is largely up to the team to determine when segments will be available for release, which is most important to work on first, and how they will arrange for software delivery. Between the team and the project manager or the champion, there will be constant face-to-face communi- cation specifically relating to releases and the delivery of the software. These are sometimes called standups or Kanban meetings. Impact on Team and Project Managers Leaders are put into an uncomfortable position with principle one because they have to learn to accept that they will receive many small pieces that will eventually make a completed system. You will need to work to under- stand that a single release may only address a particular task or one function within the software. To accommodate this, you’ll need to ensure that face-to-face communication is both consistent and easy. It was mentioned earlier that there are daily meetings such as stand up meetings, but there are other forms of communi- cation that can help the project managers or the team managers understand the flow of development and progress. Everything relating to principle one is about communication and strategy. In addition to the ongoing com- munication efforts, you’ll need to create a big picture strategy that closely looks at the problems the software needs to address. Additionally, you’ll need to dive into the expected outcomes. Work with your team closely to identify the core functions of the project. Again the plan should be brief and simple to align with Agile core values. It is a lot to ask. But to summarize: To best satisfy the customer and provide early and continuous delivery of valuable software, the team and champions must work together to have a plan and strategy which addresses the customer’s needs and the team’s expected outcomes.  Principle Two: Welcome Changing Requirements, Even Late in Development. Agile Processes Harness Change for the Customer’s Competitive Advantage Principle two is a little more straightforward than principle one because it largely has to do with change. This is one of the few principles that lends itself more to the customers, i.e., the business and the end-user, than the team itself. Agile teams must accept changed requirements even very late into the development stages. Again for many team members, this can lower morale and seem as though the project will never be done. It is part of the champion or project managers roll to ensure that even when changes come late into the game, the focus stays on creating a valuable product rather than closing out the project. Often when people reference this principle, they are looking at the secondary portion, the segment of the prin- ciple which reads that the team should grab hold of changes to give the customer a competitive advantage. Within Agile, one of the customers is the business, and if you can give the business a competitive advantage, then it is more likely that more people will use the software. Often when you come across software that users simply hate, it’s because the team was unwilling to make changes or adapt to accommodate the end-user. Those problems can be avoided when the team understands that giving the business a competitive advantage is also an advantage for the software. Application within the Team Agile teams must have a well-developed sense of change acceptance. Prior to Agile, the only philosophy guid- ing software development was the waterfall method, which explicitly resisted change. But in order to adapt to change easily and to make accepting change less of a struggle, Agile Teams need to avoid getting stuck in red tape. The change should also be able to come from the team. The team should feel confident enough to approach managers with ideas that could produce a higher value product. Impact on Team and Project Management Management and champions can have a substantial impact on how the team feels about change. Approach the team when you understand that a change is necessary for the business to have a competitive advantage or for the software to avoid being outdated by the time it gets released. However, don’t approach the team with every pos- sible change that the business might consider. Managers or champions should be dedicated to a change before approaching the team. They should also take into consideration the team’s input and insight regarding that specific change. Principle Three: Deliver Working Software Frequently with Preference to a Shorter Timescale The third Agile principle really only relates to frequent or consistent delivery. This is where Agile Teams need to define delivery, working software, and frequently means to them. Work with your team because it is possible that your team could produce weekly deliveries, whereas other teams may need months to make a delivery.  Principle Four: Businesspeople and Developers Must Work Together Daily through the Project  Communication is such an integral part of Agile Teams. The primary goal of this principle is to establish that the coding team and the business people involved in the project can’t be wildly divided. The team must interact with stakeholders, stakeholders must interact with champions, and champions and stakeholders must interact with the team. While each person is responsible for their contribution to open communication, they are also responsible for keeping other people involved in the communication process. Application within the Team The team will have many meetings and should work within close proximity to each other so that whenever dis- cussions are had, all the team members are privy to the information. Additionally, the team will need to participate in daily standups or Kanban meetings. The team will also need to meet with all the businesspersons involved during reflecting meetings. Impact on Team and Project Management You may need to adopt the most flexible and understanding open door policy you’ve ever experienced in your professional career. You may also need to move your desk or physically work nearer the coding team to ensure that they have access to one of the businesspersons involved in the project at all times. If you’re the Scrum Master or the leader of the coding team, then you’ll need to ensure that you have a direct line of communication with the champion or stakeholders involved in the project.  Principle Five: Build Projects through Motivated Individuals Give Them the Environment and Support Needed. Trust Them to Get the Job Done. This is the principle where the Agile Team really puts their needs back on the project or team manager. It is going to be your responsibility not just to motivate the team but trusting them. That means you may need to drop micromanaging habits and questions such as, “Are you sure?” The team will need an environment and a lot of support from all of the leaders involved either on the business end or on the coding end. It also means that the company needs to be understanding about the degree of chal- lenge involved in software development. “Riding” an employee, especially a coder, will only result in frustration and a much lower quality product.  Principle Six: Face-to-Face Conversation is the Most Efficient and Effective Method of Conveying Information  Principle six is a particular problem for modern Agile Teams. Even back in 2001, teams were more likely to fall back on email and memos, which are ineffective for communication and conveying information. Now with project management systems such as Asana, Trello, Monday, and chat features in almost every project manage- ment tool, it is even more difficult to promote face-to-face conversation. Application within the Team The most common way that Agile Teams ensure they communicate face to face more than through alternative communication is to sit in close proximity. Take down the cubicle dummy walls and allow your team to sit in a col- lective desk. Or allow them to have their spaces but keep the air in the room open. Don’t put up walls, don’t sepa- rate the team. The purpose of keeping your team in an open space and working in such close proximity is convenience. You want to make it more convenient to turn in your chair and say something to a team member than it is to type a quick chat or text. Impact on Team and Project Management Throughout this book, you’ll see the mention of stand up meetings, Kanban meetings, and reflection meet- ings. These are critical, and some of these meetings will need to happen daily. If team and project managers don’t take the time in their schedule for these meetings, then they may be the primary problem in any issue or chal- lenge that the project experiences.  Principle Seven: Working Software is the Primary Measure of Progress  It should go without saying that working software is the measure of progress, but it doesn’t. In fact, principle seven is often overlooked and has led to some of the biggest technological disappointments and failures within re- cent history. Common examples of teams that have ignored principle 7 include the initial iTunes to Windows Operating System release and Windows ME. Windows ME is a typical favorite for people exploring this principle because, by and large, it didn’t work. Copying a file from one location to another could take minutes or hours. That’s not diving into the bugs and glitches that plagued the system. Application within the Team This is one area where teams must stand up to process owners, champions, and businesspersons involved in the project. If the software doesn’t work, then it’s not ready for release. However, teams may suggest released beta versions, knowing that there are bugs or glitches, in an effort to rely on user activity to reveal root problems. Impact on Team and Project Management Managers must be very careful not to push a team to release a product that will only result in disappointment or frustration. If a software doesn’t work correctly, it may be as simple as an extra space or inverted number se- quence. But the act of going through the coding to identify and then correct the area is not so simple. Teams need time, and trust, from their managers to ensure that software works properly. Additionally, managers should give some consideration to the functionality of the software as progress. From day to day, a feature or segment of the software becoming more functional is an outstanding sign of success.  Principle Eight: Agile Processes Promote Sustainable Development. The Sponsors, Developers and Users Should be Able to Maintain a Constant Pace Indefinitely An Agile project certainly isn’t a marathon, but instead is a series of sprints. The term “sprints” applies to the iterations or the short runs that the team works within. However, sprints don’t inherently set a constant pace. It’s left to the project leaders to establish the pace, and it is up to the team to maintain that pace indefinitely. Everyone involved must be able to work at the same pace, which can be extremely difficult to manage. Application within the Team When something seems to be taking too long, give the team the reins. Allow the team to conduct a root cause analysis to identify where you’re working harder rather than working smarter. Your team should have enough trust from leadership to evaluate productivity and challenge the status quo. But, your team might be facing a natural ebb and flow when it comes to changes in pace. Give your team ac- cess to all the resources necessary to execute with peak performance during peak hours or seasons for your busi- ness. Then, ensure that they put their effort into pushing forward during the slower times as well. Even though it seems that coding teams are largely segmented from the rest of the business, they feel the same intensity and lulls as everyone else. Impact on Team and Project Management Having your team work longer or harder isn’t the answer. A pace must be sustainable, maintainable, and nat- ural. While you may certainly need to intervene and address times when there are distractions, most of the time, you should allow the team to control pacing. Your role in team or project management when working with an Agile Team will likely include removing unnecessary processes and obstacles. For example, if a manager wants to approve all changes in the development plan as they arise, your role might be to convince them that it would hurt the team and severely impact the project in a negative way. However, you might also compromise and invite them into some of the sit-down meetings to see the changes in the plan firsthand.  Principle Nine: Continuous Attention to Technical Excellence and Good Design Enhances Agility  For many people, principle 9 is the core of confusion with Agile Development Techniques. After all, the remain- ing 11 principles refer to guidelines to get software out quickly as long as it’s working. In fact, the general belief around Agile is that it’s the quick and dirty software development method. However, this principle is the one that brings the teams involved back to quality, because doing software development with the “quick and dirty” ap- proach simply doesn’t work. Application within the Team Agile teams largely focus on automating anything that can be automated and closely monitoring everything else. In fact, if there is anything “low-quality” with a project, the team will likely identify the lack of quality first. This is where trust comes into play. If your team says that something needs improvement, go with it. Impact on Team and Project Management Even the best of Agile Teams need help working in the right direction and challenging the status quo. Within a management capacity, you can ask when there are better alternatives available, and when you can explore addi- tional technology to provide more valuable results. The best place to start with this principle is to by getting proven frameworks into place and building a team of individuals who value high-quality work.  Principle Ten: Simplicity – the Art of Maximizing the Amount of Work Not Done Is Essential  Linus Torvalds, the creator of Linux, the open-source operating system, once delivered this prolific statement. He said, “Avoiding complexity reduces bugs. ” He is right, and the Agile Leaders who wrote the Manifesto already understood this concept. When you build a project around simplicity, you largely reduce the likelihood of error. Application within the Team Simplicity isn’t the only aspect of this principle. In fact, the larger portion of the principle is a focus on maxi- mizing the work that is not done. The team may need to extensively discuss this when it comes to determining which processes or steps to skips. What’s worse is that leadership will often see this as cutting corners, but ulti- mately it can produce a high-quality product. With every team, there is a learning process. The team members must collectively assess and identify what is and is not necessary for the project. Additionally, some members may champion or campaign for certain ele- ments, or features that aren’t necessary and simplifying the project, and not including those features could cause tension within the team. This rule demands that everyone keep their focus on the quality of the product, not sim- ply what they desire as part of the outcome. Impact on Team and Project Management Automation, systems, and habit will help to engage this principle within your team. Whenever you have to question why something is taking so long, or why there is a multitude of errors, don’t ask what went wrong, or why things are going slow. Ask the team these questions: ● Is there something we can automate? ● Is a lack of systematic handling leading to inconsistencies, bugs, and other problems? ● Do we need to make ‘x’ a habit? Asking these questions will help you cultivate trust, and keep the team largely self-lead. It gives them the opportunity to take charge of any problems when simplicity is clearly the answer. However, leaders should also watch their behavior to ensure they’re not adding in unnecessary rules or steps that could overcomplicate a project.  Principle Eleven: The Best Architectures, Requirements and Designs Emerge from Self-Organizing Teams  By design, self-organizing teams can easily overtake alternative teams in both productivity and quality of output. When teams are allowed to self-organize and propel themselves toward success, they can take greater ownership over the product and generally manage their responsibility with greater prowess. Managers need to understand that it is important to take a step back without becoming uninvolved. Allow teams to distribute work, to collaborate, and exchange ideas.  Principle Twelve: At Regular Intervals, the Team Reflects on How to Become More Effective, Then Tunes and Adjusts Behavior Accordingly  This final principle sets the stage for the remainder of this book. Reflection is one of the critical elements in regu- larly meeting, adjusting, and fine-tuning. The team and leadership will all experiment, test, and then reflect. There are many times when a change caused more work than necessary or that a revised version of the software was found to be less functional than the prior version. The process of meeting, reflecting, changing, and adjusting is an ongoing circle in nearly every methodology within the Agile umbrella. Retrospectives or Sprint Retrospective meetings will determine what steps the team takes next, and how changes impact the team and the project. However, retrospectives are only part of the reflec- tion process. The lessons learned from one retrospective will come up and help direct the team during the next sprint planning meeting, the sprint review, and may even affect the team during daily standups. For managers and leaders, retrospection, and discussions about becoming more effective can be a challenge. After all, you’re supposed to create a productive and encouraging environment. So, how can you deliver critique and reflection on what was ineffective or inefficient? These meetings are put into place so that everyone can be in- volved in the discussion, and because the team is self-organized, if you offer some critique that doesn’t align with the rest of the group, it may be seen as unfounded. In chapter three, you’ll learn more about the roles in an Agile Team and how team or project management roles impact Agile Projects.