Over a million developers have joined DZone.

The Importance of Implementing Agile Principles Over Practices

Dwight Kingdon explains the importance of implementing the Agile principles of communication, collaboration, transparency, retrospection, and simplicity.

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

Image title

Prioritizing practices over principles is one of the key reasons for Agile failure.  I’ve been in the IT industry for 25 years and was introduced to the Agile mindset in 2006. I embraced Agile because it seemed to be a great improvement over traditional frameworks. I think I took to Agile so readily because many of the Agile principles were already part of my Standard Operating Procedure. I valued simplicity, I developed software in iterations so that I could get feedback and make course corrections, I preferred communicating face-to-face, and I put my customers and developers in the same room often so they could collaborate and ensure we were on the right path. 

What I was doing in my early years wasn’t truly Agile, but the principles I followed – many of which are in line with the Agile principles – allowed me to consistently deliver projects on time, on budget, and with the quality that my customers needed.

Several years ago, a company brought me in to work with them on their Agile journey, and a couple of their IT leaders told me that they were already Agile. They had all the right roles in place, their ceremonies seemed to be well run, the artifacts looked clean and up to date – they looked like they had it all together. But when I asked tough questions and began digging into how they interact with each other, I saw a very different picture. There was distrust between IT and the business units which resulted in no real collaboration, almost all their communication was by email for “CYA” purposes, and there was a heavy status reporting burden due to a lack of transparency.

On the surface, it looked like things were running smoothly, but underneath was a terribly broken machine. They were doing all the easy parts of Agile – the practices – but weren’t paying attention to the harder parts of Agile – the principles. Real Agile transformation often requires a total culture change. Successful Agile implementation is about establishing a culture that embraces open communication and collaboration between business and technical people across the enterprise. It’s about continuous improvement through inspection and adaption and a culture of transparency and accountability.

I’ve learned that you can do all the practices perfectly and still fail at Agile. Not paying attention to the principles behind Agile is one of the leading causes of failure. You may see some improvement in your ability to respond to change, and you might even provide working software faster for a while. However, it won’t be long until the benefits of Agile become less evident. Teams will struggle to keep up the pace, software won’t match user expectations as often, and then Agile will be deemed a failure. Some will go back to their old ways – ways that are more comfortable.

Incorporating Agile principles is the harder part of Agile – things like working through communication issues, distrust, and lack of accountability. We often skip working with these principles because it involves more time and effort than we may want to invest. However, it’s almost always the harder things that give us the most benefit.

So what are some of the principles or culture changes that are the harder parts of Agile?


I often see people using the Scrum Master to deliver their messages to others. They are used to working with a project manager, and a Scrum Master is a whole different role. As a Scrum Master working with a brand new Agile team, three different team members once came to me trying to communicate “through” me during our first sprint. One of them said: “Dwight, I need this information from Ramesh before I can start coding.” Ramesh was only 20 feet away from us, but they were accustomed to having a project manager handle their communications.

A key Agile principle is communicating face-to-face whenever possible. Face-to-face communication can be scary when many of us are used to sitting in a cubicle without having to talk to people. When this happened, I walked the team member over to the other person’s desk and had them communicate the message directly. Help your teams get into the habit of communicating face-to-face as their first option instead of as a last resort. Wasted time is not Agile.


Agile is all about people working together, talking together and coming up with great ideas together. We are fundamentally at risk whenever someone works on something alone.  A collaboration issue I sometimes see occurs when a traditional Project Manager becomes a Scrum Master. Project Managers can make great Scrum Masters, but watch out for those who bring a command-and-control style along with them. Agile is not about command and control, but some new Scrum Masters tend to manage and direct instead of collaborating with stakeholders and the team. Great Agile teams are not managed – they’re encouraged to collaborate and figure things out themselves. Often, the lesson is learned better by experience (good or bad) than by being told what to do.

I also see a similar pattern with new product owners, but with the opposite behavior. Many new product owners are used to creating requirements, handing them off to the development team and then sitting back and waiting for the finished product, with little or no further involvement on their part. Continuous collaboration between the product owner and the team, along with timely course correction, helps ensure that what’s delivered at the end of the sprint is just what stakeholders intended.

