A Reminder to Balance

I hope you will forgive a bit of a personal ramble here…

One of the reasons I am such an advocate of Agile is it makes work fun.  To me, it doesn’t matter if you’re in delivery or not – working in this way is enjoyable and rewarding.  Another reason I love it is the idea of working at a sustainable pace.  It’s funny how often you have to remind teams they don’t HAVE to kill themselves to deliver or over-commit isn’t it?  I don’t think I have ever heard someone tell another person “You’re spending too much time away from work.”.  What you work on, who you work with and what you produce all have the potential to enrich your life.  I believe Agile, in the right setting, has the ability to turn that potential into reality.  We spend a lot of time working – let’s make it as awesome as we possibly can.

I have personal work experiences which are great examples of awesome and others….not so much.  Reflecting back on those that weren’t so great, I’m struck at how much energy and emotion I put into them.  They took away from my life outside of work – negatively impacting me, the people I love and the people at work. I learn from every experience but those not so good ones, are the ones that truly altered my point of view.  I discovered my boundaries and actively seek to enforce them, no matter the cost, because I’m unwilling to experience that kind of negative impact myself again.  I’m also unwilling to knowingly and negatively impact those I love again.  Even when doing work I love – as I am now – I still have to be mindful of those same boundaries.  It’s tempting to put more effort and energy into doing something I love so much but, the cost to those I love isn’t a debt I’m willing to take on.

I’m lucky.  I get to work at something every day that I love and find rewarding.  I’m also fortunate to have had experiences (though I didn’t feel so fortunate at the time) that reminded me how important life outside of work is.  I’m thinking the goal isn’t really a sustainable pace – for me or for teams – it’s balance.  It’s having the ability to grow as a person, separate from your career, and spend time, effort, energy and emotion on the people, activities and things you love.  Finding the balance may be the key to really being able to bring your whole self to work every day and enjoy the time you spend there as much as you enjoy the time away.

Clearly, this isn’t really an “Agile” topic.  It is something I learned and, therefore, keeps with the overall theme of this blog.  It’s highly probably what I’ve shared isn’t new to anyone.  Really, it’s just a reminder for myself.  Balance and Evenflow.

Advertisements

Learning from a “New to it All” Scrum Master

Over the last month or so, I’ve been fortunate enough to work with a fantastic group of people on their Agile journey.  And, I’m telling you, every time I leave them to come home, I have a smile on my face and I look forward to the next time I work with them.  One of the gems to come from this engagement is watching a brand new Scrum Master start to grow.

When I first met this SM, I was impressed with her grasp of Agile.  It was clear she understood and was passionate about it.  The amazing thing was she had never actually worked in an Agile environment or with an Agile team.  In fact, she hadn’t even led an IT project before as a PM (or any other role) but there she was, working tirelessly, to help her organization transform.  It was obvious to me she had the desire and necessary passion to be an integral part of the change….there was only 1 thing missing:  Experience.

So, along comes this opportunity to be the Scrum Master for a team.  She wanted to do it.  Her management was supportive.  She jumped in with both feet, an open mind and desire to learn and grow.  All I can say is WOW!  I’ve watched her embrace and embody servant leadership.  She asks questions and seeks input from everywhere.  She’s an advocate for her team and is sincerely “there” for them.  She may not know the ins and outs of IT but, it’s not seeming to matter right now.  In fact, in her first retro, her team expressed shock she was new to this and their appreciation for her after only one sprint.

Here are some of the take-aways

1.  No Baggage  –  When you come to a new opportunity, leave your previous “baggage” at the door.  I think one of the things that’s helping her in the Scrum Master role is the LACK of IT experience.  She has a “why not” attitude that’s refreshing and, frankly, spot on.  For her, there is no “It is what it is” or “That’s how it’s always been done”.  Fresh eyes and perspective are an edge.  For me, this is something I will try to do for myself and for the people I’m fortunate enough to work with.

2.  Expect To Learn –  There’s no way you can know it all.  It’s not possible.  When you go into a situation with an expectation to learn, you will grow, challenge yourself and set the example for others to follow.  We’re all on a learning journey together is a wonderful rallying point for a team.

3.  State Your Purpose – One of the things this new Scrum Master did was tell the team what her personal goals were.  She was very clear that she was there to learn, help them in whatever way they needed her and they were her number one focus.  That’s powerful for a team to hear.  Who doesn’t want to be someone’s number one focus?

