2016-05-27_22-55-59.jpg

 

I love to walk around team spaces and identify cool things that people are doing so I can share them with the organization.  Last week while doing a Gemba Walk in one of my offices I found this!

On his metal scrum board he created “What’s at Risk” information radiator magnets in the design of a traffic light.  Red indicates that the story is at risk with a high likelihood that it will not be completed this sprint.  Yellow indicates that the story is somewhat at risk and there is a chance that it will not be completed this sprint.  Green indicates that story is not at risk and is expected to be completed this sprint.  He uses two magnet discs to cover up the extra colors and only displays the current risk state of the story.

This is a great, simple way to make risk transparent to the team so they can make appropriate decisions and adjustments as well as communicate properly to stakeholders.  Placing the information radiators on the scrum board makes it very easy for anyone walking by to know exactly what to expect this sprint.  It also gives indications that help may be needed to remove roadblocks or provide information in order to help the team move forward on that story.

Information radiators are a great way to promote transparency.  How are you using them to help your team grow and to allow others insight into how they are doing?

IMG_0077

Agile values and principles are the core foundation by which Agile organizations operate and make decisions. Everything we do is based in these.  With that being said, viewing every principle through a holistic perspective is absolutely necessary.  Every word in the principles we live by has value and impact.  So, when we reduce a principle to a three word summary, I believe we do ourselves a disservice.  This practice often results in focusing on part of the principle without the balance of the other side.  Through this oversight, we inadvertently create environments where there is unbalance that leaves people frustrated and confused.  They begin to believe that Agile is the problem.  But, the real problem is our failure completely embrace the Agile values and principles and settle for anti-patterns instead.

Today, I’d like to take a deeper look into Agile Principle #8 which states:  Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 

People often refer to this principle as the sustainable pace principle.  The most common description given of how we practice this principle is that the development team should not be expected to do more work than they can complete in a normal business day.  We don’t want people working 70 hours a week because they are forced to do more work than is possible during a normal work week.  Working at that pace is something a team may be able to do for a sprint or two but they cannot work at that pace indefinitely.  When people are tired and overworked they make more mistakes and it actually slows down their ability to produce work.  It also impacts motivation.  When people are overworked and have no work/life balance motivation dwindles.

But there’s another part to this principle that I don’t hear quoted as often.  It’s the part that talks about the constant pace at which the sponsors, developers, and users should be able to maintain.  This is about the consistency of our delivery, sometimes referred to as predictability.  Developers should be able to trust that sponsors and users will allow them to work at a sustainable pace.  In return, sponsors and users should be able to trust that developers will consistently provide a continuous stream of valuable software.  The team has a responsibility to be transparent with the sponsors and users regarding how much work they can complete in a certain timeframe.  They also have a responsibility to be transparent when the forecast must be changed along the way due to new information or unforeseen problems.  This gives the sponsors and users the ability to communicate and make decisions regarding the impact of the forecast change.

How does this impact the way the team conducts planning and communicates their forecast?  Teams should plan for as much as they can realistically complete and communicate that forecast.  Then, they should strive to complete 100% of their forecast every sprint.  If something happens to prevent the completion of the forecast they should communicate as soon as feasible to stakeholders so they know what to expect.

Should teams forecast 125% of what they believe they can realistically complete and be happy if 80% of the work gets finished?  No.  Why?  First, because it sets unrealistic stakeholder expectations to communicate more work than the team can realistically expect to finish.  Second, because it contributes to a lack of trust between the stakeholder and the team when the team keeps promising work they consistently don’t deliver.  Third, because the extra time planning and tasking stories that aren’t likely to be worked creates waste and adds unnecessary time to the planning process.

Then what do we do with “stretch” stories?  It is my belief that “stretch” stories are not a part of the forecast.  Plan and communicate what you believe you can complete.  If the backlog is groomed properly it will always have at 1-2 sprints worth of work in “ready” state.  So, if the team runs out of work they can always agree to pull in another story.  The solutioning and tasking for that story can take place when the decision to pull it in happens.

