Like many other Agile fans, I’m very passionate about Agile. I love it. I read blogs about it. I’m are constantly trying to spread the word and help others implement it. I’m a borderline Agile evangelist.
Recently though, I’ve had a hard time convincing some of my peers that Agile is a good thing. Many are simply scoffers who laugh at story points and retrospectives. They don’t believe Agile works – they just want to work on the next work item in the queue (which is, in the most ironic sense, very much like Kanban).
So I started brain storming ways or arguments to convince them to try it. What if hold a big lunch-n-learn style meeting and explain all of the ideas in Agile? What if we write up a great manifesto for our individual team on how we do Agile? What if I secretly start tracking progress to show if it works or not?
And I realized, that my approach was not Agile. Like non of it.
I realized this after reading a great post over on medium. The author made a great point that until you have tried Agile in a few times, it won’t ever make sense.
Well, there are a lot of reasons. First, Agile goes against decades of project planning in other engineering disciplines.
- It doesn’t make sense to shift from planning for every contingency to shipping a product with only a few features implemented.
- It doesn’t make sense to estimate how long something takes based on intentionally ambiguous numbers that follow the Fibonacci sequence.
- It certainly doesn’t make sense to allow teams to self-organize if they can rather than assigned work explcity.
All of these things go against traditional planning methods and ideas.
Another reason is, well, because words are slippery and sometimes vague. As pointed out by Jon:
We assume [Agile] is obvious and intuitive. It isn’t, unless you’re talking vague high-level/nod-worthy ideas. […] but one person’s lightweight process and “open culture”, is another person’s bureaucracy and culture of fear/intimidation. So you have the challenge of slippery big words.
ie: its easy to say “YES! People over processes! Conversation over tools!” But when it comes down to it, it is too easy to turn around looking for a tool or a process to help your team become Agile. There is also your own biases. How you learned about Agile; how it was implemented on Team A vs Team B. Then there are just plan-ole miscommunications.
I remember a time when a group of engineers had gotten together to solve a pretty minor problem. We just needed to generate a report from a system to be consumed by another system for processing later. Simple. We kept using the term “Product” over and over in this meeting. No one questioned what that term meant – everyone knew right? Its, well, a Product. We finished the meeting and went to coding the creation of the report and the consumption process (both were very simple).
After all was done, my team was handed the report and it wasn’t right. The “Product” was totally wrong. It was not what our team meant by Product. We went and talked to the team so confused and a little frustrated. How did you mess up something so simple?
Well, as it turned out, everyone did know what the term Product meant – they just had difference definitions. And they didn’t all align. The same has happened in Agile and happens with almost all higher-order terms at some point. Overtime there will semantic diffusion.
All of these problems get in the way of helping others to move towards Agile.
How Do We Convince Others?
Going back to my original problem, I realized trying to explain every detail of Agile up front was like trying to help a friend eat healthier while taking them through a Taco Bell drive through. It doesn’t work together.
As Agile enthusiast, we find ourselves trying to do the exact same thing. We try to teach about Agile’s iterative approach while walking through a full day seminar of “what to do when” ideas. We try to encourage the use of working software over documentation, but instead of trying Agile, we have slides and slides explaining it.
I think the way we can convince others to try Agile approaches is to convince your team to try one thing.
It could be whatever you want. Using story points instead of days for estimation; having a planning or grooming session; talking about releasing more frequently; pair programming; etc. It doesn’t really matter. The key is to try something, see if it works, and then make adjustments. Just like you would when using Agile to build a product.
I do think that some starting points are easier than others. Don’t make life harder for yourself by making your one thing being two week sprints using scrum. Good luck with that 🙂 For me, some simple ones might be:
- Adding retrospectives after every release. This is easy. Just go through what went well, what you could improve on, and what was learned.
- Estimation sessions. Get the team together to groom and estimate stories before handing them over. You’ll identify gaps in the stories and begin working towards being able to track team progress. Be clear that estimations are just that and no one is being scrutinized to finish stories with the same estimate at the same time!
- Talk about what releasing faster would require for your team. You don’t even need to actually do it, but the exercise will expose process bottlenecks that you can brainstorm on how to solve.
- Limit work in progress. Leaning towards Kanban here, but if your team has a lot of things in flight and it creates too much context switching, consider working to limit how many stories are in flight at any given time.
All in all, the key takeaway here is to realize that Agile doesn’t make sense to those who haven’t studied it like you might have. Don’t ask your teams to understand it all before starting either. Start small and implement one thing that might have value. If it does, add something else and iteratively move your process to be more in line with Agile over time.
Just like Agile is supposed to be 🙂
Till next time!