People Spaces Reading List

Tomorrow afternoon I will be giving a talk on creating productive, team-based workspaces at the SWOC PMI Symposium 2012.  Below is a list of the reading materials that I think reflect the principles of what I will talk about.  This is by no means an exhaustive reading list but it goes provide a flavour and supports some of the claims that I make in my talk.

• A. Cockburn, "Characterizing People as Non-Linear, First Order Components in Software Development", 1999
• A. Cockburn, "Agile Software Development: The Cooperative Game, 2nd Edition", 2006.
• M. Cohn, "The Ideal Agile Workspace", 2009
• D. Hartman, "Designing Collaborative Spaces for Productivity", 2007
• J. D. Meier, "Microsoft patterns & practices Agile Workspace Tour", 2009
• J. Pierce, "Great Agile Workspaces: The Physical Environment", 2011
• J. Pierce, "Great Agile Workspaces: How We Communicate", 2011
• J. Sutherland, G. Schoonheim, N. Kumar, V. Pandey, and S. Vishal, "Fully Distributed Scrum: Linear Scalability of Production between San Francisco and India", 2009
• S. Teasley, L. Covi, M. S. Krishnan, and J. S. Olson, "How Does Radical Collocation Help a Team Succeed?", 2000
• A. Williams Woolley, C. F. Chabris, A. Pentland, N. Hashmi, and T. W. Malone, "Evidence for a Collective Intelligence Factor in the Performance of Human Groups", 2010

Agile Reading List

Tonight I will be giving a talk to our local PMI chapter about what it takes to succeed in Agile.  This gave me an opportunity to gather and hone some of my thoughts regarding what I've been referring to as "Whole Agile".  Below is a list of reading materials that I think together reflect all of the aspects (and not just practices) of what it takes to succeed at Agile.  This is by no means an exhaustive list of books on Agile Methodology that I recommend but rather it is mean to cover all aspects of Whole Agile.

• Augustine, Sanjiv and Cuellar, Roland.  "The Lean-Agile PMO", Cutter Consortium Executive Report, Vol. 7, No. 10, 2006.
• Cockburn, Alistair.  Agile Software Development: The Cooperative Game, Addison-Wesley Professional, 2006.
• Cohn, Mike.  Agile Estimating and Planning, Prentice Hall, 2005.
• Highsmith, Jim.  Agile Project Management: Creating Innovative Products, Addison-Wesley Professional, 2009.
• Martin, Angela, Noble, James and Biddle, Robert.  "Programmers are from Mars, Customers are from Venus: A practical guide for customers on XP Projects", 2006.
• Poppendieck, Mary and Poppendieck, Tom.  Lean Software Development: An Agile Toolkit, Addison-Wesley Professional, 2003
• Rooney, Dave.  "An Organizational Structure for Agile Projects", Cutter Consortium Executive Report, Vol. 8, No. 5, 2007.

Agile Software Development - Why?

I recently guest-published an article on the blog hosted by Big Blue Bubble, the award developer of handheld video games.  If you're interested in learning about why Agile software development is valuable and what benefits you might derive from it, head over to Big Blue Bubble's Out of the Blue.

The moment it becomes an IT project...

...you're dead in the water.  Steve Laster, Harvard Business School's CIO, put forward this aphorism at Campus Technology 2010 while describing a major project to investigate, design and implement an online collaboration environment at the Harvard Business School.  The statement resonated with me and speaks to the maturity of the IT culture at HBS. 

