Empathy Driven Development

Empathy Driven Development: Rescuing Value From the Bermuda Triangle

EMBARRASSING DISCOVERY

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.

Nothing. Crickets.

I made an embarrassing discovery – most of the attendees were unaware of who our end customers and end users were. Application Architects, Scrum Masters, Developers. This made it hard to talk about value and waste.

COURSE CORRECTION

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.

TRAM-SCRUM

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

T-actical

R-itualistic

Am-ateur

This was not why Jeff and Ken created Scrum. They wanted us to use Scrum Strategically and Professionally. I learned more about Professional Scrum in the 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?

 

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

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…

CURRENT STATE

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…

  1. SPONSORS: Fund the Scrum Team
  2. END USERS: Use the increments
  3. END CUSTOMERS: Served by end users via the increment
  4. COLLEAGUES: Impacted by the Scrum Team
  5. EMPLOYERS: Writing the pay-check
  6. COMMUNITY: In which the team works
  7. 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…

  1. Create a grid with flip-charts and tape.
  2. In the first column, ask your team to put post-it’s for all your stakeholders. Review and refine as a group
  3. 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…

DESIRED OUTCOMES

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
  • Un-validated assumptions
  • Head scratching
  • Curiosity
  • 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.

SELF-ORGANIZATION

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….

1. Apply Empiricism:

  • TRANSPARENCY: Current state of stakeholder empathy
  • INSPECTION: Is it where you would like it to be?
  • ADAPTATION: Self-organize to make it better!

2. Create an Empathy Map

3. Interact with stakeholders – face to face / webcam. Talk to them, talk to each other. Walk in their shoes. Self-organize and figure it out…!

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!

EMBARRASSING DISCOVERY

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.

Nothing. Crickets.

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.

COURSE CORRECTION

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.

TRAM-SCRUM

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

T-actical

R-itualistic

Am-ateur

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

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…

CURRENT STATE

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…

  1. SPONSORS: Fund the Scrum Team
  2. END USERS: Use the increments
  3. END CUSTOMERS: Served by end users via the increment
  4. COLLEAGUES: Impacted by the Scrum Team
  5. EMPLOYERS: Writing the pay-check
  6. COMMUNITY: In which the team works
  7. 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…

  1. Create a grid with flip-charts and tape.
  2. In the first column, ask your team to put post-it’s for all your stakeholders. Review and refine as a group
  3. 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…

DESIRED OUTCOMES

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
  • Curiosity
  • 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.

SELF-ORGANIZATION

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….

  1. Apply Empiricism:
  2. Create an Empathy Map
  3. 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!

 

 

Read More

A Letter to Scrum Masters

Dear Scrum Master!

Being a Professional Scrum Trainer, agile coach & consultant for a while I had a chance to work with around a thousand Scrum Masters across different organizations. I see recurring patterns of misunderstanding and misapplication of Scrum usually visible in how Scrum Masters act. Based on that experience I want to share a couple of important points with you in hope that you will seriously consider them in your work.

1. YOU ARE NOT A BOSS. REPEAT: YOU ARE NOT A MANAGER. REPEAT: YOU ARE NOT A FOREMAN.

Specifically you are not responsible for making sure the team delivers everything that was planned during the Sprint Planning. You are not responsible for gathering reports and coordinating work to meet deadlines. You are not responsible for ensuring everyone chimes in, so you are not responsible for checking if people are working hard enough nor handling laggards. You are not responsible for distributing work nor ensuring it is distributed fairly and in a way that makes best use of the talents and skills of your team.

Your responsibility is nurturing, creating a team that would care for most of the above and more. This is a huge difference.

A good analogy is that of a sports coach. During a match all a coach can do is watch from the bench. He is responsible for creating a team that will play the game, not directing each and every player once the game starts. In the end it is the team that is responsible for winning, not the coach.

2. NONE OF THE MEETINGS IN SCRUM IS FOR YOU. YOU ARE NOT SUPPOSED TO BE THE CENTER OF ATTENTION ON ANY ONE OF THEM.

Specifically, the Daily Scrum is not a reporting session, if you stand in the center and everyone else looks at you as they talk you’re doing it wrong. Also, the Sprint Review is not about showing team statistics and burndown charts. It is about showing a working product to the clients. Did I mention you’re not supposed to be the center of attention? That also applies to the Sprint Review, you shouldn’t be the one doing most of the talking — at best you should be the one doing the minimal moderation (that is keeping the meeting focused and effective) while the Product Owner and the team host the stakeholders, present their work and gather feedback.

