Only Courage

Wow.  What an amazing week at Agile 2013!  I met some wonderful people.  People I admire, who inspire me and I hope to be involved with (in some way) for a very long time.  As ever, I have so much running through my head.  I figure it will be at least 2 weeks before I’m able to form one, coherent post.  That said, Courage was the theme of the week for me.

I had lots of friends presenting and was struck at how much courage it takes to get up in front of ALL THOSE PEOPLE and present your whole self and your ideas.  It could be great or….not so much.  Happily, all of them were great but, take a moment to think on what it takes to do that and be so very vulnerable.  Could I do that?  I don’t know.  i’m certainly going to give it a go….at some point.

Also, there were so many coaches and students of Agile who had to have the courage to jump out there and do this – for real.  Having done this myself, I admire those who have been doing it for so long.  It’s a struggle to not just run back to what is known (for me).  There’s nothing easy about leaving security to go out there alone and  give this a go.  It’s risky.

Two people inspired me this week to do something else that takes a great deal of courage – confronting someone about a broken agreement.  I don’t want to do it at all, however, this one broken agreement is tainting my view of other people and what is, quite possibly, a valuable endeavor they’re working on.  What they’re doing also takes a great deal of courage and, due to this broken agreement, I’m not able to honor or appreciate it.  So, this week, I’m going to confront someone (non-violently) about a broken agreement.

I look forward to seeing how all my thoughts form over the next several weeks.  As usual, I’d love to hear any thoughts or comments you may have on this or anything else that’s put here  for your review and consideration.  Finally, many thanks to my co-author, Ed Wehr, for holding down the fort.   You’re awesome, buddy.

Holy Learning Batman!

So this week was a BIG learning week for me.  It all ended well but, dang! it wasn’t easy. When people are looking to you to KNOW it’s nice and all but, I hadn’t really prepared myself for what that really meant.  Let’s just say I know what that means now and I’m glad I learned this lesson.  

I know from my own experience that trust isn’t automatic.  I don’t care what your title is, you still have to earn trust and credibility.  The lesson was about how to do this.  For this particular situation it was my ability to communicate my thought process and how I reached the conclusions I had reached.  This is not easy for me.  I don’t think in the most organized way to begin with and my thoughts race down so many different paths, correcting as I go it’s not simple to explain nor would it really generate confidence in the person I’m speaking to IF I was even able to explain it.  (Well, hello there run on sentence!)  The thing is, that’s not OK when you’re working with someone who is looking to you and trusting you to guide them.  I mean, why would any rational person blindly trust someone just because of what they were called?  I wouldn’t and I don’t.

Interestingly enough, I found that my Project Manager hat came in very handy.  I put it on and thought through what was necessary in order to lay out the vision or direction that would convey my understanding of the situation and reflect what I had learned about the organization and the things the client valued.  Two and a half hours later, I had it.  The whole thing in my head laid out in a logical, simple, elegant way that resonated with the client and brought both of us back to a happy place.

What I’m going to do now, is lay it ALL out.  Now.  Ahead of time.  I want to have it all there, captured, in a way that’s easy to understand and simple to explain.  This is going to take a little while….

Are you having fun?

You know you’re on a good team when you have fun being with your teammates.  To me, having fun at work is critical.  I have worked on really difficult, not-fun projects but had a great time with my team in spite of crummy work.  One team I worked with was in an especially tough spot.  Constant, non-stop change, non-functioning environments and a leadership that didn’t understand the platform or Agile made for some not-at-all fun times.  One day a team member wrote on the board “It’s like we’re trying to change a tire when the car is moving.”.  The next thing you know, people started adding on to it and it went something like this:

It’s like we’re trying to change the tire while the car is moving

And we just found out the spare is flat

And, awesome!, it started to rain

And, there’s no cell reception so calling is not an option

Oh!  There’s a sign:  Next service station 200 miles

And, there hasn’t been a car on the road for the last 3 hours.

Some creative soul put it into pictures and it stayed on the board for a while.  The team was able to poke fun at the situation collectively and, while it didn’t FIX anything it did serve to give a little levity to the situation.  A good team can work well together and be glad to be in the same boat.

