Why Agile sometimes doesn’t work and how you can fix it!

“Traditional project management is predicated on the idea that people are idiots and if we don’t tell them what to do, when to do it, and exactly how to do it; they are going to screw it up.” - Dave Prior, Leading Agile. 

During my lean coffee meet-ups at Princeton University, I often hear complaints from meet-up members about how Agile does not work at their company. And, upon further examination, we always find that the principles of Agile are not being adhered to; instead, they follow processes of Scrum (IE. sprints, story points etc.); which in most cases isn’t even followed correctly.  

The values and principles of Agile must be thoroughly understood in order to ensure success and efficiency. This article will discuss the basic principles which are often lacking in companies who are attempting to “Do Agile” or Scrum. 

It will not delve into the four values in the Manifesto; instead, it will cover the twelve principles which stem from these four values and how adhering to them can help increase or achieve agility at your company. 

Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

In Agile, customer satisfaction is to be of upmost priority; otherwise what are we even doing this for? The best way to satisfy a customer, whether it be for an external customer or an internal product, is to deliver the highest amount of value as often as possible. This way the highest return on investment is always delivered. In Agile, EVERYTHING MUST HAVE VALUE.

Why is this sometimes not adhered to? 

Simply put: delivering early takes courage. Often what is delivered is an incomplete version of something bigger and it takes someone who understands the incremental delivery process to evaluate the work properly. 

The customer must be educated on the Agile process and why it works and how it will benefit them. Otherwise the ability to deliver early and often will eventually fail. 

2. Welcome changing requirements; even late in development. Agile processes harness change for the customer's competitive advantage.

One of the greatest things about Agile is being able to adapt quickly and change or stay ahead of the market. Agile loses its purpose if your company has to go through a rigorous change request process that leads to delays.

Avoiding the involvement of difficult bureaucracy, change in Agile should be the result of close collaboration with the customer, while always delivering the highest value. If the company has a difficult change request policy, try to explain to the decision makers the importance of this Agile principle of adapting to the environment.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Frequent delivery means achieving more feedback loops, such as feedback from sprint reviews with stakeholders, to end user feedback. Such feedback can only be received once the software is tested and in a working state. The typical sprint length is two weeks but this can be customized to your needs if you are using Scrum. In Kanban there are no sprints and items can be delivered on a daily basis or even multiple times during the day if the proper testing is configured and automated. 

Aside from Kanban and Scrum, there are many other frameworks in Agile to check out if neither of these work for your company. The key is to deliver early and often. 

4. Business people and developers must work together daily throughout the project.

Building the discipline of working with business stakeholders is the power of Agile. If you are using Scrum, the product owner should have a daily meeting with business stakeholders, even if it’s just for a few minutes. This creates daily feedback both ways and increases transparency across all levels. 

If you are not using Scrum then someone on the team should be interacting with the business side on a daily basis. This could be a Product Manager, Project Manager, or even a Lead Developer. Whatever the situation or framework you are using is, daily interactions should not be disregarded. Learn how to leverage this feedback to create better products and more transparency. 

5. Build projects around motivated individuals. Give them the environmental support they need and trust them to get the job done. 

This is one of the most difficult parts of Agile for many organizations since trust is something that has to be earned through time and effort. One must not only trust that their team will get the job done, but teammates must also learn to trust one another; something that doesn’t happen easily. 

Although money is a motivator, most developers today look to work on exciting projects, accomplish goals they are proud of, and are appreciated for their efforts. No one wants to work 80 hours a week in a negative environment where they are being treated poorly. A healthy work/life balance can make a big difference in individual and team motivation. 

ScrumMasters and Project Managers must remember that in Agile you are a servant leader and not a boss. The people on your team should feel like you trust them to do the work and, in return, the work environment will be greatly improved. 

Here is a great quote from Dave Prior which talks about traditional project management. You can see why this age principle was created:

“Traditional project management is predicated on the idea that people are idiots and if we don’t tell them what to do, when to do it, and exactly how to do it; they are going to screw it up.” - Dave Prior, Leading Agile.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Although this is pretty basic point, it is often not followed in today’s distributed world. With teams all around the globe, it’s impossible for many teams to actually meet face-to-face. 

Here are suggestions to achieve this goal with distributed teams:

• If possible, meet up in person once a quarter or whatever other time frame your company would allow. This will build the team trust and morale and allow people to get to know each other much better.
• Always use video chat on your daily standups, sprint reviews, retrospectives, etc. A phone call or just audio chat won’t cut it. 
• If you can, setup a webcam in both offices that will be on during work hours so both teams feel like they are more connected and easily able to speak with each other whenever needed. 

7. Working software is the primary measure of progress. Agile processes promote sustainable development. 

Simply put: if the software doesn’t work, it doesn’t have value. “Working” doesn’t mean it just works after it’s developed. It means that the software has been fully tested, verified from the business side, and ready for production. If the software isn’t ready for live production, it’s not yet working. This provides proven results and a clear direction of the product. 

The focus should be to achieve this state in regular intervals. This is the way progress is measured in Agile: not by calculating the percentage of how much an item is completed but by actually measuring what already has been done and is working.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Working too many hours in an intense environment is not sustainable. It may work in short bursts but it will lead to more mistakes, burnouts, and an overall toxic environment. If kept up for too long, your team will be unproductive or begin to look for work elsewhere.

As discussed previously, people need a good work/life balance and their personal time needs to be their own. 

9. Continuous attention to technical excellence and good design enhances agility.

Coding itself is an experimental process. It requires more than just language knowledge and theory. It’s a combination of creativity and analytical thinking that needs continuous refinement. Refactoring of code should be done regularly to reduce potential performance issues and technical debt. 

Using a process like Test Driven Development (TDD) in your projects will enhance your ability to achieve this principle. The steps of TDD are test to fail, code, test to pass, refactor, and repeat. This continuing cycle can have significant benefits to the quality of your products and agility.

10. Simplicity—the art of maximizing the amount of work not done--is essential.

Great software is simple and intuitive. This is one of the reasons Apple gained popularity in the 2000’s: the beauty in the simplicity. 

“Everything should be made as simple as possible, but no simpler” - Albert Einstein. 

Doing extra work that adds no value to a product just complicates things and takes away from the main focus. Adding too much documentation that isn’t necessary is also another way of over complicating things.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

The key here is to move away from top down micromanagement and use flat macro management. Lead by example and guide by partnership. The people that make the best decisions about architecture, requirements, and designs are the Development team. They are the ones that understand the product the most. Trust them and they will find solutions to problems more quickly. 

When teams are self-organizing they don’t need to be told what to do. Having a cross functional team is the best way to achieve this self-organization. When one person is busy or not available, someone else will work on the same item without being asked to.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

You may have heard this saying: “Fail early and fail often”. This principle is what that saying is talking about. The importance of failing early instead of late can’t be expressed enough because when you fail late into a project, it can be catastrophic to the project timelines, budget, and overall product. By failing early this gives the opportunity to learn from mistakes quickly and adjust.

By reflecting at regular intervals you can also learn from success. Learning from what is working can sometimes be more effective than learning from what isn’t. 

Lastly, all lessons learned should be shared. The team should not be afraid of failure and sharing ways to improve. The best way to achieve this is to create a culture of trust and self-organization, while staying as far away from the old “boss” mentality. 

Author:

Troy Lightfoot is the head of product development at V Group Digital. www.vgroupdigital.com

Host of the Princeton Lean Coffee meet up: http://bit.ly/29MfXEv 

And Agile tech and more! podcast. http://apple.co/29sceQV

Feel free to connect on LinkedIn: https://www.linkedin.com/in/troylightfoot