Jerry asked the coaches how they received the title ‘Coach‘ and when it came to my turn I said it’s for marketing.  All the cool kids are doing it, that’s what the industry is asking for and it sounds a whole helluva lot cooler than ‘Business Process Consultant‘.

About a year ago while talking to a couple senior people at the organization I was working with, I realized there was a whole lot more to ‘Coaching‘ than I thought.  I was getting pressure to commit to having a project done with fixed scope for a fixed date and instead of trying understanding their perspective, I immediately went into ‘Agile Coach‘ mode and tried to explain to them why they were wrong.  Needless to say it failed miserably.   Over the last year I’ve had several epiphany’s about what a coach is and it all became crystal clear during a recent coaching session hosted by Michael Spayd.

Michael and Lyssa Adkins have been delivery “What is an Agile Coach?” webinars recently and Michael shared the model with our coaching circle:

The model is based on 4 pillars:

1. Coaching/Facilitation: It’s always about the client, not you.  IE: don’t let Agile get in the way of success
2. Education/Mentoring: Understand what level the client/teams are at to choose the best approach.  IE: more green teams need ‘how’ and a more directive approach.
3. Agile/Lean Process Knowledge: When to use which one and the rationale behind it.  IE: Figure out what process suites the work being done.
4. Domain Mastery: being able to coach AND do.  IE: An XP Coach who can coach AND write code.

What I love about this model is that it can help organizations understand what is expected of a coach and it can help coaches improve their skills by having some concrete details about what skills and knowledge are needed to help organizations become successful.  More importantly, it can help identify areas where the transformation may be falling down.  For example, if you’re focused on installing Scrum and ignore (or aren’t aware) of human transformation or organizational transformation you may optimize the team temporarily.  Once the Coach is gone, the transformation may not stick.

A team I worked with at a large enterprise company really understood what ‘being Agile’ really meant.  They didn’t have the process knowledge initially but they had desire and commitment to learn.  Simply put, these guys were awesome.  As their ‘Coach‘ my approach was very much non-directive as that’s what I believed would serve them best and they did not disappoint.  They outgrew me after a few months because I helped them be aware of their situation (often referred to as ‘holding up the mirror‘ to the team) and gave them the tools and knowledge to manage those situations.

At another client I worked for, they needed much more ‘how to‘ coaching so I took a much more directive approach where I would tell them how to apply the process until they learned it well enough to mold it to fit their work and style.    In this same organization, I was pairing with Alistair McKinnell.  He has super-mad skillz in XP.  He was very well-rounded in all pillars and was particularly strong in the Domain Mastery and Education/Mentoring pillars because he could get dirty with the teams and help them with code all the while helping them understand better technical practices.  I couldn’t do that.  I felt stronger in the Coaching/Facilitation and Process pillars as well as having deeper knowledge of Product Owner practices.  This combination of skills worked very well together.   Where we lacking, in my opinion, was deeper organizational change knowledge.  We knew that at the time and the focus was at a deeper level, however having this model would have been helpful as a communication tool to the client in the sense that we could point out where the train wreck was going to be.  We ‘knew’ and struggled with verbalizing it or creating a visual model to help them be aware of it.

This Coaching Piller is what’s missing from the Agile Community and I think it’s a more effective model for addressing the certification problem than all of the new programs surfacing today.  Certification helps with 1 of the 4 pillars, there’s still much more skills required to be an effective coach.  This model will create a new level of awareness for coaches and organizations and I think it relates well to the 4-step model I use when engaging with clients.  I would also argue this model can be applied to managers and leaders.  If they can understand what a coach can do for them, they can learn these skills and help their organization self-sustain their Agile transformation.

I’ve been participating in a couple of coaching circles hosted by Michael Spayd for about a year now.  In that time, I’ve learned various aspects of this model through what he has shared and what other members have brought to the table.  This has been much more valuable to me as a self-identified Coach than any process training I’ve done.  It’s helped me understand areas where I need to improve and also helped me understand how to find the best approach for the given situation I’m in.  I plan to use this model right away as a tool for me to visualize what an organization needs to be successful and where I can and cannot help them.

Are you a coach or coachee?  What do you think about the model?

