True Story from when I was Agile Coach for a Multi-Billion Dollar, Fortune 15 Giant…
It was a large Agile program and we had new team members joining the program in waves. Not everyone was familiar with Agile and we did not have money for in-person training. So we had to do the next best thing – remote Agile training. Ugh!
Anyway, so I designed five 90 minute modules and as I was introducing the concept of optimizing value and minimizing waste, I asked the attendees who our customers and end users were and how our program helped them be more successful.
I made an embarrassing discovery – most of the attendees were unaware of the who our end customers and end users were. Application Architects, Scrum Masters, Developers. This made it hard to talk about value and waste.
I was disappointed in myself. I had let my team down. So we worked with our Product Owner to shoot a series of videos that answered key questions about our business, our customers, our end users, their pain, what made them successful and where our program fit in. We made these videos available on our Team Sharepoint and made it mandatory viewing as part of on-boarding.
A few months later, as I was walking around the office, chatting with some new team members, I asked the same questions – who were our customers and users, what were their pain points, where did our program fit-in? I got great answers. No more crickets.
This got me thinking about how frequently we get sucked into the mechanics of Scrum – the events and artifacts, without reflecting on the business value we were chartered to create. I call this TRAM-SCRUM where TRAM stands for
This was not why Jeff Sutherland and Ken Schwaber created Scrum. They wanted us to use Scrum Strategically and Professionally. I learned more about Professional Scrum in the Scrum.org Scaled Professional Scrum Course in Boston last year, but that is another topic for another blog.
I began wondering about some of the most common obstacles that prevented teams from making the shift from TRAM-SCRUM to PROFESSIONAL SCRUM. One common pattern kept niggling away at me – the lack of Stakeholder Empathy.
THE BERMUDA TRIANGLE
Our industry still suffers from the curse of the Bermuda Triangle – the place where all stakeholder value goes to die. This triangle is a crafty chameleon and seems to have changed forms over the years, but you know what Shakespeare said –
“A stinky diaper-genie by any other name would smell just as stinky.”
– William Shakespeare
Or something to that effect, anyway. English Literature never was my strong point.
But I digress. Even though we have migrated to the rituals of Scrum, in many cases, we still labor under the tyranny of the Iron Triangle of Staff, Schedule and Scope, we just rename the sides to be more “Agile”…
COST THINKING VS VALUE THINKING
So how do we stop getting more efficient at delivering waste and get more efficient at delivering value? This is another lesson I learned in the Scrum.org Scaled Professional Scrum Course
STEP 1: Let go off Cost Thinking – How can I relentlessly cut costs, without factoring in the unintended destruction of value.
STEP 2: Take baby steps towards Value Thinking – how can I increase delivery of stakeholder value at the lowest cost, to generate sustainable stakeholder value?
I think one of the barriers to making this shift is lack of Stakeholder Empathy. Which brings us to the question what is Empathy…?
Empathy can be defined as…
“The action of understanding, being aware of and being sensitive to the feelings, thoughts and experiences of another.”
It requires us to walk in another’s shoes…
So this might open up an avenue of exploration for you – what is the current state of empathy in your teams, when it comes to your stakeholders?
We must begin by creating a shared understanding of who your stakeholders are. They might fall into different buckets…
- SPONSORS: Fund the Scrum Team
- END USERS: Use the increments
- END CUSTOMERS: Served by end users via the increment
- COLLEAGUES: Impacted by the Scrum Team
- EMPLOYERS: Writing the pay-check
- COMMUNITY: In which the team works
- OTHER: …?
What indicators might you use to assess this state? Are you satisfied by the current state, or would you like to make any adaptations? And if you would like to make some adaptations, what might you do…?
A FRESH APPROACH
I humbly offer to you an idea that has been evolving in my mind for about a year or so – Drum-roll please….
EMPATHY DRIVEN DEVELOPMENT:
An approach to developing software that relies on team members making decisions based on empathy towards impacted stakeholders.
This approach requires development teams to creatively self-organize within the constraints of their organizations, to work around the barriers that isolate them from their stakeholders.
Empathy Driven Development is complementary to Agile Software Delivery with Scrum and is key to Scrum Activities and Events like Backlog Management and Refining, Sprint Planning, Daily Scrum and Sprint Review.
COMMON BARRIERS TO EDD
As you think about using this approach, chances are that you will encounter some common obstacles…
- Stakeholders Inaccessible to Development Team
- Un-validated Assumptions about Stakeholder needs
- Layers of Proxies between Stake-holders and Development Team
- Distrust between Stakeholder Proxies and Development Team
- Cynicism / Apathy towards Stakeholders
- No time / money to connect with stakeholders
If you are not ready to give up, here is a place to start…
STAKEHOLDER EMPATHY MAP
Get your team together in a room and…
- Create a grid with flip-charts and tape.
- In the first column, ask your team to put post-it’s for all your stakeholders. Review and refine as a group
- Now, ask your team to put up post-it’s to capture in 140 characters or less, each stakeholder’s…
- ACCOUNTABILITY: What outcome are they responsible for?
- MOST VALUABLE: What do they consider to be most valuable in the software they use, to help them deliver on their accountability?
- MOST PAINFUL: What do they find most painful and frustrating in the software they use to deliver on their accountability
Review and refine as a group.
For instance, if we were doing this exercise in a group that develops patient care software used in a hospital, the outcome might look a little bit like this…
Whenever I have facilitated this exercise, it has generated tremendous conversation among the team members, which is the desired outcome. We want this exercise to result in…
- Good conversations
- Identifying Un-validated assumptions
- Head scratching
- Action items to connect with stake-holders
- Many follow-up actions and conversations
But most importantly… an increase in stakeholder empathy!
HEAD VS HEART
As you explore this further, an approach that might help you facilitate the enquiry is a pattern described by International Change Leadership Guru and Harvard Business School Professor – Dr. John Kotter, founder of Kotter International. In his book – The Heart of Change, Dr. Kotter illustrates one of his Six Key Principles –
Head and Heart. Dr. Kotter’s research demonstrates that successful large-scale change requires engaging not just the minds of those we lead, but, more importantly, their hearts. Creating a vivid picture of opportunities ahead is vital. A heartfelt passion and commitment enables companies to overcome the inevitable barriers and obstacles encountered along the way to success.
Try to apply Dr. Kotter’s principle to establish an emotional connection between your team-members and your stakeholders.
Challenge your teams to self-organize within the constraints of your organization to increase stake-holder empathy. Here are some initial ideas to get the ball rolling…
- Try to get your Developers to customer site…? (Make sure your most influential / cynical team members participate)
- Try to get customers to developer sites.
- If you don’t have money, video customers using product and share it on your team site.
- Maybe you can Skype / GotoMeeting with Webcam and watch your customers use your product and get frustrated or delighted with it
- Maybe you can include all these videos in new-hire training / on-boarding
No matter what your team does, it must capture the smiles and frowns of your customers and stakeholders so it tugs at the hearts of your teams.
CALL TO ACTION
So here is my call to action – begin using Empathy Driven Development. Right Now….
- Apply Empiricism:
- Create an Empathy Map
- Interact with stakeholders – face to face / webcam. Talk to them, talk to each other. Walk in their shoes. Self-organize and figure it out…!
- TRANSPARENCY: Current state of stakeholder empathy
- INSPECTION: Is it where you would like it to be?
- ADAPTATION: Self-organize to make it better!
Rescue Value from the Bermuda Triangle of Cost Thinking and Value Destruction!
And don’t forget to let me know how it goes.
Keep calm and Scrum On!
It is very important to consider the opinion of end users in software development.
Questions such as these should be asked throughout software development lifecycle:
– Is automation reducing cycle time or decreasing costs?
– Are manual steps causing errors being eliminated?
– Are users willing to adapt the new process?
– How will the new application add value to end users?
Agile recommends more frequent interaction with the users through collaborative Backlog Grooming, join Sprint Planning and Sprint Review and Software Demo to the users at the end of the iteration.
Thanks Samidha! I agree with your comments – without closing the feedback loop with users, we lose a valuable opportunity for inspecting and adapting.
Please let me know if you get a chance to try out any of these ideas and how they turned out.