Building Up and Tearing Down

May 27, 2019

Recently I put on a public Leading SAFe training. This wasn’t your typical training, however. In collaboration with Ron Quartel, we tacked on an extra day to discuss FAST Agile. Now if SAFe is an example of a scaling framework, FAST Agile is perhaps a good example of what you might call a de-scaling framework. FAST uses an open space style of organization to provide only the most bare bones structure and guidance. It’s really quite elegant in its simplicity. 

Ron and I had both been inspired by the ideas of mix-ins – processes and practices that we can mix and match together. So, it was with that in mind that we thought putting on a combined training class would be interesting. First teach SAFe, then turn around and teach a competing framework. Then compare and contrast. Well, as it turns out, the combination was quite brilliant.

As I taught the two days of Leading SAFe training, the class built up the framework from teams, to programs, to solutions, to portfolios. Learning the roles and processes of each. By the end of the second day, I was exhausted but happy (as usual). Then Ron stepped in and proceeded to teach FAST Agile on day 3. In essence, he took everything I had taught them and tore it all down. The focus was on simplicity and self-organization. The class was totally into it – questions flew fast and furious. Everyone was fully engaged. 

The contrast between the two frameworks was stark, and it raised many questions for both Ron and I. You see, I wasn’t there to sell anyone on SAFe. Don’t get me wrong, I like the framework, and I enjoy the training a lot, but I don’t give a damn whether or not you decide to adopt it. What I really care about is that you make an informed decision based on what I hope is the deepest possible understanding of the options. If you understand the values, principles and practices deeply, then you will choose to implement what is best for you and your organization. There is a tremendous amount of nuance and subtlety to the art of organizational change (that’s probably why I like it so much), so I believe that the ability to not only adopt ideas, but also to be critical of them is important. 

The act of building up the framework and subsequently tearing it down again felt like a very powerful learning experience. It went beyond rote learning. Not only do we ask, “Why would you adopt this?” We also ask, “Why wouldn’t you adopt this?” That requires us to understand the ideas from different perspectives. People stayed after class each day debating the ideas for over an hour each evening. That’s when you know you’ve really got them thinking. I’m looking forward to doing it again.


My Personal Andon Cord

April 29, 2019

Have you heard of an Andon Cord? On the assembly line it’s that cord you yank on to stop the entire line when a problem is found. The idea is to stop everything until the problem you encountered is fully understood and fixed. That way we take the time to improve the function of the assembly line so that those sorts of problems never slow us down again. It’s a little example of that “slowing down to go faster” that those crusty old software curmudgeons blather on about.

But who listens to those old cranks anyway?

I was thinking about a recent Product Owner training I was running where I was told that the product owners didn’t actually sit anywhere near the team (that was assuming they had a product owner to begin with, but I digress). It turns out that the product owner for a given team was very likely located in another building or even perhaps another state or country altogether! This kind of colocation issue is fundamental to improving a teams performance. Address it and you will see meaningful improvement quite quickly. Fail to address it and you will be wrestling with the side effects and consequences forever without dealing with the underlying problem. 

So what did I do? Well, this was just the start of a two day training, so I had at least a day and a half more of training that I was expected to deliver. So I tossed that issue on the mountain of other issues that I was uncovering and moved on. Trainers gotta train, kids gotta eat. I raised concerns, told the right people, and moved on. Everyone kept moving.

Now in hindsight, I’m not sure if I should be proud of dismissing something that important. However, I know it happens all the time. But it makes me wonder, is there an issue sufficiently important that I would call the whole class to a stop in order to address it? What would cause me to stop the line as a trainer? Where is my trainer Andon cord?

If a fist fight broke out in class, I’d certainly stop the class. So there’s that. But what else? If someone was crying, I’d stop the class. If I found out someone was being hurt, I’d stop the class. But if I found out they were doing something stupid…I wouldn’t necessarily stop the class. I might pause long enough to mention that I wouldn’t recommend doing that. Maybe I’d hand them a Darwin Award (oh, now there’s an idea…). But stop the class? No.

Let’s look at that example of the product owners in a different location than the team. Colocation of product owners or customers is pretty fundamental. You would stop the line if you found out that the car’s tires are missing. If someone told you,”It’s OK, we keep them in another building.” You would probably be well justified in insisting that the tires get brought in pronto. There’s not much point in leaving silliness like that alone. So I’m asking myself, if the customer has paid me a few thousand dollars for the training, but instead of delivering the training, I stop the training to focus on that one problem…what would happen? Fixing that problem could probably mean a huge return on investment for them. Something far beyond the paltry amount they have spent on the training. It’s food for thought. 

