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.

I was asked yesterday to describe the difference between a Scrum Master and a Project Manager and an odd metaphor popped in my head.

When a team has just won a game and the coach is interviewed afterwards they don’t say “Yep.  The team followed my instructions and plan exactly.  They executed what I wanted them to, when I wanted them to and how I wanted them to.  That’s why they won.”

They say things like “The team gave their best today.  They have been working hard together all season and, today, it all paid off.  They were amazing out there.  They deserve this win.”

I’m not saying a PM would actually take credit for the end-product of a team.  I am saying that the coach puts the emphasis on the team and the PM puts an emphasis on the plan and the execution of it.

This mind shift is essential and not an easy one.  I have found the relationships between me (as a Scrum Master) and the teams I have worked with are all very different with one exception.  Every single one has been based on trust.  When there’s a strong bond between a Scrum Master and the team, from my point of view, there’s nothing more fun or cool.

The team helps you grow by challenging you to be better and think differently. Their learning outpaces your own!  And they’re learning because they trust you, their Scrum Master, to make good suggestions and they’re willing to try things.  Sometimes, in my head, I will think “I dare you to be even better than you already are.”.  You can see them as a single entity and the possibility of the whole.

Scrum Masters also connect with the individuals on the team.  Many of my good friends are from previous teams and they are not people I would have known well had we not worked so closely together.  A Scrum Master can see things that are possible in an individual that the person may not even be able to see.  The same is true for the team member.  Often, team members have taught me things I never would have thought about or seen in myself.  Some good and some not so good but all said with the best of intentions.  The team members and the Scrum Master can help each other learn and grow individually.

I can’t speak from the team member perspective on this final point.  I feel very protective of my teams.  When they have great things going on and happening, I want everyone to see how awesome they are.  When people are messing with them, in any way, I feel very Mama Bear.  I may actually get a little too “bear”.   When they achieve greatness, I don’t want anyone or anything in their way.  When they’re on their way, I want them to have the space and room to work their way towards it.

When people ask me now why I am so passionate about Agile, the answer is simple.  It’s the people.  I can name them all.  I can tell you why each one is special.  I can tell you everything each one of them taught me.  The bond is built on trust and is powerful because you learned so much with each other.

As part of working within the agile world, we often scour and take great ideas from everywhere.  We will also form a few of our own.  Many come from seemingly unconventional sources such as the world of martial arts.  The terminology of Shu, Ha, Ri, – the maturity phases of a team passing through beginner, intermediate and expert, come from Aikido.   I remember Bruce Lee as an epic master and his art of Jeet Kune Do also expressing several wonderful maxims.  Among them; be like water, and with all motion: be direct, simple and efficient.  Sounding pretty agile yet?  I was pointed towards a book called Zen in the Martial Arts by Joe Hyam.   It is a wonderful and quick read by a student of Bruce Lee, that shares his wisdom with more than a few stories.  It is as applicable to the world of agile, as it is to martial arts.  The same human mind is at the center of both; learning, growing, overcoming.  Here are some of the passages that echoed amidst my own thoughts and resonated with my experiences.   I encourage you to read it as well.  There were three themes I saw as fairly prevalent.

The Mind – It is a powerful part of everything we endeavor upon. Visualize the success, focus, concentrate and RELAX.  Channel the effort, don’t let it dissipate or be spent thrashing.  (Distractions may be technical or even emotional.)  We need to know ourselves with a constant awareness.   Most of the time we invent and create our own fears.  Thoughts grow in the mind like in a garden – are we growing our fears, doubts, and negativity or are we fostering confidence and trust?  ’Tighten’ or focus the mind towards achieving one specific goal at a time.  At times the mind is not ready to receive and we would do well to instead be more like an empty cup and be able to accept ideas and learn from everywhere.  Fully committing ourselves to the most advisable and best solution.   Nothing is impossible to a mind that is willing.  Flexibility wins over rigidity.  The power of the mind is infinite.

Zen – There is a Zen riddle: “When you seek it you cannot find it.”   This is so true.  There are many problems that are best solved indirectly, or perhaps need time and experience in order to solve.  These might be support or growth type of issues, or even team environment and cultural changes that have a different tempo.  Sometimes these are problems which seem to affix us, distract us, and yes – seem to BLOCK us.  Some will be alleviated only as a side affect of other initiatives and endeavors.  Still others we will simply move around and come back to.  Remember that even Masters have Masters and are themselves CONTINUOUSLY learning.  When Masters (Scrum Masters, Coaches, etc.)  prefer to SHARE and not show students – both will leave the experience better.  Philosophy, zen, as a vehicle for personal development which de-emphasizes sheer intellect and instead points towards intuitive action.  I remember another zen saying – “It is the space between the bars which keeps the tiger caged”.  I have always picture the tempo of what we do – time itself as a space like the spacing in notes.  If we disconnect for too long a time – there is plenty of room for that tiger to escape.  The same with agile sprints, standups or touchpoints and letting disaster slip from our control.