4.  Ask Questions – It’s true.  There really is no such thing as a stupid question.  Ask away!  Seek answers and knowledge and LEARNING.

5.  Walk The Walk – Show your team, through your actions, that you’re in it all with them and their growth and development is top of mind and priority.

It’s exciting, for me, to watch the personal transformation of this Scrum Master.  It’s also refreshing.  Seeing the Scrum Master role and Agile through her “new to it all” eyes has been incredibly beneficial to me.   I can’t speak to what I have done for her but, I can say with a high degree of confidence she has done more for me.  Now, off to get some work done with a fresh perspective!

My North Star

I feel certain I have written about this before but, I was replying to someone in an e-mail tonight and was struck again so, here it is….again.

What drew me to the Scrum Master role and Agile to being with was the focus on people.  In my CSM class with Joe Little and Jeff Sutherland, I honed in on something one of them said which narrowed my focus.  My North Star as a new Scrum Master was (and still is actually) PROTECT THE TEAM.  It’s very, very simple in theory but, in practice, can be very difficult.  Those three words can be interpreted in so many different ways and I have found my own interpretation has evolved over time.

I’m protective and loyal by nature so I really grabbed on to that idea of protecting the team.  In the early days it meant keeping people NOT on team from messing with whatever the team had going.  When I say messing with, I mean things like adding scope, demanding timelines and estimates, challenging the approach, pulling team members from the focus and, sometimes, protecting them from each other.  Hey, you’re in close quarters and around each other a LOT.  Sometimes, fuses get short.  I found I was good at protecting them and I loved that role but, it has evolved.  You could even say it grew up.

Fast forward to today and I’m still all about protecting the team but in a different way.  Today, I want the environment a team is in to be one  a team doesn’t need protecting from.  I’m passionate about creating environments teams need to be successful.  The North star hasn’t changed but, the focus has expanded.

Adding Scope:  This isn’t something a team should need protection from IF the business is aligned with IT in Agile software development and there are empowered product owners as part of the team.

Timelines and Estimates:  If an organization is focused on delivering value and teams have a sustainable pace with established velocity, there’s no need for timelines and estimates.

Challenging the Approach:  If the environment is supporting and enabling empowered, self-organizing and self-managing teams managers don’t have time to be in the weeds of a teams approach.

Pulling Team Members Away From the Focus:  If team members are dedicated to the team and management is supportive and aligned, there’s no worry about the manager assigning them to multiple projects or delegating their own work to them.

So, the evolution really has been to shift from running interference to creating environments.  As a new Scrum Master, I think having that passionate purpose is helpful.  It’s something akin to a vision for yourself you can always true back to as you’re on your personal learning journey.  Whenever I have been in doubt about something, I’m able to ask myself “What would be best for the team(s)?” and find the answer becomes crystal clear – well, for me at least.

If you’re clear on what your “North Star” is – GREAT!  If you’re not, think about why you were drawn to Agile in the first place.  What got you excited about it?  Why did you like or relate to the Scrum Master role?  It’s OK if it’s not immediately clear to you.  Even if you have an idea, it will evolve over time.  Take time to find your North Star so you can focus less on the path and more on your goal.  When you focus on your goal, decision making is a bit easier.  Focus on your path and you may make some short-sighted decisions – not that there’s anything wrong with that either.

Understanding Before Leaping to Agile

I wrote about establishing goals for your Agile adoption recently in a post called: Thinking Before Leaping to Agile  but, clearly, it takes more than having goals to be successful.  If only it were that easy right?

Understanding where you want to go (goals) is a major factor for success for both you and your organization.  There are other factors as well.  In this post, I want to talk about realizing what an Agile adoption means and understanding it well enough to know that 1) it’s not easy and 2) it takes far more than you think it will from every.single.person. in your organization and 3) you will never know everything there is to know about Agile.  If you ever saw the movie “White Men Can’t Jump” maybe you’ll remember the scene where Wesley Snipes says to Woody Harrelson (Jimi Hendrix is playing on the radio)  “Look man, Your can listen to Jimi but you can’t hear him. There’s a difference man. Just because your listening to him doesn’t mean you’re hearing him.” and I’m reminded of this quote quite a lot when I work with people leading Agile adoptions.

