The Evils of Management

This post continues on the theme I started in the "Agile - An Elite Game Only?" post.   This installment covers the claim that Agile "fails to address the evils of management". 

Hear ye, hear ye.  Let it now be known that I am one of those pointy-haired bastards.  The Man.  High Priced Overhead.  The Management.  My current position is CTO at the Richard Ivey School of Business.  I've previously held positions at other companies in VP Engineering, Director Engineering, Manager, Team Leader roles.  In ancient times (more than a decade ago) I was a software developer.  I've led and managed teams over those years using both traditional planned methods and agile methods.  In my past I have been known to quote IEEE and ISO as well as, more recently, Sutherland and Beck.

I hate to deflate your balloon right off the bat but the expectation that any software development methodology will "address the evils of management" is flawed.  If we assume for the sake of argument that the use of "evil" here is a colourful metaphor meaning "incompetence" rather than actual malice it is difficult to see how any methodology would solve the problem.  Methodologies might somehow stunt the impact of incompetent management but that doesn't really address the problem.

I'll steal a page from my buddy AgileMan and define "incompetence" in a very broad sense to mean "unable, for whatever reason, to perform the necessary duties of the position."  This could be due to laziness or bad attitude or fear but it could also be due to lack of job knowledge, insufficient data, overwork, competing goals, or other factors. 

Companies need to realize that leading agile teams requires different time and attention from them.  It requires more direct interaction, more trust and empowerment, more vision and leadership.  So where do leaders find time for these new responsibilities?  Thankfully if you have a good teams and healthy culture, Agile requires less Management, less reporting, less approving.

What Have I Learned?

As a manager and leader coming who has worked in both preplanned and agile environments I have learned a few things.  While the following lessons might not apply to every situation they are more or less all true for all the situations I've been involved with so far.

Software Development Team Leaders Need To Be Technical

I'll start off with a controversial one.  I don't care what you call them... scrum masters, coaches, team leaders, development managers, etc. but the leader of a development team needs to be technical.  I'm not saying the leader needs to code every day but she should be capable of and have experience in doing so.  The leader needs to know that their primary responsibility is leadership and empowerment and her goals and objectives need to reflect that emphasis.  Part of those goals should include ways of staying current on both the leadership and technology sides of the role.

Agile Can Make You A Better Leader -- If You Let It

Leaders and managers who see the opportunity for personal growth and for team growth can leap ahead in their careers by leveraging agile principles.  Every modern business leadership book talks about empowering employees to make decisions, getting "out of the way", growing your team to achieve greatness.  Agile did not not define this game, agile is just one of the newer contestants.  A good leader will leverage the expectations around team performance that come with agile and do everything they can to empower their team.  Empower the team with knowledge, with responsibility, and with trust.  Frightened, insecure, or incompetent (in the broad sense) leaders will feel compelled to control, define, over-measure.  These actions end up stifling the real behaviours that will make the team (and the leader) successful.

Teams Must Understand That Managers Have Responsibilities Too

Too often I hear team members complaining that their manager just needs to trust them.  If only the manager wasn't meddling so much we could get more done.  If only the manager wasn't asking for us to work on "useless" things we could get more valuable work completed.  I'm here to say that Trust needs to go both ways.  Teams need to trust that a manager is asking for certain things for a good reason and not just on a whim or because that's what the process tells them to ask for.  Sometimes development teams are part of a much larger organization that, for reasons outside the control of the development group, finds value in artifacts that in the team's limited view seem worthless.  Trust that a good leader will ask teams for non-product deliverables only if there is a good reason.  Naturally teams have the right to ask questions about the deliverable including its perceived value.  In the end, the leader should be trusted to make good decisions.  That's her job after all.

Bad Management Repels Good People

Finally, it should be obvious that consistent bad management will cause good people to leave.  If you feel that your talents are going unrecognized or that "the management" continually screws things up and cannot provide good explanations for the decisions they make then vote with your feet.  Even in smaller communities like where I live there are opportunities out there for those who are motivated, energetic, and talented. Life is too short to be miserable in your job. 

Coming Up "Soon" - Software Professionals

Agile: Average Developers Need Not Apply?

