In many of my conversations, I often get challenged about my use of the word “purpose”; especially when it comes to Agile initiatives. The following story is one of my favourite moments when not only was I challenged but also generously offered a new perspective that slightly, although significantly, changed my definition of working with Agile initiatives “purposefully”.
It was on a Tuesday; the meetings were streaming by without anything exceptional to report. People were applying tools like time-boxing, subject focus, and situational leadership within their meetings and that made me a happy Agile coach!
The audible notification of the next meeting from my phone signaled that there were ten minutes left to the current meeting; an epic architectural planning session for the sprints following the current one. We closed the meeting with a review of the “parking lot” items and the next action items on the board, followed by a quick ROTI (return on time invested). Result: 4.5; great!
I asked the two 4s to provide one improvement that would make the rating of this meeting a 5. One individual suggested introducing architectural concepts to a developer and the other suggested including the development director from time to time so that he’d be able to understand and engage in the development lifecycle.
“Excellent. I’ll bring these two suggestions to our next retrospective and see the outcome,” I said.
“Thanks Marc, and make sure you don’t forget the muffins for the retro!”, replied the head architect with a forceful wink. I later received a couple of chuckles when I offered a healthy twist to the snack by bringing zucchini, lemon, and bran muffins.
I then rushed to the next meeting room which was two floors up. I brushed the general director of the IT department while skipping every two steps with the Agility of a puma.
“Marc!” he shouted.
“Sorry Allan. I’m tight for my next meeting. Send me an email if it’s important and I’ll read it after the meeting,” I said, continuing with the momentum I had built up. I’m not sure he heard the last words coming out of my mouth as I was already a flight and a half further up.
I arrived to the meeting room two minutes early. All the Scrum Masters were present for the next meeting except for George, which was not surprising to anyone. We counted down the last two minutes before the meeting by a light conversation about the sidewalk conditions in the city during this unusually snowy winter. At the ring of the bell, I wrote down the meeting time on a Post-it, stuck it to the outside of the door and closed it.
I opened the meeting with a warm welcome and decided that a check-in might be of value for the day’s meeting. There was nothing particularly alarming going on in the organization, but I thought that a positive exchange might be enjoyable.
The door swiftly swung open just as Alex, the project team’s Scrum Master, was about to speak. George came in with his usual nonchalance, but this time there was a tinge of guilt in his demeanour.
“Hi everyone. Sorry for the tardiness,” George said in an interrupting yet mellow tone.
“Welcome George,” I replied. “Alex was about to start the check-in.”
“Oh. OK,” said George with a smile.
We cycled through the check-in “popcorn style”. Everyone checked-in without anything outstanding to report. We were then ready to proceed with that week’s Scrum Master meeting.
The format of our meeting varied every other week. One week we adopted the Open Space format. The other week was designated for a specific developmental topic that was decided during the Open Space. That week’s topic was: Developing with purpose; a topic that I found very compelling and inspiring.
“What does purposeful development mean to you?”
I started the discussion with an open question: “What does purposeful development mean to you?”
The answers were complementary to one another and didn’t make the discussion evolve toward more than a simple reflection of what was already being done. I felt that the group was not taking advantage of the full power of the meaning of purpose. I decided to challenge them a bit more with another open question: “How do you know the purpose is the right one?”
This one hit them like a ton of bricks. Faces were frozen with befuddled looks. A lengthy silence ensued, and then Eric, the contract team’s Scrum Master, spoke out in a partially irritated voice: “Purpose is the reason we do things. There’s no right or wrong. It just is.”
I nodded, acknowledging his statement. Another prolonged silence overtook the group. Then Eric continued, increasingly irritated by the question: “What are you getting at? I mean, how can you verify purpose when you develop? The teams just do what’s written in the stories, that’s it! No need to overthink!”
At this point, I started worrying about my understanding of purpose. Then, I reminded myself that they were the ones who had chosen the subject the previous week.
“Why did you guys want to address purpose in this meeting?”, I retorted.
Another silence filled the room for what seemed like more than fifteen minutes. Being very patient by nature, I decided to wait this one out.
Mary, the finance ledger team’s Scrum Master, shyly proposed the theory that: “Maybe there’s a feeling that the teams are simply developing what’s being asked of them and that they see no real purpose to it.”
“That’s the point! To do what you’re told to do,” replied Eric in a disconcerting manner.
Mary started replying with a bit of conviction: “I’m just saying that the teams feel they’re not involved in the process. Maybe they would engage more into what they’re doing if they were to develop with some kind of purpose in mind.”
“Mary, can you provide an example?”, I proposed.
She hesitated before answering. “Something like… I don’t know, like for example, if the purpose for this sprint’s development was to make Finance Ledger entries accessible and quick to access.”
“Do you really have to explicitly declare something like that? Isn’t that the premise of delivering value and quality in Agile?” interjected George.
“I guess so…”, said Mary. “But I think it’s not naturally retained in people’s thoughts. It gets lost in the habits and daily routine.”
“I see what you mean,” said Alex.
“Maybe there’s some value in reminding them the purpose of why they’re developing such and such,” he continued.
I couldn’t appreciate how “purpose” was being used at that moment. It was just not big enough. It didn’t seem to have the global reach and influence that “purpose” should have. I decided to challenge Alex’s reference to purpose.
“But isn’t purpose something bigger than a simple condition of satisfaction? Isn’t it something that aims at inspiring more than a simple developmental aspect?”
“Purpose resides on varying levels. I think that purpose is useful to the extent that it engages people and teams. Ultimately, the owner of the purpose is the Product Owner; and he should have the task of inspiring the team with it”, replied Alex.
No one answered. I took some time to let this sink in. This was a new perspective for me as I have always believed that purpose served evolution and development of one’s self. Anything less than that, I simply categorized as a “reason” to do things. But Alex was onto something.
At the end
This launched a series of discussions in which the Agile coaches came up with activities and new ways to encourage their teams to find purpose in what they were working on. The culmination of the meeting was the introduction of purpose for … you might have guessed it: the weekly Scrum Master meeting!
We closed the meeting with a ROTI. Result: 5!
Completely satisfied, I rushed back downstairs to meet the director that I had almost run over coming up. I knocked on the door frame and he invited me in.
“Marc. I was thinking as I walked around the floor this morning. It seems to me that the teams don’t seem to be as engaged as they could be. What do you think?”, he asked.
“Thanks for asking Allan. As a matter of fact, I think it’s a very timely subject. Can I interest you in a discussion about purpose?”
As a director, leader, or coach, are you inviting people and teams to develop and work with purpose? Are you limiting the definition of purpose based on your perspectives? How can purpose serve your teams and especially your organization?
This text uses software development as an example, but I strongly believe it is applicable to a variety of domains, and in fact, to everyday life.