Thanks for a great 2014

December 31, 2014

concert-december-31-explosion-3867-733x550

 

“Cheers to a new year and another chance for us to get it right.” -Oprah Winfrey

This blog was first started back in 2007. Since then, I’ve published 258 posts on topics that ranged from outright rants, to humor, to reviews and recommendations. Everything on the topic of Agile software development processes.

Originally the idea was to dedicate the blog exclusively to the tools used on agile projects (hence the title). Obviously I didn’t end up confining myself to just discussing tools. After all, we agilists prefer interactions over processes and tools. So I ended up writing on a variety of agile topics. Most of the topics were things that simply came spontaneously. The ideas arising from my work, my reading or simply my feelings.

Looking back, some my posts were insightful, and others were simply boring. Occasionally I have taken what felt like significant risks with the material I’ve posted by saying things that I knew would not be popular or well received. In some ways that has made writing a blog like this very liberating.

Things began slowly in 2014 with just one post in March. After 200 posts, I think it’s fair to say that I was running out of steam. It wasn’t until August, when an old colleague of mine noted that I hadn’t been writing much, that things began to change. The writing engine fired up and I began posting again.

At this point, I started a new blog, onestandardman. The idea was to focus on a long-standing fascination of mine: Self-experimentation. I wanted to run experiments serially and share the results.

So now I was writing two blogs! In fact, this just seemed to grease the writing gears for me. For 35 days, I kept up a blistering pace of writing, posting twice a day. Once to each blog. September was a ferociously productive month for me.

The interesting thing was that in the past, I had a hard time keeping my writing quality high when I wrote with such frequency. This time quality was not a problem. The material just kept on coming and all I had to do was write whatever the voices in my head were telling me. Eventually, the writing pace slowed to a more sustainable level of 2-3 times per week.

It has been a wonderful year. I’ve encountered greater challenges this year than ever before. Thanks for being there.

 


Roles Considered Harmful

December 27, 2014

business-businessman-businessmen-222-825x550

“Man’s role is uncertain, undefined, and perhaps unnecessary.” – Margaret Mead

So there I was talking to a team that was split across two locations. There was the usual set of complaints that you might expect from a scenario where a team is divided across geophysical locations: miscommunication, delay, misunderstandings, etc.

In this case, the QA folks happened to be in one location and the development folks in another. As we talked through some of these issues, I couldn’t help but point out that the root cause – that separation between the two groups, could easily be solved: just split into two teams by location. Of course, that would leave us with a team of developers without any QA. Working with dev only teams doesn’t bother me (been there, done that, got the merit badge), but it was a different question altogether for this team member I was talking to. For them, the entire idea of removing a role from the team was completely untenable.

The first objection was, “If we don’t have QA on the team, who will keep developers under control? ”

Whoa! What? Back up the truck!

Who will keep the developers under control? Seriously?

At this point, I shifted gears and started asking questions about the team roles. I was concerned with this QA role that ‘controls’ cowboy developers. Why do we need to ‘control’ anybody in the first place? How exactly do you exert this control? What would happen if you didn’t control them?

It was quite an eye opening conversation. The more I looked at it, the more I realized that the roles of QA and developer had an astonishing amount of baggage associated with them. The QA role is the only role that can test code. The developer role is the only one that can write code. One can’t possibly be trusted to do the other’s job. It would be a lapse of ethical integrity!

Oh my God! Do people hear themselves when they utter this tripe?

Apparently not. No wonder we avoid creating roles or minimize them in some processes (i.e. Scrum, or better yet, swarming). It’s awfully easy to come to the conclusion that roles carry as much dysfunction as they do benefit for a team. They invite definition and structure, but in doing so they also create walls and barriers to effectiveness and efficiency.

As soon as you create a role that is entirely responsible for quality (or anything else for that matter), you do three things:

  1. You define their job, and by doing so, you make a distinction between “the things that I do” and “the things that you do”. It starts to define what you can and can’t do. That’s useful if you are trying to subdivide work. But not so useful if you are trying to create dynamic, flexible teams that adapt themselves to unanticipated changes. You know…Agile?
  2. You create an in-group and an out-group. In psychological terms, you are creating an “us” vs. “them” distinction which almost inevitably leads to conflict.
  3. With these foundations, our thinking is constrained about how the process of value creation should work. The distinctions that we hold in our heads are what we use in order to create the boundaries of our processes. We find these boundaries between Dev and QA, sales and product, managers and teams, and yes, even Scrum Masters and coaches. They’re everywhere.

Obviously, roles can have profound impacts on how people think about their relationship with the people they work together with. So what can we do about it?

