Middle Managers are like Addicts…

This weeks experiment for softwehr and I is to write about Middle Managers.  This topic generates a LOT of good discussion.  In fact, I’ve already talked about it here.  I’m actively experimenting with this group daily, using Dan Mezick’s book: The Culture Game, trying to find some keys.  I’ll tell you up front I’m failing a lot.  My failure (I like to call it learning) is due in large part to the fact I’m trying to instill some new habits and responses that aren’t instinctive yet.

What is it I’m trying to do?  I’m trying to get people in the middle layer to change the way they view and execute work.  This group is tough.  What’s the value proposition for them?  It’s easy for teams: you will be empowered and valued for the skills and creativity you bring.  For Executives, you are going see more value being delivered, a reduction in defects and operational costs, improvement in associate morale and MORE revenue!  What’s not to love right?  For Middle Managers….you guys get to???  So, here’s what I am trying so far:

  1. Everyone has a choice to opt in or out.  I am focusing on those who are opting in. Normally, I focus on the other set thinking that’s where the problem is.  It isn’t.   There is absolutely nothing to be gained by trying to convince them.  By focusing on those who are opting in, I am creating viruses.
  2. I am asking if the purpose I believe we are striving for is aligned with their thinking.  Aligning to a common goal/purpose is essential.  Often, we are not.  However, I have found that stating my “own” purpose gets them thinking AND I find some converts.  How do I know this?  The converts refer back to it throughout the meeting and ask me questions following the meeting to understand what I was trying to get at.  They want to learn.  Virus created.
  3. I am taking every possible opportunity to teach…what are elements of high-performing teams, why is the environment essential and all kinds of other interesting systemic cultural impediments.  Sometimes, I’ll get a polite nod and murmur other times, I see a laser-like focus appear in their eyes and they ask “What are we doing to solve that?”.  HA!  Got ya.  I now have a virus AND someone to go and tackle the impediment.
  4. Every day I set out to do something “brave”.  Sometimes, the brave thing is any ONE of the items above.  Other times, it’s bolder.  The worst thing that happens?  I fail/learn.

Notice there’s nothing on here I’m forcing on anyone.  Middle managers are like addicts.  They have to recognize and accept their problem before they seek treatment.  My role isn’t to treat them.  It’s to help them be aware and find their value proposition in this change.  I help them be aware by doing the things above and some more. Eventually, more people attain awareness and results WILL follow (I have to have faith here).  Those who haven’t yet experienced it start asking those who have “How did you do that?” and the virus spreads.

The middle layer can make or break your transformation.  It’s a constituency we must pay attention to.  They’re the most difficult ones to reach.  They are afraid.  Seriously, download Dan’s book on your Kindle and read it a couple times.  As you’re reading start trying.  You have to start small to make it big.  Just like a virus.

Advertisements

Middle Management

Even in the agile universe people are acutely aware of management.  A scrum team diagram doesn’t show one, but the Scaled Agile Framework (SAFe) will.  How does management fit in? Is our management Agile?  Books like Organizational Behavior have quite a bit to say about management and even discuss motivational theory.   A better book for many of the ways managers can enable teams and keep the environment agile is Management 3.0

For a new team or manager involved with scrum, throwing a book at them is not a place I suggest starting.  If I only have time for the quick intro, I usually break Scrum down into People, Events, and Terms.  A 50 minute conversation through a handy little chart (I’ll post it if interested) that includes  a recursive acronym SME in the people section.  These are people that surround the teams; Subject Matter Experts (I consider the customer an expert on themselves), Management, and finally Environment.  The tank (environment) in which the team swims often plays a part in the teams development and behavior, thus like many things, I embody it as a character/actor.   I also like spending a few moments talking to management and the role that can be directly supportive or disruptive.

Alignment between a ScrumMaster and Management can be very powerful.  Management affects the organizational environment tremendously.  There is an Organizational Cultural Inventory (OCI) that can be taken.  It divides the reward behavior of the culture into different categories.  Few actually promote the individual and team behavior we strive so hard to promote in agile.  I have seen this test taken with an aha realization, and at times simply to help to supply words to what was happening.  An awareness of any organization is a great step towards changing it for something better.  Management often has budget. Giving some budget allocation to a team scrum master and letting the team decide how to spend it sends a strong message for being empowered. I have also seen scrum masters help management by representing a project budget burndown.

The behaviors embodied among management that I have ever cherished…

