Montague.tv

I have the distinct pleasure of helping people plan and build their careers. In my current organization, one of my primary goals is to recruit and hire talented software developers to add to an already talented and energetic team. In this role, there is something that has me baffled:

“Why is there an awkwardly high percentage of developers who aspire to be managers?”

A snippet from the great Paul Graham post (and book), “Hackers and Painters”
When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work– that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge.

Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike.

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things.

If this is true, then why aren’t composers putting on a resume, “Wish to expand my career toward Composer Management”? Why aren’t painters asking for more “Painter Leadership” courses from the market?

I truly feel that comparing developers and painters is apropos. What alarms me is the rate at which organizations, especially large organizations, bastardize the career aspirations of artistic and expressive craftspeople by giving them one narrow path to advance, management. Many organizations can’t fathom a career path that doesn’t include leading others and amassing direct reports. Now, as a result, many developers can’t fathom it either. Sad.

If we think long and hard about what we are doing by encouraging this mindset, I argue we would never do it. As organizations, we typically take the best and brightest producers and “elevate” them to a non-producing position. (This is typically followed by a giant sucking sound whereby these people’s souls are ripped from their bodies.)

Don’t get me wrong. Leadership and management IS a noble career aspiration. I’m arguing it is not the ONLY noble career aspiration, and if you’re the type of person who wants to build things and be expressive and creative, then it might not be the path for you.

With all this said, as organizations we should work at giving developers an alternate career path.  One where they can be dynamic, brilliant, and celebrated artists.

If you haven’t already, do yourself a favor and go buy Tom Peters’ great book “Re-Imagine”.  In it, Tom addresses powerful opportunities for our organizations (and our culture) to tackle.  One of my favorites – Women.     

In the book, some of Tom’s examples are subtle, but paint a picture of clueless organizations (typically run by men) trying to sell to women. Some examples are, well…not so subtle.  And I’m slowly learning they’re everywhere.

Here is but ONE example of now dozens I see regularly. 

My wife and I had a pretty funny conversation about this and we agreed this tag line HAD to be generated by a man (or all male) team.

Extra Responsive in “Emotional” Moments…. (*Releasing Sweat)

Ummm….yeah.

Does anyone else out there think this is one of the most ridiculous pieces of marketing you’ve ever seen? Come on deodorant marketing slaps…you can do better!

I have helped implement Agile project methodologies in a number of organizations. If your organization is anything like mine, you will be asked to define a project life cycle such that it can be explained, coached, and documented. I used to think the first step after this request was to work with management and educate them on the empirical nature of the agile process and that every project, customer, and team is different. As such, they will most certainly need something different in each case and therefore, a heavily prescriptive project methodology isn’t necessarily that valuable. Therefore, too many pictures and defined process is a bad idea.

Like I said, I “used” to think this was the right first step. I’ve found that this is an uphill climb (I’m sure you have too) and ultimately unnecessary. If a process design is what they want, you should give them one.

Agile concepts need to be “demonstrated” (and as soon as humanly possible) to show the real value. If some pictures will help, so be it. In that vein, I’ve created a few pictures of the overall process including two concepts that are probably unique to a waterfall organization, Iteration -1 and Iteration 0. Below is one recent example. I added a few artifacts from our current project process to show how they might be blended.

Again, this picture describes a blend of agility with the organization’s common, more prescriptive project methods (ie stage gates, risk plans, PDDs, etc). Everywhere I have worked, I’ve needed to blend these things into “agile” in one way or another. This was one approach.

The crux of Iteration -1 and Iteration Zero will be described in an upcoming post. In the meantime, if you have questions, don’t hesitate to email!

An Agile Project Lifecycle (Click Image to Enlarge)

Update: A friend wrote and said, “hey, this looks like an iterative waterfall process. What gives!?” Is the above agile? waterfall? iterative? Scrumbut? Well, the point of the post was to illustrate that many organizations want to know that certain steps are being followed. The greatest value I think we can bring to organizations is to stop fighting about the presence of these artifacts and focus on what teams can deliver. Changing culture takes time. We often times dont have the ability to refuse to infuse some of the steps that organizations require…especially very large ones.

In my past, it has taken me months and months (and spent cycles) getting people “off the solution” to start “doing something”. In an attempt to get teams going, especially in organizations that don’t have agile experience, I think focusing my energy on removing impediments (like mapping the process) was a valuable start to protecting the teams. Over time, this process can change.