On the other hand, typically these types of organizations are not in a place where they are accepting or tolerant of radical change. Usually few if any folks in the room are actually empowered to do anything to change the situation. Furthermore, even the folks who hired me may not have that power. You have to have a lot of credibility in an organization before you can even start talking about that sort of change. Credibility takes time, and that’s something that most trainers don’t have. You’re in, you do the training, and you’re gone. Poof of smoke. Vanished.

So in the big picture it probably depends on your context. If you are just in for a quick one-time training, then you really don’t have the credibility to stop and attack problems like this. On the other hand, if this is part of a long term engagement, then there is the real possibility of being able to deal with problems like this in real time. To be able to pull your Andon cord and stop the line. What a marvelous thought.


The Agile Gymnasium

January 12, 2016

IMG_0271

I used to be a weightlifter. All through college, and for much of my adult life I have been in gyms exercising in one form or another. I’ve had some modest success. The experience of joining a gym goes along some standard lines. You’ve probably done it yourself. You show up and they take you around the facility and orient you to the equipment. They may even go so far as to give you some very basic training. You get an introduction to circuit training and then they slap you on the butt and tell you to “go be awesome!” You can record your exercise sessions on this little card over here…

That’s pretty much it.

As you might imagine, the success rate with that sort of system is fairly low. A lot of people never come back (although many continue to pay their monthly dues). Those who do come back typically have no idea what modern exercise programming looks like and simply go through the motions: they ride the stair master, do a few sit-ups, and maybe do some curls. That sort of exercise has some marginal utility – you get some small amount of aerobic benefit, but it’s a far cry from exercising a meaningful percentage of most people’s potential.

Most people stop there, but there are a few who have a more ambitious goal in mind. They may be trying to improve their tennis game with better conditioning. They may be looking to build massive pectoral muscles (like most teenage boys). They may be trying to maintain their conditioning in the off season of their sport, perhaps like cycling in the winter. In other words, the purpose of their exercise is to improve their performance in some sort of real world scenario.

I’d like to pause for a moment here. I was listening to a discussion with some folks who owned their own gym and they had an interesting model. It had three tiers to it:

  1. Gym Work: Work in the gym is not like the real world at all. It is where you go to prepare for the real world. The gym is a safe place to work to the point of failure (that’s important) and to learn.
  2. Expeditions: Expeditions are adventures in the real world that are guided by a coach. So it is real world experience, but with someone there to guide you and help if you fail.
  3. The Real World: This is where it all comes together. Ultimately, this is where the training in the Gym and the experience in the expeditions pays off in terms of improved performance.

As a model for the role of training for high performance, I thought this made a lot of sense. There was one more thing that they added to this: They were capturing data on the entire group’s performance and analyzing it in order to provide better training for individuals in the future!

So when you join the gym, you use a training program that is similar to what others in the gym are using. Your performance of that program is measured and metrics across the entire population training in the gym are measured. Then experimental changes are made to the training program and their benefit (or lack thereof) is measured across the group. Gradually their training program improves over time. But the training isn’t just tested in the gym. They also track the performance of their members when they go on expeditions. This measures the effectiveness of their training program in the real world.

OK, enough about this gym. What if we could use the same metaphor for the way we train our development teams? Training would be a weekly thing. Something where you go in for training on a periodic basis to firm up your skills. There might be repetitions (pair programming, mob programming, etc.) and there might be coaching (coaching circles, etc.) and there might be someone who is coordinating the training program and measuring the performance across the entire group of trainees.

There could be expeditions from time to time. Hackathons where people get to try out what they have learned in the gym out in the real world. You know: build a real project, maybe deliver something over a weekend. Test out your mastery of your skills in the real world – with a coach there if you need it.

Then there is game day – the real world. You take what you have learned and join a team. You get to flex your massive coding and collaboration muscles and help build something challenging – something amazing. What a great model for development! But I’m not done yet…

Let’s take this model, we’ll call it the “gymnasium model”, and apply it to something like Certified Scrum Master Training. Right now, there is two days of class time and exercises and then they slap the CSM on you and send the newly minted CSM out into the world. It’s a hauntingly similar scenario to the average person’s experience at the Gym: welcome to scrum, now “go be awesome!” Maybe you do a few sprints, do a few standups and off you go. That’s about as agile as most people get. Seriously. You get some marginal benefit, but that’s about it. It could be so much more.

But what if we did things differently? What if instead of signing up for a 2 day class, you were to join an Agile gym. Maybe twice each week you go into the gym to “work out”. A coach would give you a workout, perhaps something like this:

1. Dysfunctional Standup
2. 3 Reps in the coaching dojo
3. 2 Sets of mob programming
4. 2 reps of code katas
5. 1 cool down with a retrospective

