Agile - For the Sake of Being Agile

In the last few weeks, I have been approached by corporations wanting to talk about implementing the Scaled Agile Framework (SAFe). When faced with this scenario, I often ask three questions to get the conversation started:

1. What is your current level of Agile Adoption?

2. What does SAFe mean to you?

3. Why do you feel like SAFe is the answer?

I found myself a bit surprised with the similarities I have experienced with the answers received by my questions.

Across the board, when I asked the current level of Agile adoption, I was given an answer that little (if any) Agile was in place. It almost made me wonder if the individuals asking me believed SAFe was something new and not built upon the Agile methodology. More than anything else, it felt like some publication focused on C-Level executives created a short article on SAFe and it sparked heavy interest for those working in the higher levels of Information Technology (IT).

Those I talked to gave me the impression that SAFe was going to be a silver bullet for solving problems with their organization. The whole "silver bullet" thought process continues to surprise me - since this metaphor has remained a lesson unlearned for decades within IT.

My Thoughts

I consider myself an advocate of the Agile methodology, but I always make sure there is an asterisk next to my statement. My biggest clarification is to make sure Agile is being adopted in a manner that best suits the organization. Too many times, I feel like organizations are participants in some type of Agile competition - where the one to adopt the most concepts wins a huge prize. I have no idea who is judging this competition or what reward would be received.

This is not to say that aspects of the Agile lifecycle are not important, but to say if something is not working for an organization - for whatever reason - consideration should be taken to explore alternatives. One of the alternatives is to just not do it. I mean, it is not like some Agile police department is going to show up and cite you for an Agile infraction.

I've seen this where things like daily standup meetings have been re-tooled to provide the better value while keeping the team members abreast of the progress of the team. I've seen where retrospectives are held at longer intervals because the teams realize it takes longer to truly see aspects that need to be addressed.

I have similar thoughts on SAFe. I mean, SAFe by specification is quite an involved endeavor to implement and maintain - both versions 3.0 and 4.0. In the conversations I noted above, I pushed the "walk before trying to run" ideal to my clients and to avoid doing more Agile just for the sake of doing more Agile. To me, this is no different than writing music.

With music, there are all kinds of music styles to choose from. Composers have a variety of options to explore and tools to use when being creative with their music. It is rare for a musician to incorporate every style of music in a single album - let alone a single song. While some styles of music complement each other, some just do not make sense to combine. Trying to implement SAFe in a single effort feels like a musician trying to compose an album that includes every music style. Instead, musicians pick the music styles that work for them, for a given release.

So, when you find yourself trying to push deeper into the world of Agile, make sure to avoid falling into the trap of doing more Agile just for the sake of being Agile. Agile is no different than the process it is managing ... if something is not working, learn from it, find a better way, and move on.

Have a really great day!