A sense of calm.  No matter the size of the problem, it is typically one’s grace in overcoming it that we remember.  Behavior is emulated from leadership.  We are creating individuals and teams who need a strong suite in problem solving and communication.  Insecurity and defensiveness do not help in an environment that requires exploration, risk, improvement, collaboration and achievement.  Calm also denotes a willingness to grow.  A patience for individuals, teams, and even deliverables to build upon themselves into better versions.

Listen. Long before Agile, there was lean, and Toyota Production systems.  “Genchi Genbutsu” was a phrase for Go and see it.  Managers that would occasionally attend stand-ups, and always reviews let the teams know that their work was important.  If they also waited and asked “how can I help”, this is often lauded by teams in retrospectives.  A manager seeing how the team worked together, what was being worked on, also had easier times connecting with the program, and the individuals.  Characterization of the organization and capabilities of the teams.  Perception is a part of this, especially to detect when someone or even an entire team is down and feeling unsupported at the moment.  This leads into my next behavior, the ability to…

Inspire. Some have a gift for this in an individual basis, others can inspire on scale to an entire room.  The ones that stuck with me have always been personal revelations that took some strength to persevere, or overcome.  Even more strength to voice to others. Celebrate the small wins and point us just ahead to another better spot over some obstruction.  Often this inspiration changed the way we thought the fabric of the universe was set or a small angle to see something just a bit more.  Inspiration is a different kind of urgency.  It draws and compels us.  Far different from Command and Control, it empowers others who will run far faster if we simply enable them.

Change. Not just endorse it, and support it for others, but change themselves. Represent being an agent of change.  Adapt, learn and grow as an example to others.  This change also incorporates impact – not from fear or as an excuse to stave action indefinitely. Action which is guided by when, where, and how this effort is effective.   An agile mind is able to context switch, perspective switch, level switch, and scale.  Not always easy to ask, and still be able to communicate, communicate, communicate.

-Thanks for ‘listening’

Frameworks are full of….

People.

A process doesn’t work without people.  A framework doesn’t work without people.  Process and frameworks are meant to facilitate the delivery of value.  Value isn’t delivered unless you have people.  If everyone can agree on this we should also be able to agree that, in order for the implementation of a new framework, process or effort to deliver value to customers faster, people are THE lynchpin.

If we agree people are the lynchpin, we need to agree on what they need to be a strong lynchpin.  If I think on times where I have performed the best, there were common themes:

  1. I trusted those I was working with and was trusted by those I was working for
  2. The people I was working with were all focused on the same goal
  3. We all had high standards for ourselves, our product and each other
  4. Having FUN was not an afterthought

There are a few more but, these are the “biggies”.  Note, there is nothing in here about how we worked together.  I say this because I think, sometimes, it’s easy to get caught up in the process – or framework – of work.  Actually, the simpler the framework, the harder it is to implement because it is so very reliant on…people.  When you look at Scrum, it’s very light on the process and how.  Kanban is even lighter.  Simple processes imply a faith and trust in people to do the best they can, be open and honest with themselves and each other and try to be better each time.

Heavy processes or frameworks imply a lack of trust in people.  Otherwise…why all the process?  Process is made of checkpoints, flows, owners, approvers, accountable, responsible and the list goes on and on.  At the end of the day, people either did what they set out to do or they didn’t.  A process or framework won’t actually guarantee success.

People will.

When a company or team decides to implement a new framework, they need to first look at the people and decide a few things.  One, do they have people they trust?  Two, are they (the people making the decision) open to working differently?  Three, do they believe the framework they are implementing and the people they have to work within it will truly help us achieve their goal?

Processes and frameworks for the sake of having them are no good.  It’s not good for the company, the people or the customers.  Make sure there’s an environment for people to be successful in.  Keep the framework/process as light as possible and.  Ensure people are working on valuable products.  Leave the people alone unless they tell you they need you.  Then, be supportive and enable their learning and success.

It’s about the People NOT the framework

I’ve been hearing little murmurings…..

“SAFe is great because we can still keep watch over everything”

“Reporting will be robust with SAFe.  We’ll know how each team is doing at all times.”

“We’ll need really good Integrated BSAs and Tech Leads to monitor and approve the decisions.”

There’s NO PASS ON THE CULTURE CHANGE with SAFe, Scrum, Kanban or any other Agile framework.  I’m very serious about this.  SAFe is still based on Agile values and Principles.  The great picture doesn’t mean you don’t have to change the way you think.  It doesn’t.  I believe, when done correctly, it makes it less scary to change culturally but there MUST be change.  When you look at the picture, turn it upside down.  Team on top and Portfolio on the bottom.  It’s STILL about delivering value to the customer and the people, on the teams, are the ones who do it.

