Subscribe
Posted on November 19th, 2009
While this has been known for a little while, I’m now officially announcing that I am an independent consultant and have launched a new company, Cory Foy, LLC, with a new website: http://www.coryfoy.com. I’ll be offering consulting and training services around lean and agile practices, as well as .NET Debugging and Training. I’m also going to be in San Francisco for the Innovation Games training in December, and hope to begin offering those in the new year.
So if you or someone you know is looking for a trainer, consultant, or coach, please give me a shout at foyc at coryfoy dot com, check out the site, or follow me on Twitter and say hello!
Speaking of traveling, we’ll be in the Tulsa, OK area next week, and I’ll be in San Francisco December 1st – 4th, so if you are in any of those areas, I’d love to stop by and say hi!
Posted on November 19th, 2009
Most of us don’t give much thought into what happens if our house catches fire. We call 911, the firefighters come in their shiny red (or green, or yellow) trucks, pull some hoses, spray some water, and then we call our insurance agent and begin rebuilding.
But there is a lot of training and preparation that goes into those firefighters being able to put out that fire, and then be able to hop in the truck and go back to the station, unharmed. In addition to the training, there are a myriad of safety systems to protect them – Gloves, Boots, Turnout pants, Turnout coats, nomex hoods to protect their necks, helmets to protect their heads, PASS devices if they get hurt. But there is one system that highlights an interesting look into reward systems and what it takes to change organizational culture.
SCBAs (Self-Contained Breathing Apparatus). These are the air packs and mask systems that protect the firefighters eyes, nose and lungs from the toxic effects of the smoke and the superheated air. And you would think that when SCBA’s were introduced, that it would have been taken up by any fire department that could get their hands on one.
And you’d be wrong.
I joined the fire department in 1996. Not the 40’s or 50’s when there may not have been SCBA’s. In fact, SCBAs had been around for many, many years. Yet, there was an active effort to educate firefighters that they should always wear them, and that before they went into any fire, they needed to be “on air” – mask on, plugged into the system, breathing from the tank air. Now think about that. There was an education campaign going on to tell people that it would be a really good idea for them to use this safety system which prevented them from breathing in 600 degree toxic smoke. Because the firefighters didn’t want to do it. Were they crazy? Did they have a death wish?
Of course not. What they did have was a reward system which gave credit for those who didn’t. It was considered a rite of passage to go into a fire without a mask. They even had a term – Smoke Eater. And while the fire chiefs might have wanted the change to happen, they had a culture to overcome. A culture which rewarded those people who already chose to do something a high majority of the population didn’t want to do by elevating those who took even greater risks and pain of not having a mask. It was just part of the job.
As coaches and consultants, and as those wanting to being change to our organization, we know that it typically takes pain to force a culture change. When a team is in enough pain, they’ll try just about anything to get it to stop.
Except when that pain is an accepted part of the culture.
Let’s take, for example, overtime in gaming shops. Or lack of automated testing in any sizable project. Sure, our families are upset, or every time we make a change something else breaks. But that’s just part of building software, of solving the cool problems, of getting it out the door. Right?
Right?
This is why it is so vital to measure the work streams, and to inspect what is going on with fresh eyes. Somebody should be saying, “Hey, this ‘breaks every time I check in’ thing causes me a lot of frustration, and it doesn’t seem like that should be the norm”. Sometimes the team can have that kind of introspection. Always the executives and management should be probing for these kinds of issues. And if you have a coach or a ScrumMaster on your team, then they should also be watching for these things.
Pain and frustration should never be considered “Just how it is”. And if you reward those who continue to push through it, and live with it, you’ll get what you pay for. But if you reward those who seek out to identify and remove that pain, you’ll end up with an organization capable of working through some pretty serious dysfunction.
Posted on November 15th, 2009
Dawn Cannan has a great post up called Change your organization, or change your organization. This is a phrase I use quite often to people, and something I struggled with because of this very thing:
There are many techniques for pushing through resistance, but how can you tell a fight that isn’t winnable? Or, at least, isn’t winnable for you?
It seems to be something you just "know", from what I can glean. And it is certainly not specific to organizational change. Kenny Rogers sang that wildly popular song The Gambler, "You gotta know when to hold ‘em, know when to fold ‘em, know when to walk away, know when to run…" The question I have always wondered is "*HOW* do you know?"
How does one know when it is time to call it in, when it is time to activate the second half of that phase?
At the Agile Developer Practices conference last week in Orlando, Mitch Lacey and I ran a session on ScrumButs. We had 5 ScrumButs that we were going to cover – until we asked everyone in the room to introduce themselves and list their top ScrumBut. This was the list. Notice what the majority are around. “Falling back to BDUF”. “Senior people doing Scrum but don’t want to (and actively sabotaging the process)”. “Talk the talk, but don’t walk it”. And in a session about ScrumButs, we found ourselves primarily talking about organizational values, team behaviors and elements of psychology that are solely around dealing with people instead of the process.
Remember that. People over process. You aren’t introducing a process. You are asking people to change. And people, unless they are in pain, don’t particularly want to change, thank you very much. All the models, all the processes, all the methodologies and principles and values are around one thing – we aren’t dealing with resources or teams or organizations. We are dealing with people. And people don’t fit into tidy mathematical equations, or checklists, or process flows.
In fact, one of the things around Scrum is that organizational impediments are exposed early and often, and the ScrumMaster helps to remove those impediments. Except those “impediments” are actually “people” – people that may be more powerful than whatever leverage you have, and who may not appreciate having a spotlight suddenly shone on them.
As an example, let’s say that the marketing team has always been the darlings of the organization – primarily because the development team works around the clock to get the battery of changes into production that stream from the marketing department. Suddenly, an “agile coach” comes in and posts a big visible chart showing that 62% of the developer’s time is spent on rework – rework that is coming from marketing not wanting to work together to have a cohesive plan. So the marketing VP calls the CTO, and suddenly there is no more agile coach.
What the Lean Proponents like David Anderson and Alan Shalloway discuss is that Lean principles simply report on and metric impediments, allowing the organization to decide if it is worth dealing with. And it certainly could be seen that a gentler introduction may allow greater change than a sudden one (see: How to Boil a Frog).
But at some point we come to a critical head. The team is struggling with wastes that the organization has no intent of removing. Concrete data is dismissed outright. The team can see what life could be like, but can’t seem to find the path to get there. So much so that the clarity of wastes the team sees is actually demoralizing. What then? What’s someone who is attempting to bring agility to an organization to do?
- Reach out – Sometimes it takes a fresh voice to get ideas across. Try to identify the fear that is holding people back, and find ways to address that. Perhaps it’s training. Perhaps it’s one on one consulting (under the radar if necessary). Perhaps you’ve pushed stuff for so long that your words aren’t effective.
- Practice what you preach – If you are promoting Test Driven Development, you better have some clue how to do TDD in that team’s code base, or find someone who can. The team needs the right tools, and if you are the one pushing it, they are looking to you.
- Provide a learning culture – Make sure that people are given slack to be able to discover the lessons you are wanting to bring. It can be a tricky balance (see: The Dreyfus Model Experiment), but people are much more likely to fight for things that they came up with and own
- Ensure the value system matches – If you are trying to bring frequent releases to an organization which ships once every 3 years, you need to find a way to align that with the other driving organizational values. If those values don’t match what you are trying to bring in, and you can’t find a way to relate them, then you are in for an uphill battle.
- Be a seed – Sometimes you can plant a seed in soil, water it, give it light and do everything right, and not realize that the soil is only an inch deep, and so right after the plant sprouts, it dies. And you think, “But I did everything right!”. But your plant dying has given the soil a little more nutrients, a little more depth, and a little more opportunity for the next seed to survive
- Use the law of two feet – In Open Space gatherings, there are several ways of describing when to leave a session, but my favorite is, “If your mind wanders, take your body with it”. If you are coming home frustrated, burned out, tired – that’s having an affect on you, your family and your team. The more you let that fester, the more chance you have of beginning to make irrational decisions which lead to a tearing down of things you’ve built
- Ask, ask, and ask again – There are many people who have been there. Enterprise agile transitions. Startup failures. Team upheavals. We’ve seen it, we’ve lived it. Talk to people you know and respect. Explain the situation, being as objective as possible. Ask not for justification, but for advice on ways you can be better. And if 5 for 5 come back and say, “What the heck are you doing there?” – then perhaps it’s time to move on.
This particular topic is personal to me because as of last Friday I’m no longer coaching a team I respected and admired for all the things they let me put them through. And there were many times when I questioned what I was doing wrong, why I wasn’t getting it, and how I could improve. J.B. Rainsberger and Corey Haines termed it best in a discussion I had with them. J.B. said, “It sounds like a marriage that is on the verge of breaking up because of co-dependency issues”. And it’s true. I was worried what would happen if I left. I actually thought, “I’m abandoning them”.
Abandoning. Believing that a team that has been delivering software for 13 years was suddenly going to fall flat if I left. A team that has delivered 4.5 million lines of code. And while it’s true that I’ve seen other teams fall flat after I left, it usually was coincidental and me leaving was a direct relation to the sense of impending doom.
Once I realized how much I was letting them lean on me, I realized that I had to go. So I spent several months insuring that my selfish needs were met – that they had everything I thought they needed to keep on. And watched that the more I stepped back, the more that leaders came in and stepped up. Watched as the team was grilled by Ron Jeffries and Chet Hendrickson and knew the answers. They didn’t always practice them, but they knew them. And then, on Friday, met with the VP with the best conversation I’ve had:
VP: Is there anything that needs to be transitioned from a knowledge perspective?
Me: Any minor things are documented in this wiki, and most everything in there has already been picked up by someone on the team on their own over the past couple of months
VP: What about processes? Who owns those?
Me: The team owns the processes. They are already running everything just fine.
VP: Is there anything else?
Me: Nope, I think they have everything they need
No frantic last minute transitions. No fears of things cropping up they can’t handle. And best of all, no transition task list. By me simply stepping out of the way over the past several months, the team picked up the critical things. My fears of abandonment changed to the nervous fear of a parent watching their child drive off in the car by themselves for the first time. There’s always a nagging fear something really bad will happen, but all bets are that they’ll hit only some minor bumps and generally continue to improve.
Will it be all roses? Probably not. After all, we’re saying that there are underlying organizational impediments that were in the way, and that without a desire to change, won’t change unless a pain event happens. But because I worked to make sure they had the tools, and build transitional relationships, I know I can stay in contact with them and perhaps offer guidance in the future as things progress.
Dawn may be in a tough spot, one that feels like you are losing everything you’ve worked for. But really you were a vital role – that first hook into what looking at organizational flow, wastes and organizational agility can mean to your company. I relate it to a training class I did when I was still a firefighter. It was urban rescue, involving finding a trapped firefighter who had gotten injured in a high-rise office building fire.
Visibility is zero. You are covered in gear, with a mask over your face breathing air from your tanks. You have no idea what the floor plan of the building is, nor what is going to be in your way. All you know is that one of your guys is in there, trapped, hurt and running out of air and time.
So you and your partner head in. And you stick to a left search, meaning you’ll always follow the walls left. You have 15 minutes of oxygen in your tanks, but are only allowed to go in for 5 minutes to give you ample time. You can hear the PASS device beeping from the injured firefighter. You just want to get to him.
And then your teammate smacks the back of your helmet. The call has come in that you’ve been in too long. You have to come out now. You don’t want to come out now. Every fiber of your body wants to keep going, to go just a little bit longer, a little bit further.
But here’s the great thing. The whole time you’ve been going, you’ve had a hose, or a rope, or something else that is tied to the entrance. And so you loop the end on a halligan bar, jam it into the wall, and get out as quick as you can. And the next team is at the door, and within 30 seconds has followed your guide back to where you were, and is able to get the injured firefighter out 5 minutes later.
Sure, the guys who pull the firefighter out are the ones who get their picture in the paper. But I can tell you from experience that without a doubt those guys know they could not have done it without you, without the line you laid, the route you chose, the experience you gained.
And so it is with organizations. I wish we had more Chief Engineers in organizations and that managers would not be afraid to be leaders as well. I wish more organizations would approach the lean principles and not be afraid to assess the overall flow of waste in their organization and tackle that. I wish that more executives would not be afraid of exposing impediments and waste and addressing them head on, instead of being holed up in dysfunctions. And finally, I wish that agile adoption didn’t have to come from team members who suddenly see the value and fight to bring that value to their teams, their departments, their organizations.
But when you find yourself doing that, don’t let it destroy that value in yourself. Be cautious of tunnel vision. And don’t be afraid to walk away. Because that might be your most powerful tool in changing organizations.
So Dawn, I admire you for posting that article, for addressing the concerns you have. And I wish there was a way to tell you when to know. But take heart in this – the work you’ve done *has* had an impact in your organization, in your teams, an impact that won’t readily go away. Think not only about what will happen when you leave, but how you can impact other organizations with the knowledge you now have. And don’t be afraid to let go. You might be surprised at what happens next.
Posted on November 12th, 2009
This week, I had the distinct pleasure of co-presenting with the ever lovable Mitch Lacey at the Agile Development Practices conference in Orlando. I also got the chance to have a great conversation with Alan Shalloway about the state of Scrum and the Scrum Alliance, and to run into Alistair Cockburn.
This got me thinking about the whole ecosphere that makes up agility in software today. There are so many angles one has to consider – from development practice changes, to team and project management changes, scaling up to organizational issues such as portfolio management, risk management, and avoiding local optima by focusing on the flow of value through the organization. And it we look at the practices and methodologies out there today, one could say that the cure to what blocks value in an organization is X-LACKS:
- X – Extreme Programming – This focuses primarily on the software development team, though with an important nod of the importance of customer involvement at all times
- L – Lean Software Development – Lean has been around for a very long time in the manufacturing world, and had a strong applicability to software organizations.
- A – The Agile Manifesto, the founding document outlining the values and principles behind the agile movements.
- C – The Crystal Methodologies are a family of methodologies which provide a sense of what tradeoffs and restrictions have to come into play as the size, scope and criticality of the agile project increases.
- K – Kanban is part of the Lean principles, and has twisted to have a split meaning. The Kanban board is a specific artifact, similar to the Information Radiator from XP or the Sprint Backlog from Scrum, but with an important twist – statuses are limited to the number of items in a column at a time. This is called limited WIP (Work-in-progress). This concept of limited WIP is applied at the broader sense to the team under the same term of Kanban.
- S – Scrum. Ah yes. Scrum. Three Artifacts, Three Rituals, Three Roles. One of the great love/hate stories in the agile world.
Just like ex-lax is made up of multiple ingredients, each with a specific purpose, so goes the above list. People like to make blanket statements like “Kanban is better than Scrum” or “You still need XP in Lean”. But pay attention. The people you want to listen to will provide the context like “…when you are adopting a large-scale organizational transformation” or “…when you are working with a company whose primary function is software” – and that context is what is necessary to know if the medicine you are using is appropriate.
The agile practices aren’t snake oil. They really do work. And the information they expose can make it seem like you’d rather stay sick. But if you address it with the right combination, and with the right leadership, vision and values, you’ll end up with an organization magnitudes better than what you could have ever achieved before.