I do feel many organizations want stage gates (even though we hate them and know better). This visual depicts two very simple steps going from basic organization of the project team and vision / project definition, to construction (which includes all disciplines plus release if necessary), and then to the maintenance phase (warranty period). I think this depicts a basic approach that has worked well. That is indeed the point, isn’t it? The point is not to do “perfect Scrum”. The point is always, in the end, to add value.

Is it Scrum?
No.

Does it need to be Scrum?
No.

I was recently asked about the initial steps in an Agile project, building the architecturally significant pieces, planning and roadmapping, and I thought I’d post a quick “Thumbnail Sketch” of a workshop I led last year to get a large project started on the right foot.

The process below essentially walks through the process at a high level but gives enough detail to get someone started. I use terms like “Epic” “Feature”, and “User Story” but do not define them below. I also talk about “Reference Sets”, “Relative Estimation”, “Planning Poker”, and “Anchors”. Much of this work comes from Mike Cohn, Alistair Cockburn (among others) and has been adapted to meet our needs. I would be happy to discuss these areas in more detail in a later post or by email.

The outcome of this workshop yields:

1. User Stories derived from high level features or epics (titles and basic detail only)
2. A Walking Skeleton consisting of architecturally significant, and business critical features
3. A prioritized backlog of all stories currently in the project
4. A reference set of stories used to estimate from
5. Relative estimates for each of the stories in story points (or NUTs, or whatever relative unit you prefer)

The outcome of this workshop is the INPUT to your Release Plan and Roadmap.  This workshop does not describe that process.  This workshop step would happen during Iteration ZERO. I will follow this blog post with a picture and description of Iteration -1 and Iteration 0.

The pictures depicts (for us) a large conference room table with different color/size notecards used to make collaboration easier.  Visually and practically this is a great choice because it lets your team survey the table (project) as a whole, move cards around easily, add cards quickly, etc.  Please click the picture for full view (and so you can read the detail!)

Step 1: Initial Prioritization

Step 2:  Story Brainstorming

Step 3:  Walking Skeleton

Step 4: Walking Skeleton

Step 5:  Grouping & Leveling

Step 6:  Reference Set

Step 7:  Estimation

Organizations stagnate for a variety of reasons. One that I have come to recognize through the work of Dr. Russell Ackoff is a systemic, abiding fear of failure. Most leaders are gripped with this fear. If you think through our accounting structures in public and private organizations you start to understand why employees find complacency as the “safe bet” to career growth over evolution and change.

Fear Explained

To dig deeper, Dr. Ackoff describes the two key types of errors: errors of commission, and errors of omission. An error of commission is one where something is tried and later fails. Our current accounting systems are built to track these errors and they do it well. As do our internal “cultural” tracking systems through mores and norms.

Jim’s initiative was a complete disaster! What a terrible leader and failure he must be.

This is compared to an error of omission, where an organization or leader fails to do something they should have done. There is a stark contrast in the way our culture and accounting methodologies track this type of failure. In short – they DON’T. In your organization, how often are employees blamed for NOT creating change? We pay lip service to improvement, but rarely do employees have their feet held to the fire regarding too little change and missed opportunity.

We’ve Learned Our Lesson

So what’s the lesson? For employees, the lesson is that the only error that we seem to track, and can have an effect on your longevity, career and social standing are errors of commission.

You effed up Jane!  Now what do you have to say for yourself!

Yes, our organizations tend to focus on errors of commission and track failures this way. Now ask yourself this question.  What do you suppose is the most likely strategy employees utilize to protect themselves from the fear of failing when they try new things? 

You guessed it… They try NOTHING.  They play not to lose…and sadly lose the ability to be great in the process.

Maybe we don’t have exactly what we want, but as they say, no one’s ever been fired for buying IBM.

Leadership Opportunities

The key to solving the complex, sometimes mind boggling system problems we face every day is to help craft an environment that accepts failure and disdains apathy. Those creative souls trapped in your organizations and on your teams will never produce amazing results if leaders don’t free them from the crippling (and real) fear of failure and begin to demand experimentation.

This will ultimately teach us, allow us to develop, and expand our ability to solve complex and growing system challenges.  Paradoxically, failure allows us to learn how to be great. Maybe we should start looking at failure as evidence of the drive for greatness.