Anywho, onto the position paper:  You’ll notice these are high-level points, that’s the point of Coach Camp.  The goal is to share experience and gain feedback from the Agile community.

Title: A Recipe for Enterprise Agile Transformation

Background and Challenges:

• large department within large organization
• tall hierarchy, great deal of office politics
• heavily silo’d organization
• complex product portfolio
• mix of full time, contractors, outsourced developers and teams
• limited people with Agile experience in the organization
• no recognized Agile champion

Speaking and Presentation topics I plan to share:

• transitioning focus of functional managers and other roles
  • there is much confusion about ‘where does my role fit’?
• breaking down silos between multiple groups
  • having to prove you are worthy of being trusted
  • demonstrating and sharing success and failures
• portfolio and team organization
  • how to structure your teams with the right skills for the project
• techniques for handling ‘specialist’ groups
  • how these groups interface with teams
  • how these groups share information gained from working with multiple teams
• cross-project knowledge sharing (technical or process related)
  • getting people together to talk about experiences.
• How PMO and process teams evolve
  • more teaching and coach, less command and control
• spreading Agile culture
  • making it about the organization, not the coaches
  • teaching the organization to think for themselves

The above topics will be accompanied by some fancy diagrams I’m working on for an experience paper and due to the format of Coach Camp, if my paper is accepted and put into the plan, the topics discussed with likely be determined by what my peers want to hear about.

I am still planning on writing and experience paper I had hoped to have finished by now where I can share more details.  Interested in your thoughts and experiences!

I had been asked to present a quick talk on Scrum for a couple of new teams that will be starting up soon, followed by a quick overview of these new projects.   The output of this session coupled with what I learned at AYE and through the weekly coach round-table I attend with Michael Sahota, Gerry Kirk and Declan Whelan (special thanks to Michael Spayd for his recent ‘guest appearance’!) gave me some inspiration to write this.  I hope it is of value to you.

Client Success over Personal Gain:  The Coach isn’t the hero.  They are there to help the organization.  They need to understand the client and contribute to their success, without worry about accolades or personal gain.  This includes the coach fulfilling his duties to the best of his abilities instead of holding back to extend the gig.  I like to take the approach that my goal is to work myself out of a job as efficiently as possible because the organization needs to be self-sustaining to succeed.  Others will argue that “well, I need to make a living” but I knew the risks when I took this path.  If I’m any good I’ll find more work.

Guiding over Dictating: Resist the temptation for the ‘my way or the highway’ approach, especially in organizations that have a more controlling culture.   Organizations need to learn and they learn the same way a team learns, through experimentation.  A coach needs to help guide them to the answer because the people in the organization are best served to find these answers with the help of a coach.

Objectivity over Subjectivity:  The coach needs to remain agnostic in order to avoid making emotional decisions.  I do get frustrated when my observation is that the client isn’t listening but that just means I’m doing a poor job of communicating. Remain clearly focused and you will serve the client better.

Adaptation over Doing-What-Worked-Last-Time:  Ok, so this one is the same as ‘Responding to Change over Following the Plan” however I mean that organizations are unique.  What you were successful with at your last gig won’t necessarily translate into success at your current gig.   To me, this one is about understanding the organization’s culture so you can frame your approach.  Controlling cultures will require a different approach as opposed to collaborative cultures for example.

I firmly believe it’s the responsibility of any coach to make sure the Agile transition is about the client.  Deflect focus from being the expert and help the organization understand that Agile is a tool and it’s only as good as how it’s used by the people using it.

A common theme that has been emerging from the classes I’ve been delivering and conversations I’ve been having are along the lines of “wow, we need to change our culture” or “agile won’t work here because … <insert excuse>“  There seems to be a clear delineation between these 2 camps.

I blogged previously about the importance culture has with an Agile transformation and I make sure that I convey that to anyone I talk to that is new to Agile.

The first statement I usually use to combat this fear, uncertainty and doubt is the fact that there always must be a reason to transform to Agile.  Companies aren’t switching for the sake of being cool and hip, well if they are they have bigger problems, but instead they are switching because fundamentally, the way they are working is broken.

Transforming to Agile requires a deep organizational commitment and a fundamental shift in how companies operate and how departments and people interact with each other.