You can read a LOT about Agile.  There are books, blogs, web sites and white papers galore out there.  And they’re all great sources of information but reading all of them – even being able to quote them – doesn’t mean you understand, really understand.  Agile isn’t something that only touches IT.  Your business, operations, legal, compliance, marketing and human resources departments will all be touched, in some way, by an Agile adoption.  What’s great about Agile is there’s nothing prescriptive about it.  What’s difficult about Agile is there’s nothing prescriptive about it.  There’s no guidebook so understanding the application of Agile values and principles isn’t clear cut and you and the people who work for you will be figuring it out and learning together.  You won’t have all the answers and neither will the people who work for you and that’s OK.  How an organization goes about transforming to Agile is as unique as a fingerprint.

This will be a change (for the better in my humble opinion) and as a good friend of mine once said “Change is hard.”  Organizations spend years, decades even, building the structures, processes and culture they have and Agile will challenge and change every one of them.  What takes years to build and create doesn’t just vanish overnight and you will be surprised at how hard people hold on to it all.  It’s known, familiar and probably is perfectly adequate.  But, remember those goals you laid out?  Those won’t happen by staying the course and doing the same things.

Insanity:  Doing the same thing over and over again and expecting different results.  This quote is often attributed to Albert Einstein, however, I was told recently the first appearance of it is actually in an AA manual.  Regardless, it’s a good quote.

When you understand the implications of the change you will be asking for, it puts you in a position to anticipate and appreciate the difficulty of what your people are doing or trying to do.  It will help you be empathetic to what your people are going through.  It will help you lead your people through the change because you will know what it is you’re inviting them to do and you will be able to be transparent and up front about the challenge.  Being up front and transparent will help build trust.

So, how do you even begin to understand what an Agile adoption entails?  How can you really “hear Jimi”?  The very best thing you could do is be on an Agile team.  That’s probably not something you’re in a position to do….  The next best thing you can do, in addition to reading everything you can get your hands on, is to talk to people who have experience in Agile.  There are sure to be some people close to you who are knowledgable.  Go and speak with them.  Ask them what they liked, what they didn’t like, what was difficult, what are the top three things that would have made it easier, what are the top three things that would have made them happier.  Then, talk to people outside your organization.  If there are bloggers or authors whose writing and thoughts are interesting to you, send them an e-mail.  Ask them if they would be willing to give you an hour of their time to speak to you.  You will be shocked at how open and willing this community is to helping you.  Then, once you have their ear, ask them to tell you everything they think you should know about adopting Agile in your organization.  Ask them the three things they wish organizations would do before and during the shift to Agile.  Finally, speak to some consultants – big and small – and when you find one that listens to you, asks you lots of questions and speaks in a way that resonates with you and reflects understanding of your organization and situation, hire them.

You won’t be able to understand everything possible about Agile.  And, I’ll be honest, there isn’t anyone out there who does.  Agile champions continuous learning and improvement and taking the steps above gets you on your own, personal learning journey before you jump in to a HUGE organizational learning journey.  You will start to think about your processes, structures and culture differently.  You will begin to see areas where small tweaks could yield big benefits and you will also see where you need to completely overhaul what’s in place today.  Understanding will give you the foundation you need to look at things honestly and evaluate not only how “Agile” they are or aren’t but, how everything will help you reach the goals you have defined.  It will also make it easier for you to say “I don’t know” which is a powerful, trust building statement.  Now, you will be learning and figuring it all out with your people…creating new processes, structures and culture.  Ready?

Thinking Before Leaping to Agile

So, you think you want to “Go Agile”?  The very first question I have for you is:  Why?

Before you embark on a path as challenging as an Agile adoption be very sure, from the outset, of your goals.  And, let me be very clear here, the goal cannot be “To meet a mandate from our <insert title here>”.  It also cannot be “We just need to deliver more, faster.” There’s no doubt there are benefits to be had through an Agile adoption, but you will need to know WHY you want to take this journey.  More importantly, the people you will be asking to embrace, support and implement this change will need to know why.  If you’re not able to explain it – to put your goals out there – STOP.  Don’t take one more step or have one more conversation about it until you do.  Then, once you’re clear on those goals look to see if there’s anything about people on them.  The heart, soul and awesomeness of Agile lies in people.  If there’s nothing in the goals about people, STOP.  You will not realize the goals you have laid out without considering, paying attention to and cultivating your people.

