by Marjan Venema
The longest journeys start with a single step. You get to where you want to go by continuing to put one foot in front of the other.
My energy to keep taking those steps comes from a big vision. Over the past few years though, I’ve learned that big visions can also put people off. When I see the prize, I want to get moving and do whatever gets me closer, while many other people simply get discouraged by the length of the journey and its obstacles.
Over time I’ve learned to tone down my idealism so as not to discourage my peers. However, like Jürgen Knuplesch, who, back in September 2017, asked how to be a “constructive patient”, I struggle with this.
Ever since reading and resonating with the Agile Manifesto back in … 2010? 2012? (I don’t quite remember, it’s such a part of me now) I have been an Agile Advocate and, just like Jürgen, I was seen as that “crazy agile guy”, although in my case it’s been that “crazy agile gal”.
As a thinker, dreamer, and philosopher, as well as a pragmatic analyst and rationalist, I had great difficulty understanding why people didn’t get how we would benefit from agile practices, and why, if they do “get” it, they would not jump into action and learn to do whatever it takes to get there.
Feedback from colleagues and managers during those early years usually centered around: “You are too critical.” and “You are making goals too big.”
I understand that now. While I never was critical of people, I wanted to adjust our processes all the time to get us to “Agile Nirvana” and that was seen as criticism. For me, it was simply because I didn’t see any reason to wait to make an improvement once you identified it.
Unfortunately, for my colleagues, I cannot help but see ways to improve and I tended to forget to celebrate today’s wins because I was already focusing on tomorrow’s improvements.
Quite simply, I moved too fast and tried to get my colleagues to take steps that were too big for them. What I was advocating — the practices we needed to adopt to reach “Agile Nirvana” — was so far removed from our reality that people just couldn’t see how to get there. While, all I really wanted them to do was to get interested and start learning…
A good example was unit testing.
We had a lot (Yay!) of unit tests. Still, we needed a lot more to have a good safety net and early warning system, if only because the code base was so large. So, I would keep stressing that we should do more of it and should be striving to add unit tests to every bit of code we touched.
Considering the code base we were dealing with and the fact that some of my colleagues didn’t have all that much experience with unit testing at the time, I was advocating something that was simply too far out of their comfort zone. Add to that the pressures of day-to-day work and with perfect hindsight it’s easy to see why none of them took me up on my offers to help with bringing code under test.
Being aware of the differences in appetites for learning and improving has helped a lot.
As has figuring out what to do instead, as I told Jürgen back in September:
“You (and I) are the ones that know where we want everybody to go and what pots of gold will be ours when we get there. They may be able to see it, taste it even perhaps, but have no idea of how to get there and the entire thing seems to big an effort to even start.
“So, we need to break it down. Use retros to come up with the smallest steps forward that are manageable. Celebrate every little victory and build a little momentum. Then they may start getting enthusiastic and may start to pull you for more.”
I can still do with some help and inspiration for “how”: how I am going to identify — and be happy with — steps that are comfortable enough not to be too daunting and challenging enough to keep moving forward for those around me?
Essentially, I need help with how to tackle eating an elephant one bite at a time — preferably without the indigestion.
Questions that keep surfacing:
- How do you know what is a small enough step, yet not so small that people stay mostly in their comfort zones?
- How do you avoid getting stuck in technical improvements?
- How do you get a more or less dysfunctional team to start addressing the underlying (trust) issues?
- How do you raise the thornier subjects — like trust, feedback, and diverse personalities — when you are simply another team member and know people would rather avoid these topics, hoping they will go away by themselves?
- How do you keep up your own energy when a team’s appetite for improvement is not as high as your own?
- What are good ways to make practices stick? In other words: what are good ways to turn “we should”’s into habits?
- How would you tackle the influence of an architect’s personality when the managers are pushing everyone to involve this person with every story or project?
- What are good ways to celebrate successes with a team – or a team with a member – that’s prone to avoiding everything that feels “childish”?
- What are good ways to celebrate small victories without sounding hollow or like you are inflating achievements just so you can celebrate?
- What would change in these answers for a distributed team? What about a multicultural team where cultural diversity may still be felt as a burden?
Those are in no particular order of importance. They probably overlap. Or their answers do. Any thoughts you have to help me forward, will be much appreciated. Kindly share them here in the comments.