Another team I was on would randomly do things like all dress up like another team member or have a “talk like you’re in Marketing” day.   I’ve also seen rotations of telling Chuck Norris jokes at stand up.  Who knew there were so many!  The BEST fun I have seen on a team was when a Team Member plugged her mouse into the developers dock next to her.  He came in, started up and she pretended to be absorbed in her work – headphones on and everything – while making his pointer go crazy.  He rebooted, got going again and, what do you know, the pointer was all over the place.  He then started releasing (for him) expletives.  He immediately shut down AGAIN.  At this point, I dove under my desk b/c I was almost in tears.  I stayed there as he frantically tried to figure out the problem.  He unplugged everything and re-plugged it in.  It was all connected.  He was baffled and getting ready to call support when, finally, the team member rescued him from what was sure to have been a hilarious call.

All of these kinds of interaction go a long way towards team camaraderie or BA.  This is what adds to the soul of a team.  As a Scrum Master, it’s great to hear a team laughing and enjoying being around one another.  It’s part of their hum and single entity identity.  When people are having fun, they like being at work and will engage more.  This only makes for a better end product.  If your team isn’t having fun think of ways to get it going.  Have a happy hour together, start going on walks, look for interactive and engaging (somewhat silly) team exercises, use the Chuck Norris idea.  Ask the team what they would LIKE to do for fun.

I’d love to hear about your teams’ fun.

Write Your Own User Story

I’ve talked before about creating a vision for your life and how helpful it can be in assessing opportunities and situations.  I’ve also talked about how relevant Agile and Srum are to real life.  So, it’s not surprising for me to suggest that leveraging the User Story format to succinctly capture a personal vision is something interesting to explore.  Think on this for a moment YOU are the Product Owner of your life.  What do you want?

Initially, the story will be too big – Epic sized.  That’s OK as long as it’s something you can true back to and captures your vision.  Obviously, it will need to be broken down to a Theme or Feature.  It’s possible to have one for work, for family and personal.  These will also be too big and you will need to break them down further into story size.

As you go through the exercise of creating your personal backlog, remember it’s all negotiable and will shift.  You may choose to discard, add and change stories.  You may also decide to move things around and change the order up.  All of this is to be expected and encouraged.   The important part here is you are clear in your ultimate vision – the Epic.  This allows you to begin to define  your path so you can focus on and use it to make informed decisions.  If you have  understanding, your “how” will be easier to chart.

I also like the idea of being able to respond to changes as they arise and learning more through emergence in order to refine the vision.  It’s a very elegant way to keep your focus on your end goal without letting shifts in the environment bog you down.  If you are clear on what you want in your own mind the bumps, turns and surprises of life won’t be as frustrating.   It’s something you can share with your “team”.  No one goes through life completely alone – no matter how it may seem.  And, even if you think you’re alone in your journey, when you share your visions, it’s surprising how people will help you realize it because they know what you’re trying to do.

On my last trip I was asked “What do you think about when you go to sleep at night?” and I was able to respond easily.  I think about all the things I need to do tomorrow, next week, next month and so on.  The person I was having the conversation with said: “Stop.  Tonight, when you go to sleep, think about where you want to be five years from now – what it looks and feels like.  Focus on it.   Forget about the time in between.”

In short, write your personal backlog.  Try not to start with the books you want to read or the classes you want to take.  Limit yourself to WHAT you want.  You’re the Product Owner.  You’re also the product.  Own it.


I Believe!

Sometimes, jokingly, I will refer to an end-vision of Agile as the Agile Land of Rainbows and Unicorns.  The thing is…I believe in it.  I have seen great, magical teams.  I know it’s possible.  The journey to get there is different for everyone and, seriously, you must believe you can reach it.  There is no one-size-fits-all approach.  There is no pre-determined path.  The path is completely unique to every individual and every organization.  If I didn’t believe in it, there is no way I would be doing this.  It’s too difficult a job to do if you don’t.  Maybe, instead of being called a ‘coach’ I can be an Agile Navigator OR Fairy Tale Guide OR Be Agile Do Agile Super Star (BADASS for short).  Similar to Peter Pan, YOU have to BELIEVE!  You can’t fake it. 

A Retrospective For One

It’s easy (most of the time) for me to coach others.  I truly hate when I have to coach myself.  I talk a lot about having an open mind and being willing to try new things.  I ask team members, leaders, co-workers and all kinds of people to just give things a chance.  These concepts apply to me too.  As I go through my own changes, I need to coach myself and remember openness, only courage, trust, focus and respect.  It’s not an easy thing to do though and I’m reminded, again, about how difficult change really is.