What about people is important to an Agile adoption?  Well, all process and structures/frameworks depend on the people working within them to bring them to life.  In an Agile adoption, people and their ability to trust you and your ability to trust them is vital.  There will be things you learn about your company that will be uncomfortable and they need to be able to bring them up to you, their leader, to help change them.   Additionally, they will need an environment where they really can live the Agile Values.

When I reflect on the goals an Agile organization should consider they’re, actually, rather simple.

  • Are we delivering more value to our customers?  How do we know?  Your customers will tell you.  Ask your customers prior to your effort to tell you how they feel about the services and benefits you provide and, then, continue to ask them.
  • Are our operating costs going down?  Is your call center experiencing less call volume?  Is it easier to resolve an issue when they do call?  Do you need less and are able to deliver more?
  • Are our associates reporting a higher degree of engagement?  Do they feel empowered?  Do they feel they have real, true ownership of solving problems?  Do they feel their managers are, more than ever, focused on their development over their work?

Agile alone isn’t a Silver Bullet.  Maybe it seems that way OR someone is positioning it that way to you but just “doing Agile” will not deliver the results you’re probably looking for.  “Doing” Agile will get you some improvement – in the 25%-35% range.  “Being”  AND  “Doing”  Agile has the potential to deliver exceptional (400% improvement) results.  Being Agile depends on you, the leader.  When you announce the intention of an Agile adoption, you’re making an agreement to adhere, as closely as possible, to the Agile Values.  What’s more, your people will believe you and it’s critical you mean to live the values and you’re asking them to do the same.  Your actions from that point forward will confirm (or not) your commitment to those values and, essentially, your people.  So, WHY do you want to go Agile?

Trust+Courage+Vulnerability = Authenticity (?)

Steve Peha wrote a wonderful blog post about Taking Yourself To Work this week.   That and Ed’s post (which was originally a comment) Be Like Water are my two favorites on this blog so far – including my own.  I have written a lot about vulnerability, trust and courage in one way or another here and I think all of those probably add up to being authentically you every day.  It’s another one of those things that’s “simple but not easy”.  I don’t have a great deal I can pile on to what Steve has offered us this week other than this:

When I am focused on people, teams, my work and my passions I find I am able to be authentically me.  When I’m focused on anything else but those, I do not “bring myself to work”.  This blog, a lot of trial and error and practice being vulnerable, trusting and courageous has helped me be authentic more of the time.  It is definitely something I am challenged by daily.  What I like about Steve’s post is that it’s something we can (probably) all relate to.  it serves to remind us that we’re not alone AND we all have an opportunity to help each other do it more often.  Maybe it means finding a person you feel you can practice with individually or bring the topic up in a retrospective with your team to work on as a team.  Possibly, it’s just making an agreement with yourself to try to be more of who you are more of the time a little more each day.

When I start to imagine an organization where people are able to be who they are easily and freely I get a little giddy.  Think of the conversations, great ideas and results that could happen!!  It has to begin somewhere, so rather than giving notice to experience that sense of freedom, I’m going to just give myself permission and see what happens.  Meanwhile, I’m just very thankful to have inspirational friends like Steve and Ed who help me learn and inspire me to try to be better.

 

A New Comfort Zone

My apologies for not posting on the theme of comfort last week.  Technical difficulties with WordPress stripped my author permissions.  Let me just tell you, that was LOADS of fun.  I’m grateful to Elizabethmiller2 for putting herself and he learning out there for everyone just as I’m grateful to Steve Peha for doing the same.  Thank you, both, very much.  Here’s my very late post on comfort from last week.

Last weeks theme on comfort sent my brain all over the place.  Personally, there are very few periods of my life where I can say I was “comfortable” and I think it’s because I’m wired that way.  When I find myself close to comfortable, invariably, something changes and, more often than not, becomes somewhat UNcomfortable.

Comfortable can mean stable and secure.  There’s a tremendous amount of value in stability and security.  It allows us to do or try things we haven’t before because we KNOW certain things to be true.  It’s important for people to achieve a level of comfort so they can then pursue levels of discomfort.  When you take a look at teams, comfort may mean they’re not challenged – either by their work or themselves.  Don’t get me wrong, we all need time to just breathe, but discomfort for a team probably means they’re challenged.  When a team is challenged, some really amazing behaviors begin to emerge.

