Share This Page


Share This Page


As stated in my earlier blogs, incorporating principles is the harder part of Agile – things like working through communication issues, distrust and lack of accountability. We often might skip working with the principles because it involves more time and effort than we may want to invest. But it’s almost always the harder things that give us the most benefit. Culture changes and principles – these are the harder parts of Agile.

This week, we’ll look at three more of the more challenging parts of Agile – Transparency, Retrospection and Simplicity.

Transparency is being honest – telling it like it is; it’s sometimes being vulnerable. I once had a leader at a client’s place who asked me to spin the reporting of a project’s status so it would look better to senior leadership. I explained the importance of transparency, which he humbly accepted, and 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.

Agile lifecycle tools like Rally and Version One are great, but for teams and stakeholders to see what’s really going on, they have to take time to go into the tool and find the information in order to see it. In my experience, very few people outside the team take the time to do that regularly. I encourage teams to make projects more visible by putting large Scrum boards and Burn-down charts on the walls and showcasing this information to the world. I learned that leadership really appreciates the visibility this brings to projects. 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-ups. 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. The quieter team members especially need encouragement to speak up. I like to reward those who speak up and raise obstacles in the first few sprints, especially the quieter people, by recognizing them.

Retrospection (inspection and adaption) is one of the harder parts of Agile. 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 continual improvement when you pause to reflect on what’s working or not working, and making a conscious decision to adjust things. Little tweaks here and there can make the difference between success and failure of a project. It is hence vital to conduct Retrospectives after every sprint and actually implement the valuable changes that come from the retrospective. I heard someone say once that “action without reflection leads to burnout, and reflection without action leads to cynicism”.

Finally, Simplicity is one of the harder parts. Agile is very simple – the four values in the Manifesto and 12 Principles. Scrum has three Roles, three Artifacts and four Ceremonies. Everything else out there is someone’s attempt to improve on the Agile philosophy. Some of these 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. There are two keys to effective but simplified Agile documentation. The first is to minimize artifacts to only what’s really needed to get the job done. Documentation still has value, don’t get me wrong – corporate governance still exists and usually requires specific documents, and new software has to be maintained and typically needs support documentation. But, there’s sometimes a tendency to create documents just because “we’ve always done them before”, whether they have value or not, whether they’re ever read or not. Creating those documents uses up valuable sprint time. We need to understand and weigh the true cost of creating each document against the anticipated benefit. The second key to simplify Agile documentation is to minimize the effort to create 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 of the corporate culture and principle-related harder things to get ourselves and our companies to do. And they can make a big difference.

The principles can sometimes just seem like common sense, but common sense is in reality, not very common. We have to make a conscious effort to do the harder parts of Agile, and not just the easier parts – the practices.

So, while Agile and Scrum practices are important, practices alone often lead to Agile failure. Agile principles and changing of software 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 hard parts – and help your team do what they need to do. Teams that keep working on the principles and culture-change hard enough and long enough will become the Agile elite, the few that truly understand Agile, and will unleash the true power that Agile has to offer.


About the Author

Dwight Kingdon
Program Director - Agile CoE

Dwight Kingdon is an Agile Coach at Mindtree. He is a thought leader in Agile methods and best practices, leveraging many years of software development, analysis, project management and leadership experience. Dwight has 25+ years of project management experience leading complex information technology projects, and over nine years of Agile/Scrum experience coaching and leading high profile, mission critical projects.

Other Stories by the Author

Let's Talk About Your Needs

Thank you for your submission. We'll be in touch.