I’m being an Agile player
So I’m being an Agile player. I’m dating a few different versions of Agile to see which works best while trying to keep it from the other methods I’m test driving. Don’t tell Scrum that I was scoping out Kanban. Don’t let Kanban know I made a date to get to know TDD better. How can I help the team decide which is best when there are so many options to consider? A hybrid approach can sometimes work, but under some corporate guidelines the relationship needs to be with one or another exclusively, not multiple. It’s all about exclusivity in this corporate Agile dating world. (I plan on posting a subsequent post exploring the non-exclusive relationships and hybrid approaches to this in the future – check back).
Honestly I’ve only tried each for a short time, so it could be too soon to tell. How long do you date one until you decide to make your relationship and commitment public? There is the get-to-know you phase where you’re just trying to figure out what each methodology is about, what they stand for, and what they work best for. It has to be determined if they are compatible with the team and project and if the relationship will work in the future.
Once you have an idea of which you want to commit to, how can you be sure? Should you keep the others on the line in case it doesn’t work out? If there are a few things that don’t work in one, do you try to tweak those things at the risk of losing the integrity of the methodology itself? What are the long term consequences of not being able to make a commitment? Obviously methodologies don’t have feelings but teams do, and how do you help the team to determine what is best without causing them unnecessary pain and confusion?
Does the team settle for what works “well enough”? Where they and the stakeholders can be happy? But what is to say there is not more happiness out there to be found? That hopefully should be found as the team improves and continues to inspect and adapt for what works best for them. There are things in methodologies, like people, that won’t change in relationships, but there are other things that can and will change as the relationship grows and matures. Goals get more defined, it becomes more comfortable, but there will still be and should still be ups and downs. That is how the relationship continues to improve and get stronger. Maybe at some point if the team or project changes too much the relationship will need to be ended, but that shouldn’t be looming overhead. If it ends, it simply means the team and the methodology grew apart and will need to look to start dating again.
It’s okay to be an Agile player at the beginning but in some corporate PMO run environments, the non-exclusivity does not work for very long. It’s best to go in with your eyes open, learn as much as you can quickly, and help the team to make an informed decision for what methodology they should have a commitment with.
[…] post first appeared as I’m being an Agile player on Natalie’s blog in June […]