If the team consistently gets 100% for 3-5 sprints, stretch yourself and bring a few more points into your sprint forecast.  It may take you a couple of sprints to get to 100% again but it will stretch your ability to produce work and push you to incorporate practices like automation in order to move faster.

There should be an understanding that no team will always complete 100% of the work forecasted.  This is another part of the concept of trust and transparency.  Stakeholders and customers trust that developers will always strive to complete 100% of the forecasted work.  Developers trust that when something happens and they can’t deliver 100% and communicate openly to stakeholders and users there will be grace and understanding extended.

 

IMG_3265

One of my favorite things about being and Agile coach is connecting with the Agile community through conferences, meet-ups, and other networks.  Because of these connections I get to interact with  Agilists all over the world.  Over the past few months I’ve noticed a concerning trend coming from the Scrum Master community.  They are telling me with excitement, “I’ve finally worked myself up to two teams!”  Some have said they are now working with three or four teams.  The thing that concerns me is that they seem to view spreading themselves across multiple teams as an accomplishment.  I am hearing pride in “being busy” and “being able to handle more” and that tells me that we still have work to do.  It tells me that there may still be an anti-pattern running rampant in our Agile organizations telling us lies.

The belief that “the more I can handle and the busier I am the more valuable I am to the company” is left over from days when sustainable pace wasn’t a part of the culture.  The truth is that busy does not equal productive.  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  It is not to ensure that everyone is at least 100% (or more) utilized.  Agile processes are supposed to promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  When we are running at 100% (or more) of our capacity we cannot maintain that pace indefinitely.  At some point, we burn out mentally, physically, and emotionally.  We cannot afford choose utilization over productivity.  Our primary measure of progress should be working software, not how much more we can get done with fewer people.  The efficiencies in an Agile organization don’t come from piling more work on fewer people.  They come from improving our technical practices, increasing automation, increasing quality, lowering technical debt, collaborating, and learning to continuously improve our processes.  These things give us the ability to produce more without adding employees because we stop tripping over ourselves and can run along a clear path.

I read the following question from a user on stackoverflow.com:

“Does running your servers at 100% CPU usage cause any issues or is it just good CPU utilization?  My servers have 8 physical cores constantly running at near 100% for “open hours”/10 hours per day.  The program is architected to run on 8 threads – and it fully uses them. Performance is good but the infrastructure guys are worrying about the “maxed out servers.”  I think it’s just good use of available resources. What’s the point of having lots of core if they are not all fully utilized?”

The problem with this line of thinking is that when resources are fully utilized they don’t get more done.  Contrarily, less gets done.  They move slower, wait time increases, and so do errors.  Here’s the response someone gave to this question:

“Almost without exception it causes issues, or will cause issues down the road (as demand grows).  100% CPU utilization on a web service server is not good.  If your CPU utilization is at 100% it means that each time the server gets a new request there is a 100% chance that the work will have to wait some amount of time before the server gets started on it.  The typical performance sweet spot is about 70%.  Does that sound low?  If so, remember that 70% utilization doesn’t mean that 30% of the CPU is being wasted.  Instead, it means that 70% of the CPU’s capacity was used over a sample period.  For CPU measurement metrics, a sample period is something like 2 seconds.  During that 2 seconds the breakdown of that 70% is uneven.  In other words, it may be something like 100% for 1 second and 40% in one second.  For short bursts like that, 100% utilization is okay because we know that if a piece of work is delayed it is only for a brief period. (One that won’t make the human waiting upset.)”

I’m wondering, if we adhere to this rule with our hardware resources, why don’t we realize that the same rule applies to our human resources?

I’ve been in the position where I was a scrum master on one team doing an excellent job.  I knew the pulse of my team and they were growing rapidly and performing better than ever.  Then, I was given a second team.  Sure, I had enough down time in my average week to handle facilitating Scrum events for two teams (in theory) but because I was toggling between two team rooms I missed a lot on both. On sprint end/start days I felt very pressured.  I ran from one retro to the next on and often couldn’t compile the improvement plan into a consumable format until two days later.  I fell behind updating information radiators and had less time to think analytically through what was happening with each team.  Over time I saw that both teams were maintaining, even growing some, but the rate of growth was slower than when I had only one team.

