I will be one of the first people to admit that I have a limited exposure to agile methodologies, including Scrum, as I feel I have so much more to learn and experience.  Since we started implementing Scrum a few years ago, and some other agile practices such as Continuous Integration and Test Driven Development, I have become more and more passionate around “agile”.  It just seems to make sense.

Put the Team First

It can be disheartening when I see posts online from Scrum teams that absolutely hated the experience and want to go back to Waterfall.  How can that be?  Scrum can be a difficult pill to swallow at first when one is very used to the ebb and flow of the waterfall, but the core principles of the Agile Manifesto and the core principles of Scrum should make sense and eventually be embraced by the team. So why does this not happen?

I believe one of the main reasons this might be happening is because some of us are not doing a good job as Scrum Masters.  We need to do a better job selling agile to the teams.  Selling does not mean shoving down their throats, blindly following the Scrum rules.  It means putting yourself in their shoes and see the change from their eyes.  More meetings?  Possibly.  More transparency?  Of course.  More productivity?  Let’s hope so.  Less risk? Definitely.  These are not bad things for the team, but they may not see it that way initially.  It could take months, or longer, for them to “get it”.  Unfortunately, some of them may never “get it”, or may never want to.

Once we understand the changes that are occurring, not just in process, but also in culture, we can do a better job communicating to the team.  Each team member may see things differently, and we should acknowledge that fact and see if we can find a common avenue to help address issues or concerns across the team.

These types of discussions and transition plans could be well beyond the skill level and experience of a new Scrum Master, so in that case a professional agile or Scrum coach may be necessary.

We must not forget that a large part of Scrum and agile is team empowerment, and valuing people over process.  If the team is resisting, then the process probably isn’t working, and may need adjustment.  Use common sense.  I strongly feel that if the Scrum Master protects and empowers the team to the best of their ability, success in a better process in the end should be inevitable.  It may not be Scrum by-the-book, but I think that is perfectly fine.

Selling Leadership on Agile

Has leadership bought in and is fully committed to going agile?  Perhaps not.  Even if leadership stated that they are committed, they may not fully understand what it means to go agile.  Helping to form cross-functional empowered teams, providing dedicated Product Owners, and embracing and leading the agile cultural change, are all things that leadership should be doing.

If leadership does not appear to be fully on board, perhaps the benefits of agile are not clear?  Perhaps we need to do a better job selling agile to leadership.  Agile best practices are in their best interest as well.  Motivated, well-equipped, cross-functional teams working on the highest value items to the business at all times?  Reduce waste in process; increase productivity; increase transparency and thus reduce delivery risk.  Who would not want that?  Continuous Integration is an easy sale, in my opinion.  There are no real negatives that could possibly come close to outweighing the automation and reduced waste and risk that would ensue.  Test Driven Development is more difficult to sell, but I am convinced it can be done with supporting arguments and information.

Everything can, and should, start in moderation.  That also helps reduce the risk of spending time on processes or procedures that may ultimately fail.  It reduces the risk that team members will be caught up focusing on areas that are not providing the highest value to the business.

With leadership support, agile teams can do so much more.  It is our job to help leadership see the benefits of going agile, and to try to obtain that support.

Selling the Client on Agile

I think much of the same arguments above apply to communicating the benefits of agile to clients or our users.  Shorter feedback loops, more transparency, adaptation to change; I see all of these as positives from a client perspective.  Adjustments will need to be made. Smaller iterations will mean delivering smaller chucks of features to the client at a time, which is quite different than what they are used to. They should begin to see the positives of more transparency, bigger features coming together over time, especially if this allows them to course correct more gracefully when priorities change.

If a Scrum or agile transition is not going as well as planned, or preparations are being made for a future transition, keep in mind that we must all be good stewards of agile.  We must be able to sell agile, to a certain extent.

After that, it should continue to sell itself.