If in doubt what Daily Scrum or Sprint Reviews are for re-read the Scrum Guide or attend a training led by a qualified, experienced trainer from a reputable Scrum organization (as of now this means Scrum.org or Scrum Alliance).

3. YOU ARE ALSO NOT A “SCRUM SECRETARY”.

The fact that the team “does Scrum” and you have been elected/nominated/duped into being its Scrum Master doesn’t automatically mean that you should draw burndowns, move cards around on the board and keep other “Scrum artifacts” up to date. You may choose to do some or all of those things for a while, especially with a new, inexperienced team, but never ever allow the team to think this is your job as a Scrum Master.

Doing that might give them the false idea that all those artifacts are for you — or the process, the management etc. — while in fact they are all for them, the team sprinting to reach the Sprint Goal. You are there to help them realize that.

4. YOU ARE ALSO NOT A TECHNICAL LEADER. NOR AN ARCHITECT.

You might be a brilliant programmer with lots of experience on the product, but being a Scrum Master doesn’t give you any authority to decide how the product is going to be designed & built. Specifically, as a Scrum Master it is not your duty to do code reviews or (worse) approve code or designs, answer technical questions or make any technical decisions. Doing so would bring you very close to becoming a traditional lead programmer or technical lead and thus would prevent the team from healthy self-organization.

Yes, Scrum allows a person to be a Scrum Master and a developer at the same time in the same team. If that is the case you will have to carefully balance those two roles and make it absolutely clear to everyone and in every interaction whether you speak & act as the team’s Scrum Master or as one of the developers. This might turn out to be trickier than it seems on the surface. It may sometimes work, but in most cases the burden is too much for one person which is why it is not the encouraged model.

Sadly, many organizations have even made it into a standard thus in most cases denying themselves full benefits well functioning Scrum teams could have given them.

5. YOU ARE NOT THE TEAM’S SPOKESPERSON. NOR AN INFORMATION RELAY FOR THE TEAM.

As it was pointed out above the Scrum Master is coaching the team, protecting the team, nurturing the team and pushing it gently towards working better and smarter — but is not replacing the team in actually doing the work. Contrary to what some may think a development team’s work does not consist of just typing code into computers while drinking caffeine-rich drinks. It also involves communicating (preferably face to face) with others — teammates, other teams, the Product Owner, stakeholders, clients, users etc. — to first understand what and how to put into code. Very often when analyzing why things went wrong we discover it was because some people didn’t talk, didn’t communicate fast and early enough opting for sending an e-mail then forgetting about it or — worse — assumed this or that was ‘obvious’ and just went ahead based on that unfounded assumption.

Because communication is so important for the art of developing software in teams as a Scrum Master you should care about it. This means you should monitor this communication to make sure there is enough of it, encourage it (in most cases just reminding developers it is better to call or walk over and have a chat rather than typing an e-mail is sufficient) at the same time ensuring that the process is not ‘leaking’ (for example no new work is being pushed into the team outside of the Product Backlog and PO’s knowledge). However, it is the team’s responsibility to communicate — it is them communicating, not you. Therefore you should never ever step in to act as a relay.

So, if everyone who wants to get some information to or out of the team comes to talk to you, the Scrum Master, you’re doing it wrong. Get out of the way before too much harm is done.

CONCLUSION

There are of course other misunderstandings and dysfunctions, but the ones above are by far the most common. If any of the points above is not obvious for you please do rethink whether your stance as a Scrum Master — or what is considered standard in your organization — is indeed beneficial and in line with what Scrum calls for. In other words whether you are a Scrum Master — or is it just a title you have in your e-mail signature.

Yours truly,
Andy Brandt

Read More

True Certification

True Certification – Earned or Purchased?

“Eventbrite Order Notification” – This is probably one of the best mails I receive as a ScrumTrainer :) It usually means I have another student with whom I can share my passion for Scrum. Sometimes it doesn’t quite work that way.

Last year, I got this notification for a student who wanted to attend my PSPO course. I usually send my students a survey asking them about their background and expectations and have a pre-training conversation, just to make sure we are on the same page. In this specific case, I’m so glad I did this.

PRE-COURSE INTERVIEW

The student had no background knowledge of Scrum and wanted a guarantee that she would pass the PSPO-I assessment as a result of attending my class. I explained that I cannot guarantee she would pass the assessment. Especially since this was an advanced assessment and she had no experience with Scrum and had not yet passed the foundational PSM-I assessment. She would have to study hard and earn it.

