Book Review: The Five Dysfunctions of a Team

In The Five Dysfunctions of a Team: A Leadership Fable, written by Patrick Lencioni, he discusses--well, five dysfunctions of a team.

Lencioni's style with his books seem to be a sort of fable-story-type narrative in the first part, and then real meat in the latter part.  I have to confess I skipped about half of the fable stuff, but found the meat at the back to be very interesting.

The five dysfunctions he examines are:

  1. Absence of Trust

  2. Fear of Conflict

  3. Lack of Commitment

  4. Avoidance of Accountability

  5. Inattention to Results

Being a single guy, I could most readily identify with #3, Lack of Commitment.  And the more I think about it, all of these dysfunctions could be more-or-lesss applied to dating.

His book comes complete with a team-assessment worksheet, and directions on how to identify and overcome these five dysfunctions.  A good read for any manager.

Mike J Berry

Book Review: The Tipping Point

The Tipping Point: How Little Things Can Make a Big Difference, by Malcolm Gladwell, is an insightful book that discusses factors that cause market surge.
Gladwell points out the two phenomenons that seem to primarily be market catalyst factors:

  1. One high-profile, highly-connected individual's public endorsement
  2. A critical-mass buildup of interest

Gladwell suggests people like Oprah Winfrey can have great power in markets, and sites her single negative market-shaking comment about the U.S. beef industry back in the 80's as an example of such dynamics.

I found the Tipping Point to be an inspiring read and highly recommend it, especially to the marketing types.

Mike J Berry

Book Review: Blink

Blink: The Power of Thinking Without Thinking, by Malcolm Gladwell, is an inspiring book that encourages us to "trust" ourselves and our intuition.
Gladwell talks about several interesting documented situations where seemingly factual information purported to suggest one reality, but an intervening expert just "knew" something wasn't right and--with further research--was able to bring the real facts to light.

I enjoyed reading this book and it reminded me of all of the amazing women around me that seem have this gift, inherently. Now that I think about it, Gladwell was probably writing this book just for men.

Mike J Berry

Book Review: Value Innovation Portfolio Management

I Just finished reading Value Innovation Portfolio Management: Achieving Double-digit Growth Through Customer Value, by Sheila Mello, Wayne Mackey, Ronald Lasser, and Richard Tait.

This book discusses implementing corporate project portfolio management by focusing on insight gained from your customers as to what they value.  I like this because I agree with their premise.  They call it the VIP approach to Portfolio Management.

This group of authors is a consultancy which has developed a methodology for gathering customer insight and applying it to their clients organizations strategy plans.
One novel offering that suggest is that while most of the industry is using bubble-charts to express strategy dynamics, they suggest using a radar-chart instead because it compares more than three axis.

The book goes on to discuss various portfolio "models" for understanding customer value in product development including Grounded, Relevant, Intentional, Optimized, Measured, Supported, Actionable, Fortified, Dynamic, and  Sustainable models.
I enjoyed reading the book and found the most valuable part of it to be their model of gaining customer insight.
Mike J

Agile Development and Government Contracts

So I attended our SLC-based agile development forum yesterday.  Alistair Cockburn was there, along with some other associates from around the valley. We discussed various successes and challenges with using the Agile Development Model for software development. 

One particular topic that became a main discussion point was how to get government agencies to accept Agile Development Model contract bids. Fortunately, executives from several companies were represented in the room that use the Agile Development Model and pursue government contract work.  They gave us some insight on how to proceed. The challenge is that the Waterfall Development Model (SDLC) is the traditional project development process for government contract submissions.  They like it because it expresses a project in terms of scope, components, time-lines, and milestone dates.  All of this is measurable, so it works very well with the government procurement types.

Agile is a less structured methodology--where you build requirements and code more in a module, by module format.  These modules, called user-stories, aren't spec'd in detail until they are actually being worked on.  Because of this, milestones and time-lines for an Agile project are not as predictable.  The Agile Development Model accepts this reality, and suggests that most projects are not really so predictable anyway.