Confidence – It is not self consciousness but concentration that should be cherished.  A defeat is part of the learning process.  Just do it, because with practice, anything become second nature and part of a natural instinctive reflex that no longer requires thought.  Diving into a problem or going up against a partner on the mat, you are simply seeking to become better and more experienced in the work ‘dojo’.  Situations which are unfamiliar to us cause us to be less confident.  It is our own exploration, extending ourselves into what we do and probing the limits or our abilities that offers us the greatest experience.  By seeking out others who are better than we are – we are able to improve.  When we lose our temper – we lose ourselves, we are no longer learning, and the situation rarely allows anyone to come away unharmed.  Accept yourself even with your limitations.  Practice and mastery of trivial things will allow us mastery of larger, and more precious things.

Hopefully not too much like a fortune cookie…  Yet there it is.

Years ago, I was preparing a meeting room.  50 minutes to help a team (in a defensive posture) get into some actionable technical debt that they had been criticized for by management.  It occurred to me to leave my shoes at the door.  I was treating that time/room akin to a dojo or safe place to learn.  Enlightenment.   It was simply a visual cue when combined with a few more analogies, helped quickly calm the team to get on into the work.   By picking them up and out of a combative context, it was fairly easy to help the team focus.  We flew through an exercise to identify, recommend priority and value for this technical debt.  All of which was from legacy code and project initiatives remaining prior from their adopting scrum.  We even had fun.   ( I did have clean socks and didn’t force anyone to remove their shoes.)

As Ever – if there are any challenges you are facing, a book that especially resonated with you, or you would simply like to share…  please.

A friend of mine did an informal poll today:

If you need three pieces of information quickly, what’s your preferred method of getting them?

a.  Phone call

b.  IM

c.  e-mail

What’s missing from the options?  Face to face communication didn’t even make the cut!  The people who responded generally preferred e-mail and IM due to having a paper trail to CYA.  Seriously.  I get it.  I do.  The difference for me now is perspective.  Why the need to CYA?  Why not EYA and own it?  If a paper trail is necessary, the problem isn’t anything other than the culture that exists is one where covering your ass is necessary. 

Channeling someone else here…..  that just makes me sad. 

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.

 

As I intimated in a previous post, when I first heard about Agile and Scrum, I poked around a bit and came to the conclusion it wasn’t very different from what I was already doing.  I figured it was no different than normal Project Management except I would have a captive project team (YAY!), all the work going on would be on a board instead of .mpp (EVEN LOUDER YAY!) and there would be 1 fifteen minute daily meeting rather than all the other endless meetings.  Yeaaaahhhhhh.  So, that wasn’t right.

I found some people in the department who did know this and started learning from them.  When I say started learning I started accumulating knowledge.  After I spent a good amount of time listening to others, there were pieces that started to click.  I still didn’t have the whole picture partly because I was getting information in pieces and partly because I didn’t “get” it and, as a PM, didn’t believe what I was hearing really either.

As more and more pieces started to fall into place I began to understand.  That is I knew, in theory, what I should expect and what Scrum should look like.  Once I reached a level of understanding, I was able to ask much better questions AND accumulate more information.  If you thought I was going to say I could apply it (well), I’m sorry to have let you down. I did start looking at the the team, the organization and myself a little differently and tried to think about how all of this information could possibly be applied.  My attempts had not been very, well, awesome.  I had theories…

I set out to figure out HOW to effectively apply my understanding of the information I knew.  Do you know what???  It’s really difficult to tell someone HOW to apply the information they have.  People can give you suggestions and they will be good ones.  True Learning happens when you just go and start trying it out.  We tell teams to do it right?  Fail fast (which means learn fast to me).

Talk about scary.  It’s scary to be with a team and just try stuff out.  However try you MUST.  You will learn so much faster and you can apply all that learning to grow and get even better.  You need courage, trust, some more courage and a desire to improve.  Knowing is useless unless you’re learning, applying and learning some more.  If I had started trying to apply all that knowledge earlier, I would have learned faster.  Would there have been mistakes?  Yes.  What do we learn the most from?  Our mistakes.  See where I’m going here?

When people say “I know all about Agile and Scrum.”  Just smile and wave and wait.  In the meantime, get out there and experiment.  Don’t be afraid to learn and grow.

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! 

 

 

 

 

I have thought that the interaction within a framework like Scrum and what it brings to the world of software development has some definite inroads into mitigating the risk of our endeavors.  In short, to simply deliver.  For a company adopting Scrum for the first time, here are some of the reasons why:

 Time-boxed