Discomfort generally comes hand in hand with change.  The change can be self-inflicted or forced on us.  Change, as we all know, is hard.  A persons or teams ability to perform in uncomfortable situations can be influenced by several things.  The chief influence, in my mind, is their environment.  The environment needs to be safe and what I mean by that is one that is supportive.  Teams experiencing discomfort will have different ways of dealing with it.  Some may engage in some constructive disagreement (loudly).  Others may hole up.  Regardless, teams need to be given the space and support to walk through the change at their pace.

As a Scrum Master, the challenging part is knowing what to do when things are too comfortable, volatile or challenging.  I have to say that I don’t have THE answer.  I have some ideas to try.

TOO COMFORTABLE

  1. Ask the team to think of three things that would be impossible for a team to accomplish in your organization and why it would be awesome if someone could do it.  Get a conversation going – blue sky the heck out of it.  Then, ask them WHY they, amazing team they are, can’t be the ones to try.  The worst that can happen is improvement.
  2. Ask if any team members would be willing to pair with another team member in a different role for a sprint and learn more about the role.  If anyone opts in allow for it in the velocity of the team for that sprint and, in the following one, observe what the results are and call them out to the team.  Then, ask if anyone else would be willing to try.

TOO VOLATILE

  1. Things change fast and furiously and can overwhelm a team.  Get them out of the room.  Go for a walk.  Go for a long lunch.  Give them room to breathe and not think about work for a bit.  A brain break is a good thing.
  2. Have a mind dump exercise.  Ask the team to write everything on their mind on  a piece of paper and, when done, do a quick sort of In their control or NOT in their control.  Then, creatively destroy all those that aren’t in their control and focus on the sprint and save the others for retro data.

TOO CHALLENGING

1. This one is tricky because it’s probably not that it’s too challenging it just seems TOO big.  So, what do we do when things are too big?  Break it down.  Go through an exercise to find the vertical slices with the team and find a simpler picture.  Big challenges are often ones that seem TOO challenging.

2. What?  Is there anything too challenging for your team?  If they have created a vision, bring them back to it and remind them of all the good they have.  Sometimes, you just need someone to believe in you.

Some of the best things I have done in my career have been during times of extreme discomfort.  Admittedly, I have also done some of the worst things during these times too but, those horrible things helped me learn and prepared me for the next one.  So, maybe it’s also good to remind yourself (or your team) about how strong and capable you are.  What’s the worst that can happen?  Even if you fail, you learn and there’s absolutely nothing wrong with that.

An Open Invitation from Ed and Valerie to Share Your Learning Experiences

Hi All!  This is an invitation from both Ed and I.  We hope to hear from you!

We are all always learning.  The intention of this blog is to share those learnings and build on them.  It’s less about what we (Ed and I) think and more about community-generated sharing.  We would like to invite everyone to share their learning here too.  We already write on the same topic on Wednesdays but, to push the spirit of Agile Yammering further, we hope to invite and generate more participation.  Every week agileyammering would like to feature a learning theme generated by someone other than us.  Your post will be published, along with posts of our own on your topic in an effort to get a true dialogue going.  We share a passion to learn, share, grow and offer an environment for others to do the same. If you have something to say, want to share an experience, desire to learn more about a topic and add to our community please contact us through agileyammering@gmail.com.  There are some ground rules:  We want this to be a safe environment for people.  Snarkiness or criticism that isn’t respectful, kind and written with the spirit of being helpful is not OK.  The topic this week is “Comfort”.  We would like to extend our thanks to Beth Miller for being the first to share an experience.  If you would rather not write a post of your own, we would love for you to contribute to the learning by commenting on others.  Thank you for your continued support of this experiment.

A SAFe Dialogue

I want to write a few words about SAFe.  It’s been a hot topic but, now, it’s on fire.