When coaching, I am able to see situations from a different perspective and, because I have the understanding I have, offer insight and advice.  When I’m just living my life my perspective isn’t very objective and it’s difficult to think through how to apply my understanding to my situation.  As I go through this change, I find I’m constantly challenged to just stop, wait and process information before I react.  My project management roots run very deep in my personal life and I have expectations and plans for how everything should work but, sometimes it doesn’t and I’m forced to remember that value “Responding to Change OVER Following a Plan”.  My plans are pretty good though and WOW life would be smooth if everything went according to it. The odds are pretty good too that, even though it’s not going as expected, it will probably all turn out just fine.

Today, I took some time to assess what I was feeling.  I wrote down what was bothering me.  Then, I thought about WHY it was bothering me.  Finally, I assessed whether or not any of the bothers are in my control.  For the ones that are, I started thinking what action I would take.  Does all of this sound like a retro?  It was.  It was my own personal retro.  It worked too!  I have solid actions I can take which will keep my focus where it belongs.  I should mention a crucial piece of data was my personal vision.  Having that really helped me hone in on what the most important items are.

Finally, for any of you who may have going or are going through something similar, I’m reminded it’s not easy for most people to coach themselves and it’s OK to have your own, persona,l coaching moment.  What’s not OK is not taking the necessary time for reflection and allowing the squishiness to continue.

The Learning Never Stops – Not Ever

I think of myself as a perpetual Agile student.  I’m happy this is what I am.  I love the work I do and feel fortunate that I get to do it.  Seriously, I am so lucky that I get to do what I do – Learn about Agile and help others do the same.  Now, I’m not only learning about Agile I’m also learning about being the person people look to and rely on for guidance. 

It’s MUCH easier to be in an organization and offer up an opinion or assistance here or there.  It’s fun and nice to be asked for help and guidance.  It’s quite another situation all-together when an organization needs help and YOU are the one they are looking to.  The ONLY person they’re looking to.  NO PRESSURE!

Don’t get me wrong, I love pressure.  When you’re worried about doing well, you will try that much harder to ensure you do, in fact, deliver.  There’s a lot at stake to be sure.  It’s not one Scrum team looking to you or one release train.  It’s an entire organization and, yes, learning is good.  Experimenting is good.  Mucking up an organization is not. 

I find myself thinking non-stop and being very cautious and thoughtful about my words and actions.  I challenge myself in every conversation to view situations with new eyes.  And, when in doubt, true back to the values (great advice given to me courtesy of Don Gray).  Finally, as a “north star”, I keep the teams top of mind and think about what THEY will need to be GREAT.   It’s a completely different challenge and one I am thrilled to take on.  Now that I’ve jumped off the high dive, I’m not looking to make a big splash.  A nice, clean and quiet entry will do nicely.

Can you put an estimate on the value of conversation?

Some time ago I heard about a trend of “No Estimates” and, have to admit, was not happy about it.  The reason I wasn’t happy about it had nothing to do with understanding the velocity of a team.  It had everything to do with the team missing out on critical conversations that occur when arriving at an agreed upon estimate.  I love watching new teams estimate stories.  When someone throws a 20 and someone else has a 5, the discussion that takes place – THE LEARNING – is pretty powerful to observe.  Estimating is a way for team members to get to know one another better and understand how they each view things differently.  Eventually, they start applying others’ perspectives to their own and the team truly finds a voice as a single entity.

Dan Mezick wrote a good blog post recently and pointed out “One may say with some certainty that the estimation task is actually a ‘cover story’ for the wider task of team learning. If estimates are 100% eliminated, how is this team learning replaced? Team learning is obviously essential. Discussions during the estimation task create many team-learning moments.”

Frankly, I believe a team, who is committed, will get to a point where estimates are not required.  This will happen once they learn – not before.  Scrum has estimates and the concept of velocity there for a reason.  A team must go through Shu (Follow the rule) before they can muck around with it and find something else that works best for them or reach a state of Ri (Make the rule).  If you start a team out with no estimates, I believe the learning curve and reaching a performing state will be delayed.

