Are Agile Principles More Important Than the Practices?

I’ve been in IT for 25 years and was introduced to the Agile mindset in 2006.  I embraced Agile immediately because many of its principles were how I already worked.  I like simplicity, I developed software in iterations so 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.

Fast forward to just a few years ago, when a company brought me in to help them on their Agile journey.  Day one, the IT Director told me that they were “already very 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 began digging into how they interact with each other, I saw 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 great, but underneath was a huge mess.  They were doing the easy parts of Agile – the Scrum practices – but weren’t paying attention to the harder parts – the Agile principles.  I’ve learned that prioritizing practices over principles is one of the key reasons for Agile failure.

You can implement Scrum practices perfectly and still fail at Agile.  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.  You may even decide to just go back to your 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?

Communication

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.

Collaboration

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

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.  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.

Retrospection

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.  

Simplicity

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.