If you believe that change is the only constant, ever so often, we need to push ourselves out of our comfort zone. We need to tell ourselves, “I am not entirely sure how this is going to play out. But we need to do something different to achieve (insert your business objective here) because the current way of doing things isn’t doing a great job of keeping us one step ahead of our competition.”
When I was invited to speak at the Project World Business Analyst World in Moncton this year, I chose to talk about my experiences adopting lean and agile tools and moving away from waterfall where it makes sense. Now, delivering a session at any conference typically follows a similar routine. Submissions from speakers are invited. A selection committee reviews and selects the speakers. The speaker prepares a PowerPoint. At the conference, the talk is dominated by the speaker with questions from the audience sprinkled in. This is beginning to look like a waterfall approach.
The waterfall approach to presentations
Let’s go over it one more time and look at the similarities. The speaker prepares the talk with visual aids (the plan) and delivers it (follows the plan). A good speaker would take into account questions from the audience and time the delivery accordingly (estimated time with buffer or contingency). If the speaker does a poor job of estimating he or she does not meet the plan (scope) or rushes to meet scope with impact to quality. If there are more questions from the audience, he or she ends up with scope creep. Sounds very waterfallish to me! There’s got to be a better way to show the power of agile and lean tools than talk about it in a traditional manner of presenting. How can one talk about the transformation to agile in this fashion?
Transition to agile
As I mulled over this, I hit upon a thought: “Since my talk is about the transformation from waterfall to agile, why not structure my talk using the agile framework?” I sat pondering about the implications of this. I would need to accomplish the following in less than 75 minutes:
- Undertake change management: people are used to these presentations. They come in, sit and listen to the speaker, ask a few questions and then at the end leave. I will be asking people to participate and help create the content of the talk. BIG change.
- Invite them to state what they perceive as value. At the end of 75 minutes what would cause them to say, ” I got value for my time spent in there”. Ask them to state their user stories.
- Depending on how many user stories I got, I will need their help in prioritizing them. Akin to grooming the product backlog.
- Use agile estimation practices to determine the complexity of each user story, break it down further to understand the real ask. Estimate how many points we will actually cover. I also need to set an expectation that I will be unable to hit all their topics.
- As I start talking about each, have someone monitor the time and stop me as we reached the time allocated for each user story.
- As we transition from each sprint have a brief lesson learnt about what worked and what did not work. Try to incorporate the lesson learnt into the next topic.
I thought the benefits of this approach outweighed the risks. Firstly, most people only get to see the theoretical side at conferences like these since they only hear people speak. This way they get to see the application of agile framework and how value is delivered, which incidentally is what agile is all about. Secondly, they get to decide what topics will add value to them rather than what i think they want. Finally, I also decided to get out of the “scrum master” role frequently and explain to the audience why I was doing what I was doing.
Risk management
The uncertainty, and hence the risk, was the questions that the audience would pose. But I was reasonably confident of addressing them satisfactorily, since I have been weaving agile and lean principles into my projects for quite some time now. Additionally, as part of risk management I planned to set the following expectations:
- The user stories should focus on topics related to the steps involved in the transformation from waterfall to agile.
- Get an agreement to focus on just 2-4 user stories and have a more meaningful discussion on the transition process.
Of course, this was all contingent on whether the audience would go along with this plan. I did not think they would disagree since I was inviting them to ask their questions at the outset and as we progressed, they would realize that they were in control of the presentation. I had a few questions in my back pocket to get them started.
Ah-hah!
I’ll share one very powerful event as I went about executing this strategy. After we checked off the second user story, a voice at the back of the room piped up, “based on the conversation so far and what you talked about, does it not make sense to bump up the priority of user story with priority 6 and talk about it instead of the use story currently marked priority 3? It is only logical that we talk about that now.” You could hear a pin drop as the rest of the room considered this. I could also see a number of eyes light up.
One of the attendees summed it up eloquently – “let the customer decide what is value add to them and focus on delivering value right from the outset. It is perfectly alright to change direction as new information becomes available. The fact that this came from the audience made that lesson more valuable.
Retrospective and feedback
As I think back to the session, the audience practically steered my talk into the questions they wanted answered. They were in complete control of the hour and how it was spent. Needless to say they loved the approach. Some of the comments I received at the end of the session were:
- I always thought agile was an IT thing. But seeing you use the framework to present convinced me that the principles can be applied into any environment
- Initially I was skeptical when you explained your approach. But as you went along, it became clear that you knew what you were doing. It was a refreshing change to the traditional formatformat
- You really made the process appear easy to use. And you did not mince words when questioned about the transformation from a command and control culture. We are going to introduce change within our span of control and start showing success.
I throughly enjoyed the questions and the ensuing conversations. That’s exactly what it was – conversations. Instead of blank stares, I saw a very engaged audience. After all, we were delivering what mattered to them the most, and that is the very essence of agile.