She said she found it very surprising that I could not guarantee her an assessment. So I gave her a refund. Not the kind of student I wanted in my class. I am not in the business of selling assessment certificates.

This experience made me think about our relationship with assessments and certifications in the Agile Industry. Maybe there are some differences relative to other areas of our life…?

CHOOSING A PEDIATRICIAN

For instance, how do we choose a new pediatrician? The health of our children is the most precious gift we have, so it is obvious that each parent tries their best to find the best doctor for their children. Many of us might have a multi-step process to pick the right pediatrician….

1. Do they have theoretical knowledge?

2. Do they have the right values? How do they treat their employees and patients?

3. Are they ethical – will they do what is in the best interest of my child?

4. Can they integrate theory, values and ethics into skilled practice and apply their expertise to treat my child?

5. Do they have a track record of taking good care of other children?

6. Are they recommended by my trusted friends?

7. Is their chemistry between us? Does my child and my family like them?

Since we cannot assess their theoretical knowledge or skills, we rely on an assessment by a recognized certification body like the American Board of Pediatrics to assess their qualification and we just check if the Pediatrician is certified through the ABP. Maybe questions 1 to 4 are assessed by the ABP.

So our selection process may look a bit like this…

Now, let’s look at how we choose future members of our Agile Teams…

CHOOSING OUR NEXT SCRUM TEAM MEMBER

When we choose a new member for our team, a lot is at stake. Complex Software Delivery is a risky business to start with. I tackle this topic in one of my previous blogs – Agile Gambling . There is so much at stake…

  • The future of our customers
  • The future of our investors
  • The future of our company
  • The future of our scrum team

Since the stakes are so high, we might apply a similar level of rigor towards choosing our next team member…

1. Do they have theoretical knowledge of Agile Software Delivery with Scrum?

2. Will they live by the Scrum values? How do they treat their colleagues and stakeholders?

3. Are they ethical – will they do what is in the best interest of stakeholders?

4. Can they integrate theory, values and ethics into skilled practice and apply their expertise to Agile Software Delivery with Scrum?

5. Do they have a track record of effective Agile Software Delivery with Scrum?

6. Are they recommended by my trusted industry connections?

7. Is their chemistry between us? Does my team like them?

We may trust a recognized industry certification to assess the candidates on questions 1-3. For instance, Scrum.org offers scrum Scrum Assessments for Scrum Foundations, Scrum Masters and Scrum Product Owners.

So our selection process might look a bit like this…

ASSESSMENT AND CERTIFICATION CREDIBILITY

This is where it gets tricky.

There has been a proliferation of assessments and certifications in the Agile Industry. Not all assessments and certifications are created equal. Not all assessments ask challenging situational questions that mimic the real world, challenging candidates to dig deep into theory, values and ethics and demonstrate their expertise.

In some extreme cases, organizations are no more than certification printing machines boasting about the low cost and effort for candidates to get their certificate…

ASSESSMENTS AND CERTIFICATION TO BUSINESS RISK MANAGEMENT

So we are faced with a challenge as Agile Professionals – how can we manage the business risk exposure by choosing the right assessments and certifications to add new team members, or to measure an upgrade in the skills of existing team members?

How seriously should we take our research on Agile Certifications and Assessments? As seriously as we take our research on Pediatric Certifications and Assessments?

How do you decide which Agile Certification and Assessment to trust?

Here is a set of Assessments from Scrum.org that I trust…

So in closing, in my opinion, True Certification is Earned, not bought…

What do you think…?

Read More

