“That’s Not Agile”

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?

Advertisement

Agile Certifications…What’s The Value?

Scrum certs

Last week I attended an agile training seminar for the Certified Scrum Master (CSM) certification. It got me thinking about what is really the value of going to an agile training session.  Having already attended the Certified Scrum Product Owner (CSPO) training last year I was curious as to how much I would benefit.  When I attended the CSPO training the trainers take was that you needed to learn almost as much about the scrum master role as you do the product owner to be able to understand better. I have to say I was pleasantly surprised with the amount of new knowledge I walked away with. I’ve noticed that each trainer has had a deep background leading and coaching agile teams, and with that comes different nuggets of wisdom. While the first 1-2 hours were mostly review, after that it seems that each session had a life of its own and had tremendous value.

Do you really need an agile certification to be effective on an agile team?  Technically no. But if you are someone who is looking to make a role transition or have an extensive background in waterfall environments, it could be a great tool and demonstration of your ability to make that transition. Obviously time and experience with agile is more valuable, but if I were going to make a statement in the same format of the agile manifesto it would look something like this “Working experience over training seminars and certifications.  That is, while there is still value in certifications, there is more value in working experience.”

Why should you keep going to training seminars like this? For me I realized that when you work in an agile organization you can start to get used to the way you are doing things.  And being with a room full of people talking about what they do gives your copious amounts of inspiration for what you are doing. I was furiously writing out sticky notes with ideas for things to try, and now the challenge will be slowly introducing some of those ideas to the team without being “that overly hyped out conference high let’s change everything” guy.

Something else I was pleased with is that after attending the CSM training I was required to take an exam (open book), that required me to prove my knowledge. It didn’t sit right with me that I could attend a 2 day CSPO training and leave with a certification.  The CSM exam was actually pretty challenging, even with the internet at my disposal.  It was a good exercise all in all.

Apology to the internet and an intro to the blog

Dear internet and devoted bloggers, I’m sorry.  I occasionally write some blog posts on my personal blog, but for the most part I’ve been one of those who consumes but doesn’t contribute.  Have you ever thought while searching for something “I really should be one of the people that posts helpful information on the internet and not just the one who searches for it.” ???  Well…I have too, for many years, and that’s part of why I am starting this blog.

I’m a project manager in the Seattle area working at a consulting firm.  In recent years I’ve been working with agile team more and more, and know I’ll have some information others might find useful. I’ve developed such a strong interest in agile/scrum that I’m going to get of my keyboard butt and write!

I’ll be posting about practical everyday tips for agile teams, my experiences with different training resources, agile memes and will even have guest bloggers from time to time.  Hopefully we can keep a lighthearted and humorous approach to solving real business problem.

Thanks for stopping by The AgileSphere!

-Chris