Back in the spring of 2013, I wrote an article about the Agile Manifesto
titled, "What Does the Agile Manifesto Mean
?" That article focused on the four main values.
Following the four values are 12 principles that, when followed properly, lead to better outcomes and better software. This article discusses these principles.
Of course, the devil is in the details, and understanding principles that may seem contradictory, in some cases, doesn't always make them easy to implement. My goal with this article is to shed some light on these principles and provide tangible advice that will help teams deliver better software.
These 12 principles can be divided into three broad categories. We will discuss these categories next and include the associated Agile principles.
Regular delivery of software
Many of the older processes measure progress with detailed plans and Gantt charts. Software that is the true deliverable is one of the last things to be delivered to the customer. In contrast, Agile principles focus on the software, which is the most important thing, being delivered early and often.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Teams work together better when they trust each other. It is common for tension to exist between the customer and the delivery team. When the customer is satisfied by constant delivery of valuable software early rather than later, trust is built.
The term valuable
is important. In Scrum, the customer or product owner decides what is valuable. The product backlog is prioritized and the most valuable features are delivered first.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
It is important to deliver software frequently. Scrum is built around this principle. Under Scrum, features are delivered in sprints of two to four weeks, with a preference toward two weeks.
Working software is the primary measure of progress.
Software not only must be valuable and delivered often, it must be working or done. Scrum requires the features to meet a team-defined Definition of Done. Ideally, this should mean that the feature is potentially shippable.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
As teams build trust and build and deliver software over and over, a constant pace that is sustainable without overtaxing anyone will emerge. This allows the team to work forever -- or until enough value has been added to the product.
An important aspect of this is regular releases of a product. If a team can deliver a shippable product each quarter, for example, it makes conversations with the customer much easier. The team learns that they ship every 12 weeks. When a feature request doesn't fit into the current release, it is only a short wait till the next one.
It is common knowledge that teams need to communicate in order to be successful. Simply saying, "We need to communicate better" is a bit like saying, "To be successful at the stock market, we need to buy low and sell high."
These principles provide some insight into how to communicate.
Business people and developers must work together daily throughout the project.
The whole team needs to be readily available to each other. Scrum uses the daily stand-up meeting as a critical communication mechanism. Here the team reports what was accomplished since the last meeting, what will be accomplished by the next meeting, and whether there are any impediments to completing the features in the sprint.
This meeting exposes issues early so they can be addressed before they become critical.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This principle was authored before geographically separate teams were common. Today, with offshore teams and teams that are divided across the country and the globe, regular face-to-face communication is often not possible.
On-line meetings and instant messaging tools are available that improve communication when teams are separated.
Meetings that include the whole team may be planned so that face-to-face communication is possible. This does add cost to the project, because portions of the team need to travel to a central location for the meeting. This approach is helpful for important meetings like sprint and release planning.
When offshore resources are used, portions of the offshore team may be rotated to the U.S. for a period of time. This allows team members to interact personally and get to know each other. It allows the offshore team to return home with firsthand experience that helps the remote team gain valuable insight. This is often a win-win situation, because offshore team members look forward to an experience in the U.S.
When possible, separate out teams so the individual teams are co-located. For example, it is better to have one whole team in the U.S. and another in India than it is to have the teams split. This allows the individual teams to benefit from face-to-face communication.
It is best to have face-to-face communication, and techniques like this should be used to get as close to this goal as possible. Separated teams do pose a challenge, and a cost, but on large projects, the incremental cost addition is often worth the expense.
The best architectures, requirements, and designs emerge from self-organizing teams.
The team knows the best way to get something done. They are the experts. However, this does not mean the right outcome will happen on its own.
Each individual is at a different place in his or her personal growth and career. The term "servant leader" has emerged in the Agile community and replaced the typical command-and-control project manager.
A servant leader observes how the members of the team operate and interact with each other. He or she asks probing questions and acts as a "flashlight," shining light on areas that individual team members may not notice. It is critical for the servant leader to treat everyone with respect and dignity, even when tensions are high. Conflict among team members is normal and actually a good thing. A servant leader understands this and embraces healthy debate.
Self-organizing teams do not happen automatically. They emerge under the proper guidance and advice of a servant leader.
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
This is an extension of self-organizing teams. There are some important words in this principle.
No one would ever admit to not being motivated
. The servant leader pays attention to the aspirations and goals of the team members and aligns these goals with project needs wherever possible. People perform best when they are doing something they are passionate about.
A good servant leader also shelters the team from outside distractions. In Scrum, a team commits to completing a set of features. Anything that distracts from this is a risk. By being there for the team, the servant leader provides them with the environment
needed for success.
is not automatic but is built over time -- and is easy to lose. The team members must trust each other and be comfortable with conflict. Here are some tips to building trust in a team:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Do what you say. No matter how small the task, if you tell someone you will do something, do it.
Admit when you are wrong. Everyone makes mistakes. When you make a mistake, admit to it and make it right.
Follow up. Follow up on open issues that take some time. This allows people to see that you have not forgotten them.
Scrum uses the retrospective for this purpose. Teams often need help for this activity to be effective.
People may be challenged when it comes to engaging in true self-reflection. This is all part of the Agile journey. Each of the Agile principles are interrelated. The retrospective is the perfect place for the team to reflect and improve. It is up to the ScrumMaster to elicit self-reflection.
Once we have identified areas for improvement, we need to really improve. If teams spend time reflecting and do not improve, they see the retrospection as a waste of time.
It is again up to the ScrumMaster to tactfully remind the team about areas of improvement they agreed to. Some teams hang the points they agreed to up on the wall where the stand-up meetings take place.
If we hope to maximize an Agile approach, we need to design and build excellent software solutions. These principles emphasize these points and allow us to accommodate change. Design excellence is not a once-and-done thing. Like most of Agile, it is a journey that requires vigilance and attention to changing events.
Continuous attention to technical excellence and good design enhances agility.
We need to pay close attention to technical excellence and design as our product evolves. There is a balance between "Building the right thing" and "Building the thing right."
We must also be wary of delivering fragile systems. If we make a few changes and our application falls apart like a house of cards, we are not in a good place.
Extreme Programming and, to some degree, Scrum recommend test-driven development and automated builds as a way to avoid fragile solutions.
When we have a set of proper automated unit tests that are included in some sort of automated build, we see problems every time the build runs. The higher our code coverage is and the closer we get to continuous integration, the better our solution will be. It is all about balance.
Over time, our solution will accumulate technical debt. As we weigh the trade-offs between "building it right" and "building the right thing," this is bound to happen. It is best to include a few technical-debt features along with features that add value in sprints so each sprint is delivering business value.
Simplicity -- the art of maximizing the amount of work not done -- is essential.
Agile is all about doing the right amount of something at any given time, and no more. We should author user stories small enough to get the job done and no more. We should build what we know we need now. We should not build some huge framework we think we may need someday.
It is critical to have a complete and thorough understanding of the software frameworks we use. Code is evil, and we can eliminate quite a bit if we have a good understanding of our chosen frameworks.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
This principle will scare teams who are used to Waterfall projects. At first glance, it seems crazy to welcome change late in the development process.
First, we must be successful at implementing the first two principles in this section. If this is not happening, welcoming change is impossible.
"Late in development" means late in the release of the complete product. Scrum delivers features in short sprints. We do not welcome changes in an in-process sprint. Because we are delivering features in short cycles, change is part of the whole process.
In Scrum, the change is directed by the product owner. It is up to the product owner to understand what the competitive advantage is for each feature in the backlog.