You can’t realize the full benefits of Agile until the culture change starts.

I’ll say it another way.

If you want to realize the full benefits of Agile, you will need to change the way you view people and work.

Here’s another way.

When you do not change your culture and Agile doesn’t work it will be because you didn’t change your culture.

Do not blame Agile.  Do not blame Scrum.  Do not blame SAFe.  SAFe is an excellent framework to learn how to apply the Agile/LEAN values and principles. So is SCRUM. Neither is a silver bullet.  The silver bullet is your brain and it’s ability to change.

Be DARING and Disagree!

Why are we afraid to disagree?  Are we worried about hurting someone?  Hurting ourselves?  Do we worry about looking stupid?  Why do we focus on those feelings instead of focusing on why we want to disagree in the first place? Do we know how to REALLY disagree with someone?

That last question is the one that hit me.   Generally, people  don’t disagree with someone to upset them or hurt their feelings.  Disagreement happens with good intentions and I really believe this.  People disagree to expand horizons, offer different views, challenge the speaker to think/be/act more!  But how do people learn how to do this well?  How can you disagree without making someone feel defensive?

On teams, disagreement is necessary to achieve greatness.  There are smart people who all have good ideas.  Elements from a bunch of good ideas make a GREAT idea but you need disagreement to get there.

We need to learn how to effectively disagree and how to open ourselves and minds up to those who have the courage to disagree with us.

My response to the comment “How”:

Thank you for the nudge and the comment. I had a great reply, hit submit and *poof*. I’ll try to re-create it…

1. By listening – so often we aren’t listening to what the other person is saying. We’re thinking about what we’re going to respond with.
2. By aligning – we need to understand what the goal is. If each person is coming in with a different goal, it will be hard to align, disagree and agree. Common purpose. Align on it.
3. By asking – we don’t ask if people disagree. We ask if they agree. What would happen if we asked for disagreement?
4. By thanking – thank the people who disagree with you. They are probably doing it to help you NOT thwart you.
5. By acknowledging – there is more than one way.
6. By being open – we need to be open to trying different ways and approaches
7. By respecting – we need to disagree respectfully.

Working in Agile May Seem Risky at First….

The very first project I worked on in IT was “Agile”.  As a new-to-IT project manager (my background was in Business Strategy and Operations) I wasn’t quite sure what this meant so I poked around, did a little research and came to the (very wrong) conclusion that it was no different than what I was doing today… Except now everything the team was working on would be on a board and we would only have to a have a 15 minute meeting everyday to discuss it.  Bless my heart.

For many reasons, the project was NOT Agile.  The team worked an insane amount of overtime with requirements and NFRs changing at a break-neck pace.  Two weeks before launch everything was ready.  It was defect free (as far as we knew), environments were working (as far as we knew), the performance testing was successful (as far as we knew) and we were only waiting for “Go Live”.  About a week or so before launch the Business Customer walked into the room, congratulated the team on a job well done (10 months) and let us know we would not be launching into production.  Why?  The financial collapse happened and the products that would be offered would not be available to customers any longer.  The company could not take the risk.

This is one story I use to demonstrate the risk reducing benefits of Agile.  Had the team been running Agile, truly Agile, we would not  launch EVERYTHING into production on one day. We also wouldn’t have wasted – yes wasted – money for new Infrastructure, resources and consulting.  We would not, at the end of the project, only have a “good job” to show for all the team had accomplished.

  • Small, incremental releases would have told us environments were working as expected and minimized the risk of identifying problems too late
  • The developers, who had very different styles and approaches, would have HAD to align on working agreements and standards to ensure smaller releases would be successful and easier to maintain and build on.  I shudder to think of how challenging the application would have been to manage…
  • The business could have tested whether or not they could drive customers to the application, if it was useful to the customers, WHAT the customers really wanted and make informed decisions regarding their investment and their strategy.
  • The team could have worked in a thoughtful, sustainable way rather than the reactive death march way they were forced to operate in making for a happier team and, ultimately, a more productive team.
  • The application may have not been kept alive following the collapse but, the learning would have been there.  There would have been SOME value to the business and the customers generated.