As I asked further questions, it became apparent to me where I might go. Talking to the team would be a complete waste of time. They didn’t define the roles. They were hired for the roles that their managers defined. So step one is talking to the managers.

Of course managers are people too. They are only trying to fit in the hierarchy and culture of the company. Eliminating roles would be a very threatening thing to a manager whose whole career has been based on making and supporting such roles. So we can’t expect a whole lot of help from there either.
Of course you could just show them…

There are some talented developers I know, coaches really, who are very good at working side by side with teams and demonstrating by example how to blur the distinctions between roles. You can even do it yourself with other managers. Build those relationships. Help them out. Show them how it feels to have someone else help out that doesn’t have the same role as they do.

In the end, I think it comes down to people being able to experience what not having hard defined roles is like. You can’t talk them into it. You just need to roll up your sleeves and demonstrate with them.

“I’m not playing a role. I’m being myself, whatever the hell that is.” – Bea Arthur

References
Scrum Masters Considered Harmful, Paul Hodgetts
Us and Them: The Science of Identity, David Berreby


The Ultimate Project

December 24, 2014

christmas-gift-present-3466-830x550

Delivering toys to 7.125 billion people in one night.

Dang.

Now that’s a project. It kind of puts my own project management hassles in a different perspective. I guess I’m going to have to stop whining about my project headaches. I mean, 7.125 billion? How many servers is that? Well, if we’re talking about the same Santa, I guess the answer is 1. Now that’s multitasking!

As I watch my family and I gear up for another Christmas, I’ve realized we are a pretty agile bunch. There are multiple projects in flight at any given time: hanging christmas lights, picking a tree, wrapping presents, cooking, to name just a few. Things are handed off from person to person with very little regard for role or authority. There is a definition of done – and a very real deadline! There’s plenty of pressure (especially at the mall). Everyone is committed. It’s crazy. Frankly its a beautiful project to be a part of.

I don’t have any startling observations here. I’m just kind of happy to be bumbling along in my own projects with my favorite team (my family).

For those of you working on your own holiday projects, I just wanted to say Merry Christmas folks!


Push v. Pull: Part 2

December 19, 2014

boat-sail-sailboat-2447-825x550

Full of new enthusiasm courtesy of his impromptu mentor Rex, Peter was eager to try some of them out in the next race. He went home and immediately proceeded to write down some ideas for “pulling” with instead of pushing the team, like Rex had advised.

After giving it a little thought, here are a couple of the things he came up with:

  1. I will let people know what I see happening so that everyone on the boat has the same information that I do and can act accordingly.
  2. I will ask for feedback. For example: As we complete a tack, ask the jib trimmer if he feels enough pressure on the sail. Adjust my driving to help compensate.

There, he thought, that seemed like a reasonable place to start.

So when the next race came around, Peter shared his ideas with the team (well, those that came back anyway). The team was cautiously receptive. That was good enough for Peter.

So once more they went back out onto the race course. This time it went better. They managed to get a start in the middle of the fleet, and they even managed to hang on to their position all the way to the windward mark. That’s when things got complicated.

Things got crowded at the mark and Peter’s boat lost a lot of ground. They managed to to claw back some ground against the competition on the final run, but they were still in the last half of the finishers – definitely not where Peter wanted to be. On the bright side, instead of fleeing the boat when they reached the dock, the team decided to join Peter for a beer back at the clubhouse.

After having a round with the team, Peter found Rex. “So how did it go?” Rex asked.

“A little better. We did great on the first beat and managed to keep up with the pack.” Said Peter.

“I saw you were in the game. Nice job!”

“Yeah, but we blew it at the first mark.” Said a rather dejected Peter.

“What happened?”

“Well, we tried out some of the stuff that you recommended. I came up with a few ideas and shared them with the team. They seemed to work, but then things got stressful and I forgot to do the stuff I’d committed to doing. I couldn’t help it. There was just too much going on.”
Rex shook his head, “Actually I kind of expected that. It happens a lot to folks when they start pulling. Don’t sweat it, you’re off to a promising start.”

“What do you mean?”

“Well, it’s like this: you understood the idea I was trying to convey. That’s a good start, but what you need to do is to show everyone how it works. You need to set the example.”

“I still don’t get it.”

“Let’s take a concrete example: before the next race, here’s what I want you to do. Switch places with anyone on your crew. It could be the trimmers, the bowman, the pit. Anybody at all. Your job for that race? To dedicate every ounce of your passion to performing the best you can. Bring all the love you have for sailing to the role. Show everyone what that looks like.”

“But if I do that who will drive the boat?” asked Peter.