That’s just a sample workout. The Agile Gym is a safe place to try out new skills and to push ourselves. The coach would be responsible for measuring the effectiveness of the workout and modifying it over time. Experimenting with new techniques and combinations of methods and evaluating the outcomes. Of course, this is just training in the gym. From time to time we are going to need to test our our competence in the real world. The coach would provide some guided expeditions (perhaps twice a month). For example:

1. Participating in a Hackathon
2. Participating in a Startup Weekend
3. Participating in a Maker Fair

These are events in the real world that are important places to evaluate the effectiveness of our training in the gym. If our coding skills have improved, then we should do well at these events and build confidence in our ability to use our newfound skills in the real world. Speaking of the real world, hopefully now we would see the agile behaviors that we have practiced being manifested in useful ways in the actual projects that we are running from day to day. Our collaboration skills should be tight, our planning impeccable, our retrospectives revealing. And if we find any weak areas, then it is back to the gym for more training.

In this model, the gym is always open. You actually practice your skills and see improvement. What an amazing way to learn about agile!

It’s not a bad model really. Actually, it’s a really darn good one. Who wants to start a gym?


Agile Coaching and Training is a Scam

May 5, 2013

con-man4

In the Agile world, coaches and trainers are distinctions that were created in order to create different ways of making money. They have no useful business purpose outside of filling the pockets of consultants with cash.

How can I maintain this? Here’s how I see it now: I (used to) have friends who are trainers. They are normal people like you and me. They typically got their start as project managers and or scrum masters just like the rest of us. At some point they go through a process where they are vetted for the following:

1) An understanding of the vague terms used in the agile lexicon
2) Conformance to religiously held views regarding a process
3) Communication skills & attitude

Once they are hit with the golden hammer, anointed by the powers that be, given the blessings of the bishops, or certified, they can charge large amounts of money to provide the same training over and over…and over…

Or they can just go out on their own and do it without any such approval. Of course if they do that, then they have to survive based on whatever actual skills they may have. They have to come up with their own material that isn’t provided by some governing authority. They have to market their skills all by themselves, and it’s a cold and unforgiving consulting market out there.

Regardless of which path you choose to take, are you doing anything that a good scrum master or a project manager couldn’t do? No. Training is part of any good manager’s role. Many scrum masters that I know have actually given CSM training at one time or another – and done quite well. Furthermore, the agile training that I’ve seen isn’t rocket science. It takes only marginal presentation skills to successfully deliver agile training. It’s not original material. It’s not like you have to know how to write code. In fact, most trainers I know, can’t write code. Are these really the people who are going to tell software developers how to work?

It’s nice work if you can get it.


Continuous Improvement & Risk

July 1, 2009

I witnessed an interesting pattern today while running Boris Gloger’s “The Ball Game” exercise with a team. The basic idea is to iterate a team activity, stopping to make improvements each iteration. The idea is to practice and measure the impact of continuous improvement on team performance of a task. In general, the team did as you might expect: the first iteration things were pretty rough and their performance wasn’t very good. In subsequent iterations, their performance continued to steadily improve until they were nearly perfect at peforming the task.

Here is what I think I saw happening: with each iteration the group became more stable. They eliminated variation until they reached a plateau in their performance. They found stability, but they also reached a plateau where they were not making significant additional gains with each iteration. It felt very much like they were playing it safe. They didn’t want to do anyting to risk their “score” each iteration of the game.

Now I knew something that they didn’t – as facilitator I knew about other rather creative ways of configuring the group that would have given them a quantum leap in performance. There was an opportunity to take a chance and rethink the problem and make some stunning gains in performance – but at a very real risk to their short term performance. What I saw was a group that was tweaking the small stuff and missing the opportunity to change the big things that would make dramatic differences performance. It felt like there were competing pressures that were impeding the teams ability to see opportunities for performance improvements. Now of course this was just an exercise, so there really was no risk if they didn’t perform well – so any pressure they were putting on themselves was basically self imposed. And that may have been enough to blind them from seeing the opportunity for greater change.

How often do we do this on our own teams? We make improvements that fine tune the status-quo until it feels reasonably stable – and then we stop. I know it happens to me. Add a little pressure from management, and I very quickly can’t discern the forest from the trees any longer. There may be opportunities for change that offer dramatic improvements, but I will very likely not even consider them if it means potentially risking my team’s established performance.

I think this is all the more reason to focus on making the team feel “safe”. As managers we sometimes need to protect our teams external pressures so that they can keep relaxed and flexible – open minded enough to see all the possible alternatives.

Or I could be nuts. You decide.