Then, something tragic happened.  I was “doing such a great job” that I was asked to take on two more teams for a month to fill a hiring gap.  I felt like a total failure.  I had to choose which teams I was going to work with and leave the others stranded.  I had no clue what was going on in any of the four teams because I wasn’t spending enough time with any of them to catch the important conversations.  My teams all felt abandoned by me and had to pick up the slack felt by my absence.  While in my manager’s eyes nothing fell to the ground because my teams were mature enough to fill in the gaps without me, my teams felt all the pain and none of the benefit.

I learned a very powerful lesson through that experience.  Being utilized at 100% (or more) capacity didn’t make me a super Scrum Master.  It made me a terrible Scrum Master.  On a ledger somewhere it may have looked like the company saved money by utilizing me to full capacity but the impact of the hidden cost was much greater than the financial gain.  We would have done better to allow the third and fourth teams to work without a scrum master for that month.  Instead, we caused four teams to operate without a scrum master by spreading me too thin.

What message do we send as an organization when we tell our teams we expect them to plan their sprints at 125% of their capacity?  It’s a message that says we do not value sustainable pace.  What message do we send when we tell our employees we want them on multiple teams so we can fully utilize their capacity?  It’s a message that says we do not value sustainable pace.  What message do I hear when Scrum Masters tell me proudly that they are working on multiple teams?  I hear that they have forsaken the Agile principle of sustainable pace.  I hear an anti-pattern.  It makes me know that though we have come far we still have more work to do before becoming truly Agile.

IMG_0069

While attending the Agile Coaching Institute’s Coaching Agile Teams class a while back the instructors read this poem to the class.  It served as a powerful reminder that as an agile coach, or a scrum master/team coach, we must see people and teams as naturally creative, resourceful, and whole if we want to empower them to grow and move forward.  As a coach I must be a servant to those I coach.  I’m not here to be better than them or to have all the answers.  I’m here to serve them in their quest for greatness.

It’s often a first reaction to want to jump in and fix things and fix people.  It’s so easy to have all the answers.  It’s empowering to play the super hero.  But the real power is in allowing people to identify their own solutions.  The real power is in self restraint and waiting for people to grow and change on their own.  The real power is in stepping back so other people’s greatness can shine forth.

This poem serves as a daily reminder that it is impossible to both be a fixer and a servant to others.

A Fixer*

A fixer has the illusion of being casual.

A server knows he or she is being used

in the service of something greater,

essentially unknown.

We fix something specific.

We serve always the something:

wholeness and the mystery of life.

Fixing and helping are the work of ego.

Serving is the work of the soul.

When you help, you see life as weak.

When you fix, you see life as broken.

When you serve, you see life as whole.

Fixing and helping may cure.

Serving Heals.

When I help, I feel satisfaction.

When I serve, I feel gratitude.

Fixing is a form of judgment.

Serving is a form of connection.

*Author Unknown

IMG_2084

I spent some time coaching one of my clients* recently who was planning an event and needed to enlist the help of others in order to be successful.  The problem she was facing involved feeling overwhelmed.  She knew that there were many details that she didn’t have the best skill set to handle.  She said that she felt stuck because she didn’t know who she could pass the responsibility to and didn’t know how to hand over the work to them.  She felt like she had to maintain the ownership and babysit all of the details and that feeling was very overwhelming.

As we worked together we identified that what she needed was more confidence in her understanding about how delegation works.  This is what we discovered that enabled her to move forward and have a more effective working relationship with the others on her planning committee.

1.  Set proper expectations.  Describe the responsibilities you expect the person to take on.  Set boundaries around what they should and should not do.  Describe the outcomes you wish to see.

2. Determine and agree upon the feedback loop.  Set expectations for how often you expect to get reports on progress, how detailed the reports should be when presented.  Set expectations for how you want the information communicated.  For example:  written reports, emails, meetings, informal communication, etc.