The trick with the Government is to bid your first project as a waterfall project.  Then, after you have a relationship, suggest that forthcoming projects have an Agile model. You can also submit a Waterfall project with some additional requirements listed on the contract.  ie: "Requirements base-lined at a high-level" or "Progress reported via Project Backlog" or "Prioritization by Need" or "Daily Scrum" or all of these things.

Mike J Berry

To Gantt or not to Gantt? That is the question!

A curious experience is looking on Microsoft's Project Template website for 'Software Development Project Plan Templates.' 

With Microsoft being a software development company and Project being what it is, you would think there would be many software development templates--some for Waterfall, some for SCRUM, some for XP, some for Crystal, etc. I found only two.  Both were quite rudimentary.  Interestingly enough, though, there are tons of cookie recipes, scrapbook planning templates, and other fun, useful project plans.  I was tempted to add a new subcategory for weekend jeep projects. This sort of begs the question about how many of us are really using Gantt Charts in our software development processes.  I've asked my peers about it and seem to get an overall answer that it takes as much time to update the gantt chart is it does to complete the project.  Hmmm.

We used gantt charts for a while at one of my client sites, in an attempt to display project status.  Although I think the executive staff felt catered to, I got a sort of 'deer in the headlights' effect from them. An interesting side affect was that the development team discovered we could use the gantt chart, projected on the wall in all it's glorious complexity, to underscore how busy our workload was and to negotiate for more time.  (This seemed to momentarily put us in the strongest negotiating position.)

Still searching for a better project status communication medium, I came across a wonderful process called Earned Value Management.  This is a process that developed in the government contractor circles, that displays--all-at-once--the project projected baseline for cost and progress, the actual cost, and the actual progress.  It's a wonderful tool, and after you understand it, you would think why would we do this any other way? Other tools exist, including Agile Burndown (or Burnup) charts--and they are helpful.  They show workload vs. schedule--two of the three series of information.  But Earned Value Charting seems to be the final endpoint for communicating succinctly the progress of your project.

Oh, btw, Microsoft Project will produce an Earned Value Chart for you.  You just need an advanced degree and probably another staff member to keep track of all the numbers it requires.  I wonder if anyone has ever tracked earned value progress on cookies baking in the oven?

Mike J Berry