Occasionally I come across a piece of  “internet inspiration”  that actually speaks to me. It echoes the feelings and sentiments I have so closely that I feel compelled to print it off, cut it out, and hang it in my line of sight.  I’m gullible in this way.

I was scanning my desk this week, looking at photos of family and taking down papers, project schedules, etc…just cleaning up a bit when lo and behold, I ran across one of those articles. Once again, it moved me. It moved me enough to a) keep it up, and b) blog about it. I think it’s brilliant and I continue to believe, and try my hardest to heed, these well written words.

I obtained this from a magazine that (truthfully) I can no longer identify, but the original content is from Marshall Goldsmith.  If you recognize some of these because you “do” them, or because you “experience” them, feel free to print, cut, hang, or share.  I hope you find this smacks you in the face as completely and painfully as it did me.

The following is the article adapted from MarshallGoldsmithLibrary.com

Whats Wrong with Us?

I find that the 20 flaws that hold most people back are rarely flaws of skill, intelligence, or personality. They are challenges of interpersonal behavior, often leadership behavior:

1. Winning too much:  the need to win all all costs and in all situations – when it matters, when it doesn’t, and when its totally beside the point.
2. Adding too much value: the desire to add our 2 cents to every discussion.
3. Passing judgment: the need to rate others and impose our standards on them.
4. Making destructive comments: the needless sarcasm and cutting remarks that we think make us sound witty.
5. Starting with “No”, “But”, or “However”: The overuse of these negative qualifiers which secretly say to everyone, “I’m right, you’re wrong”.
6. Telling the world how smart you are: The need to show people we’re smarter than they think we are.
7. Speaking when angry: using emotional volatility as a management tool.
8. Negativity, or “Let me explain why that wont work”: the need to share our negative thoughts, even when we aren’t asked.
9. Withholding information: the refusal to share information to gain or maintain an advantage over others.
10. Failing to give proper recognition: the inability to praise and reward.
11. Claiming credit that we don’t deserve: The most annoying way to overestimate our contribution to any success.
12. Making excuses: The need to reposition our annoying behavior as a permanent fixture so people excuse us for it.
13. Clinging to the past: the need to deflect blame away from ourselves and onto events and people from our past; a subset of blaming everyone else.
14. Playing favorites: failing to see that we are treating someone unfairly.
15. Refusing to express regret: the inability to take responsibility for our actions, admit we’re wrong or recognize how our actions affect others.
16. Not listening: the most passive-aggressive form of disrespect.
17. Failing to express gratitude: the most basic form of bad manners.
18. Punishing the messenger: the misguided need to attack the innocent who are trying to help us.
19. Passing the buck: the need to blame everyone else but ourselves.
20. An excessive need to be “Me”: exalting our faults as virtues simply because they’re who we are.

I’m not sure about others, but in my career, there has been no debate about the use of the “command and control” leadership style. It’s just bad. More than bad, it’s completely ineffective when the intended outcome is lasting, cultural change and commitment.

Have you ever witnessed an attitude of “chest-puffed” dominance that some leaders hold when it comes to leading others.

“I don’t want to have long winded discussion on this. This is how it’s gonna be!”

“If we just force them to do it, we will get results!”.

Yes. You will get results, but I doubt the kind you intend.

Over the years, at almost every turn, I am reminded of the power of collaborative leadership…of common goals and shared purpose. And I’m also reminded how difficult it is to stay above the notion and allure of forcing teams to “just do it” (whatever “it” is). It is a shortcut, a cop out of sorts.

The short cut always seems so clear. Come up with an edict and the hard work is done. However, “cultures” simply will NOT change when commanded to do so. They will comply, but will not change. That means that real commitment to a common purpose will never be achieved. This is especially true of knowledge workers.

Cultural change requires others to reach conclusions on their own, and my ability to edict change is no substitute for the hard work of leadership. This particular anti-pattern, however unsavory, seems to capture my vision of leaders who fall victim to this shortcut when they should know better.

I wanted to provide an updated prezi we just finished outlining our experiences and tips for implementing Behavior Driven Development. We just delivered the updated version and had lots of success with it!

Comments Welcome! (especially if you have ideas for us or corrections)

I recently (2 days ago) finished my second Ironman Wisconsin. While it’s still fresh in my mind, I wanted to recap the day, but more importantly share a lesson that I keep learning (or relearning) in my life. Sometimes goals are only clear after you’ve arrived.