3.  Empower with proper authority to accomplish the task.  Establish clear guidelines for the amount of authority they have to make decisions and when they should seek approval.  Give them the autonomy to work within the expectations and boundaries provided.  When others come to you to make decisions in areas where you have given the delegate authority, point them towards the delegate for answers so you do not undercut the authority given them.

4.  Check in at established intervals and make adjustments to the agreement as needed.

Following these simple steps to delegation can help you be a more effective leader.

*Printed with permission

logo

“Tell me why you think we should consider you for the CST.  I’ve never heard of you, never seen you at any user groups, haven’t met you at any conferences, never seen you speak publicly, and you are making no contributions to the agile community.”  Those words spoken by Devon Morris, CST were critical to my path to become a CEC.  His advice to me that day was, “If you want to be a CST do something about it.  Get out there.  Join the Agile community.  Go to user groups.  Go to conferences.  Speak at conferences.  I want to see you and know who you are.  And you can never stop coaching.  You can’t be a good CST if you aren’t coaching.  That’s where everything you know comes from.  That’s where you gain your credibility and true expertise that can help people.”  Well, Devon, thank you for being hard on me.  Thank you for speaking truth to me.  Thank you for shining some light on my path.  And thank you for inspiring me to go forth and conquer.

I’m writing about the experiences I had on my journey to being a Scrum Alliance Certified Enterprise Coach because it is a long journey that many never complete.  There’s no one way to get there because everyone has a different road to walk.  My road was about following my heart and always chasing things I was passionate about.  My road wasn’t about the application process – it was about the growth and learning I encountered along the way.  And I would like to share a few things about my experience that I hope will help others.

Tip #1  – Remain humble.  Be open to input and advice.  Listen when the reviewers and mentors who have walked this path before you give you feedback.  They aren’t picking on you.  They want to see you grow and want you to be successful.  If they tell you that you need more experience, go get it.  Don’t get mad…get better!

A couple of months after my conversation with Devon, I heard a fellow consultant and agile coach saying that he had applied for the CSC (the former name for CEC) and had been rejected and he wasn’t very happy.  This sparked my curiosity because I had never heard of the program so I began to investigate. What I found was that the CEC was a much better path for me because it was more closely aligned to what I really loved doing — Agile transformation.  I pulled the sample application from the website and started looking over the monstrous requirements to be a CEC and realized just how spot on Devon’s advice was to me.  And just how far from qualified I was.

I knew that I had at least 3 years of hard work ahead of me just to qualify to fill in the application.  But, the application I held in my hand was more than just a path to a certification.  These requirements were the guide that I would follow to learn and grow as an agile coach.

TIP #2 — Be strategic.  Get the application and pay close attention to the requirements.  If you don’t clearly meet them all make a plan to close the gap.  Don’t be in a hurry to get the certification.  Remember, the journey is about your growth as a coach.  The goal is to learn to be excellent – not just meet requirements for a certification.

I started investing in the agile community by speaking at conferences and user groups.  I volunteered to mentor people in the agile community and connected to individuals I coached to develop mentoring relationships — all things I completely loved.  I learned to surround myself with people who were more experienced than me who I could learn from and I watched them and listened to them.  They served as mentors to me and validated my gut instincts and helped me to learn to make better decisions in my coaching.  They gave me advice about how I could be better – and they were right!

TIP #3 – Invest in yourself.  Invest in others.  Get involved in the Agile community.  Allow others to invest in you.  Be with passionate people and learn from them.  Remember, the CEC isn’t just a certification.  It is a way to validate and confirm that you have solid experience and expertise that can help people and organizations experience success.

One decision I made early on was that I would only work with a client for one year or less.  This personal choice allowed me to work with three fortune 500 companies in three years getting experience in multiple different industries.  It provided the opportunity to try new methods and expedite learning through success and failure.