Why you should stop using SQL Server 2000+ (even though it's a superior product!)

SQL Server 2005 is fantastic.  SQL Server 2000 was wonderful.  SQL Server 7 was OK.  I hear SQL Server 2008 will be even better...

...but wait a minute??  Really, SQL Server 2000 does everything I need.  So does Oracle versions 6, 7, 8, 9, and 10!  So does PostgreSQL, so does MySQL.  So what gives? Don't get me wrong.  I've grown up in the Microsoft garden.  I still have a VB for DOS development kit, and I have used VB 3, 4, 5, 6, and .NET 2003 and 2005.  These are superb and superior products.  The madness is accumulating with a new release every 2 years.  Microsoft is now forced to offer a downgrade from Vista to XP option because folks are getting fed up.

One client of mine is busy upgrading their flagship product from SQL Server 2000 to SQL Server 2005.  Why?  Not because of any new features.  Not because of a better price.  Not because of really any reason at all, except for the fact their customers are asking for it by name. Because SQL Server (and Oracle) are highly visible in the public's radar, many trade journals speak volumes of marketing info about the new bells and whistles they contain.  As developers, however, we all know that perhaps the management UI is better, and 64-bit it great, but basically the engine worked fine and met all of our needs several versions earlier. So my client is spending $500,000 and seven or eight months upgrading their core product--and all of the internal support tools that must work with it--to SQL 2005.  Again why?  To 'add value to the customer experience'...meaning that the salesperson can say "yes, it works with SQL 2005."

You see, in the real world, often non-technical or semi-technical people make the final purchasing decisions for enterprise software.   They grasp for 'clues' of what should separate an inferior product from a superior product, and--well--version 2005 should be better than 2000, right?  Therefore, a product based on 2005 is better than a product based on 2000!  Right?  In reality, somebody must pay for the $500,000 so that same customer is misleading themselves into requesting a higher price-point.

A better model would be to choose a database that is solid, but not in the customer's radar.  This way, they would have no 'journal information' about the database and would not be pressuring you to spend $500,000 every other year to keep up with Microsoft. PostgreSQL, MySQL, Interbase, etc. are all robust databases with 64-bit support now.  If your software is for an internal client (your own company), this whole dynamic shouldn't affect you, but if you make a commercial client-server product, there's no doubt you've experienced this already.

Mike J Berry

Meetings? We Don't Need No Stinkin' Meetings!

There seems to be no set standard for development meetings. Some groups complain about being 'meeting'd to death,' while others complain about a lack of communication, direction, or group cohesion. 

Given the two options, it is generally agreed that over-communication is much better than under-communication. One of the more innovative approaches to cutting down on meeting drain is the concept of the 'stand up meeting.'  This is where all participants (except maybe senior citizens) stand for the duration of the meeting.  Amazingly, during this process, nobody seems to have long weekend stories to tell the group, and answers and discussion points become more concise.

Normal development meetings ought to serve the following purposes.

  1. Communicate transparency from development to corporate.
  2. Communicate direction and prioritization from corporate to development.
  3. Communicate present-status and next-step planning regarding a project.
  4. Promote team-workload communication among team-members.
  5. Six month employee review.
  6. Deployment rehearsal.

More on these later...

Mike J Berry

Improving Accountability Within Your Development Department

Many Software Development Managers find their way into the "coveted" position from attrition after being a development team lead, or senior architect. Having a technical background is an obvious advantage in terms of understanding the complexity dynamics the team deals with. One big reality, however, is that these vast technical skills are only a subset of what is required to become a great manager, and the new manager soon discovers he needs to learn much more about the role.

In Jack Welch's book Winning, he explains that being a good leader means you shift the focus from you to them--from being the only one able to solve the latest problem, to being the proverbial "dumbest person in the room."  Accountability should come hand in hand with empowerment. Learning to empower your teams can be difficult, and seem like a leap of faith at first. You soon learn, however, that letting your team originate the solution, predict the schedule, perform the work, and solve the problem builds their trust in you and in themselves.

Another effective technique is to make your team accountable to the executive staff themselves--in person--instead of you being the go-between, shielding them. Have the team leads accompany you to the Executive Committee meeting to report their progress. This way, they can feel a sense of accomplishment for their victories, and feel the pressure from the top, instead of from you!  Teach them to be commitment oriented.  Develop a commitment-oriented culture by keeping track of their commitments and holding them accountable for each one. Base their bonus structure on their ability to keep their commitments. This will teach them to be more accurate, which translates into better predictability that that is better for everyone.

Joel Spolsky has a simple solution for this.  It's called Evidence Based Scheduling and you can read about it here.

Mike J Berry

The Role of the Development Manager

I remember my grandmother explaining what it was like to teach grade-school.  She said to be a good teacher, you had to be part teacher, part nurse, part referee, part coach, part police officer, part mother, and part collections agent. Fortunately, software development management requires a smaller skill-set.  Software Development Managers really have four areas of responsibility.  These four areas are:

  1. Responsibility to the corporation
  2. Responsibility to the development department
  3. Responsibility to the customer
  4. Responsibility to the product

To the corporation, the development manager owes efficient yield,  predictability of delivery dates, and transparency regarding the health and status of each project. To the team, he owes corporate transparency (what goes on in the executive meetings), clarity of direction, priority of tasks, empowerment, and accountability. To the customer, he owes the highest reasonable product quality, and highest reasonable product relevance. And to the product, he owes the best tools, architectures, and programmers he can find.

Mike J Berry