So underneath the skepticism and FUD, what’s the REAL problem?  What are people afraid of?  Here’s a brief summary of the top 3 excuses for why Agile don’t go ’round here:

1) We can’t have a SINGLE product owner, we need multi-level signoff and too many people are “the go to guy”

2) Agile won’t work here, everybody works on multiple projects at the same time.

3) Management tells us we HAVE TO launch with all these features on this date.

Hmm.  So what do we do?  Where’s the Agile checklist that allows us to fix these problems?  I’ve seen Scrum teams absolutely banging their heads against a wall trying to figure out why their fixed-date, fixed-scope projects either don’t make it or have terrible quality.  In this cas,e the ‘rapid de-scoping phase‘ happens in order to make the date but in that instance the damage is already done.  The teams inability to say no has rendered their yes useless, mis-trust ensues and the cycle repeats itself.

I’ve had this post brewing for a few weeks and decided to post it after our pilot team’s recent success and after reading Gil Broza’s great post entitled “so you think you’re Agile?”

While our topics do differ, the underlying tone is the same.  Organizations needs to understand what being Agile is.  They need to look to the manifesto, not to the Nokia Scrum test or a checklist.  They need to un-learn what has been instilled through so many years of the command and control approach.

AYE helped me change my approach from saying “here’s what you’re doing wrong and here’s the right things to do” to “what are you concerned about?  what are your challenges?  how can the knowledge and tools I have solve your problems”

Lately that approach is working much better and I find people who want help are more likely to accept help.

10:15am – We usually skip the standup on iteration planning day and since the team needed to travel to the head office for the demo yesterday, we all agreed to do our retrospective today.  Normally we would go right into the retrospective after the demo, but this worked better for the team and they suggested it and all agreed to it.

Retrospectives are new to the team, so we’re following the typical “what went well, not well and what to try” approach but we always start off by reviewing what we wanted to try from the last retrospective and see if it was still a valid improvement and if so, what was the progress.

We finish the retrospective, have a quick break and then get into planning.   The first 2 or 3 sessions were pretty painful but everyone is starting to get a better feel of how to interact with each other.  The team is having a hard time breaking out one of their stories so I suggest that they create one general development task, pair up when they do it and then jot down some notes while working on it.  I figure this will help them for the next time and give them some ideas about how to break up future stories and they generally agree.

I offer to enter all the tasks and hours into the tool but mention that at some point it would be ideal to rotate that duty each iteration between team members.  That will help keep everyone interested and remove their dependence on me, plus it’s pretty simple and everything I do for the team is something they can’t do on their own.   This is especially important given the strict waterfall background where they’re just used to being handed tasks and relying on a PM to do this type of work.

2.30pm - After ordering on some pizza for lunch, planning is finished and the team gets to work.  Just before we leave the planning meeting I remind the team to start on the highest priority story first and make sure that they don’t start all 6 stories they committed to like they did last time.  They were able to recognize that they felt rushed at the end to finish everything and this approach allows them to finish something and move on as well as allow the business the opportunity to pull out a lower priority story if something more important popped up.  If the team hadn’t started the story, there’s no waste to worry about.

3:30pm - I’m feeling pretty worn out from the previous 2 days and with a 4 hour training session in the morning, a mid-town meeting after training and back to the satellite office after that, I decide to call it a day.  The team had agreed that core working hours were 10 – 3, so I check with them before heading out to make sure there isn’t anything else they need.

On the way home I give my mentor a call to update her on the team’s progress and I ask her if she will attend the training tomorrow to evaluate me and point out how I can improve the delivery of the class.  She gives me an update on progress with the team environment we’ve been trying to get setup for a couple of months now and progress on the new team that is starting soon.

Sometime in the evening – I take some feedback from earlier classes and, based on the audience I am expecting tomorrow, I try and come up with some other examples that might be more relevant to drive the material home.  I toss down some internal blog post ideas, pack up my class materials and head off to bed.

10am – standup. The team wasn’t really happy about standing up at the standups from the get-go so today is the first day we’re actually sitting down.  I have to remind a couple of the guys that they aren’t reporting to me so there’s no need to face me and report their status.  A couple of guys get into a discussion that doesn’t belong in the standup so I ask them to let the rest of the folks finish up and then whomever needs to be involved in the side discussion can stick around afterwards.

