Machiavelli on Agile
By Carl M. Manello
Benefits should be conferred gradually; and in that way they will taste better. – Niccolò Machiavelli, Italian diplomat, historian, and political theorist (1469-1527)
While Agile has grown in acceptance over the last decade, and is currently the fad of effective delivery in today’s development arena, a company taking on this change might consider moving slowly. By leveraging an incremental approach, a company may realize a large stream of benefits from Agile. In the real world where companies have legacy methodologies, people with entrenched habits, and an aversion to change, implementing Agile methods can be challenging–thus necessitating the incremental approach. In many cases, new methods need to be tailored in such a way as to fit the company’s situation without diminishing the value and essence of the Agile approach.
We have helped a number of companies assess their readiness and to make the move to Agile. Here are some of the bigger challenges we see in making that move:
The product owner is “the voice of the customer,” the evangelist, and the decision maker for the project. It is critical to have the right person in the role to sponsor the effort within the organization and provide the balance of skills between the business and technical requirements of the project. To effectively guide the work of the development team, the product owner needs to be willing and able to commit the time to provide clear direction on priorities and requirements.
Projects (or on-going application maintenance efforts) that have multiple product owners introduce additional organizational complexity that can limit the effectiveness of Agile methods. Multiple owners blur the clear roles and responsibilities that Agile methods advocate. If there are multiple product owners, then a formal steering committee and prioritization process needs to be established to create release goals and to provide the development team with the requirements to include in the next development cycle. In a case where a team supports an application that crosses many areas, each that wants its own requirements addressed first, an organization should consider using Kanban. Kanban is a scheduling system that helps determine what to produce, when to produce it, and how much to produce. Development teams can use this approach to support flowing requirements through the organization in order to reduce the need for a dedicated, single voice of the customer.
“Do Agile Now!”
Agile is an approach that requires a new set of behaviors across an organization, from corporate management and project sponsors, down to the development team. Most organizations have an established “way that things get done.” Agile will change the project processes, the roles and responsibilities, and will change how work throughput is measured and assessed. While some companies want to move to Agile immediately, there is concern about creating Agile teams and launching projects without planning for the change, missing the opportunity for clearly establishing internal sponsorship, or short selling the training of participants.
In a situation where a company urgently wants to move to Agile methods it’s important to remember the sage wisdom of Machiavelli:
“And it ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things.” –The Prince, Chapter 4
Make no mistake. Adopting Agile is a ‘new order of things’ for a company and it will require a focus on organizational change management. Without addressing the organizational and process changes needed to move to Agile, an organization prematurely puts its overall effectiveness at risk and may kill the transition all together. If a company wants to start their transition to Agile quickly, they should identify a pilot project and build a team around that effort to both limit the necessary investment and the increase the likelihood of success. Simple, incremental, value add.
Development Team Skills
Agile development methods are a significant change from waterfall methodologies. Agile focuses on the ability to rapidly develop components of a solution with quality and to adapt dynamically to new business requirements. This approach requires a highly skilled and experienced development team. By role, responsibility, skill level, and team interaction, the work is very different than a traditional waterfall project where requirements and the development process proceed more slowly and needs are progressively elaborated. On an Agile project, the development yeam will need to be able to quickly work with the product owner to identify the type of solution to address the business need. They do not need to create the solution immediately, but they must understand what needs to be done and roughly how long it will take. This forward-looking ability requires experience in software development and an understanding of the type of business problem that is in scope.
Ideally, a development team will be selected for the project based on their skills and experience with the problem being solved. Often times this doesn’t happen and an un-optimized team is built. Therefore, in the less-than-ideal world, there are two ways to address a development team that is under-skilled for the project:
- Supplement the team with one or two experienced software architects who can guide and mentor the team members; or
Set the expectations with the project sponsor on the throughput of the team and plan for time in the development cycle for additional analysis and refactoring.
With either option, the key step is to assess the team before the project starts and take the appropriate actions to put the team in a position to succeed.
Commitment is the key prerequisite that should be defined, discussed, and understood by everyone. Agile requires a high-level of commitment by everyone participating in the process since it exposes gaps, inefficiencies, and weaknesses very quickly. If a company cannot dedicate resources, rapidly prioritize and elaborate requirements, define estimates, produce product, and is comfortable exposing their status and results, then they could have problems adopting Agile approaches. Everyone needs to be committed to the new way of working together. This means everyone must know their role and responsibilities, be able to execute at the necessary tempo, and be willing to expose both successes and failures. In some companies, politics or historical practices can make this new way of doing business difficult.
Borrowing from Machiavelli again, “He who neglects what is done for what ought to be done, sooner effects his ruin than his preservation.” To best avoid ruin, a company should tread lightly into Agile. Assessing a company’s readiness for Agile methods is ideally the first step taken. It’s much less expensive–and more effective–to define what needs to be done, assess the organization’s readiness, and then adapt a launch plan.
Conversely, if a company tries to fully transition to Agile all at once and fails, they risk losing long term support for Agile approaches. If you find your company isn’t ready to fully embrace Agile, then it’s wise to start with a pilot project with the right team of experienced and interested business and technical people. Success with the pilot project should lead to support for delivering additional projects using Agile approaches, and generate interest (and excitement!) in the company.
Carl Manello is a Solution Lead for Slalom‘s Program & Project Management practice based in Chicago who enjoys exploring how to tightly couple the art and science of project delivery with business operations. You can read from Carl on his blog.