Really, the list can go on and on.  Working in an Agile environment is less risky.  The business strategy is focused on delivering value.  If something isn’t valuable to the end-user, you know it quickly – not after months or sometimes years. This means the business isn’t wasting money and resources on non-value add efforts.  The team is able to respond to quickly to change.  If direction shifts following a sprint, the overall impact is limited to one sprints worth of effort.  Think about it.  When there’s a scope change 10 months into a 12 month project in waterfall, the ripple effects can be tremendous.  That’s no good for anyone.  Your architects and support can work ahead just in time rather than having to anticipate every need for the next couple years saving money and effort.  Who wants to build something that may or may not be needed?  When you release something into production that does cause a problem you’re not searching through a massive code base that took months/years to develop.  You can focus on two weeks worth, identify the problem quickly and limit the impact to your customers and the platform.  When you make small changes and something is really awesome you can build on that to maximize the value rather than focusing on other things that may not.  An organization can respond to necessary changes that will help to reduce call center volume which has exploded since some marketing or servicing change was introduced reducing the risk of attrition for both customers and the poor call center employees.

There’s another meaningful way in which Agile reduces risk.  People.  Employees are working on things which they know and believe to be value add to the company and their customers.  They’re empowered. They have business context.  They have support to resolve issues quickly.  They’re happy.  This means they will stick around!  You don’t have a staff of knowledgeable, hard-working and willing resources walking out the door b/c they’re micro-managed, overworked or putting an effort against something that may or may not, at the end of the day, make a difference.

Agile principles have people at their core.  When you focus on people, great things can happen.  When you focus only on the work….

You complete that sentence.  Thanks for reading!

You can’t part time a new team…

Recently, there was a suggestion made that a Scrum Master need only dedicate 25% of his time to a team.  I disagree.  I really, really disagree.  Even if the team members are experienced Agile team members, there’s forming that needs to happen and they need to find their groove.  If they’re not experienced Agile team members, then 25% certainly won’t cut it.

MAYBE when a team has been together and is in that high-performing place, a Scrum Master need only devote 25% of their time but, I still question it.

So, tell me, what do you think?

Make IT Easy

The first job I really loved and had fun in was challenging, crazy, frustrating and awesome.  I used to think about that time a lot and wonder why it was so amazing.  The people were wonderful.  The work itself was good.  What really made it stand out was we all – about 150 of us – had a purpose.  Our CEO had a vision.  It was almost a rallying cry and we all were working towards achieving it.  And we did.

In the transformation I’m working on now, it would seem obvious that everyone would know the vision but, I bet if you asked 20 of us separately, you would hear themes rather than a unified, consistent no-doubt-about-it response.

I LOVE the idea of having a rallying cry for this huge, enterprise-wide effort.  I want a three word sentence to sum up what we are doing.  To me, it’s simple.

Make IT easy.

Make delivering value easy for our teams.

Make it easy for our customers to interact with us.

Make it easy for our teams to make good, informed decisions.

Make it easy for stakeholders and management to get the information they need.

Make it easy for people to learn.

Make it easy for people to challenge.

Transformation is hard.  Change is hard.  Making it easy is hard but, that’s our job. We need to make it easy.

You can’t focus on how far you have to go. Focus on how far you have come.

It doesn’t matter what kind of journey you’re on, focusing on the goal can be discouraging.  I have fallen into this trap myself.  In the midst of the transformation my company is going through, if I only looked at how far we still had to go, I might not show up to work.  When working with teams, I have thoughts on the ultimate goal for the team and can get impatient with the amount of time they are taking to get there.  This isn’t good for me but, it’s especially not good for the team.  As a Scrum Master, I have an idea of where I want to go and the kind of coach I want to be and there’s always so much to learn that it can be overwhelming.  I mean, will I EVER be there?  If I look back at where I started, I am there.  I have modified the end goal along the way.

Take some time to think about where you were when you started.  Reflect on what you have learned on the way and how you’re incorporating it now.  Celebrate the successes you have.  I guarantee you have more than you think.  Do this with your teams too.  Have them reflect on where they were when they first got together and assess where they are now.  It’s quite a motivating way to spend some time and, let’s face it, a little motivation never hurt anyone.

No matter what journey you’re on, keep your eye on where you want to be but, don’t forget to reflect on how far you have come.

“Fail fast” = “Learn fast”

When people start saying “We learned” instead of “We failed” you’re on to something awesome. Some people have a reaction to the word “fail” that isn’t positive and may create a boundary to learning the concept you’re trying to teach. So, change the language. Learn FAST! Every attempt at something new – big or small – results in learning. From making attempts or trying experiments, you will find things that are good and some that are not so good. The point is you try something and you learn. As long as you’re open, you will learn. As long as you learn, you will get better.

When you stop experimenting or trying you.just.stop.

Who wants to just be stopped?