My Thoughts On Refactoring Agile

#1

This was super challenging for me to write. Curious of everyone’s thoughts and comments. Don’t hold back either (like I need to say that to some of you lol).

#2

One of the things that stuck in my head after the podcast with Josh from Modern Agile was his remark of “we preach inspect and adapt and yet scrum hasn’t changed in how many years?”. I never thought about it that way and once he planted that seed I started really looking at how we do what we do. I think as a whole we as practitioners/coaches/etc. do ourselves a giant disservice by not applying what we preach to our practice as a whole. Second law of thermodynamics; we need to constantly improve or else the steady decay will get the better of us.

Sad to hear your idea of coach pairing got you the unicorn look as I really like that idea. If someone has a fragile ego (or is super competitive) it makes sense to approach the situation as peers trying to help each other as opposed to a mentor/mentee. None of us is as dumb as all of us!

#3

Hi Chris! Wish I could have had a beer with you before you left Pittsburgh; didn’t get a chance to see you off!

Pairing and mentoring with a coach are both perfectly acceptable. You need only look at Vic Bonacci and Brett Palmer’s talk at Agile 2016 on the subject to see how viable coach pairing is. The folks that made you feel disheartened likely didn’t have the insight, yet, that you have. It wouldn’t have been your responsibility to turn on the lightbulb for them, anyway :wink:

On your article, my biggest challenge is making a connection to refactoring agile. Your thoughts felt like observations and experiences, not concepts that are changing (or have changed) to achieve new clarity. I might be interpreting “refactoring” too literally–or I’m just being dense–the latter being most likely… I’m not the brightest person in the world lol.

For example: certification. How would you refactor it? What might you adjust or change to reduce the impact of the “cash mill”?

#4

Gee thanks Zach love you too. Tell me how you really feel!!! :slight_smile:

Self-admittedly, in the article I said I do not know refactoring but when I looked at the meaning it suggested small tweaks in mindset or behavior to yield a better outcome. Then I remembered something I heard about challenging things I hold most dear.

Maybe I’m wrong about them. Maybe the things I think are wrong can be right in different settings. Or the converse. Small tweaks in mindset can yield positive change. So I tackled 3 ideas.

The list isn’t exhaustive and was meant more of a challenge to everyone else.

So, while I don’t think you are being dense there might be a slight literal meaning. But again it’s my take on what it means, which is why I put that in the title. Not definitive thoughts on refactoring agile. Just my thoughts to start a conversation.

Thanks for reading.

#5

Well, you said “don’t hold back” - so I just shared how I felt. Nothing passive aggressive intended! I’m glad we talked directly over Twitter about this because email/text/comments are easily flipped sideways (I avoid being present in social media or the Internet for this very reason…)

As part of the dialogue you’ve invited, I’ll share this: knowing you, I’m certain that how you act is a form of refactoring towards the right principles.

We can be dogmatic and stifling, yet we can also be coerced by dysfunction in the name of pragmatism. I agree to challenge that which is held closely, which is what prompted me to ask about what you’d change with respect to these ideas :wink:

#6

The difference between Scrum and many other agile systems is that it is a framework. While XP requires certain practices, Scrum allows any practice within it. Also, Scrum has had several changes over the years. 2009 05, 2009 11, 2010 02, 2011 07, 2011 10, 2013 07, 2016 07 are the ones that I have.

#7

“THE BUSINESS OF CERTIFICATIONS WILL RUIN OUR INDUSTRY”

Certifications are not the problem. Certifications where you have to go through an extended period of showing your skills (as opposed to “just” knowledge), are extremely valuable and useful.

Lazy recruitment practices are and the resulting certification industry are the problem.

Lazy recruiters try to substitute the hard work of assessing candidates themselves with selection using tags and certifications.

The certification industry is just a response to the desire of candidates to float to the top of searches by these lazy recruiters. I have given in to this phenomenon as well. I am looking for my first dedicated agile coach position and it became very clear to me very quickly that rather than being valued on my coaching skills, I was being excluded from selection (not just searches but knock-out criteria as well) because I didn’t have a scrum master certification. So I dedicated a week to study and passing the exam. That’s one obstacle out of the way.

In hindsight I could have saved myself the money. I should have focused on getting in touch with companies that realize that “knowledge based certifications” are interesting but don’t tell you much about someone’s skills. I count myself very lucky that I have had the opportunity to go through a recruitment process with a company that focuses on live assessment as the main driver of their selection process. Assessments that they conduct themselves with people who you’d be working with as the assessors and using criteria that reflect what you will encounter day-to-day as a result of how the company goes about their business. It’s been an amazing experience so far. And even if I don’t make it all the way through, it will have given me invaluable experience and has already made me realize that I am no longer going to settle for any firm relying on knowledge based certifications for their recruitment.

#8

On an other aspect: pairing as opposed to mentoring / being mentored, I fully agree with you. As mentioned in my other reply, I am still setting out as a coach. I have the basics down but need a lot of experience before I’d be comfortable calling myself an agile coach (regardless of my job title). But experience alone will not be enough. To learn, to get better, you need feedback. As close to the time of “performance” as possible. Pairing, or simply having someone observe, is a way to go. That will however only be of real value if you have a debrief shortly, preferably straight, after a coaching or facilitation session.