When I returned from SAFe class, there were definitely pieces about it which gave me cause for concern.  Mostly, they were around points made in the training and how they would manifest in the hands of someone who was not experienced to an inexperienced audience.  For example, there was guidance on a Scrum Master ratio of 1:4 (teams).  The ratio may be possible when you have teams who are high-performing but, not at all appropriate for new teams starting out.  Anway, following my training, I worked with my first Release Train and the experience was powerful.  Watching the teams come together to collaborate with their Product Management, Leadership and other Services there to work with them and ensure the “tracks” stayed clear was, frankly, a sight to behold.

There’s a risk of any framework not working well and it’s not the framework that makes it risky.  It’s people.  People make frameworks and processes work.  The buying of any framework is also risky because of people salespeople.  The person selling SAFe has an obligation to represent more than just the framework.  SAFe is Agile at scale which means there are cultural and tactical elements.  To get the results organizations want they must pay attention to and work on both.

I don’t believe Dean Leffingwell set out to take people out of the equation or diminish Agile in any way.  I don’t believe he has executed the launch and adoption of SAFe to take focus away from the people either.  Possibly, there could be language added in the abstracts to speak more to the culture or people aspects but, the consultants who are out there training it have roots in Agile and I trust in them to maintain, teach and strike the right balance. I also trust in them to recognize that frameworks are guidelines and there’s no one-size-fits-all implementation.  Just as with the implementation of Scrum, there’s give and take at first and work continues to get as close as possible within the constraints that exist….until they don’t any longer.

I would rather some c-level person see the SAFe framework and give Agile a go than not.  I’m also glad there are people out there who are courageous enough to post their thoughts in order to get a constructive dialogue going.  Also, can’t we all just get along while having constructive disagreements?

Confronting Missed Agreements – FAIL (First Attempt in Learning)

So, yesterday, I blogged about courage and confronting someone about a missed agreement.  Well, I am happy to report I did it.  However, I am unhappy to report that, in my eagerness to get it over with, I didn’t do it very well.  

I was inspired by a presentation given by Amr Elssamadisy and Steve Peha at Agile 2013.  They made a fantastic point that people build trust by keeping agreements and one missed agreement can pretty much wipe out any trust that has been built.  It’s an excellent point.  They touched a little on why we hesitate to confront those missed agreements with the person who didn’t keep it but, the main point is, to confront it.

There are steps one must go through – on their own – prior to confronting said agreement and I’ll try to do them justice here.

1.  Safety:  What is meant by this is to evaluate how safe you are prior to making said confrontation.  Safety meaning will there be ramifications?  Will the person allow you to do so?  Is the relationship one where BOTH individuals are safe?  Are YOU able to make it safe for the other person to hear you?  Can they question you?  Can they disagree with you?  Safety is an integral part of any relationship but probably VITAL in an interaction such as this.  

2.  Whole Being:  Are you able to speak to this person as someone who is worthy of respect?  If not, waiting is a smart thing to do.  Any disdain or lack of respect will come out loud and clear in any type of interaction you have – written or face to face – so making sure you approach someone as one worthy of respect is critical.  And, really, I’m hard-pressed to come up with reasons why any person isn’t worthy of respect so, treating someone with it shouldn’t be difficult.  

3.  Owning your part:  You need to own your part of both the problem AND the relationship. And, it’s not just giving lip service to it, it’s truly owning it.  If you can’t or aren’t able to, you’re not ready to “confront”. 

So, here’s my reflection on why this wasn’t a good confrontation.  

I was anxious.  I wasn’t anxious to do this well.  I was anxious to just get it over with.  Already, this means I’m not owning my part nor am I seeing the whole being.  I was only seeing my part – how this missed agreement impacted me.  As far as safety goes, I felt safe but that doesn’t mean it’s safe for this person to have a dialogue about it.  In fact, I’d STILL prefer to not actually speak about it.  So, not wanting to even discuss it pretty much throws respect right out the window.  

So, what about this situation makes having this conversation so difficult?  I don’t want to open myself up and be vulnerable again.  I’m afraid of the impact it will have and my ability to handle it.  If I don’t have this conversation, I’m worried about the same except it’s with regards to future interactions.  And, see, that’s exactly why trust is such a vital element of any relationship be it 1:1 or 1:TEAM.  I need to do this for myself and in order to help others (possibly) some day do the same.

Well, one thing is for sure, I can’t let it hang out there.  I need to reflect on this some more and figure out what my next course of action is.  Meanwhile, it’s just another good Adventure in Learning (or Failing).