Agile Software development is based on core principles. To make an agile process work, it isn’t just a process change or new tools or techniques. You have to change your thinking and the culture within which you are working. This thinking must change in a few key areas:

• Customer and User Involvement — The customers and users of the system being built need to be intimately involved throughout the process so that their assumptions can be known by the team. It is important for the team to talk directly with the users and customers to truly understand the assumptions being made and, therefore, what needs to be built. Documentation and written words are insufficient ways to communicate complex systems so they are fully understood. Conversation and open communication is required to get a full understanding.
• Team Ownership — The team needs to be truly empowered to own the solution and to take steps to make that solution the best it can be. The team signs up for work they will be doing, as opposed to having it assigned to them. This, coupled with the team’s direct interaction with the customer and potentially the user, creates accountability and thus ownership for the team.
• Decide as Late as Possible — This is a very important change for teams to make. The mentality has traditionally been ingrained in us that everything has to be decided upfront: the more thoroughly requirements and designs are defined and locked in before any development starts, the better! The problem with this is that everything isn’t known upfront and can’t possibly be known in today’s rapidly changing world. Additionally, how many people do you know who know everything they want built, how it should work and how users will use it, all up front? Probably not many, if any. Deciding as late as possible doesn’t mean all decisions are delayed, but key ones are, and should be. For example, if you need to integrate with a third party who hasn’t finished their portion of the work, you can still build all of the code around that interface and leave just the interface until the end. Or better yet, build one function of the third-party integration and completely integrate that to test everything and decide on the other details of the integration later.
• Document Only What Is Needed — Good documentation provides a lot of value. However, systems are often documented for the sake of documentation and to check off a box for some process, not because that documentation provides value. How many detailed requirements or design documents don’t get looked at again after development or, worse, aren’t updated, so they are out of date by the time you’re done with development? Not having any documentation though, is not the answer — that leads to chaos. You need to find the right balance on each project of how much to document and in what way. The best documentation of how a system works is simply an elegant and working system.
• Iterate and Learn — Traditionally, projects involve set gates that must be gone through: define what is needed, design it, build it, test it and finally release it. Experience has shown that small iterations, or sprints as they are called in agile, rather than large batches of work, are critical to success. This involves breaking down a large project into logical parts and completing each part before moving to the next. These sprints are time-boxed so that a set amount of work is done in a defined period of time. This creates predictability since, after a few sprints, it becomes very clear how much work can be done in a sprint, and by knowing the backlog (the total work to be done), the total project timeline can be known. This is a key change in mindset: focusing on smaller sprints that are done, demonstrating what’s done, getting the customer’s evolved understanding of their needs, and learning what the team thinks is important to improve, and then improving for the next sprint, thereby creating a constant cycle of learning and improvement.

This leads to the key change: Just-in-time planning and building. Traditionally, software has been built by defining what needs to be built up front, then estimating it and deciding to move forward or not. The development team then goes off and builds it and months or years later delivers what was specified. This gives the illusion of control to the client – “I can define what I want, find out how much it will cost and then get it.” However, there are many problems with this, which are clearly demonstrated by the disastrous state of software projects that are developed using this model. Among a number of studies “25% of projects fail outright”, “46% of projects egregiously did not meet the real needs… they weren’t used and another 20% required extensive rework” (see: https://www.versionone.com/agile-101/agile-software-development-benefits/).

That doesn’t sound like control. That sounds like a lack of control!

The appearance of control, “clear” baseline scope, schedule, and budget up front, leads to products that don’t deliver the desired value in the desired timeframe.

To get control, ironically, you need to give up control. You need to shorten iterations and adapt quickly to change. You need to stop worrying about having all of the scope perfectly known and trying to manage that ahead of time. You need an Agile process and this means how you currently plan projects needs to change.

For just-in-time planning and building you spend your time on your vision and your immediate roadmap and plan for things to change. You budget clearly and work off of a prioritized backlog of work in a continuous manner. This leads to predictability – you know what can get done in this Sprint and if something changes you only need to wait a single Sprint to change, depending on how you prioritize. You can also set goals for what will get done at a high-level knowing that the details will change and that is ok, it will be worked out in each Sprint as work is done.

Agile is, therefore, much more than a process. It is a framework that requires a mindset shift and a culture change across the entire organization to allow it to thrive. Senior leadership needs to understand and back these changes. It is harder to succeed in agile if senior leaders or customers are demanding requirements be fully documented and a complete schedule be prepared and approved before development can even begin. Most important, your team members need to understand the expectations of them in an agile environment, as these expectations are very different than those that existed in the world of traditional software project development.