Knowing and Understanding is different than Applying and Learning

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.

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 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?

The Sound of Silence

I’m uncomfortable with awkward silence.  It’s, well, awkward.  I’m starting to realize how powerful silence can be.  I have been challenged lately by some people to learn more about myself.  It goes something like this:

Person:  Do you want A or B?

Lily:  I want A.

Person:  Why?

Lily:  Well, because of x, y and z.

Person:  Is that all?

Lily:  *blink*  – Pause – Fidget  and finally I mumble something to the effect of Yeah.  Maybe.  I don’t know.  Why do you ask?  Do you think that’s not right?  and so on until I finally share what I’m really thinking and feeling.

Silence makes you think about what you are going to say especially when paired with an intense stare.  I’m learning to use this with my teams because I have found my true thoughts are generally what I share.  The silence makes me honest with myself and others.  It’s powerful.  Try it.


I firmly believe trust is the secret sauce to a highly performing team.  I also believe that without it, a team will never be great and is likely, in fact, to fail.  When teams have trust they speak plainly and openly to each other because it is safe to do so.  They will be open to trying new approaches and listening to ideas because they trust their team-mate.  They will joke around with and support each other.  When there’s no trust, managers are copied in e-mails.  Play by plays of the retro leave the room.  The team room is quiet.  Factions form.  It’s ugly.

Many years back I was coaching a team that was doing pretty well.  A manager came over and told me they were going to combine two teams together and I would be the coach.  Um…..oooooooooooook.  To say that neither team was thrilled would be an under-statement.  Even the introductions were tense.  Then came moving day.  The new team moved into my “old” teams digs. Moving members didn’t like the room arrangement.  Already moved members liked where they were sitting just fine.  I’m sure you get the idea and this was just the beginning.

None of the team members wanted to make an effort with those who weren’t part of the original.  Planning was a nightmare.  There was no collaboration.  They planned within their old team lines.  They divided the board in half.  I didn’t know what to do.  Naively, I felt they would work through this and all would somehow be right with the world.  Luckily, I had a mentor coach in the organization to whom I turned for advice.  His advice?  You need a good retro.

He helped me craft the retro and I wish I could remember the activity, but I cannot.  What I remember was it got the conversation started and kept the conversation going.  And going.  And going.  And going.  They didn’t trust each other at all.  Each team felt like the other was judging them.  They each felt the other thought they were better.  They both thought I cared more about the team I was originally with!  They were both worried that all the good they had built up as separate units would vanish if they didn’t take steps to preserve it.  Ah HA!  Now we’re getting somewhere!

Eight hours later.  Yes.  E-I-G-H-T hours later the team had created a joint vision, joint norms and proceeded to re-arrange the room.  Any artifact previously on the walls was pulled down.  A new team was born.  And, they were awesome.  Truly, powerfully awesome until a short time later when they were split up again.  *sigh*

Here’s what I learned from that experience:

  • Trust on teams is incredibly important.
  • A teams identity is also very important.  You have to coach them through establishing one.
  • Don’t sit back when you see a team doesn’t have trust.  Get to the bottom of it quickly.
  • It’s OK to have an agenda as a Scrum Master when you go into a Retro.
  • Teams will solve the problem for themselves when they realize what the problem is, that they are a team and that they can.

What experiences have you seen when there’s been a lack of trust on a team?