scrum coaching

Start With Scrum?

chriswmoody2 Comments

“Start with Scrum.”  Have you ever heard someone say this?  I’ve heard this statement multiple times over the years when folks are talking about agile transformation, and it rubbed me the wrong way.  The problem is, I couldn’t quite put my finger on why. In many ways, it makes sense right? Scrum can help someone wrap their mind around work decomposition, shorter feedback loops, retrospection, and being connected to the customer more through user personas. But why are so many teams struggling to find agility with scrum? I think I finally can explain why I think this approach isn’t the right thing to do if your end goal is agility.

1 – Scrum is a framework and agile is a mindset.

sahota

Source: Michael Sahota

Last year when I was presenting at the Global Scrum Gathering, we borrowed from Michael Sahota who said something to the tune of “If you adopt agile practices you could see a 20% benefit. If you adopt an agile mindset you could see 300% benefit!” So many people I meet that are interested in agile for their organization just want the benefits but without the mindset shifts needed to get there.  I don’t fault them for that because when you look at the Agile Manifesto it reads out very well and sounds like positive things for most rational people. What is sorely missing is the “counting the cost”. If becoming agile as an organization was as simple as doing some training and doing the Scrum Events, there wouldn’t be agile coaches.

2 – Scrum is so 1990’s.  (just like these awesome “hackers” in 1995)

hackers

Look…I love scrum.  I really do!  It’s something that opened up a doorway for me to be exposed to agile manifesto which has changed my life and career aspirations.  But, while I was working on a blog post entitled “The History of Agile” it dawned on me that Scrum was a response to waterfall. And it was a tremendous leap in the right direction away from fixed cost/scope/timeline type projects.  Then came along the agile manifesto which was a response to scrum and the various flavors of agility frameworks sprouting up. But we need to look ahead and allow the agile mindset to lead us into the great unknown.  Ron Jeffries, one of the great original thought leaders in agile even said “I may have invented points.  If I did, I’m sorry now.”  The point is, we need to inspect and adapt as technology changes, culture changes, and people change.

Here’s another awesome 90s picture just because I found so many great ones to use for this article.

fresh

 

 

 

 

 

 

 

3 – Training wheels can create improper habits.

training

 

 

 

 

 

 

 

 

I was listening to a presentation by Joshua Kerievsky last week and he told a story about teaching his daughter how to ride a bike. He said that many people talk to him about how Scrum is like training wheels for their organization to adopt agile.  He pointed out though that training wheels don’t actually teach you balance, they just teach you how to steer and peddle.  He took his daughter to the park one day and had her learn how to ride a bike by keeping her feet of the peddles and just pushing herself and lifting her feet to learn the balance.  She quickly got comfortable with keeping balanced which is typically the hardest part of learning how to ride a bike.  And in no time she was ripping around on the bike!  What’s the lesson here?  You don’t always need training wheels to begin your journey towards agility.

In conclusion, starting with Scrum may not be the right strategy for your team(s).  My personal guidance as an agile coach is to only start with Scrum if you envision something close to Scrum being your destination. And even in that is your situation, always start with trying to adopt an agile mindset before trying to implement a framework. By doing this, you are allowing your organization to tap into their creative potential, untethered to just one framework.

Advertisement

“That’s Not Agile”

chriswmoody3 Comments

right_way_and_wrong_way_sign-other_zps8c090af3

If you work in an organization that utilizes one of the many agile methodologies, you have probably heard the statement “that’s not agile”. It could be about a proposed process change, or a critique of an existing way of doing things. It baffles me to no end when people get lost in the weeds about if something they want to try as a team is agile. This is unfortunately very prevalent in Agile Coaches and Scrum Masters who have a lot of experience.  Since agile is an emerging idea that is really starting to catch some momentum, some who have been advocates for a longer period of time can be standoff-ish about how to do things.  This should be a huge red flag, because there are so many variations of agile and not every organization is the same. You can know all the right things, but completely fail at helping a team adopt agile. That is why it is very important to be flexible, and not have a “better than” mindset.  The principles of agile/scrum are meant to be a guide, not a law that must be perfectly adhered to.  I’m not suggesting you should throw all caution to the wind and try any and everything, because “everything’s agile!”  No.  What I am primarily addressing is the way in which this topic is approached.

So, who’s right?  Maybe saying “that’s not agile” can be valid.  Or maybe we’ve lost sight about what agile is all about.  Let’s just take a quick peek at the Agile Manifesto for a refresher on what it’s all about:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

To be brash: If someone tells you “that’s not agile” and it’s something that could enable one of the 4 agile main points of the manifesto, I would seriously question how well they truly understand agile.  And agile by nature is something that I believe will continue to evolve as people uncover better ways of doing things. (sound familiar?)

If your organization is looking for an Agile Coach or Scrum Master or you are just trying to improve your skills in that realm, here are some suggestions for what not to do, and what to do.

  1. Don’t try to impress anyone with your agile credentials.  Do try to identify things that have been successful on similar teams/organizations.
  2. Don’t be preachy when trying to present new ideas.   Do suggest ideas with a humble and flexible attitude.
  3. Don’t rely solely on past experiences of what worked for other teams.  Do spend a lot of time listening to people’s needs an challenges.
  4. Don’t react when people are critical of agile.  Do find a way to tie what people want back to agile principles and show them how they could enable those things.
  5. Don’t press your own agenda.  Do thoroughly understand how you can support management’s vision.
  6. Don’t treat the agile principles as a law.  Do use them as a guide for making continual improvement.
  7. Don’t be too critical of a team’s existing processes. You never know how much hard work they have put into building what’s there. Do make a point to try to build on existing foundations, and position it as an improvement rather than tearing down.
  8. Don’t be too quick to judge what will work best for  a team.  Do ask a lot of sincere questions and follow the breadcrumbs of how things became the way they are.

 

Hopefully the next time you want to say “That’s not agile” you can remember the big picture and help your teams find the very best solution.  What things are important to you as an agile proponent in these regards?  Do you have any good stories to share?