Prequel
I was preparing for the AgileIndy conference, so I thought I’d gather up some notes for products I’ve worked on and see if I could find some common success factors. I started digging through my old Trello board for blog ideas and started noticing something. A word kept shining through my notes. I thought, “That’s neat. I’ll have do something with that later.” But I didn’t really grasp the importance until later.
AgileIndy 2019 kickoff
I’ve been to AgileIndy a few times now. I enjoy getting away from the office and see how others are applying these agile/lean principles out in-the-wild. (If you haven’t been, I’d recommend it. If not Indy, find your closest Agile Community.)
The opening keynote by Arie Van Bennekum was well-received. I got some great sound bites that gave me a laugh and really ring true:
Don’t worry about being late. Your competition will be on time.
If a picture is worth a thousand words, why do we keep writing all these documents?!?
However, the one that started the day and seemed to follow me around was:
Stop starting; Start finishing
This was a gut-punch, both professionally and personally.
- How many technical side projects have I started but are on a GitHub branch?
- What about the pull request to that open source project that I haven’t pulled the trigger on?
- How many video games have I started but not gone back to finish?
Breakout Sessions
My first breakout session at the conference was by Laura Hansen, who was speaking about The “F” word: failure. Who hasn’t had a failed project? I was curious on her spin.
It started out with a dig on agile certification companies, where she posits that those companies are primarily in it for the money (which I respected, because I had a similar, yet reserved, opinion). Then she went into a retro, of sorts, on her failed project(s). Each point focused on a value of the Agile Manifesto.
In speaking on the value of “Individuals and Interactions over processes and tools”, she mentioned the biggest factor (when absent) in failed projects. This factor was the same theme that I saw in my notes for my successful projects not a week earlier:
TRUST
Each of my projects that “hit it out of the park” had a strong sense of trust, both me to my client, and from my client to me. My team and I built this trust up over time with on-point deliveries and transparent conversation. If I could trust my client would answer questions in a reasonable amount of time and were transparent with conversations, I had confidence the project would run smoothly. If my client trusted me and my team to deliver the best quality of product that met their goals, that’s what they got.
However, if my client would micro-manage me and my team because they didn’t believe our forecasts, it was rocky terrain. If my client wasn’t engaged when we had clarifying questions, I wasn’t confident that what we delivered would be good enough for them, usually requiring re-work and stress at the end.
In my next breakout session, Joe Jacob talked about reporting metrics. He had a dozen or so metrics that were commonly reported by teams to assess the status of their project. In most cases, you could find a person who could defend the use of that metric and another person to defend the abolishing of that metric.
As the saying goes, “you can make the data say whatever you want it to”. The teams had to trust that the manager would interpret the information properly, and the manager had to trust that the team wasn’t gaming the numbers just to look good. There’s that word again…
Full Circle at Lunch
As I was having lunch, I struck up a conversation with a lady from a local insurance company. I had mentioned the theme of “trust” throughout my morning, and she confided that in her company’s transition to being more agile, their leadership had bouts of good and bad dealings of trust. It felt good to get out of my own personal echo-chamber and hear validation from outside.
Trust is greater than Control
(Spotify’s Engineering Culture)
As we shared our respective stories, I was reminded of Spotify’s engineering culture presentation. We don’t strive to control people but to trust them. That means there are no politics; there is no fear. The fear of failing must be purged because it is a fact of life. Agile recognizes it, in that we fail fast so we can learn and adapt quicker. Without failure, there is no learning.
The after-lunch keynote by Maria Matarelli brought it full circle for me. She talked about focus and the importance of direction over speed. We may go fast, but if it isn’t in the right direction, it really isn’t getting us to our goals. The lack of focus can lead to abandoning efforts before completion:
Stop starting; Start finishing
As Laura put it in her breakout, we have to build rapport among the teams to optimize our outcomes. If we don’t, we risk moving in the wrong direction and leaving something on the table that could have been great.
Trust and focus lead us, personally and professionally, to success in everything we set out to do.
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