10.20am - The Standup finishes a bit later than usual but since it’s demo day the team wants to make sure they are understand what they need to do before 2pm.  Myself and a couple of other team members walk over to the environment support folks and ask that they not allow any changes into the environment we’ll be demo’ing in today and we get the lead’s mobile number so we can call him in the event there is any issue.

11am – We pack up and drive down to the head office, 1 team member stays back to handle any last minute issues.  Today’s the first day the team is doing a full demo to about 40 – 50 people including some stakeholders, observers not directly involved in what we’re doing and, of course, our product owner.  I wanted to make sure the team had the chance to experience this since most of the time in traditional settings stakeholders don’t get the chance to meet the team.

1pm – We get to the boardroom for the demo, setup the projector and go over the stories with the product owner and the general script for the demo.  The Product Owner asks me how we are supposed to keep the demo from going off the rails just in case there is too much feedback so I let her know that when the demo kicks off, we’ll set that expectation properly.  Feedback is great, but I remind her that it should be in context of what we are showing them and other feedback can wait until after the demo.

1.45pm - 15 minutes to showtime and our QA environment goes down.  Uh oh.  A quick email and phone call and at 1:58pm we’re back in business.

2:15pm – After the last straggler stumbles in we get started and the product owner welcomes everyone and introduces everyone to the team.  As the Product Owner is going through the stories (we had given her a demo previously to get the stories accepted) one of the QA guys on the team notices a problem so I grab an index card from my utility belt and write it down.

3pm – The demo finishes up and I have 4 or 5 new index cards with questions and feedback.  Not too much, but some ideas we’ll want to prioritize against the existing backlog.  A couple of folks stick around for more questions and I have a brief chat with the Product Owner about some of the new cards.

4pm – I head over to chat with my boss and let her know how the demo went.  She asks me to setup a couple of training sessions for the next week and we review a blog post I wrote for our internal blog.

She gives me an update on a new team that is forming and will be starting up soon.  Since my team is already doing well, taking on mentoring a new team won’t be stretching me too thin but we talk about the risks and how we can help each other out with it.

5.30 - After a quick check of the Agile support inbox and couple of quick chats with a few other folks wanting some advise, I head out for the day.

A new article will be posted each day this week and I’ve tried to keep them as short as possible.

Week 1 – Monday Morning

8.45-ish – Monday’s always start off with meetings so I make it to our head office downtown and head up to see how the guys from the previous team I was working with are doing.   It’s iteration planning day for them and Joe, their scrum master, asks a few questions about  how he can help them figure out how to task their user stories.  The team is having a hard  time switching from the old way of being told what to do so it’s not coming naturally to them.  They’re finding they have quite a bit of un-finished work at the end of the iteration so we sit down and look at a few of the stories to be presented and I offer some suggestions for tasks they could create and remind him that they should limit work-in-progress so they can finish a story before moving onto the next one.

We talk about possibilities for tasks based on the stories that will be presented with the key message to Joe that he shouldn’t be the one to hand these tasks out.   I remind that the team will figure this out, they may need to some poking from him so at least now he has some ideas he can guide the team to.  Joe heads off to his planning session so I stick around and chat to a couple of other folks before heading out to my first meeting.

10:30am – I’m filling in as a Scrum Master for another team and next up is a meeting with the Product Owner and some other folks on our Product Definition Team.  Our next iteration is starting in a couple of days and the Product Definition Team’s goal is to make sure the stories are ready for the team to pull in.

We draw up some sample wireframes on the whiteboard with the help of the usability person we pull in when needed, take some photos with my camera phone and upload them to the stories in the tool we’re using.  They’re crude but good enough for the team to work with.

Now that we have almost 2 iterations of work ready, according to the team’s velocity, we grab some lunch and informally chat about some cool ideas for future iterations or suggestions the team had last week.  When necessary I scribble some notes on cards for reference later on.

