An Interview with Mike Vizdos

I had the chance to interview Mke Vizdos for a podcast recently. You can find it here.

Even if you aren't familiar with Mike, there is still a good chance you are familiar with his work. Here is a list of some of the things he's been up to recently...

Mike Vizdos is  ____(please select from below)____________ 
 X  A Father of two great kids and Husband of an incredible wife
 X  A Certified Scrum Trainer
 X  An Agile thought leader / author who has been talking about enterprise level Agile adoption since before it even occurred to most of us
 X  All about Implementing Scrum
 X  Entrepreneur
 X  One of three guys in a shop working with Lean Startup 
 X  Co-founder and Community Builder of Gangplank RVA  
 X  Podcaster (will link to)
 X  Author of a children’s book illustrated by his son
 X  Founder of Real Scrum Jobs (will link to)
 X  A really nice guy
 X  Way busier than you…
 X  A walking example of how following your passion around certain areas of focus can help you establish an agile work life that is creative, experimental, invigorating, and of course, full of failure in the best possible way.
 X  Is working on applying what he learns daily using “this” cartoon as a reminder:

Generation Agile

When I posted on twitter earlier this week about the presentation my wife and I gave at the Global Scrum Gathering, Paris 2013, on The Agile Girl Scouts, a friend of mine asked me to put some context around it. He was able to understand that this was a pretty big deal to me, but was't sure why. My hope is that this blog post will provide some explanation around that.

The Waterfall

Most adults in the workforce today have learned how to manage work using a waterfall model. That means work follows something along these lines:

• Initiation - We figure out what we need to do

• Planning - We figure out how we are going to do it

• Execution - We do it and try to follow the plan as best we can

• Monitoring and Controlling - We check to see if what we delivered is what was wanted

• Closing -  We shut it down and capture what we've learned along the way.

Bag of Oranges Days

For many of the people who adopt this method, success comes from a command and control approach. This approach tends to view people as "resources" which are expended on a project to achieve a specific end. In the IT space, it has a history of being successful about 30% of the time. For the person acting as Project Manager, it often leads to a lot of "bag of oranges" days.

When I learned and later began teaching this model, I kept wondering why no one had taught me that stuff before. The simple tools it provided, seemed more like common sense. Just having the simple capacity to see an overwhelming amount of work and have the basic tools to break it down into manageable, workable elements was very enlightening. Since then I have been looking for ways to go back and teach my younger self some tools that would have made life a lot easier. 

Those tools were great, but using them was a bit like Frodo putting on the ring. The more I used them, the more I started to feel that I was supposed to try and control the uncontrollable and the more I started to view the humans I worked with as "resources" and not people. They were pawns on a chess board and I was playing chess against an opponent I could not hope beat because the only thing I could be sure of was that whatever I was able to imagine, predict, or plan for, was the only thing that was not going to happen. 

When I entered the workforce and started to work for people who had been taught that success came through control, I was often the pawn on the board. In many jobs I was micromanaged, condescended to, accused, blamed and generally treated like someone who could only be counted on if they were bossed around and threatened. I, in turn, reluctantly learned this approach and tried, to apply it (with limited success). This didn't happen all the time. I was lucky to have a few really great bosses and teams along the way and I was fortunate to find myself in situations where I really was able to be creative and collaborate with other people who cared as much about the work as I did. Those moments were invigorating. 

The Agile Manifesto

As part of a response to the waterfall approach, in 2001, a bunch of smart guys got together and came up with the Agile Manifesto, which says: 

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

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

That is, while there is value in the items on
the right, we value the items on the left more.

In my journey towards adopting the above and learning to use the models and frameworks which support the Agile Manifesto, a lot of what I do is a reaction against the traditional command and control approach I had been taught.  I often joke that I am in a state of recovery, but I do tend to view it that way.  One of the reasons I get so much joy from what I do for a living is that  I get to help others on their transition as well. But I do think it is important to acknowledge it as a corrective action. 

Hope for the Future

Any parent wants their child to have a better life than they did. We all want for our kids to experience less adversity (or at least different adversity) than we did. If Agile is about creating a work environment that values people, their ideas and ability to collaborate in an effort to deliver higher quality work, then it is a very positive and healthy response to a workspace that did not support creative collaboration and self-organization. 

Each new generation finds that certain things which were common in previous generations, are no longer good for us. When I was a kid we'd go to the Jersey shore in the summer. If my Mom was able to get some Coppertone SPF2 or 4 on me it would only last until I was able to get to the water and scrub it off. I'd play, swim and lay in the sun until the blisters formed. The blisters were an indicator that maybe it was time to put on a t-shirt, a baseball hat, or in extreme cases, SPF 15. My daughter has been spared that due to how much more we know about the damage the sun can do to our skin.