What we do is to break up big things in agile.  Even time itself.  Instead of here you go, see you in 6 months, which is a really LARGE time-box…  We prefer the ability for a program to connect, realign, adjust, share discovery MANY times in much smaller durations so that we can respond with changes that are not left to aggregate, grow larger, and simply fall upon us at the end.  We are slowly changing an organization’s ability to be able to respond quickly. This can be a cadence, or tempo, but the chance to do this and coordinate across individuals within a team, teams, programs, and even within an organization at an executive level is a force multiplier.  The time box helps us perform other breaks, loose couplings, explorations and growth/stage based building.  It forces us to think critically, innovate, and  simplify self-driven achievement.  By pausing to learn from it, early and often, we will realize  much larger wins.   such as Here are some more time-box benefits:

  • Narrowed focus to prevent distractions within a foreseeable goal (Limit task Thrashing or the shiny object distractions)
  • Make mistakes but not fail (discover and uncover things early and limit the time to do so)
  • Sprint length (every 2-3 weeks – and yes there is the 1 week Shock Therapy by Sutherland)
  • a small part of the entire commitment, delivered and used by the customer early.
  • See effect of change on team (a new team member) – velocity drop/increase or the work
  • Adjust priorities.  There is nothing like urgency to help us determine what is important.  It is unfair to list a 100 things as the same priority.  It also forces us to recognize the limitations and reliability of our own capacity to do the work. (If I only had 48 hours my bucket list would be very clear, concise, and achievable)
  • Not STUCK, frozen in analysis paralysis but move on into somewhere actionable.

Visibility

Under this I include communication, context and perspective switching, learning, and much much more.  We are seeking to identify EVERYTHING it takes to get through this organization and into the customer’s hands.  It uncovers the organization itself.  We characterize the capacity of our teams to perform the work, and we improve upon it.

  • Learning
    • Bring kingdoms into the light - Less isolation more engaged in continuous thinking
    • Break down CYA and your fault – we all own this, how can I help? My recommendation is…
    • Break down hidden processes – want to tie integrate, add value, bring technology, learning, perspective, change, experience
    • Everyone making as informed a decision as they can
    • Sharing best practices
    • Shakes loose the comfortable decay many processes can fall into
    • How it aligns directly with what needs to be done
    • Question and help represent what needs to be done and when
  • Communications
    • Through functions, roles
    • Through the Business and the organization around the teams
    • Through teams themselves
    • Are we working on the right thing in the right way?
    • Did we get into our riskiest areas first to learn more?
  • Commitment
    • Earn Trust by doing what we say
    • Getting better at predicting what we can do
    • Convergent expectations
    • Vetted solutions
    • Motivate
      • Celebrate wins
      • Listen to the feedback and actively seek it out

Iterative

Coaches hold practice for anyone in sports… Practice, practice, practice.  We want to get is right, we want it to feel natural.  It doesn’t seem right in business to say practice, and instead we focus on our competition.   When it is easy to move within the framework, we also allow ourselves a space to reflect, contemplate, try, innovate, as well as simply get in there and play. These events are done over and over, and the expectation every time is not just a check box on a list.  Did we improve it? What would have been phenomenal?   We lessen the  risk whenever we know ourselves, our team, our organization and how to coordinate in attacking the work.  Scrum iterates on these things:

  • Team-Delivery (Review)
  • Shippable Software
  • Retrospective (Program and Team)
  • Planning
    • predictability of aggregates
    • empirical analysis – we indirectly see and understand
    • right sizing and right timing the work
    • our own estimates -
      • the people doing the work estimate it
      • We become better at breaking work up, and estimating it
    • scope or valued work
  • Adjustments to make the work Sustainable effort
  • Improving processes and practices
  • Improving Team skills
  • Discovery (leveraging our experience and trials)

TEAMS

Ultimately the organization has not chosen Scrum but, redirected themselves with an emphasis on supporting teams that create software.  Teams at many different levels.  At times this is a cultural shift.  A choice in how we recognize, reward, and motivate these teams and enable their achievement.  Empowering a team is one form of reward.  These teams are comprised of the different roles, functions, and surrounded by others which will help solve, assess risk.  A team exists as well to mitigate the risk of the availability, talent or skills of a single individual.  Ultimately, the team is also there to help mitigate, solve, or assume that risk.   Our skills, experience, work and perspective together will collaboratively make this solution the right one, the one the customer expects and we can be proud of.

What happens when two very different Agile people write on the same topic and publish on the same day?  Hopefully some learning and growing!

Tomorrow there will be two posts published on the same topic: How Agile Reduces Risk

I’m pretty excited to see what my partner in crime has to say on the topic and how he says it. I’m very grateful to him for being open to this experiment and dedicating his time and thought.  Thanks, buddy.  I believe this will be fun and, if not, we’ll change it up!

I hope you will stop by to see the results and let us know your feedback, thoughts and other offerings.

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?

The Agile Guy...

My journey on the road called 'Agile'

Finding Marbles

Making sense of systems – Agile, Scrum, Kanban & Lean

Post Agilist

Your post-agile website on the web

Agile Greatness

A Scrum Masters journey through Agile and SCRUM

awelaf

Just another WordPress.com site

Path of Three Hundred

The story of Petah. The sailing adventure of a simple human in search of Peace. Authored by Greg Frucci.

Agile things

A Scrum Masters journey through Agile and SCRUM

esther derby associates, inc.

A Scrum Masters journey through Agile and SCRUM

esther derby associates, inc.

A Scrum Masters journey through Agile and SCRUM

Agile Scout

Agile Software Development News

A Scrum Masters journey through Agile and SCRUM

Jason Little

A Scrum Masters journey through Agile and SCRUM

Agile Coach Jacque

Musings of an Agile Coach

Follow

Get every new post delivered to your Inbox.

Join 32 other followers