TIP #4 – Get experience in multiple organizations and learn from your mistakes.  Learn that what works with some won’t work with others.  Focus on teams.  Focus on management.  Focus on C-Level leaders.  You must have solid experience in all three to be an effective enterprise coach.  Experiment and fail.  Learn, learn, learn.

At some point I realized that my skill set needed to be expanded into professional coaching in order to truly serve my clients well.  So, over the next 2 years I took 170 hours of professional coaching training from two different coaching schools.  I practiced these skills with individuals, teams, and people outside of the agile industry.   I paid mentor coaches to monitor coaching sessions and give me feedback that helped me to sharpen my coaching skills.  While focusing on professional coaching I continued to  attend conferences and other agile training classes where I was able to learn how to use these new skills in an agile environment.

TIP #5 – Get educated.  You must have professional coaching skills in order to coach leaders and to effectively coach organizations in transformation.  My recommendations for this training are:
  • CTI (Coaches Training Institute) is a great coaching organization who works with a lot of agile coaches.  They teach creative co-active coaching which is focused on individual coaching but the techniques are easily translated to coaching teams.
  • ORSC (Organizational Relationship and Systems Coaching), taught by CRR Global is another valuable recommendation.  This coaching focuses on coaching groups, teams, and organizations specifically. They also work with a lot of agile coaches.
  • Agile Coaching Institute teaches several valuable courses that will help you to apply these professional coaching skills in an agile environment and at the enterprise level specifically.  I recommend the Coaching Agile Teams Bootcamp, The Coaching Stance, The Agile Manager, and Agile Wizardry for enterprise coaches.

Periodically, I checked the application that still sat on my desk where I’d laid it when printed and used it to guide me as I filled in the gaps in my expertise and experience.  Finally, over three years after my conversation with Devon, I paid the fee and got the official application from Scrum Alliance.

Tip #6 – Cherish the experience.  Completing part I was a beautiful experience for me.  Filling in the information gave me the opportunity to think about all I had done and learned over the past few years.  It also helped me to recognize and remember all the people who contributed to who I am today.  I felt humbled as listed mentoring relationships I had formed and recalled how amazing it was to watch people grow into great scrummasters, managers, and teams.  It was actually a bit overwhelming to see it all written in one place because until that time I didn’t have a complete record of my journey.   It took me two months to fill in Part I because I took my time and thought through every section carefully as I filled in the details.  After submitting the application I waited anxiously about a month before getting the approval to move to Part II.

When I read through part II my heart stopped.  I read over every one of those questions about 50 times and they were intimidating because I had no idea how I would answer them.  It all seemed very easy until the moment of truth came.  So, I just took it one step at a time.  I read questions one at a time and internalized them.  Before attempting to craft an answer, I thought on each question for days … sometimes weeks … and over a month on a few occasions.

Tip #7 – Take your time to understand the questions and to really understand your position on the answer.  There isn’t a time limit to complete the application.  Rushing will not serve your purpose.  Be honest.  Be vulnerable.  Don’t try to look like a super hero.  It takes maturity to honestly explain what you have learned through your failures and to show how you recovered to help clients move forward.

I wasn’t sure how many of my references would actually send in a referral so I contacted extra people just to be sure.  It took several months for the recommendations to be sent to Scrum Alliance because people weren’t sure exactly what they should say.  I asked them to be completely honest about the quality of my work, the state of their organization when I arrived, how I impacted the organization, and to describe any impact I had on them personally.  I also sought references from people at multiple levels who were able to describe my work throughout the layers of the organization.

Tip #8– Decide who the best people for client recommendations are and speak to them early.  Clearly explain what the recommendation is for and ask if they are willing to speak on your behalf.  When they say yes, clearly spell out what the recommendation needs to contain and how to send it to Scrum Alliance.  Ask them to be finished by a specific date.  If you do not get a notification from Scrum Alliance by the agreed upon date, follow up and remind them of the need.

Finally a year after beginning part one I completed part II.  I held on to the application for another two weeks and carefully re-read and revised my answers until I felt completely comfortable with them.  After submitting part two I received a response telling me that one of my answers was too long and that I had too many recommendations.  After revising the answer,  I had to make a note on the application telling the reviewers that if they chose to only consider two of my client recommendations and one mentor recommendation, which ones I preferred them to consider.