Some teams use relative estimation.  Others will use Planning Poker.  Heck, I have seen a team estimate in “farm terms”. Seriously.  A duck is less than a cow which is less than a barn and so on….  It worked for them.  Who am I to question it?  So, yeah, maybe this idea has merit but, I really would caution against giving it a go with a newly formed team.  Sound snippets like this one make me a little nervous.  You can’t place a value on the conversation that takes place during estimation.  You CAN place a value on a team taking twice as long to reach a performing state.

My Light Bulb Moment

Thanks to Michele Sliger for asking me to write it all down!

I started out as an ”Agile Project Manager”.  I accepted a contract for an IT project (my first) and was told it would be run as an Agile project.  I had no idea what Agile was and I was a Project Manager.  I had a great track record as a PM of driving results.  I googled Agile and was thrilled to learn my entire team would be in the same room, everything they were doing would be on the board and we would only have a 15 minute meeting once a day to discuss the project.  Oh….how very wrong I was.  Mind you the team delivered after slogging through entirely too much overtime, continuous pressure from me and the business and constant driving.  Unfortunately, their work never saw the light of day – two weeks before launch, the project was pulled.  What had worked for me before didn’t work this time.  I heard a lot from the people on the team who knew what Agile was and I was decidedly NOT a Scrum Master.  I cared, a great deal, about the people on the team and there were certain things I began to grasp but not enough to make a difference for them.  Honestly, why I stayed in IT after that project is beyond me but, I did.

Following that project, the next team I had was already formed and doing well on their own.  I still hadn’t had any training but, was asked to be the Scrum Master.  I started reading more and asking more questions of those around me who seemed to get this whole Agile thing.  I came into the team sure I would make them different and better.  I came in without acknowledging or respecting their history.  I asked them all kinds of questions about the work they were doing, why they were doing things the way they were doing them, pushing them a little so, in short, I didn’t really learn much and it still wasn’t clicking for me.  It was not a very comfortable place to be for anyone.  Then, someone had the brilliant idea to combine two teams together – mine and another – and that was when things started to get interesting.  The team that joined my team DID get Agile and they were not at all OK about how I was running them.  They pushed back.  I went to CSM training.

Joe Little and Jeff Sutherland were teaching the course and, as I sat there, all the pieces started coming together.  I understood how it was supposed to work and how I wasn’t doing anything AT ALL to make it easier.  Jeff Sutherland made the point that I still true back to all the time:  Protect The Team.  I came back to work energized and excited.  It clicked and I couldn’t wait to get going.  That said, there was this HUGE team which was really two teams trying to keep their individual team identities in place and continue to be the good teams they were separately.  It wasn’t working. I knew, in theory, what I was supposed to do but I didn’t know HOW to do it.  They fought over desk position, norms, how stand up should be run, how planning should be run and we were all incredibly miserable.  I thought I was doing the right things and protecting the team.  I wasn’t.

I asked another Scrum Master for help.  He came to observe a retro and, at the end of an hour, told me I couldn’t stop.  I had to keep the team talking for as long as it took for them to work their issues out.  The retro lasted all day.  Seriously,  Everyone was open and honest including me.  There were things said which were really hard to swallow for me.  I really had been trying to do the right things.  They made me question everything I had ever thought about my abilities. However, after that retro there was something different.  We all realized we were all trying to do the right things.  There was no malice or ill intent.  We trusted each other a little and we had overcome a decent amount of pain together.  After that retro, I started reading, researching, asking and experimenting and the team let me.  I would tell them what I wanted to try and why and I knew they would tell me when I was off track. They would tell me because they knew I was trying and I wanted to get better.  They also wanted to be better.  We all wanted to be the best team possible.

So, we’re all on an upswing now and someone decides to split the team back up.  Yes.  After ALL that pain we needed to split.  I remember being in the room with several other people figuring out who would go where and they were all looking at me to make the new teams.  It tore me up though.  I had gotten close to everyone and they were doing so well but, I did it, and I chose the team I was going to stay with.  The team was named BOB.  We worked together for about a year and it was the single-most rewarding and fun time of my career.  What I learned from that team in terms of trust, what empowered teams can do, what protecting a team meant and what the role of a Scrum Master really was is what has shaped me and guided me to where I am now.  It is an experience I hope everyone working in Agile can have.