For those who aren’t familiar, an Ironman consists of a 2.4 mile swim, a 112 mile bike, and a 26.2 mile marathon run. All of this is done during the course of a day, starting at 7 AM and ending at midnight. Two years ago I set out in my first Ironman to hit a plan and a goal time. The goal was 13 hours and 30 minutes. During that race, I had 4 flat tires, (FOUR) due to rim tape and a poor understanding of simple bike mechanics. My plan quickly turned into FINISHING, and that’s indeed what I did.

“On the Helix, the swim start looked like a pack of piranha!” – Randy Hull

This year, the race was a bit different. The swim was much rougher as everyone (2900 people) were WAY too aggressive. It didn’t seem this bad 2 years ago. Not even close. People were kicking and punching and laying on you the whole way. The corners were the worst as everyone bunches up and that’s when the melee starts. I drank a lot of water this year (unintentionally) and my stomach got upset pretty quickly. I was happy with my swim time and finished it 2 minutes off my 2008 pace.

On to the bike…

I got blisters on my feet from torn socks. The socks were torn running from transition 1 through the bike transition. I finished an hour faster on the bike than last year and actually felt pretty good as I had no mechanical issues. Remember the four, yes FOUR flat tires in 2008?…but whose counting.

Marathon Blues…(and blisters)

Coming off the bike, my feet had bad blisters and I couldn’t feel my toes. The feeling just came back this morning, two days later. I’m thinking I might lose some toenails after this one. The run came and it was pretty brutal. Walking hurt my feet more than running, but when I ran, I couldn’t keep food or water down. The only way to finish the marathon at that point was to change my plan. I needed to hobble around the run and make sure I could take in fluids and salt tabs. So that’s what I did. It made the pain and blisters worse, but it gave me a chance to rehydrate, get my stomach right, and keep down food and fluids. It allowed me to finish.

Overall, it sounds bad but the race was pretty good. My brother caught me at mile 9 and we helped one another the final 17 miles to the finish line. We actually came in together which was pretty cool and got the exact same time, on the button. Our good friend from home (who is very fast and much better at this sport than us) pulled out after the first 13 miles on the run because he was throwing up so badly and dehydrated.

The Lesson?

In the end, this was a memorable, mentally challenging race. I didn’t reach my goal time (again), but as my Uncle Marv reminded me…in the immortal words of the most prolific and legendary philosopher of our day,

“Everyone has a plan….until they get hit.” – Iron Mike Tyson

Awkward to take life lessons from Mike Tyson, but I can’t tell you how well this quote fits my life. Many people plan goals and envision their lives well in advance of “living” their lives. As time drifts by, everyone faces challenges and struggles that are unexpected. Be it four flat tires, physical ailments, or any of hundreds of other challenges that derail our plans. The measure of success is how well you ADAPT to those challenges and reformulate your goals as they become more clear. My goal became more clear as the night wore on:

“Finish this race. Make it to the finish line and tell my wife how much I appreciated all of her hard work helping me get here. 13:30 is meaningless compared to telling her I appreciate her help and that all the date nights missed, mornings getting up at 4:30 AM, and weekends I spent on my bike or in the pool or on the trail were worth her effort.”

As I reflect, that was the real goal. Sometimes goals are only clear after you’ve arrived. And this one is completely obvious to me.

Thanks Dee.

PM:  You want estimates?
Mgr:  I think I’m entitled to them.

PM:  You want estimates?
Mgr:  I want the truth!

PM:  You can’t handle the truth!!

Son, we live in a world of computer applications and those applications have to be built by people who write user stories. Who’s gonna do it? You? I have more responsibility than you could possibly fathom. You have that luxury. You have the luxury of not knowing what I know. That Version 1’s existence, while inexplicable to developers, helps project teams build applications. And that my profession, while incomprehensible and grotesque to you, also helps build applications. We use words like user story, range based estimates, and done criteria. We use these as the backbone of a life spent building and defining something; you use them as a punchline. I have neither the time nor the inclination to explain myself to a person who develops and tests off the well written stories we provide, and then questions the matter in which we provide it. I prefer you said “thank you,” and went on your way. Otherwise I suggest you log into Version 1 and update your story estimates; either way, I don’t give a damn what you think you are entitled to.

Mgr:  Did you under-estimate that story?
PM:  I did what I had to.

Mgr:  Did you under-estimate that story!?
PM:  You’re God damn right I did!

(Via Andy Sargent, Project Manager)