Anne Burgess [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

Can rituals help agile teams bond?

Years ago I was complimented on “improving the group dynamic” by bringing in a cafetiere for the my agile team to use.  We developed a bit of a ritual around this object.  One person had made it clear that the kettle needed to be left to cool so the coffee was not burned, procedures were in place for who got the rocket fuel left at the bottom, etc.  At the time I thought little of it but was reminded of this shared practice after reading this article in New Scientist (subscription required) about rituals and their role in binding groups together.

In the Shetland islands, there is a yearly ceremony where people dress up as Vikings and burn a longboat.  Etiquette in Asian tea ceremonies is complex and distinct to each region.  In the UK Parliament, when a new Speaker of the House is appointed they are physically dragged to the chair by fellow MPs.

Research referenced in the article supports the idea that ceremonies and rituals form part of an instinctive human behaviour.  This behaviour is believed to have provided an evolutionary advantage by strengthening social cohesion, making it clear who is in and who is an outsider.  Those within the group feel a stronger sense of identity and commitment to shared goals.  As an agile coach it may be beneficial to understand these instincts and assess their effect in the modern workplace.

Reflecting on observations in other agile teams, the presence of evolved rituals or practices seems to have coincided with healthy team dynamics.   One agile team used a mangy-looking toy cat to indicate who was building the release.  The use of customised avatars on boards is common, and the effort put into them seems linked to team identity and the pressence of trust amongst team members willing to make themselves vulnerable.

Teams that have formed strong cohesive bonds are likely to develop common practices with a shared and tacit understanding.  A lack of engagement in shared practices by one or more team member can be a sign that a team has lost its sense of purpose.  This may be a sign that people no longer see the value of working together due to an underlying issue that must be addressed.  A common example of this is a lack of commitment to attending the daily scrum or stand-up.  The problem is rarely to do with public transport or setting alarm clocks, so an agile coach trying to engage with the problem on that level is likely to fail.  If the team have lost their sense of cohesion and commitment then the reason for this needs to be found.

How can the natural instinct for ritual help an agile coach?  I would encourage the agile team to define the boundaries for their team events, and take collective ownership of them.  Rituals, or a new lack of engagement in them, are a symptom rather than a cause.  This can form part of your observation toolset and give you cues to delve deeper into issues.  You can help the team develop by encouraging new foibles as they form or supporting existing rituals, while explaining to co-workers that “Viking helmet Fridays” are no threat to corporate values…

Image Attribution: Anne Burgess [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

Read More

Agile and Scrum, entwined and related

“Agile” (the label) is all over the place. Who would have guessed in early 2001? When the Manifesto for Agile Software Development was created and the English adjective ‘agile’ obtained its specific meaning in the context of software development. What is this manifesto, commonly known as the Agile Manifesto, about actually?

“Scrum” (the method) is all over the place. Scrum terminology increasingly dominates software development vocabulary. Who would have guessed in 1995? When Scrum was codified for the first time and presented to the public? What is Scrum, essentially? And how does it relate to Agile?

Agile

In 4 value statements, backed by 12 principles, the signatories of the manifesto captured the mindset common to their approaches to software development. Agile is the DNA that drives behavior, not the behavior itself. Every method (behavior) claiming to be Agile can be expected to express these values and principles. The Agile Manifesto is a cohesive set of interrelated values and principles. Agile is a trait, not an activity.

With the increasing adoption of the methods for Agile software development, Agile became a proper noun, capitalized, pretty popular and ultimately big business. Success obfuscates and diminishes actionability, it seems. Today “Agile” is all over the place; coming in many flavors, wrappings, definitions, interpretations, abated and discounted. “Agile” sells. It is probably the most used prefix for roles, jobs, positions, functions and phases found in the software industry. And, it needs scaling.

Given the nature of Agile, correlating ‘scaling’ to Agile is pretty odd. Tactics change with scale. Strategies change with scale. Values and principles don’t change with scale. Claims and statements on the need, the ability, the inability, the whatever to scale Agile are besides the point. Values and principles are agnostic of scale.

Agility is the extension of Agile into a noun. As such it refers to the state that people, teams, organizations look for by adopting Agile development processes. Agility, as such an extension, is a state of high responsiveness, speed and adaptiveness; a state of constant invocation of change, evolution and improvement. Such state of agility augments the capability of people, teams, organizations to deal with the complexity and unpredictability that are natural to the work of software development itself, the organizational context within which it happens and the external circumstances faced. The adoption of Agile processes indeed is an important foundation for this state of (business or enterprise) agility.

Scrum

Scrum emerged in the early ’90s from the work of Jeff Sutherland and Ken Schwaber. They formalised and turned their way of working into a cohesive set of rules and roles for complex product development, that was formally presented as “Scrum” to the public for the first time in 1995. As the co-creators of Scrum are signatories of the Manifesto for Agile Software Development, the Agile values and principles underpin the Scrum framework.

Success obfuscates and diminishes actionability, it seems. Versions, interpretations and flavours of things that looked like Scrum started appearing, abated and discounted. It inspired the co-creators of Scrum to define Scrum, its rules and roles and how they tie together, in the Scrum Guide. Scrum as intended and designed. The core of Scrum stands, immutable, for reasons of cohesion. The tactics to apply the rules are left to the intelligence and creativity of the people using Scrum. Their unique discovery is framed and given direction by Scrum.

Scrum is a servant process, not a commanding process. Scrum thrives on empiricism and self-organization, characteristics that are better understood when seen through the lens of the Agile Manifesto.

As with Agile, the Scrum Values and Scrum’s fundamental roles and rules as described in the Scrum Guide don’t change with scale. But scaled implementations of Scrum do require different tactics in implementing the rules, yet respecting the foundational values and principles.

Agile and Scrum, actually, are not interchangeable synonyms, but two inseparable ingredients in a software development ecosystem, pure chemistry.

Agile are the principles to Scrum, Scrum is a foundation for agility.

Read More

elephant-in-the-room-698

Are Your Leaders Promoting Courageous Communication?

Have you ever been in a meeting where you felt afraid to share a difficult and truthful statement? Was “the obvious” in the room the whole time, but no one would speak up and talk about it? If so, then the time has come for your organization’s leadership to embrace the role of a Courageous Communicator.

 

Organizations that act Agile and responsively on the outside usually have incredible leadership dynamics operating on the inside. One critical dynamic is when senior leadership supports the role of Courageous Communicators. These emerging workplace leaders bring a fine-tuned set of skills and emotions to bear when circumstances are difficult and will surface the “hard truth” that is essential to the success (or perhaps survival!) of the organization. However, for a culture of courage to thrive, an organization’s senior leadership must be supportive of open and honest behavior in the workplace. Think ‘Family Core Value #6′ from the often-admired Zappos company culture.

 

For example, what if…

…a software company ships a broken feature to your smartphone prematurely and it causes you (the customer) a big headache. Application Developers might have known that the quality was suspect, but perhaps they felt management pressure to ship it because of a competitive threat or a customer obligation. Or even worse, maybe the Developers have a financial bonus that will only be awarded if they ship the feature immediately.

If you were a Team Member in this situation, consider the answers to these questions:

How would this management pressure make you feel?

How would your fellow Team members feel about all of this?

What is important to both the Team *and* Management in this situation?

How can you be truthful to management without getting in trouble, losing your bonus, or getting fired?

This situation can be avoided with Courageous Communication. Perhaps someone would respectfully and calmly step up to senior management and say something like:

I feel like the management approach is forcing us to do something that could be damaging to our customers and our company’s reputation. This feature doesn’t meet our mutually-agreed standards of quality and completeness. If it isn’t “done”, what will happen if we ship it now?

What is Courage?

Courage is a profound value of great leadership, but it requires skillful communication, emotional awareness and a degree of professional safety to be effective in the workplace. Let’s use an abbreviated definition from Wikipedia to dive a bit deeper:

  • Courage – the ability and willingness to confront fear, pain, uncertainty or intimidation.

I’ve seen many great moments of courage unfold in the workplace, especially in organizations that experience a breakthrough moment in the pursuit of higher performance. Someone steps up and makes a truthful (and possibly painful) statement, but at the same time, this person fosters alignment from everyone and creates a better outcome for all. Have you ever seen this play out in your organization?

 

An Example

Okay — let’s try this one out:

Imagine you’re invited by a Scrum Team to observe a Retrospective at the end of a 3-week Sprint. It can be a powerful learning event if the conditions are healthy, but sometimes, it becomes another wasteful meeting where nothing is accomplished. In a productive Retrospective, Courageous Communication is critical.

As you are observing as a fly-on-the-wall, the Scrum Master intentionally breaks an important rule of this event & invites senior technology managers to participate, so that the Team’s performance can be “evaluated”. You sense that the environment is uncomfortable for the Scrum Team, so when it’s time to examine its own challenges, the room becomes eerily silent – you could drop a pin on the floor. The managers break the silence with feedback: “We have evaluated each Developer’s performance and here’s where you all can improve ….”

<silence gripping the room>

Now what? Where’s the real leadership in the room?

Out of nowhere, a leadership moment emerges from one of the Team Members. It might sound like …………

I feel like we all understand the importance of this work and the impact it will have on our company’s success. However, I am afraid to admit that none of us understands how The Scrum Framework is really supposed to work. To be successful, we must acknowledge this and commit to a better understanding of Scrum and how we can all work together for a great outcome.

This person goes on to share the issues with an individual-driven performance evaluation process and how it is putting the Team on the defensive. Suddenly, the other Team members come out of their shells and nod their heads in agreement. Even the Scrum Master realized the terrible error in judgment that was made. The Courageous Communicator also admitted a fear of being fired right on the spot for honesty, but felt that it was the right thing to do for the organization.

Whoa.

That incredible moment of courage shattered the current reality for the managers, but it opened the door for a shared understanding of the real problem (judging individuals), so they could move forward in the right way (empowering and trusting the Team). It changed everything for this Scrum Team’s performance and the relationship with senior management.

 

How can you become a Courageous Communicator?

This type of communication isn’t easy, but with practice, you can elevate your own leadership ability and exemplify courage to benefit yourself and others around you. Here are a few tips to consider as you examine your own capacity for courage:

1. Be open and honest about your own fears.

Courage requires a leader to be vulnerable in front of others. If there is something about the situation that scares you, be honest and say it — respectfully. If you do this, you will help others feel safe to speak their own views in an honest and open manner.

2. Do not judge.

Read through the example above (again). Notice that the Courageous Communicator did not point fingers or verbally attack anyone. Rather, this person took a non-judgmental stance and did not blame the stakeholders. Point a finger at an issue and not at a person. If it’s a 1:1 conversation, point a finger at your fears and the behaviors that are making you feel that way. Then, seek a common purpose between both of you, so you can open the door to a fruitful dialogue.

3. Stay calm.

Don’t let emotions get the best of you. I have seen many situations where someone tried to show some courage in the workplace, but emotions were out of control and everyone tuned out. A Courageous Communicator can state “the obvious” in a calm and seasoned manner that helps everyone accept the reality.

4. Don’t wait.

The worst thing you can do is go silent and wait until later. If a situation has escalated and the “hard truth” needs to be understood by all, then a great leader will step in on the spot and communicate the truth and foster alignment. The time is now, not later. Just make sure your skills and emotions are in check first.

5. Celebrate courageous moments from others.

Courageous Communicators are influential leaders that live in all levels of an organization. Be on the lookout for well-timed and skilled moments of courage, and if you witness courage in action, show some appreciation and praise it! This is a demonstration of your own leadership when you celebrate and encourage others to be courageous in the right way.

 

Are you a senior leader who just read this post?

If so, then Courageous Communication starts with your willingness to ‘lead by example’. If you embody this value within your organization, then you will encourage a healthy environment of professional safety where people are completely comfortable to be open and honest when it matters most. If you don’t, then you will hear what you want to hear, but it might not be the truth that you need to make effective business decisions. Agile leaders understand the power of Scrum and constantly reflect the mirror on themselves in an effort to continuously learn & improve. Are *you* a Courageous Communicator? Are you fostering a culture where courage is valued?

Have you witnessed Courageous Communication in action recently? What was it like? I invite you to share your experience in the comments section below.

 

—————————————

I really appreciate you taking time to read this post. If you learned something new or were inspired in any way, please consider sharing with your colleagues so we can collectively make a difference in organizations of all shapes and sizes. Scrum On!

I am living my passion by teaching, mentoring and coaching People, Teams and Organizations to high levels of performance in an Agile environment. Want to experience some of my teachings in person? I would be privileged to collaborate with you at one of my upcoming events.

Try some of my recent posts and let me know if they inspire you to bring out the best in Scrum in your organization:

—————————————-

The original version of this post can be found on LinkedIn Pulse.

Read More

Techniques for using the Definition of Done (DoD)

I always spend time during training classes thoroughly covering the concept of Definition of Done, sometimes abbreviated “DoD.” As a concept it’s fairly easy to understand and people generally see the value right away. And in practice, for many teams, this concept is the single biggest game changer for their speed, quality, and process. But I’ve also found that there are many ways to put the DoD into practice, and many techniques for using it during the course of a Sprint. I’d like to share some of those here:

done-sm

(more…)

Read More

Manager to Enabler

Are You a Manager or an Enabler?

Are you a Manager that believes in the power of Scrum? There is a difference between thinking, believing and knowing. Don’t miss out on a huge opportunity to become the next market leader in your space. It’s time to understand your role and how it needs to change in order to survive in a creative economy, and it starts by transforming your mindset from Manager to Enabler.

At the turn of the century, I was a proud and young Manager. I had the job title, a ‘corner office’, people reported to me, and life was good. I was entrusted to manage a lot: people, projects, programs, customers, company strategies and the like. But I could tell that something wasn’t right with the world. What was it?

At the time, I couldn’t put my finger on it, but the signs were deceivingly clear and compelling. Experience a few pieces of painful evidence from my own 360 feedback around the Y2K period, which looked something like this:

  • Subordinate: He is a good Manager and very smart, but he doesn’t trust us.
  • Superior: He is an extremely hard-working Manager, but needs to improve his ability to “drive the teams and the results” to customers.
  • Peer: (blank)
  • Self: (???)

Clear as mud, or clear as crystal? Was I a Manager or an Enabler? What did the organization want me to be?

Transforming from Manager to Enabler

It took some time for me to fully process and understand this feedback, but I eventually had a breakthrough moment that launched my own professional transformation. If you are a Manager who lives in a bureaucratic and controlling company hierarchy, then you might be receiving similar feedback.

Are you ready for your own breakthrough moment? Is this YOUR time? If so, then consider embarking on a challenging and rewarding personal journey from Manager to Enabler. If you are able to transform from a Manager to an Enabler, then great Agile leadership ability will be attainable for you. You will also be in a position to truly understand the essence of The Scrum Framework for complex product development.

Welcome to the innovation economy – where Enablers allow their organizations to effectively compete and succeed in a turbulent and relentlessly-changing marketplace.

I offer a few introductory questions as a thought provoking tool to evaluate your professional frame of mind. These are just some questions – I invite you to think about the answers for yourself. Write them down on sticky notes and take some time to think about each one. Expand your awareness as you reflect on each of these questions and what they mean to you, your teams, your organization, your customers and your competitors.

This is not a formal assessment tool and you won’t receive a chart or graph that explicitly tells you whether you’re a Manager or an Enabler. But I assure you that if you invest some time to think about these questions, you’ll start to understand where you are now and if a journey from Manager to Enabler is right for you. If you’re already an Enabler, then you might be ready for an even more fulfilling journey into great Agile leadership.

 

Are you a Manager or an Enabler?

How does it feel to coordinate a large group of people and own the results of their work?

Do you enjoy being the go-to person for the answers? Do you pride yourself on being the source of business and technical knowledge in your company?

If you’re a people Manager, what does it feel like to invest in those people? Could their own professional growth and autonomy threaten your position in the company?

What does the concept of self-organization mean to you?

Are these 4 secrets of enablement new or foreign to you?

Does “work” feel like work to you and others in your organization? What would it mean for work to be fun?

Is money the motivator for you and others? If not, what is the motivator for you and others in your organization?

 

As you work through this on your own, read the beginning of this post again and try to answer these questions from the perspective of the young Manager. This will test your sense of empathy, which is a powerful component of great Agile leadership. What were my answers back in Y2K? What do you think my answers are now?

Are you a Manager or an Enabler? Are you helping to Enable the power of Scrum in your organization? Share ‘your answer’ in the comments section below.

 

—————————————

I really appreciate you taking time to read this post. If you learned something new or were inspired in any way, please consider sharing with your colleagues so we can collectively make a difference in organizations of all shapes and sizes. Scrum On!

I am living my passion by teaching, mentoring and coaching People, Teams and Organizations to high levels of performance in an Agile environment. Want to experience some of my teachings in person? I would be privileged to collaborate with you at one of my upcoming events.

Try some of my recent posts and let me know if they inspire you to bring out the best in Scrum in your organization:

—————————————-

The original version of this post can be found on LinkedIn Pulse.

Read More

Sprint Review Technique: Videos

File this one under: “how do you do Sprint Reviews when you have lots of teams?”  Indeed, the traditional presentation format gets long, boring, and ineffective when you have more than a handful of teams presenting at a Sprint Review.  From the point of view of an executive, this is exponentially true if you are overseeing many different products.  The Video Sprint Review technique can help.

I learned about the Video Sprint Review from Aaron Bjork at Microsoft, and if you skip to the ~40 minute mark of this video you can hear it too.  Basically, with hundreds of developers, it doesn’t make sense to do a presentation style Sprint Review every few weeks.  So they’ve adopted a pattern of “Sprint Mails.”  Each team sends out an email at the beginning of the Sprint with what they have planned, and at the end of the Sprint with what they have DONE, along with a video of the working software.  This email goes to all the teams and all the management:

SprintMail
An example “Sprint Mail” from Microsoft. Sprint Plan on the left, Sprint Review including a Video on the right. Screenshot from the linked video.

 

A few things about this really work for Scrum at scale. And there are a few dangers.

What works is that it’s actually feasible that a single stakeholder could review dozens of videos each Sprint. Whereas a traditional Sprint Planning meeting would take hours and hours, these short videos deliver information in concentrates bursts. The constraint of a 2-3 minute time-boxed video encourages the team to show the most important stuff in a highly organized and distilled way. This scales well, both in size and in geography – much easier to work with a distributed team using this technique.

A few things to watch out for, besides the urge of creative folks to make Hollywood quality productions, as Aaron points out in his talk. This technique is largely unidirectional. The teams are telling the stakeholders what they’ve done. It’s incumbent on the stakeholders to speak up, and actively search out the teams and give feedback about what they’ve seen in the videos. This takes a special kind of culture, and managers are going to have to constantly work on creating this environment. The closer stakeholders and teams work together, the better product you’ll end up with.

Another thing to watch for is the Definition of Done. We need to be extremely clear on what DONE means, especially when it comes to deployment environments, as a lot can be concealed in a video. Perhaps a good addition to these Sprint Mails would be a DoD checklist, or starting the video with a quick review of what DONE means.

With these things in mind, I hope you consider adding this technique to your bag of tricks. Video Sprint Reviews can be very effective at scale, with many teams, and with many products.

Read More

Giving Feedback – A Worse Than Useless Idea

making judgement, aka giving feedback
A judge preparing some feedback, a.k.a. passing judgment

 

One of the favorite activities of HR departments seems to be herding people into teamwork trainings. In these trainings they will have endure learning about all sorts of ideas related to teamwork. Most of them with no scientific validity. Learning to give feedback to other team members has its sure place in sessions like these.

We also have the common practice of managers giving feedback to employees. This is a particularly toxic version of the feedback idea.

I guess that the belief is that it all will contribute to better teamwork and performance. It does not though.

The whole idea of giving feedback to others actually prevents any type of progress towards collaboration.

If you are interested in agile ways of working, this is something to think about. Most agile ideas are based on increased collaboration…

Why Give Feedback?

The way I see it, the idea is often that:

  • You will bring to the attention of others how they have behaved/performed.
  • After receiving your helpful feedback, they will then be able to improve. In the direction that you so graciously have identified.

Thus, the feedback is about the other person. You tell them how things are so that they can alter their behaviour. Great idea!

So What Is So Wrong With That?

Many things…many things…I’ll focus on one aspect below:

From Team Facilitation Point of View

The problem is the mindset commonly associated with giving feedback. I perceive it like this:

  • The way I percieive reality is the right one!
  • I will now educate you on what the truth is! That is a one way process!

In the research of Argyris and Schön, we find a similar mindset called “Unilateral Control Mindset“:

  • I understand the situation; those that see it differently do not
  • I am right; those that disagree are wrong
  • I have pure motives; thiose that disagree have questionable motives

Pretty similar, isn’t it! For me, the way “feedback” is most often used, is deeply rooted in the mindset of unilateral control.

If so, how would that affect things in a Scrum/Agile team or in an agile organization?

“It would prevent any sort of progress when it comes to collaboration!”

Wow! And that is the opinion of master facilitator Roger Schwarz. Author of “The Skilled Facilitator“, the standard textbook for team facilitation.

In his book Schwarz dismisses the unilateral control model. Instead he bases his facilitation approach on the quite different “Mutual Learning model“.

The Mindset Of Collaboration

Some assumptions in the Mutual Learning model are

  • I have some information; others have other information
  • Each of us may see things the other do not
  • Differences are opportunities for learning
  • People are trying to act with integrity given their situations

According to Schwarz, when acting from these assumptions, true collaboration, synergy and growth is possible.

So, what is the difference? A key difference is that with this mindset you do not assume that you understand the full picture. You accept the fact that in a complex environment, such as a team or an organization, for one person to know what the “truth” is not possible. Instead you focus on learning.

So, please stop giving feedback/passing judgement on others. It does not matter if the “feedback” is good or bad.

You do not have the full picture, pretending you do is both silly and unproductive.

My Take On It

So, what to do then? Communication and collaboration is great. It is just that giving feedback is not the way to achieve that!

Here are some alternatives that have worked well for me:

  • Make sure that you know what the needs of people in your environment are.
    • What do your teammates want to experience, learn, achieve etc?
    • What would make them feel that working together is worth their time and full attention?
  • Take responsibility for making your own needs known
  • Take responsibility for that the way you work adresses the needs of the people around you
  • Engage in dialogue. Do not give feedback.

Note that these are all focused on you. Your learning, your needs and what you can do. So, if this does not work out, you know who to talk to… ;-)

Good luck, and if you have any feedback on this article….you know what to do with it ;-)

(Sent it to me that is, in the comments field, for mutual learning…;-)

signature

 

 

 

 

Also published on: http://www.cedur.se/giving-feedback-a-worse-than-useless-idea/

 

Read More