When regular feedback like that is not to be had in your day job, the way to go may be to find a community of practice where you can do peer-to-peer coaching, preferably with a third person as an observer. The IAC supports setting up coaching circles for this, but I don’t think they organize/run them. (To get fully certified by the IAC, by the way, involves records of your coaching hours as well as submitting recorded coaching sessions for their assessment.) The ACI (Agile Coaching Institute) and the ICF (International Coaching Foundation) do more towards this I think, with local chapters. Yes, they are not so much focused on agile coaching as they are on “general”, “executive” and “life” coaching, But hey, coaching skills are coaching skills and certainly executive coaching is very much in scope for an agile coach.

We sh/could look into how we can support each other with a community of practice that wouldn’t involve training businesses, but would be for and by ourselves. Even beginners can help each other get better, simply by stating what they observed happening. Of course a shared frame of reference would help in structuring the feedback / observations.

The times I have tried to get this off the ground informally, it ran aground on people’s busy schedules, including my own. But a call for practice coachees in the same communities, generated a great response and provided me with quite a number of practice “victims” to prepare for an assessment.

#9

Awesome thoughts @marjanvenema. What I appreciate about your comments is something very near and dear to me: stating your opinion and being willing to look inward and challenge yourself first instead of others.

With the last two posts and some conversations with some great minds in our community, I think I’ve stumbled upon something. People (in general, nobody specifically especially you as we have not met) in our community are very quick to blame others for our agile adoption challenges.

It’s the executives for not providing the right leadership. It’s the trainers for not teaching the right principles. It’s dev managers for not understanding velocity is relative. It’s the team for not knowing they should limit their WIP. It’s other coaches or project managers. The clients don’t know what they are buying.

Not everybody does this, but many in our own community can’t take our own damn advice. Look inward and inspect and adapt.

I did not write this post to say certs are all bad, or that following the Scrum Guide is wrong. I wrote it to own my own biases and encourage others to do the same. Maybe if we all did, the community might improve.

That’s just a guess. :slight_smile:

#10

Challenging your own biases is never bad :slight_smile:

Taking your own medicine is something most professions have a hard time with. There are plenty of sayings about it. “Onder de vuurtoren schijnt geen licht.” is a Dutch one that I like very much as it paints a clear picture. Literal translation: “Under the lighthouse shines no light.”

The fundamental reason for that, I think, is that doing what is “right” or “best” requires the ability to postpone rewards, i.e. play the long game. In this day and age of instant gratification that is getting exceedingly difficult, both on a personal and an organizational level. Not to mention the stock market driven extreme short term focus of many companies. (The company I am currently working for was acquired by private investors last year and taken of the market so it could focus on the long term in peace.)

Combine that with the reality that learning requires a willingness to tolerate discomfort on many levels.

And then with the cultural infatuation with excellence which stymies learning, creativity and change. Big Think had an interesting video/transcript about that: http://bigthink.com/videos/eric-weinstein-our-cult-of-achievement-is-crushing-the-genius-out-of-people

Learning, inspect and adapt, requires the willingness to be uncomfortable, to be vulnerable, to be open to being wrong, to be open to not having the answers, being uncertain. That’s asking a lot. Of anybody. And especially of people who have been brought up and are living in families, schools, companies and societies that use shame as their main way to influence (control) other people’s behavior. Unfortunately, using shame is very effective, especially with kids. Unfortunately, using shame is soul crushing. Bit I digress.

Any transformation started from above is doomed in my not so humble opinion, unless… execs are willing to open up an be transparent themselves and rebase the company around purpose and learning. HBR has an interesting post on that “why leadership training fails” that can be read entirely as “why agile transformation fails”: https://hbr.org/2016/10/why-leadership-training-fails-and-what-to-do-about-it Any agile coaches brought into to “implement agile” are set up for failure unless they manage to change the mindset of managers and manage to work their way up a company’s food chain.

Mind you, reading that stuff would make you think that every change always has to start at the top. I don’t agree. It will make change easier, sure. But grass roots movements can be just as successful. Trouble is they require a lot more courage than many can muster. Because with a grass roots movement, we are talking revolution. And that requires courage. A lot of courage. From the people at the grass roots and the people hierarchically just above them. To insulate them from the rest of the organization so they can start convincing with results instead of talk.

Maybe the way forward is to let go of the A-word. To stop trying to rake in business with buzz words that will be hijacked by the less scrupulous looking for a quick buck. Or to trade mark, copyright and whatever else is needed to protect a new term we might come up with. That would require serious bucks though… not just to register it, but also to defend it from the less scrupulous… :wink: As we can’t control others, maybe we should simply focus on getting real and managing expectations. That will mean we will lose the clients / customers that are not willing to take on long term programs or fundamental change. Don’t think that would be such a bad thing. These would be the headache producing clients / customers anyway. :wink:

By the way: apologies for hijacking your thread and thank you for allowing me the space. Talking or writing always helps me clarify my own thoughts. (Might turn my ramblings here in a slightly more well structured essay)