1:30pm – After lunch I meet-up with the other coach (who’s also my boss and mentor) and talk about the Estimating and Planning class we’re preparing for new teams that will be starting up soon. We plough through the slides pretty quickly and get on the same page about balancing the theory with fun exercises.  After that we talk about challenges we’re both having, brainstorm some ideas and co-ordinate what we’re going to work on for the week.

3:30pm – I head back up to our other office where I’m based to see how the team is doing.  This happens to be our first true pilot team working in their 6th iteration and so far so good.  The team really gets it and have already implemented some automated testing, a new build process using Bamboo and have really impressed the business with how much great quality work they’ve been able to do.  I log in to our tool, check the burndown and talk to a couple of the guys and see if there’s anything blocking them that I need to help out with.

Unfortunately the team isn’t co-located yet but we all sit pretty close to each other.It’s great to see how motivated they are working this way which makes it possible for me to spread myself around and not be 100% dedicated as their Scrum Master.  Not ideal, but doable in this situation and the team is providing much more value than “the old way”.  There is still work to do but the motivation is there and some of the “test first??  automate your tests?? the hell you say!” comments are changing to “oh, you know what, if we had some automated tests that xyz thing would have been a lot easier to take out”

4:30pm – As the day is winding down I check our general Agile Support mailbox, respond to a few questions and then send out some invites for an Agile training session I’m delivering on Thursday.  To close off the day I check our internal blog to see if anyone has commented on the last post about Retrospectives I added last week.  One of the PM’s in another group wants to find out what real internal teams have done to improve so I send him the link to our wiki where we post our iteration information and retrospective notes so everyone can see them.

A quick check on tomorrow’s calendar reveals that it’s iteration review day so I’ve got a prep meeting, iteration review and retrospective for the afternoon so I figure it’s time to head out and rest up for the busy day tomorrow.

Experiment. Fail.  Learn, move on and get better next time around. That is what “being Agile” is all about.

There is no magic formula or checklist to make an Agile adoption successful.   It’s up to how willing the individuals are to accept help from a coach or how open they are to getting out of their comfort zone to improve on something that isn’t working.  Class after class I get bombarded with questions that range from how QA integrates with an Agile team to “how does Agile tell you to deal with the expense of buying a developer a laptop?”. (yes, that was a REAL question I was asked once).

Esther Derby posted a few months ago about 5 reasons to hire an Agile Coach which leads me to ask what actually makes a coach successful?  What makes a coach worthy of self-labeling himself a coach in the first place?  These are the top 3 attributes I consider to be the most important:

1) Self-less:  A coach must care about the team (and organization) and morally and ethically do what is right.   A good coach must possess the desire to work their way out of a job for the greater good of the organization that has invested time, money and most importantly trust in the coach’s abilities.  Now in the real world I am quite sure there are some folks who want to extend the gig as long as possible for security or other selfish reasons, but IMO that’s not the point.  If you are trying to teach and organization how to build trust, that lesson starts with the coach.

2) Honesty:  A good coach must be clear that the road may (and mostly likely will) get rough and there is a chance adopting Agile just will not work if the organization doesn’t want to change.    You can say “honesty is the best policy”  is a rally-cry or fluffy sounding but it rings true.  If you set the expectation that you will be honest regardless of how painful that honesty may be sometimes, a coach will stand to earn the respect and trust of the organization which is a first step towards having that spread throughout the rest of the organization.

3) Guide, Not Dictate:  Ok, so this isn’t so much an attribute phrased like the other two, but it’s important nonetheless.  As I mentioned at the start of the post, lotsa folks want the “how” without wanting to think about it first.  It’s important a coach help the organization/team/person get to the right answer for their situation.   An organization needs to learn how to becoming a learning organization and the best way to accomplish that, IMO, is to use the tools, knowledge and frameworks to help people find the answer that works.   If teams or individuals are making real attempts and showing true desire to adopt Agile practices, give them the freedom to apply what you have taught them.  Let them experiment and maybe they’ll fail, but if they have the desire and motivation, they will learn and improve.

I’ve always bought into the thought that skill and knowledge is never a problem.  Skills can be taught and knowledge can be obtained.  Motivation and desire are the most important attributes that help organizations or individuals commit to constant improvement.

Agree?  Disagree?  What other attributes do you think make a coach successful?