My goal with teaching Agile to young people is similar to educating them about the dangers of too much sun. My hope is that if they learn about Agile first, their experience with it and exposure to the benefits it can provide will "inoculate" them against some of the challenges they would otherwise face if they entered the workforce as "resources" to be used up on a waterfall project. My hope is that they will see Agile not as a response against something else, but as a natural, organic way for empowered, creative people to deliver high quality work. 

Ninja, Baker Priest

In the Agile and Scrum classes that I teach, one of the topics that seems to cause a fair bit of stress, or at least, more than it should, is Cross-functional Teams. The stress tends to be rooted in a misinterpretation of what cross-functional means.

So first, what it doesn’t mean is that everyone on the team has to have the exact same skill set.  That would probably make finding people to work on the teams pretty tough. Everyone has things they gravitate towards and develop a certain amount of expertise in. Finding a really talented graphic designer who can code like Neo and is still willing to write documentation is unlikely. But we still want to have a team of people who have some ability to help each other out.

When I think about these things I sometimes find it helps to consider it outside of the context of Agile and Scrum.

Example 1: The A-Team

In 1972, a crack commando unit was sent to prison by a military court for a crime they didn't commit. These men promptly escaped from a maximum security stockade to the Los Angeles underground. Today, still wanted by the government they survive as soldiers of fortune. If you have a problem, if no one else can help, and if you can find them .... maybe you can hire The A-Team.


In the A-Team, everyone has a role:

Hannibal – the Planner and Visionary
Face – The Master of Disguise (and Social Engineering)
Murdoch – Pilot of anything that can fly and team Wildcard
BA – Wheel Man and Muscle

Now, BA hates Murdoch. Actually, that’s not really true. BA pities the fool. He does not trust Murdoch because

1) Murdoch is certifiably insane 

2) BA hates to travel by air. 

So, every time they have to fly, Face or Hannibal has to slip BA a mickey finn or a needle and put him out.  While he out, they travel by air. When they land, someone has to drive. This role typically falls to BA because it is his primary area of expertise. However, if BA is still knocked out. Someone else has to drive. The other team members do not necessarily have to be as good at driving as BA, but they have to be able to drive well enough to get from A to B and possibly evade some law enforcement along the way.

Example 2: Ninja, Baker, Priest

Let’s say you have a team comprised of a Ninja, a Baker and a Priest. As part of the work they have committed to for the Sprint, they are responsible for taking steps which will result in the death of Mr. X.  Since the team has a Ninja on it, this should be no problem at all. But what if the Ninja comes down with a terrible case of the sniffles. He (or she) can’t exactly be a silent agent of death if they have to stop and blow their nose every 5 minutes.

So, the team has a meeting and discusses the situation. It is agreed that the Ninja should stay home, have come chicken soup and try to get better. In discussing the work, the Priest and the Baker agree that between the two of them, the Baker has the most experience with knives, so he agrees to head out and complete the contract on Mr. X. The only catch is that the Baker also had work to do. Fortunately, the priest has been well trained and has been known to be able to do some pretty cool stuff with Bread too, so he will help the Baker while the Baker is helping the Ninja.

So, the idea of cross functionality is that the team has or develops the ability to help one another when they need to. It is not that everyone on the team develop the exact set of skills. Once they have made a commitment, they are responsible for meeting it. If everyone on the team has a specific skill set that is not shared, a smart team will take some tome pairing or cross-training to remove single points of failure.

This is just a simple explanation. For me, these kinds tend to work the best. If you’d like something that digs a little deeper on this topic, I’d recommend checking out Heinrick Kniberg’s post on Crisp.

Agile 2013 Interviews - LeanKit CEO Chris Hefley

BigVisible Interview with Leankit CEO and co-founder Chris Hefley at Agile 2013 from BigVisible Solutions on Vimeo.

Agile 2013 Interviews - Jim Elvidge

Jim Elvidge at Agile 2013 from BigVisible Solutions on Vimeo.

Agile 2013 Interviews - David Bernstein

David Bernstein Live at Agile 2013 from BigVisible Solutions on Vimeo.

Agile 2013 Interviews - Ron Jeffries and Chet Hendrickson

Agile 2013 Podcast with Ron Jeffries and Chet Hendrickson from BigVisible Solutions on Vimeo.

Non-Violent Communication and Scrum with Juan Banda

Click here for the interview

At the Scrum Gathering in Las Vegas I had the opportunity to attend a presentation given by Juan Banda on using Non-Violent Communication (NVC) with Scrum. If you are unfamiliar with NVC, it is a way of communicating that the Center for Non-Violent Communication describes like this:

Nonviolent Communication (NVC) is based on the principles of nonviolence-- the natural state of compassion when no violence is present in the heart. 

NVC begins by assuming that we are all compassionate by nature and that violent strategies—whether verbal or physical—are learned behaviors taught and supported by the prevailing culture. NVC also assumes that we all share the same, basic human needs, and that each of our actions are a strategy to meet one or more of these needs. 

People who practice NVC have found greater authenticity in their communication, increased understanding, deepening connection and conflict resolution.
The NVC community is active in over 65 countries around the globe.

Over the past several months I have begun to notice NVC cropping up more and more in conversations between Scrum Trainers and Scrum Practitioners. It has also become a frequent topic of presentations at Agile conferences.

Outside of my work with Scrum I have also become more aware of people using it in their day-to-day interactions. To describe it as a framework for communicating does not really address the depth to which it impacts the people who practice it. If practicing Agile is a way of transforming how we approach our work, NVC could be considered to be a way of transforming the way we interact with the people we are working with.


In this podcast interview, Juan explains how he became aware of NVC, how he began practicing it and how it has impacted his work with Scrum teams. This will be the first of a number of posts and podcasts on the subjects and I will also be posting about my efforts to incorporate it into my work coaching Scrum teams and providing Scrum training.

If you would like to contact Juan Banda, you can find his blog here. You can follow him on twitter here: @juanbandajara 

Personal Kanban with Johanna Rothman

This interview was originally recorded in July 2013 and posted to Projects at Work.  The original blog post and posting of the recording were lost when P@W became part of Project Management.com.

BUT Johanna is brilliant and I learn a ton from her every time we talk. 

Also, Personal Kanban is REALLY important. So I found the original post and am reposting to fix the broken link on my index of Personal Kanban blog posts and podcast. (Which you can find here: https://drunkenpm.blogspot.com/2014/10/summary-of-personal-kanban-posts-for.html)

This conversation centers around one of the topics in Johanna's book Manage Your Job Search (https://leanpub.com/manageyourjobsearch) and her article on how to use Personal Kanban for your Job Hunt (https://www.jrothman.com/htp/agile-job-search/2013/04/personal-kanban-for-your-job-hunt/)

If you'd like to learn more about Johanna, her work and her writing: https://www.jrothman.com/

drunkenpmradio · Johanna Rothman - Using Personal Kanban to Manage Your Job Search - July 2013

Personal Kanban - Lessons Learned

“And now we're back
Where we started
Here we go round again
Day after day
I get up and I say
I better do it again”
Back Where We Started ~ The Kinks

It’s been seven months since I began using Personal Kanban. Initially I wanted to learn more about Kanban and also come up with a better way to cope with the massive amount of things I had waiting for me to do. I’ve definitely learned more about Kanban and my ability to manage the work I have to do in a much healthier way than I had before. Most of all, there were learnings that caught me by surprise.

• Personal Kanban helped me get more clarity on what my workflow process actually is. It isn’t easy to be non-judgmental (with yourself) about this, but I believe that doing so is a very important part of understanding and improving.
• Personal Kanban helped me come to the understanding that despite the pressure and stress I put on myself, there is almost nothing I have on my plate that I don’t actually really want to do. The hard part seems to be to keep that in mind all the time. It is something I still need more work on, but I do feel extremely fortunate in that respect.
• Personal Kanban has allowed me to become more aware of the “waste” in my “system”. This has allowed me to make a conscious choice about what waste should remain and what should go. Some of the waste is an important part of my workflow and creative process.
• I learned that one of they keys in my own management of work I have to do is to maintain a physical board with a limited amount of space in which to capture work to be done. I need to be able to see everything at once for it to be workable.

And now, seven months down the road, I am on the road to recreating the same mess in KanbanPad that I used to have in Things. Right now I have:

• 15 items in my Backlog Queue
• 16 items in my Someday Queue
• 17 items in my On Deck Queue
• 17 items in my Today Queue
• 4 items in my Doing Queue

The biggest benefit of the last few months by far, is that I have become more aware of how I work and I am more aware of what I need to do to correct it.

When you begin studying certain forms of meditation you learn to count your breath. When thoughts arise you are to observe them, but not engage them. You just let them move on without getting caught up with them. If you do find that you are caught up, once you realize it, you let go and then refocus on your breath and start counting again. Not easy in the beginning, but the more you do it, the less difficult it becomes. My expectation is that working with Personal Kanban (or whatever approach is taken to getting work done) is similar. There are have periods where things go well and, and some, not so much. The trick is just to go back to the starting point and do it all again.

Time to make the donuts…