Tip #9 – Adhere to word limits and follow all the instructions.  Be patient and be professional.  Remember, every reviewer is a volunteer who is reviewing applications that can be 40 pages long on their own time in order to help you grow.

Throughout the entire process, about once a month I received an email showing where my application was in the process.  It took about two months for my application to be reviewed once I submitted part II.  But finally, I received that long awaited email telling me that my application was approved.  One thing that I didn’t know about during the process was that there is a google group for CEC Candidates that you can join to ask questions and even connect with a CEC who will mentor you through the process and give you feedback on your application.

Tip #10 – Join the CEC Candidate google group and read the postings.  They will give you information that can help you.  Ask for a mentor to review your application and give you advice.

The journey to become a CEC is long and hard.  It is also a journey worth taking.  Don’t give up even if you submit your application and it doesn’t get approved right away.  Listen to the feedback and go learn more.  Remember, what’s really important is that you become an amazing enterprise coach and serve your clients well.

2016-05-24_08-36-53

 

A Few weeks ago while attending a Coaching Agile Teams class I heard one of the instructors (Lyssa Adkins) make a reference in passing to “signal to noise” ratio in reference to our ability to communicate with others.  Her comment intrigued me because I’d never heard that phrase before, so I started to do some investigation.

Signal-to-noise ratio (abbreviated SNR or S/N) is a measure used in science and engineering that compares the level of a desired signal to the level of background noise.

Signal-to-noise ratio is sometimes used informally to refer to the ratio of useful  information to false or irrelevant information in a conversation or exchange. For example, in online communities, off-topic posts and spam are regarded as “noise” that interferes with the “signal” of appropriate discussion.
Signal-to-noise ratio is defined as the ratio of the power of a signal (meaningful information) and the power of background noise (unwanted signal):

SNR =  Power of the Signal / Power of the Noise

The higher the SNR the less noise is in the conversation.   For example, a conversation that had 15 sentences on topic (signal) and 3 sentences off topic (noise) would have a SNR score of 5.  But, a conversation that had 15 sentences on topic (signal) and 23 sentences off topic (noise) would have an SNR score of .65 and would more than likely be a less clear and effective conversation.

Signal-to-noise ratios in conversations often go down when people feel the need to qualify their comments with explanations.  These explanations, while intended to convey clarity around the message, often lead to confusion because they make conversations harder to follow.

Another signal-to-noise ratio killer happens when people attempt to clarify questions by stacking other explanatory questions on top rather than just letting the question stand on its own merit.  Questions become less powerful when the listener has to sort through multiple questions and determine which one to answer.  The reason people stack questions is driven by a fear that their original question was not clear or that it needed to be justified.  It is better to just ask one question and trust that if the listener needs the question clarified, they will ask for clarification.

One skill that coaches use to combat the signal-to-noise ratio is bottom-lining.  Bottom lining is when you strip all the extra words out of conversations, sentences, and questions and speak to the essence of the message you want to convey.  Bottom lining uses fewer words and creates a higher signal to (lower) noise ratio.  Because there is less noise in the conversation it is easier to follow and remain engaged.  It is proven that the most effective questions generally contain 3-7 words; so,  asking questions in this bottom line manner the questions actually become clearer and easier to answer and thus, more powerful.

One exercise you might try while learning this skill is to tell a story in 1 minute.  This exercise helps you learn to sort through all of the details you could tell and forces you to speak to the essence of the story with only the most important information.

Another way you can practice this skill is to review emails and other written correspondence before sending them and determine how many words you can pull out by rephrasing.  What information is not really important to the main point of the message you are trying to send?  Can you bottom line the information into 3-4 bullet points?

I encourage you to practice this skill and pay attention to the difference it makes in your conversations.  Notice if some of your monologues start shifting to dialogues.  Keep in touch and let me know what you learned through the experience.