“It really doesn’t matter. It can be anybody – after all, steering isn’t that hard.”

“Wait a second, I spent a lot of money on a boat so that I could be the man at the tiller.” protested Peter.
Rex nodded his head, “Precisely, and until you learn to share that passion and that responsibility with everyone on the boat, you will never win a race.”

“What if I’m not that good at the role? Won’t people just think I suck?”

“No, in fact you will probably gain some credibility with the team if they see you failing – what matters is that you are working along side them pulling for the win.”

“I don’t know…I just want a good crew that will help me win races.” said Peter.

“A good crew is something that you build together. It has to be a joint enterprise that everyone has a stake in. I don’t know of any better technique to get there than by pulling.”

Peter put his head in his hands and groaned. This really was a lot more than he had bargained for. He just wanted to win a race! It was infuriating!

Peter looked back at Rex, “OK, man. I’ll give it some thought. I’ve really got to wrap my head around this.”

Rex winked at him and replied, “Take all the time you need.”


Push v. Pull: A Leadership Story

November 10, 2014

sailing

It hadn’t been a very good race. In fact, it wasn’t an understatement to say it had been a disaster. To Peter Smith it was embarrassing just to show his face in the clubhouse afterward. He was at a complete loss to explain how it had happened. He felt like had just managed to snatch defeat from the jaws of victory.

He’d put together a decent crew. There were no rookies on the boat. Everyone knew their jobs and some had even sailed together before on other boats. Some even had more experience sailing than Peter did. It should have been a pretty decent team.

The boat was brand new. It was the latest club racer with all the bells and whistles. It was blazing fast on the water upwind and downwind. They had all the right equipment, the right sails, and every reason to win.

That’s why their performance was all the more frustrating for Peter. They’d sucked. There was no getting around it. He felt like he’d made all the right moves and still managed to fail. He’d reviewed it backwards and forwards and still had no idea what to do. It was definitely time for a beer.

Still licking his wounds Peter took a seat at the bar. Things were hopping and the whole place was abuzz with sailors recounting the day’s action. It happened that Pete had picked a spot next to one of the club’s old timers, Rex. Pete knew him only by reputation, but he was supposed to be one of the best racers in the club.

Rex was the gregarious type and soon introduced himself to Peter and asked how his race had gone. Beer now in hand, Peter proceeded to tell the story of the day’s humiliation.

“We went out on the water early and did some practicing before the race. We needed to get used to working with each other and get the kinks straightened out. We had no problem there. A few short tacks, a few gybes and we were ready to go.

So race time comes around and we get to the start and begin working for a good spot on the starting line. You know how it is, it’s a tough fleet, so there are lots of boats and they are all pretty intense. If you leave those guys an opening, they are going to take it and you can kiss a good start goodbye.

This is where we had the first hint that there might be an issue. As the maneuvers on the start line became more intense, the crew execution started to weaken. A boat would cut us off and we would have to spin to avoid them. As we would execute the spin, one of the trimmers would make a mistake and we would get stuck, stalled out behind the line.

Of course we would recover and try again, but is was the same story all over again. I’d have to execute another rapid maneuver and the trimmers would blow it again! It was intolerable. I began to yell, because we were never going to win a race performing like this. I don’t think the yelling helped much (in fact they seemed kind of annoyed), but what else was I supposed to do? I couldn’t exactly trim the sheets for them, could I?”

Peter saw Rex frown as he described this last bit, but he was starting to get some momentum in the story, so he powered on, “Anyway, when the starting gun when off, we weren’t in a good position and ended up starting in the second rank, sucking wind behind all the good guys who had managed to get off the line with good starts.

From there, things went tolerably well on the first beat to the windward mark. We did the best that we could with a bad start, but we still ended up toward the back of the fleet as we prepared to round the windward mark. Strategically, there wasn’t much we could do until we reached the mark, and we managed to execute well, with no major screw ups.

Of course that all changed when we reached the mark. That’s where everything fell apart. As we rounded the mark, the bowman wasn’t ready and we launched the spinnaker late as I was trying to gybe set and cover the competition. Nobody was ready! We ended up with the spinnaker wrapped around the forestay and the bowman was screaming at the trimmers to ease up on the sheets. There he was on the foredeck, flailing away trying to untangle the mess, as boats went by us on either side. Jesus was he slow! I hollered at him to hurry up, but I don’t think he was listening, because nothing changed. It was costing us the race.

Finally we got the spinnaker sorted out and we got ourselves back in the race. Only now we were at the very back of the fleet. That’s right, we were dead last. As if that weren’t bad enough, when we eventually got to the leeward mark, it was an even bigger disaster!”