We were nearing performance management time and I was writing my self-appraisal.  I didn’t have anything to write.  I didn’t have any results.  There were no “BIG WINS”.  In fact, I sat there thinking I hadn’t had to do much with the team at all.  I started to get truly worried about what was going to happen come end of year.  With none of the usual problem-solving, risk mitigating, implementation strategizing and scheduling management-type-stuff my piece of paper looked really empty.

“Scrum Master for a team who has delivered more scope than originally requested within the same amount of time.  No defects released into production.  Team has created automated test harnesses to enable faster identification of defects and leverage the QS resource more effectively.  Team members have learned new skills to be more efficient in their delivery approaches.  The team manages themselves, including removing most impediments. The team has created a build book to be used by the platform and serve as guidelines for UI development.  The team is able to respond quickly to change and is frequently sought after by the business to help shape strategy and inform intent.”

The TEAM had done great.  They had knocked everything thrown their way out of the park.  They were having fun and everyone wanted them.  Then it hit me.  They did it!  They were a self-managing, self-organizing, high-performing machine.  That’s what is supposed to happen.



This Old House – Agile Edition

When you’re transitioning to Agile, there’s a lot going on all at once.  It occurred to me  it’s similar to home renovation – a really, really big home renovation.  Personally, I LOVE old homes.  I love going to see them and, one day, I want to buy one and fix it up.  Sometimes, I walk into a house and while I’m oohing and aahing my husband is groaning.  He’s groaning because the houses don’t generally meet any criteria he has for a home.  I’m oohing because I can see the potential a house has.  All you need is some imagination, good bones and time.  That’s what an organization needs to create a great environment for Agility too.

IMAGINATION:  To begin, you need to be able to ooh and aah instead of groan. You need to be able to see what is possible for teams, management and your users.  If you don’t have imagination absolutely everything about the process will frustrate the hell out of you.  You can’t hire someone to “take care of it” for you or oversee it.  Nope.  You need to be willing to be architect, general contractor and all the subs.  If you have imagination and can envision what it will look like you have an open mind.  An open mind is necessary because everything you thought you knew about “how your house was built” is going to get thrown out the window.

GOOD BONES:  There are some things that just need to be in place.  It’s no good and not practical if you have to bulldoze the house and start from scratch.  You need smart people who are willing to opt in and give Agile a serious go.  You need managers who are way more into the products their company produces than they are into their “turf”.  These managers must also understand how to support, motivate and develop people.  You need a culture of drive and commitment.  You need a business who will look at the business differently.  You need a company that invites people to opt in instead of mandates.  OPEN MINDS are essential.

TIME:  It took a long time to build what is, arguably, good enough.  To change, grown, learn and be great you need time.  You know the saying “Rome wasn’t built in a day”?  An Agile transformation doesn’t happen overnight either.  This renovation is going to take time.  Since you know that, you also need to know to be patient.  Also, you should know that you will never be “Done”.  You will always and you should always look for things to improve on.

In my vision of a great Agile environment there are spaces for teams to work together, as a whole team and places to pair or collaborate with a smaller group.  There’s technology available for distributed teams to use.  People laugh!  Anyone walking by can see what the team has going on and how awesome they are.  There’s some corporate furniture around but teams can put their own identity on their spaces too.  There’s a wall for anyone who wants to put an idea up to try and others can join in the effort.  Directly opposite is another wall that celebrates the successes and failures (learning) from the efforts of these self-organizing teams.  The environment is safe for everyone to be open, honest, disagree and try anything they think will be for the good for the team, the company or the user.  This safe environment also has a hum – there’s energy and people are genuinely happy to be there and be a part of it.  There’s also an endless supply of post-its (all colors & sizes), sharpies (all colors), magnets and flip charts.

As with any major project, you’re bound to hit some snags.  That’s OK.  It’s all part of the adventure.  You have no idea what you will learn along the way and the creative solutions you will find.  The time, thought and care you put into creating this environment will be huge.  If done well, at the end, you have teams of completely happy and motivated individuals.  You have a safe environment where learning, trying and trying more is encouraged.  You have users who are loyal and more than satisfied with the products you are producing.  All this because of the environment.   There’s no need for razing the house to get to the land.  Keep what’s good and useful, ditch the rest and strive for the perfect environment.