This post continues on the theme I started in the "Agile - An Elite Game Only?" post.  This installment discusses the notion (or myth, in my opinion) that agile methods are meant only for the elite or superstars of software development and that the gains promised by Agile are not attainable by the merely average.

Agile teams are expected to learn and experiment and teach and grow.  All the time.  The argument goes that developers of average skill just can't keep up with that and therefore agile is not for them.  Further goes the argument that Agile should only be applied to small teams of superstars and more structured processes should be used to keep the developers of average skill "on track" (or, less kindly, "in line").  I've also had some developers express to me concern about "fading into the background" of a team if they are not allowed to continue as single contributors (although it's almost never a superstar who expresses this concern to me). 

Over the past 8 months I've been working with a small team of 6 software developers.  I don't think there is a single person on the team who would describe themselves as a superstar.  Rather each of them are "just" solid performers who want to do a good job and make a living.  I'm also working with a team 4 of business analysts who possess varying depths of knowledge in the various products that are needed.  This team of developers and BAs has done some amazing work over the past 8 months while transitioning to agile methods.  By just applying the following core principles they have enjoyed higher productivity and, from the feedback I get, much higher job satisfaction all while working on much the same software they had been working on 8 months prior. 

• Direct and active developer contribution to planning including requirements breakdown, estimation, risk identification
• Competent business analysts who value the skills and knowledge of the development team
• Daily and continuous collaboration between and among developers and business analysts
• A development manager who trusts the team and inspires a culture of learning
• Automated unit tests (although this has only been added in the past 4 months)

This team is readying themselves to move to the "next level" by adding in better automated builds, better source control, and better automated testing.  They have developed an energy for learning and a spirit of collaboration that has elevated everyone's game.  In other words, their attitude is influencing their behaviour which are both having a major positive impact on their aptitude.  Superstars?  We'll call one if we need one.


So What About Those Superstars?

Still, there's no question in my mind that superstars are fantastic assets.  They develop at 10x (or more!) the speed of other developers, produce top quality, and generate new ideas all the time.  They live and breathe their profession.  They are also, unfortunately, rather rare.  I've worked with maybe a half dozen directly (i.e. in my organization) and maybe a dozen indirectly (in partner organizations) over my entire career. 

Whenever anyone suggests that we keep the superstars separated from the rest of the team so that they can "do their thing" I just shake my head.  Why would any company want to keep all that goodness locked up away from everyone else?  My experience has been that superstars bring up the game of the team they are on.  They become teachers, role-models, inspirational leaders.  The effect is multiplicative!  Good developers become great developers when they are on teams that have a superstar.  Only once have I found a superstar (in the productivity sense) that truly needed to remain an island.  All other cases have resulted in higher performing teams without eroding the output or visibility or "aura" of the superstar.

In summary, teams, whether they have a coding wunderkind on the team or not, have always benefited from agile methods in my experience.  What's important is that the team developers their own passion for quality and growth.  Leaders can influence and inspire this attitude but it cannot be mandated.  So choose your leaders carefully!


Coming Up - The Evils of Management

Agile - An Elite Game Only?

I thought the following comment to my last post (Manifesto of Second Best Alternatives) was important enough to inspire a new post rather than a comment.  Anonymous writes:

"Sure, Agile approaches an answer to many of the noted problems all too common in the software development world, and maybe in another decade we might improve upon it some more. But amongst the positives, it occurs to me that Agile robs us of specialization, making all developers fit a ridiculous mold that only a handful can actually aspire to fit, hence the consensus that there is some need for "less than agile" methods. It's great to be able to learn new things and do so at light speed, but that is not every developer trying to make a living. So all you do is reflect back your own smugness when you talk about these so-called "incompetent individuals." Beware that label: One day you, too, will reach age 50 and the youth getting by on 1/3 of your pay will undercut you because they are 80% as good as you.

Another observation I have about Agile gets right to the heart of why nothing attempted by the Agile community matters, and that is: Agile fails to address the evils of management. It doesn't matter how well you estimate something, management will always demand twice as much no matter how much realistic evidence you present to them. Management sees Agile only through the lens of "how can I make these assholes produce more and whip themselves in the process?" And so we have reopened the doors to the sweatshop. Information Sharecropper has a real nice ring to it, though, right?

You want a fix? How about making software development a profession equal in status to doctors and lawyers. That will solve 99% of the problems. Doctors don't let non-doctors manage them, it simply is unacceptable.

What I'm looking for is that holistic manifesto--the one that gets the job done, gets me paid, and doesn't leave me feeling completely played the way I have been for over decade now. Anything else is just blather. Smart people in America are just easy marks."

This is a great comment because it raises some very important themes.  I was going to touch on them all in this post but I'm afraid that would result in a huge post that few would have time to read.  So what I'll do today is list the themes and start a discussion on one.  Over the course of the next few days I'll post some thoughts on the remaining themes. 

First some background, over the past dozen years I've held a number of software management positions from team lead to CTO.  Prior to those years I was writing software primarily in C++ and Java for client and server solutions.  I've directly led small teams and also led organizations up to 100 software professionals.  I've managed using both traditional, planned methods as well as agile methods.  

Here are the important themes that this terrific comment touches on.

1. Specialization vs generalization
2. Agile for the elite superstars
3. Evils of Management
4. Respect for the software profession

Specialization vs Generalization

Agile teams work very closely with each other on a daily basis.  Team members collaborate on problems and solutions all the time.  They communicate with each other at least once daily but typically much more.  Team members are expected to pick up tasks even when not directly in their field of expertise

So does agile necessarily rob us from the benefits of specialization?  I think this is less of an agile issue than it is a team issue.  Do you value the speed that comes from deep specialization (at the risk of damaging your company should a specialist leave) or the flexibility of generalization (at the risk of team members being jacks-of-all-trades-and-masters-of-none)?  In my experience, the benefits of specialization, even on agile teams, are too great to move to total generalization.  That said, agile teams do not necessarily mean a push to generalization.  Software developers are not automatons.  If an agile team is truly doing their own planning (and not under the thumb of a heavy-handed manager) they will naturally leverage the skills and experience that are on the team.  The following quotes are representative of the meme I'm expressing here and all commonplace on the teams I've been involved with.

"Jim, you know databases better than any of us, can you take on this schema deliverable?"

"I'll do the UAT for this requirement.  I'll fit right in to the framework Janet and I wrote a couple iterations back."

"I'll take on the server task.  Nathan, can I get some of your time this iteration since you know the server so well?"

An additional benefit of an agile team arrangement is that the daily interactions developers have result in some specialized knowledge getting absorbed into more team members.  This reduces the company risk of maintaining specialization pillars.  Teams naturally drive towards becoming (and by now you've probably been wondering when I would bring up this term) generalizing specialists.  There's enough written about generalizing specialists that I'll just leave you a Google link. 

Coming up tomorrow - Agile: Average Developers Need Not Apply?

Manifesto of Second Best Alternatives

The Yahoo! XP mailing list recently had a discussion about whether or not Agile was attainable by any team or whether it was really only for 1337 developers.  There was a suggestion on the list that some in the community should collaborate on a second manifesto (or, as Bill Caputo put it with tongue in cheek, a "less-than-agile manifesto") designed for those developers of "average skill" or who are part of lower-cost, commodity labor markets (i.e. off-shore).  Ron Jeffries, co-creator of XP, responded with the following "viciously sarcastic" draft which I found very entertaining. I should make it clear that Ron's angle here was humour and not attack.

A MANIFESTO OF SECOND BEST ALTERNATIVES

We intentionally hire incompetent individuals who will not stay
with us long, and organize across geography so that their
interactions are few and hampered. We try to compensate for these
irreparable errors by using Draconian processes and expensive
tools.

Our developers cannot really build software on their own, because
we hire them that way to save money. They do not stay with us long
enough to justify training them. We try to compensate for their
almost complete inability to perform, using large documents
describing, mostly in a language our workers understand only
imperfectly, how to use our massive tools and how to follow our
rigid process.

We position our incompetent developers as far as possible from the
people who know what we need. We cannot get together with them
often, because travel is expensive and no one wants to go there
anyway. Since we cannot collaborate effectively, we try to
compensate by writing strict definitions of what we need for our
incompetent developers to follow. We fail to notice that if we
knew that accurately what we want, we could just write it down in
Java and be done. In any case, our incompetent developers may not
be able to follow these strict contracts, and we will have a good
case for recovery of damages.

In the absence of competence, and with collaboration being
essentially impossible as well as undesirable, we will not be able
to accommodate many changes, despite the many mistakes that will
inevitably be made in planning and communication. Nonetheless, we
will insist on rigorously following our plans in every detail.

By doing all four of these things, each of which is at best half
as good as doing the right thing, we will guarantee that we will
be at least one-sixteenth (one-half to the fourth power) as
effective as we would be if we actually followed the Agile
Manifesto.

But this way we get a manifesto of our very own.

What's on your Pod?

I recently acquired a new Apple iPad as part of an experiment we're running at work.  In addition to my iPhone, I now have a couple of connected devices that are meant to make my life better.  I've been taking a look at the dizzying number of applications available for both devices and it got me wondering what applications do the folks I know have on their devices.

In addition to the built in applications for email, browsing, contacts, calendars, photos, and tunes here's how my devices are kitted out.

On Both

I think it's pretty well known that iPads can run iPhone applications.  Some applications are written to be resolution independent and look stunning on either device (yay!).  Others are meant strictly for the lower resolution of an iPhone (or iPod Touch).  They are functional on an iPad but look pretty bad when pixel doubled (anyone working at my old company can attest to the poor visual results of pixel doubling).

• Evernote (Free) - essential for anyone like me who needs their brain backed up and/or extended.  Evernote syncs your notes seamlessly between all your devices and computers.
• OmniFocus ($24.99) - the best Getting Things Done (google "David Allen GTD") application I've come across.  Synchronizes your todo information across all devices and computers.  No iPad version yet though (pixel doubling -- puke).
• Tweetdeck (Free) - by no means am I a media socialite but Tweetdeck does a great job at presenting your Twitter, Facebook, LinkedIn, foursquare (and other) feeds in one UI
• Dropbox (Free) - the more computers and connected devices we get the more important it is to have access to your important files no matter where you are in the meatsphere.  Dropbox seamlessly synchronizes your files across all computers and provides access to your files on mobile devices.  Comes with 3G storage for free.  (Oh Apple, why the $99 charge for MobileMe?)
• Net Portal ($1.99) - I don't really know why I bought this app.  It lets you access the files on your computers from your iPhone or iPad.  But if my important files are in DropBox why do I need to get at my computer you ask?  Good question.  Don't buy this app.
• Remote (Free) - Apple's remote control allows you to control your iTunes library or Apple TV
• Skype (Free) - 'nough said
• Flixter (Free) - Movie reviews no matter where you are
• Urbanspoon (Free) - Restaurant reviews and recommendations no matter where you are
• IM+ Lite (Free) - Nice multi-IM client with support for MSN, AIM, GTalk, Yahoo, and others.  Supported by ads unless you purchased the paid version.
• Mocha VNC Lite (Free) - Control your computers from your iPad or phone (although the phone resolution is a bit tiny for this to be practical).

On iPad

• iBooks (Free) - Apple's book reader.  Fantastic.
• Noterize ($2.99) - Note taking ala the built in Notes application but with many more features including the ability to do freehand annotations, and load PDF and PPT files.
• Marvel (Free) - Marvel's comic book reader.  Does a great job at providing the comic book experience in electronic form (don't tell kimota94 though). 
• Adobe Ideas (Free) - freehand sketch tool from Adobe.  Works better with a stylus such as the Pogo Sketch. 

On iPhone

My iPhone apps tend to be applications take either deal with photography (the iPad doesn't yet have a camera) or that leverage the high mobility of a phone over the iPad.  

• PS Mobile (Free) - Adobe Photoshop Mobile.  Simple photo touch ups right on your phone.
• FX Photo Studio ($0.99) - Photo effects on your phone.
• Stanza (Free) - A free ebook reader.  Before the iPad and iBooks I read books on my phone using Stanza.
• Momentile ($4.99) - Momentile is a social media site that, as far as I can tell, really hasn't taken off but I like it.  The idea is that you take a photo every day (or as near to every day as you can) and upload it to your Momentile site as a kind of photo diary.  The iPhone client lets you upload from your phone (which is really essential given that you are trying to capture an image every single day and in unpredictable situations).
• foursquare (Free) - Ok, so I foursquare.  Shut up.

So iPhone, iTouch, and iPad compadres... what's on your pod?