Peter paused for a sip of his beer and continued, “I told the crew that we had to move faster to keep in the race, but it didn’t help. They just couldn’t execute. By the time we crossed the finish line, there was complete silence on the boat. No cheers from the crew. We all felt like we never wanted to do that again. I’m completely baffled. How could this have happened? Where can I get a good crew? I need a crew that can execute, not a bunch of whiners who shout at each other when things go wrong.

Look, I can’t change that it’s a race. We’re not in this to have a good time. We’re here to win a race. Why can’t anybody understand this? I need a little positive attitude here. I need people with a will to win! Where can I get some of that? We sucked!”

There was a long moment of silence. Rex was shaking his head and chuckling quietly to himself. He paused and looked at Peter with an assessing sort of gaze and said. “That’s a helluva story. I’ve seen it before. You want my advice?”

Peter looked down and swirled the beer at the bottom of his pint thoughtfully for a moment. Then he looked up and replied, “At this point, yes. I’ll do anything.”

“Buddy, what you are doing is pushing these guys, and what you really should be doing is pulling with them. You don’t succeed by pushing a team, you succeed by pulling along with them.” He said.

Peter frowned, “What the hell are you talking about?”

Rex paused to take another sip of his beer and continued. ”It’s like this, You can push the problems on the team. You can make it all their problem. In that situation, at the best, you are simply not helping, and at the worst, you are actually creating additional problems for the team.”

“Problems? What do you mean? I don’t give problems.” objected Peter.

“Hold on, let me explain: Let’s take your race today as an example. When you were maneuvering on the start line, what did you do to your trimmers?” Rex asked.

“I didn’t do anything to them. I spun the boat about and it was their job to trim the sails properly to execute the spin.”

“And did you tell them you were going to spin, or did you just slam the tiller over and wait for them to figure it out?” Rex tilted his head as he asked this last question.

“Well…I had to spin. I didn’t have any choice. Otherwise we would have hit another boat.” Peter said rather defensively.

“OK, so you had to spin, but you didn’t tell anyone what you were going to do, right?”

“OK, alright, yeah.”

“So, here’s the question: When you do that, turning without telling anyone, are you suddenly creating a problem for the trimmers or are you helping them?”

“Well OK, it’s not helping I guess.”

“That’s right. You’re creating a challenge or impediment for the trimmers to overcome – you’re pushing the problem on them. Not only do they have to trim the sails as fast as they can, but they also have to be mind readers – guessing at when you may spontaneously change direction without telling them.

Let’s look at this another way. What could you do to help them?”

Peter looked a bit sheepish and said, “I could call out the maneuver before it happens?”

“Right, if you did that you would be helping to make their jobs easier. You would be setting them up to succeed rather than setting them up to fail. You would be contributing to the successful execution of their work.”

“Yeah, I guess.” Peter said a little petulantly. “But I’m still not really sure what you mean by this ’pushing vs. pulling’ thing.”

“OK, well let’s talk about that mark rounding you did. What do you have to do to round a mark?”

“Hundreds of things!” Peter exclaimed. “Everyone has dozens of tasks that they each have to perform in a choreographed fashion in order for a mark rounding to be successful.”

“And what did you do to help them round the mark?”

“I did the steering, their jobs are their problem.”

“So again, how could you help?”

Peter gave it some thought and then said rather tentatively. ”Call out the maneuver?”

“Yes. What else could you do to help?” Said Rex.

“Well, I suppose I could slow down the turn in order to give them more time to make their adjustments?”

“Bingo!” exclaimed Rex. “That’s more like it. You have to be thinking of what you can do for the team to make their jobs easier. You need to think beyond your own role and be constantly asking yourself: How can I help the team? What can I do to help this team work like a well oiled machine? As long as you are thinking only of your job, you aren’t really part of the team. To be part of the team, you need to be pulling along with them to help them reach the goal.”

Peter nodded his head, “OK, I think I get that, but it’s kind of abstract don’t you think?”

“No, not really. I see it out on the race course all the time. You get these hyper competitive types rushing about without thinking about the team. They rush through mark roundings thinking only of themselves and winning the race and not about the crew. The poor crews are pulling as hard as they can, but they just aren’t in synch with the helmsman. They aren’t pulling together as a team.

It’s push vs. pull.” he finished.

Peter looked down pensively and was quiet for a minute. Then he called over the barkeep and bought Rex another beer. “Thanks. I appreciate the advice. I’m going to have to give that try.”


Paired Mathematics

October 21, 2014

