“A coach is someone who can give correction without causing resentment.” 
― John Wooden

 “I have a rule on my team: When we talk to one another, we look each other right in the eye, because I think it's tough to lie to somebody. You give respect to somebody.“ ― Mike Krzyzewski

“The interesting thing about coaching is that you have to trouble the comfortable, and comfort the troubled” – Ric Charlesworth

It was a normal Monday morning, not much to speak of. I walked into the building and greeted the security officer: "How was your weekend?" "Too short!" A shared laugh, and I was on my way upstairs to catch a conference call, a couple of daily stand-ups, and a coaching circle gathering. When nobody showed up to the circle, I decided to watch a video that a fellow coach pointed me to. He hadn't even watched it yet, but the topic looked interesting: Modern Agile.

For the next 40 minutes, I was mesmerized as Joshua Kerievsky, CEO of Industrial Logic, gave his Agile2016 keynote on his invention, Modern Agile. For months, I'd been tortured by the idea that somehow, some way, Scrum and the Agile Principles could be leaned down, but just couldn't put my finger on how. Little did I know, Kerievsky had it all worked out before I even started wondering. 

Below is the Modern Agile spinner. No side is destined to remain on top, no side has precedence. He compared scrum and the agile manifesto/principles to an old laptop that looks just like mine (ouch!), and said it was time to put those old thoughts in in an agile senior home ("the food is great!").  I agree. 

I immediately redesigned my Scrum/Agile Basics training around the four easy ideas above. No more will I walk through all twelve principles, explaining each on in detail to confused new hires. In the spirit of one of the discarded principles, the art of the work not done includes not having to make a "cheat sheet" for students so they can remember them. I'll post more as I used Modern Agile to lean my own processes, teams, and training. Stay tuned! This is just day one! 

https://www.agilealliance.org/resources/videos/modern-agile/

Inspired by Mike Vanier's If programming languages were cars... 

If you have suggestions for changes or additions, please send them to me! You will be credited. That's cool, right?

• Adaptive software development (ASD) - A bunch of frat guys get together and decide where to go, then speculate how much money they'll need for both beer and gas. After they hit the first two bars, you'll see them on the side of the road thumbing for a ride.
• Agile modeling - Document continuously until you have a 16-page whitepaper describing the entire trip, then decide that the Best Practice is to just leave the car in the garage.
• Agile Unified Process (AUP) - You take your Grandpa's old '57 Ford out for a spin, but paste flames on the side to make it look cool. You go three miles before the car overheats and you have to push it the rest of the way.
• Crystal Clear Methods - Car? We don't need no stinkin' car!
• ​Kanban - A small team develops a car in small pieces. The work moves quickly across the board, where it all congregates in a junkyard heap waiting for someone to pick it up for testing.
• SaFE - You and 1,000 of your closest friends take a road trip on a Greyhound Bus that has a Volvo logo pasted on it.
• Scrum - Everyone works as a team to design the car in small increments, inspecting and adapting at the end of each city block. By the time you've travelled ten blocks, you realized that you are just going around in a big square.
• Scrumban  - You decide that you're going to MapQuest your trip, but then you decide the directions are wrong, ignore all signs, swerve into the ditch and then blame MapQuest. 
  
  

Last month, I had the privilege to be invited to speak at Agile Camp 2015 in Dallas, TX. Jeff Sutherland was the keynote, and it was an amazing presentation. You can see it, along with the back of my head, here:

I just read an excellent blog post titled, "A Scrum Master Job Description," on one of my favorite blogs, Illustrated Agile. In it, Len Lagestee describes the role of a scrum master from the view of the team and the company, based on their needs rather than a checklist of to-dos.

Here is my favorite part:

I recently came across an old blog post by Marc Loffler titled "10 Things to Drive Your Scrummaster Crazy." The "10 Things" seemed pretty innocuous to me...be late, hide impediments, do tasks that aren't part of the sprint backlog. All things that are not fatal, but a practice that the team could improve upon. I just kept focusing on the first line, "In my life as a ScrumMaster, I faced many things which drove me nuts."

As a ScrumMaster, one way to improve your own skills is to become so comfortable with your position that things don't drive you nuts, make you crazy, freak you out, or otherwise cause your blood pressure to rise. Relax. Breathe. It's only scrum.

In fact, I will counter with five ways to make sure that nothing a scrum team does will drive you nuts.

1. When you talk to your team, make sure that the first thing out of your mouth is a compliment or other positive statement. If you start right in with whatever it is that you think they are doing wrong, they will naturally be defensive. On the other hand, when you start with a positive statement, that reminds you that not all is lost - that there is success, even if they were late to stand-up today, or even tomorrow.

2. You don't have to tell them everything you see that can be improved. Like the breaking down of large stories, large changes in a team require attacking issues one small step at a time.

3. Learn to identify things that aren't your problem to solve. Loffler lists at least five things that aren't in the Scrum Master's realm of things they should be fixing, at least directly: work assignment, lateness, ignoring the definition of done, working on non-sprint tasks. If a developer says they don't have anything to do, it's the team's responsibility to help that person figure some things out. If an individual repeatedly can't figure out what to work on, then the training moment from the Scrum Master isn't to the individual, it's to the team on the importance of accountability and inclusiveness.

4. If something really bothers you, just mention it to the team...."I've noticed that...." and let it go. The team will either pick it up, or they will decide it's not important. That should be OK. If a team were required to fix everything that you didn't like, you'd be their project manager, not their Scrum Master.

5. Remind yourself of the Agile Principles. Encourage your team to know and love them. Set a good example. The details will come, if you help them feel the benefit of the overall picture.

Basically, relax and let go of the need to control.

To muck up an old saying about watches: a team with one backlog always knows which item is the highest priority, a team with two backlogs is never sure.