However, this can be time-consuming for the Product Owner, and many new to the role are either not ready for the commitment or just don’t know that they need to be so involved. I encourage product owners to get involved with the project team regularly throughout the sprint. This way, the Sprint Review becomes more of a formality because the product owner has already seen several iterations of the features during the sprint and has guided the team to build exactly what the stakeholders want.


Transparency is just being honest – telling it like it is and sometimes being vulnerable. I once worked with a VP who asked me to spin the reporting of a project’s status so it would look better to his senior leadership. I explained the importance of transparency, which he humbly accepted. The resulting frankness set a precedent of honesty and openness that continued, no matter what the results were.  We can’t fix things if problems are swept under the rug. In Agile, transparency means bringing issues out in the open where they can be dealt with. Automated Agile lifecycle tools are great, but for teams and stakeholders to see what’s really going on, they have to take the time to go into the tool to see it. In my experience, very few people outside the team take the time to do that regularly.

At least in the beginning of an Agile transformation, I encourage teams to make work more visible by putting large paper Scrum boards and burn-down charts on a wall and showcasing this information to everyone around them.  Leadership really appreciates the visibility this brings to development work. This can also help reduce the need for status reporting since anyone can look at the team wall and see exactly what is going on.  

Another transparency tip I learned stems from the fact that many new Agile team members are reluctant to raise obstacles during stand-up meetings. One of the primary functions of the Scrum Master is to remove obstacles so the team can focus on delivering software.  But if obstacles are not raised, the Scrum Master can’t help remove them. I remind new teams at the beginning of every stand-up meeting to bring up even potential obstacles if there’s any chance something might delay their work or cause them to not live up to their sprint commitment. Quieter team members especially need encouragement to speak up. Reward those who speak up and raise obstacles in the first few sprints, especially the quieter people, by recognizing them in front of the team.


I like to compare retrospection to software documentation. Software documentation is often not done because it’s considered low priority compared to moving on to the next project. In the same way, some Agile teams skip sprint retrospectives because they think they don’t have time or they don’t see the value of doing them. You can only have continuous improvement when you pause to reflect on what’s working or not working and make a conscious decision to adjust things. Little tweaks here and there can be the difference between success and failure. I once read that “action without reflection leads to burnout, and reflection without action leads to cynicism.” It is vital to conduct retrospectives after every sprint and then actually implement the valuable changes that come from it.  


This can be one of the harder parts of Agile. The Agile mindset is very simple – there are four values in the Agile Manifesto and 12 accompanying Agile Principles. Scrum has some roles, artifacts, and ceremonies. Everything else out there is an attempt to improve on the Agile mindset. Some of those ideas are great additions and some just complicate the simple concept of Agile. Software documentation is a great example of how Agile can simplify our projects. Artifacts should be minimized to only what’s really needed to get the job done.

Documentation does have value, don’t get me wrong – governance and compliance documentation are often required, and software has to be maintained using commenting or support documentation. However, there’s often a tendency to create documents just because “we’ve always done them,” whether or not they have value or are ever read. Understand and weigh the true cost of creating each document against the anticipated benefit. Then, minimize the effort to create those artifacts. You can make it look fancy later if that’s really important. If a hand-drawn and scanned diagram is sufficient for the team to move on, that’s a great time saver.

These are a few examples of how Agile principles make a big difference. We have to make a conscious effort to execute the harder parts of Agile – the principles – and not just the easier parts – the practices.

So, while Scrum or Kanban practices are important, practices alone often lead to Agile failure. Agile principles and changing of the development culture are generally the harder parts, but they are what make Agile sustainable in the long run and maximize the great benefits it has to offer.

So what’s the next step? Look at your team, pick one of the principles or areas of culture change needed – one of the harder parts – and help your team do what they need to do. Teams that keep working on the principles and culture-change hard and long enough will become the Agile elite, the few that truly understand Agile, the few that will unleash the true power that Agile development has to offer.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

agile practices,scrum,agile adoption,development,principles,kanban,lean,agile best practices

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}