4404087460_9beb6332bd_b

This evening my daughter was sitting at the kitchen table, pencil in hand, confronting a full page of math homework. It was one of those dreadfull rote exercises where one has to solve variations on the same problem over and over again until either the exercises are complete or the child expires from boredom. I remember those math exercises, usually associated with the dictum to “Show your work” – meaning that every exercise would take what seemed like hours to complete. I’m breaking out in a cold sweat just thinking about it.

Nobody I know really likes these sorts of homework assignments. I guess they are a rite of passage in grade school. Seeing the dread in her eyes, I sat down and proceeded to just start talking her through it. It was all the usual stuff. I’d ask questions, and talk about different ways of solving the problem. I’d check her results and ask more questions. And I’d challenge her to do silly things (Write your numbers as tiny as you can. Smaller. smaller!). I’d stop and ask her how she did it, because Dad doesn’t know the new math (I really don’t – today they use all sorts of fun strategies that I never learned as a kid). And of course there was a high five at the end.

And then it occurred to me that we were pair programming!

Well, pair problem solving anyway. She was driving – doing the work. I was navigating, validating her work and thinking about how to tackle the next challenge. We had a dialog going on where we questioned each other. It turns out we both tend to make the same kinds of silly mistakes: like father, like daughter. I just see those mistakes better because I’m navigating, and I’m more experienced.

It seems a very similar pattern to what we do when we are pair programming. Someone is working on the problem, the other is verifying, asking questions, looking ahead. And both are very focused. It’s very intense – requiring full concentration. But, depending on who it is, it can be playful too.

That sounds like a nice way to work. Better than individually grinding away. Of course programming and math problems from grade school are very different things. But it made me wonder, is a place where we all pair a more pleasant place?


Time After Time

October 20, 2014

4e616845-2d64-4eb8-85ab-7f5dcdbab12d

Last year I led an effort to implement time tracking for our teams. A quick warning is probably in order here:

Never, ever, be the person who introduces time tracking at a company. You will be reviled before the gods and your name shall be stricken from the roles of the Agile. People will avoid you at parties, your kids will spurn you, and your pets will pee in your shoes. On the bright side, that Darth Vader helmet you have sitting in the closet will suddenly seem like a good thing to wear around the office.

So, now that we have that out of the way, back to our story. So I was leading this effort to introduce time tracking to all of the developers in our little corner of the company. The idea that had lead to this little misadventure was simple enough: if we used a time tracking tool we will get more detailed information about where time is being spent on projects than if we just make some educated guesses using excel spreadsheets (our existing mechanism). This will give us higher quality information and we will enable us to automatically handle things like capitalization easily.

That was the idea. If we ask people to report their time daily, they will give us a more accurate picture of the time that they are spending on the work. Simple enough. Our old system of excel spreadsheets made a lot of assumptions that probably weren’t true. For example:

  • Everyone works an 8 hour day
  • Everyone on a team works on a given project at the same time
  • Team membership doesn’t change during the sprint

If you use those rules then you can come up with some rough estimates for how many hours the team put into any given project on a sprint by sprint basis. You have to assume that any errors or mistakes will just be averaged out over time. That makes the time tracking very simple to do, but it makes the finance guys twitchy. They get anxious because you are making a lot of assumptions about things that we all know probably aren’t true. And they really don’t like that “It all kinda works out on average” bit either.

So we decided to go down the path of detailed time tracking. Give up all hope ye who enter here. Detailed time tracking doesn’t assume much: every hour of the day must be accounted for. However there is one hidden assumption:

  • Everyone will bother to take the time to accurately report their time for every day.

And there’s the rub. Very few people actually report their time accurately. First, you have to understand that they are ticked off that they are even asked to enter time. Second, they are very likely already entering their time in other places, like agile project management tools, HR vacation tracking tools, contractor management tools, etc. A single person might have to enter their time in 4 different systems! All you have done is add one more tool to the list and it is definitely not welcome.

So how do they use it? They either book all 8 hours of their day to the project and copy and paste every day, or they take one example day and copy and paste that. You aren’t going to get the real data, because the people using the system don’t really want to give it to you. At the end of a long day, nobody wants to have to sit down and try and figure out how much of their day was wasted in all those godawful meetings. They just don’t.

Oh, I suppose you could try policing it better – good luck with that.

You might come away from this little diatribe with the impression that I dislike time tracking. That’s not true. I realize there is a legitimate need for it in our business. However implementing it is much tougher than I realized and it’s very easy to find that the benefits really aren’t that clear at the end of it all.


Follow

Get every new post delivered to your Inbox.

Join 561 other followers