Many IT organizations (and I'm not limiting myself to the education sector) would have eagerly jumped into the project.  A short time later, the latest and coolest Web 2.0, social media integrated toolset would have been installed.  And henceforth ignored.  I attended another session at CT 2010 where the IT director described the new ePortfolio system they (i.e. IT) had researched and implemented.  It had all kinds of great features that students and faculty could use.  After the first semester exactly 0 (zero) students and faculty had signed up.  The IT director chalked it up to a lesson learned regarding communication.  Certainly communication and change management would have helped but I'd bet their results would not have been significantly better if all they changed was communication.

HBS approached the challenge of online collaboration quite differently.  Right from inception, they treated the notion as a business question rather than an IT problem.  Instead of jumping right in to a juicy "IT project" or allowing the school to "just let IT solve this problem" Laster pulled together a small group of key stakeholders from different departments of the business (yes, I say "business" rather than "school" although it grates on some faculty).  While the HBS Collaboration group included an IT representative it was comprised of and even lead by representatives of other business units.  It was that team's conclusion that an online collaboration tool was indeed needed.  Furthermore, they worked together to develop requirements and explore options. 

This approach had a number of immediate benefits.  The technology choice had immediate buy-in due to the inclusive method of its selection.  The business units had at least one, and often more than one, knowledgeable member on their team which helped in communication, change management, and rapid adoption.  These knowledgeable members were trained as expert trainers which distributed education and support responsibilities.  The team of experts continued to meet during and after implementation.

Would it surprise anyone that HBS is a Scrum shop?  Those with a background in agile software development methodologies no doubt see the HBS arrangement as perfectly normal.  The cross-functional working group was, in essence, a product owner / customer proxy.  Wouldn't it be great of more IT organizations thought of their projects and potential projects as being owned by the business rather than by IT? 

From Campus Technology 2010

Today is Day 2 of my Campus Technology 2010 tour.  While yesterday's speakers and activities had my aching to run away from the conference never to return (Janet had better luck than I did) today's speakers more than made up for the deficit.  Yesterday brought me no insight nor inspired any new ideas.  Today, however, my horizons were expanded and many of my assumptions were challenged.  Perfect!

The Keynote

The day kicked off with an excellent Key Note by the Stephen Laster, CIO of the Harvard Business School.  Stephen is a great speaker and his topic was near and dear to my heart -- factors (8, in this case) that contribute to the success of an IT organization.

1. Hire and mentor a great team (people first!)
2. Run the shop as a business (a key consideration for an internal IT organization)
3. Leverage planning and governance
4. Take smart risks
5. Actively measure
6. Capture the customer (not literally!)
7. Communicate, communicate, communicate (and make it someone's responsibility in IT)
8. Leverage trusted advisors

He didn't come out and say it in his keynote but in a talk later in the day I got the impression he had a 9th factor which would go something like "Start small and iterate quickly".  It's nice to see successful organizations subscribing to the same principles as your own.  They're just a little further down the path than we are at Ivey and I hope to stand on the shoulders of HBS in order to accelerate ourselves. You can get a sense for the keynote from this interview Campus Technology did back in April.   

Conference Themes

I must admit that the themes I spotted at the conference were different than what I expected.  I expected a major theme to be cloud computing but it was barely even mentioned.  Other themes that received little or no attention: classroom A/V, eReaders, IT infrastructure, IT methodologies (ok, I'm not surprised about this one).  Below are the major themes that I picked out.

Distance Learning

This one comes as no surprise as higher ed institutions try to either bring in new revenue or reduce costs of delivering courses.  The industry has been working on this for some time and it looks like it'll be some time still before we can deliver a good student experience to remote learners.

Post-LMS World

The LMS (or Learning Management System) is considered a table stake technology for any educational institution.  Ivey has a homegrown LMS.  UWO uses WebCT (now Blackboard).  Moodle and Sakai are viable open source options as are others.  At the conference there seemed to be an underlying theme that the LMS as we know it today (calendars, events, forums) are outdated concepts and not in step with how students of today communicate.  There was an emphasis on leveraging modern collaboration and social networking tools.  A move away from "management" towards "personal collaboration".

ePortfolios

There seemed to be an explosion of ePortfolio vendors at the conference.  I must admit that I wasn't familiar with the term prior to the conference but now feel sufficiently schooled to at least describe what it means.  An ePortfolio is an personalized, online aggregation of a student's achievements in not only academics but also in other activities such as volunteerism, sport, clubs, etc.  Think of it as a mash up between LinkedIn, Google Profile, Facebook, and Dropbox.

Mobility

The community seemed to collectively recognize that students entering higher education did more communication via handheld devices (like iPhones, Androids, and even Blackberrys) than they did on laptops and computers.  A few schools were experimenting with mobile offerings but most were not even that far.

Academic Content Support

I was surprised to learn that many schools offer Academic Content Support via their IT organizations.  This type of support involves aiding faculty in the creation and maintenance of the content they use for teaching.  This might mean developing interactive web content to use in class.  It might mean adapting a lecture for display on an interactive whiteboard.  It might mean developing a mobile application.  It might mean aiding in the selection of a simulation vendor.  It might mean recording and/or editing video for use in a class.

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?