I've changed the way I am doing the interviews and putting the podcasts together. So, this is a bit of a test and any feedback would be greatly appreciated...
Part 1 - Interview with Shane Hastie on Hybrid Agile models, Business (Organizational) Agility and Bimodal.
Part 2 - Interview with John D. Cook and Troy Magennis on data literacy, what we should be looking at and finding the multiplying factors to help us increase productivity.
Any feedback (good, bad, whatever) would be greatly appreciated. You can reach me at firstname.lastname@example.org or twitter.com/drunkenpm.
Following a suggestion from Derek Huether, I'm including some notes (below) to moments in the interviews you may find of interest.
Some info on the interviewees:
Shane Hastie on LinkedIn and Twitter
Troy Magennis at FocusedObjective or on Twitter
John D. Cook can be found on his website, or on Twitter.
Shane Hastie Interview
Podcast Overview 00:44
Shane Interview Start 02:14
Opening question on hybrids, organizational agility, and bimodal 02:32
Will Hybrid models continue to exist 03:31
Letting Infrastructure off the hook 03:50
Why knowledge workers aren’t off the hook 04:25
Infrastructure example to explain where you need traditional and where you need agile 05:00
Where you need incremental roll out without iterative change 06:05
The PMP / Architect Happy Dance 07:00
The Agile people are all spitting on themselves 07:24
Launching a new product example 07:50
Learning is everything - you want Lean Startup 08:10
Knowing when to stop pivoting 08:50
Agile is spot on - Learning and Adapting 09:10
The goal is not agile, the goal is learning 09:30
Are we making progress 09:58
Throwing down the Agile banner 10:21
Agile is just a set of tools and a nice brand 10:40
We are still addicted to waterfall 11:00
People have been successful in the old way or working 11:25
There are not many pathological managers out there. 12:05
Helping them see that the global paradigm of business has changed 12:20
Finding the right combination of techniques and practices12:35
Packing agile brands 12:50
Can you design a new insurance product with TDD 13:19
What about the people who do not recognize that the business paradigm has changed 13:41
The pace of change is increasing 14:30
Cultural Change Officer 14:43
People don’t resist change unless they can’t see the benefits 15:00
Finding the personal win 15:40
Defining (Organizational) Business Agility 16:40
Leveraging skill and knowledge of people in your organization 18:33
Practices designed to fill the gaps in Agile 18:50
Shane’s favorites from the Agile 2015 19:40
Defining value for organizations 12:08
Teaching the organization 21:00
If we could all be Sweden… 21:50
Wrap up 22:00
John Cook and Troy Magennis Interview
Are we data literate enough? 24:05
experiments and lean startup 24:34
Using legacy charts we don’t understand 15:00
Bing addicted to bad data in legacy charts 25:20
How do we help them see the right data 25:50
What should we measure and look at 26:23
Working on multiple projects 26:35
How much work are we doing 27:00
When they ignore what the data tells them 27:30
The chronic problem of multitasking 28:00
Extreme examples from academia and leveling 29:22
Tools fostering dysfunction 29:50
How do we teach them to ask for better stuff 30:25
We knew this stuff and we threw it all away 31:00
Agile and the laws of physics 31:15
Probability in the future 31:30
A predictable environment vs rolling dice 32:15
How long will things take 32:40
Creating / Defining a stable team 33:00
Tracking interruptions per week: 33:23
Helping hem understand why interrupts are bad by visualizing it 34:20
Understanding the difference between what you do and what the tool says you do 35:25
Interrupting managers v interrupting programmers 35:40
Tracking positive interruptions 36:00
A level playing field - they all suck so it worked well 37:15
The managers that will breed 38:00
Finding the multiplying factors 38:35
Technical Debt 39:10
Figuring out if we are looking at something meaningful 39:45
What is the mission with respect to data? 40:10
Trying to find the best course of action 40:45
We’re more about removing metrics and detail 41:10
William S Burroughs
Language is a tricky thing. It is a broken, imperfect system of encoding and decoding a message. If the encoder and the decoder have the same key, the message may be heard and understood as it was intended. If the encoder and decoder have different keys… bad things.
The encoding and decoding takes place on many levels and often carries around a lot of baggage.
If I am in a conversation and someone says:
It probably means they are from, or have spent a significant amount of time in Philadelphia.
If someone says:
“We need to assign some resources to work on this project.”
It probably means they have been trained to manage or work with projects using a traditional (waterfall) approach.
When I took my CSM training I sat in a room full of 40 software developers. When I referred to people as “resources”, they boo’d me... literally.
In Agile, and in traditional project management we both use resources on our projects. But, because Agile takes care to focus on “Individuals and Interactions”, resources are generally considered to be things that do not have opposable thumbs and a capacity to binge watch five seasons of Breaking Bad in a 3-day weekend.
The way we use language infects our interactions with individuals. In this TED Talk, Diane Benscoler talks about being deprogrammed from the cult she had joined as a young woman. In the talk she refers to a “viral memetic infection”. This is, simply put, how language can be utilized to hack the brain.
In working with people on a project, if I regard them as individuals I work and interact with, I am likely to behave differently towards them then I would if I were to regard them as resources I expend to get work done (like a stapler). This can appear in very subtle ways – or, at least, ways that seem subtle to the non-Agile.
When I first began working in Agile I stumbled over a lot of similar encoding/decoding issues. The more experience I got with it, the more I learned how important it was to translate ideas before they passed my lips. As I would speak with someone about the project I was still thinking in waterfall, but speaking in Agile. I’d think “resources” but say “team members”. And that helped a little. At least, I thought it did. To other PMs, it sounded very Agile, but being a little further on with it now, I do feel it is fair to say that language aside, intent shows through. If I am thinking “resources” but saying “team members”, the fact that I have not truly bought into the Agile mindset still shows through to those who do think of individuals and interactions.
If you are in the process of trying to transition from traditional to Agile, it is important to bear this in mind. There is often a significant difference between how we perceive ourselves and how we come across to others. I may believe I am able to fit in with the Agile folks once I learn to speak their language. Certainly that is a massive improvement over not doing so, but being able to speak the language and adopting the behaviors and value systems are not the same thing. One may lead to the other, but being aware of the fact that it is an ongoing process is an important art of not destroying your credibility along the way.
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 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 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 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:
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.
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.