Don’t be too focused on doing Agile
A friend recently sent me a post about agile. It was an interesting take on what’s happened since the Agile Manifesto was written 14 years ago. And it reminded me that too often, we see companies, teams, groups of people focused on doing, what they consider to be, agile. It’s what makes frameworks like SAFe and DAD appealing to large companies. They don’t know what to do, and these frameworks offer a solution to that problem… They propose that by following their process, the company will realize the benefits of agile. Or maybe it’s not that much – perhaps it’s a team or two trying to follow the Scrum framework. The interesting thing about all of these is that they’re starting points, and not destinations.
I was working with a new Product Owner on a Scrum team recently. In one of our first interactions, he asked me what we could be doing to be more agile. I think I may have scared him a bit when I explained that I don’t think our goal should be to quantify or focus on how agile we’re being. That shouldn’t be the goal. Odd, given that I tell people I’m an Agile Coach (not that I really know what it means to be an Agile Coach, but it sounds cool). I explained to him that our goal should be to deliver higher quality software, working software, delivering value to our customers, however we want to define value. At this company, profit and NPS are two key metrics. So let’s figure out a way to do deliver more shit that our customers love and will advocate to others about, and let’s also figure out a way we can make more money. It just so happens that one of the ways we can do this is through a better, tighter, shorter feedback loop with our customers. And that’s where agile fits in this case.
It’s not about following a process. Being agile isn’t about doing Scrum, or whatever flavour of process or framework happens to float your boat. It’s about uncovering better ways of developing by doing it, and helping other do it. (Wait… I’ve read that somewhere before).
In my opinion, it’s about finding ways of continually improving. Too often I’ve seen people and organizations focused on “doing” agile (or what they consider this to mean), rather than focusing on continually finding ways to get better. And I’m not talking about a little better. Or working a bit less overtime. No… I’m talking about massive improvements, and gigantic changes in the way we think about business, development, and our customers.
If you’re using a framework, use it as a starting point, and not a destination. Figure out what works for your business, employees, and customers today. My guess is that what works for you today won’t be what will work for you down the road. It’s been said that the only constant is change. Agile is all about adapting to and responding to the change that’s inevitable in a way that works for you.
Don’t be Focused on Doing Agile
A friend recently sent me a post about agile. It was an interesting take on what’s happened since the Agile Manifesto was written 14 years ago. And it reminded me that too often, we see companies, teams, groups of people focused on doing, what they consider to be, agile. It’s what makes frameworks like SAFe and DAD appealing to large companies. They don’t know what to do, and these frameworks offer a solution to that problem… They propose that by following their process, the company will realize the benefits of agile. Or maybe it’s not that much – perhaps it’s a team or two trying to follow the Scrum framework. The interesting thing about all of these is that they’re starting points, and not destinations.
I was working with a new Product Owner on a Scrum team recently. In one of our first interactions, he asked me what we could be doing to be more agile. I think I may have scared him a bit when I explained that I don’t think our goal should be to quantify or focus on how agile we’re being. That shouldn’t be the goal. Odd, given that I tell people I’m an Agile Coach. Not that I really know what it means. But it sounds cool. I explained to him that our goal should be to deliver higher quality software, working software, delivering value to our customers, however we want to define value. At this company, profit and NPS are two key metrics. So let’s figure out a way to do deliver more shit that our customers love and will advocate to others about, and let’s also figure out a way we can make more money. It just so happens that one of the ways we can do this is through a better, tighter, shorter feedback loop with our customers. And that’s where agile fits in this case.
It’s not about following a process. Being agile isn’t about doing scrum, or whatever flavour of process or framework happens to float your boat. It’s about uncovering better ways of developing by doing it, and helping other do it. (Wait… I’ve read that somewhere before).
In my opinion, it’s about finding ways of continually improving. Too often I’ve seen people and organizations focused on “doing” agile (or what they consider this to mean), rather than focusing on continually finding ways to get better. And I’m not talking about a little better. Or working a bit less overtime. No… I’m talking about massive improvements, and gigantic changes in the way we think about business, development, and our customers.
If you’re using a framework, use it as a starting point, and not a destination. Figure out what works for your business, employees, and customers today. My guess is that what works for you today won’t be what will work for you down the road. It’s been said that the only constant is change. Agile is all about adapting to and responding to the change that’s inevitable in a way that works for you.
“I’m very disappointed with each of you” – An experience from Toronto’s Agile Coach Retreat
When I’m interested in something, I really like to get into it. As a true generalist, this means I tend to like to get into a lot of stuff. And one of the things I like the most is helping & supporting others in being their best. This lets them be the specialist in whatever it is, but I get to tag along for the ride, and often learn about it in the process. Why do I start with this background info? Well, it’s because the one thing I do think I’m pretty darn good at is working with people.
This weekend, I had the opportunity to take part in Toronto’s Agile Coach Conference. The day was at a great space in Milton, and featured some amazing coaches leading the day. In typical agile coach fashion, the facilitators were really adaptable to the needs and interest of the group. And that led us to throwing a couple of topics out in the afternoon to explore Lego Serious Play.
It’s a fantastic and engaging way of helping people explore and articulate things they may have trouble doing through more traditional formats. LSP is for solving the really hard problems. I’ve facilitated sessions with Lego myself, but am not (yet) a certified LSP facilitator. A number of the people at this conference are. They’re amazingly talented people.
A scenario was set at each table. Our scenario was a scrum team with lots of interpersonal problems. There were six of us at the table; one Scrum Master, one Product Owner (me) and four Team Members.
After a number of introductory questions being answered and explained through the Lego, the question became focused on the scenario, and we were asked to build something that represented the problem we were having. Playing the role of the PO, I built something to illustrate that I felt stories were being estimated too large, that requirements were being missed by the team and not coming to me (as the PO) until late in the sprint, and that what was being built by the team was not meeting my customers needs. I was pretty specific, and really got into the role of the PO, calling the Team Members on the team “my resources”, and blaming the team because I thought the stories should be estimated smaller.
Now remember, I said I like to get into things. Really into things.
And I surprised myself with how I started explaining my Lego creation to those at the table.
I said: “My model here represented just how very disappointed I am with each of you.”
I have no idea where that came from. It certainly wasn’t premeditated. There was a fair amount of laughing going on as I said it. As the session went on, I found myself becoming even more uncomfortable with what I had said. No one in the room seemed to take it personally, which was good, since it was just a case study scenario. But it started becoming more and more bothersome to me. I realized part of the reason for my discomfort, as a Coach, is that I have no idea what I’d do in a situation where someone verbalized such a strong attack at others.
One of the great things about LSP is that comments are almost always directed at the lego models, and not at the other people. It’s one of the things that makes LSP a safe environment for solving those hard and complex problems.
So, I shared my discomfort with the group, and asked for some ideas on how to deal with such a strong emotion. Here’s a quick highlight of a couple of ideas and discussion that this sparked:
In a real world situation, it’s unlikely that this would have been the first time for such strong emotion and words to be spoken. As such, LSP might not be the right activity or approach in the first place with such disfunction. In fact, any group activity might not be right for this team. It could very likely be that individual coaching is required first.
After such a strong attack is made in what’s supposed to be a safe setting, it could be a perfect time for a break. And that break is a great opportunity to explore the feelings of the person making those comments in a one-on-one setting, away from others on the team.
If it’s not as directed as my comment was, it certainly requires the facilitator to focus/change/adapt the next question/activity in something that will bring the group together, or really guide the participants back to the focus of comments being directed at the Lego, and not at the people.
One person suggested that an attack like this should be the end of the session. Not a break. A complete and hard stop. I’m not totally convinced of that.
I think that there’s a great deal of work to do, and certainly the conflict that’s come out is really uncomfortable. But I think it could be an amazing opportunity, now that it’s out there, and verbalized with the entire team. After a break. And after a discussion with the person to make it a safe environment again for everyone.
There were lots of other great ideas and comments, but these are the ones that resonated with me.
I’m still not sure exactly what I’d do. I’m not sure I’d be quick enough on my feet to protect others at that table, and have a level enough head to take a break to evaluate the situation with a bit more time. I certainly like to think I would.
It certainly made me feel uncomfortable.
In one of the following builds, the question was to build something that reflected an ideal future state. I made sure my build included the Team standing along side me (as the PO). And I made sure to build a representation of 1 & 2 point stories (instead of the 13 & 21 point stories I’d built in the first build), with the comment that the Team was estimating the stories at the right size because I’d asked for their help in writing better stories. I wanted it to be clear that I was willing to work with the Team as the PO.
In that last build, one of the Team Members had built a car that was either going to drive towards adding value to our customers or driving towards another job, depending on what I built.
It turned out that since the PO had learnt and listed to the Team, we managed to keep the team together.
It was a great conversation… Just one of many great conversations on Saturday.
And it’s because it was a very safe environment with friends and colleagues.
I feel really lucky to be part of such an amazing community with such amazing people.