Teamwork and Flavors of Agile

May 29, 2009

We have three Agile teams in our company, with each team managing a different product and each with its own distinct “flavor” of Agile. The general process that the teams follow is identical, but each team definitely has its own look and feel.

Some of the differences were expressed during an exercise we conducted to define what a high-performing team should look like. Each Agile team and the management team went through the exercise in the spirit of continual self-assessment and improvement.

We found that there was general agreement in what everyone thought a high-performing team should look like, although some things were expressed in different ways. In general, everyone had the following categories addressed in their list:
  • Commitment
  • Transparency
  • Accountability
  • Respect
  • Trust
  • Self-Determining
  • Collaboration
  • Communication
As I discuss the details, there is an important factor to keep in mind: Each team not only handles different products, but each team is handling products that are in very different stages of the product life cycle. To set the stage for you:
  • Team A handles our proven/in-production (numerous implementations), stable, full-featured, legacy product.

  • Team B handles a much newer product (few implementations in production) just entering the market.

  • Team C is designing and developing an early-stage product that has high-level objectives, but is wide open in terms of the specifics needed to meet those objectives.
This led to some interesting differences in the actual specifics put forth by each team in some areas. I’ve noted the a few key categories and the comments related to each made by the management team and the Agile teams in the tables below.



Individual and team commitments are met.

All team members are contributing, including taking the lead on one or more tasks.

Team A

Meets daily commitments.

Team B

Attitude, dedication.

Team C

Individuals are highly motivated.




Each team has a working agreement and lives up to that agreement.

Push back to stakeholders on issues with resources (being pulled off) and estimates.

All team members are self-directed.

Team A

Reviewing working agreement regularly.

Individual initiative.

Team B

Minimal outside influence, not micromanaged.

Input into product direction.

Team C

Involved in all aspects of the product (development, QA, marketing, demos, etc.).

Team feels like they own the product.




Teammates assist one another, even if it means operating outside their respective area of expertise.

Team A

Assists team members with road blocks.

Team B

Work together well, creatively, and with a common goal.

Pitching in when & where needed, no “not my job” attitudes.

Team C

High level of collaboration.

Flexibility – no defined roles.

Are the differences a result of the personalities involved with each team, or are the differences the result of the product life cycle driving the perceived needs of team?

I say both. The personalities of Team C are those of people who need to define and shape a product, requiring a high level of technical competence along with the ability and desire to deal with ambiguity; this in turn requires a high degree of interaction and collaboration. And I hope that based on the comments that I’ve provided, you can determine that they have a strong sense of ownership, due to the fact that the product is the direct result of their input and efforts.

Would these same people succeed with the more structured care and feeding of our legacy product? Yes. Would they enjoy it? No. Would I retain them for long? I doubt it.

It may be difficult to discern from the comments that I’ve provided, but Team A does have a sense of ownership as well, but not in the same way as Team C. Our legacy product is the result of years of effort by a lot a people, many of whom are no longer with the company. There is a historical sense of ownership and Team A takes pride in their work, but the product is well-defined at this point. The needs of Team A’s product are very different from that of Team C.

Team B is clearly in that middle ground. The product that they are responsible for has demands for new features, although far less in terms of volume when it was our new product in design and development. Team B wants input into product direction, but they didn’t articulate the desire to be “involved in all aspects of the product” like Team C did. Team B’s sense of ownership is grounded to the relative life cycle stage of the product.

The management team – having embraced Agile development – wants to see teams be accountable and successful. The focus is on the teams and results, and as you can see from one comment, “All team members are contributing, including taking the lead on one or more tasks,” the management perspective is derived from experience that includes the notion that in order for certain things to be accomplished, someone has to be responsible for it, to own it. And teams and individuals should own their tasks.

The management team also recognized that teams need to push back when appropriate – particularly if the agreed-upon deadlines are impacted due to resources being pulled (something we strive to avoid). We also expect candid conversations around our target dates, particularly seeking to avoid the all too common scheduling technique of “Here’s the date we have in mind, now work backwards when creating your project plan.”

My takeaway here is that the needs of one project or product will attract certain personalities that are suited for the needs of that project/product. The team dynamics and working norms will vary, in part because of the people involved, and in part due to the nature of the work involved. Even though we have a defined process and approach to development, we do have distinct flavors. As long as we’re achieving results, I certainly can embrace the differences.

How Commoditized White-Collar Work Will Change the Work Dynamic

May 20, 2009

My last post Is Commoditized White-Collar Work on the Horizon? reported on the concept of turning white-collar work into numbers by cataloging the skills of individuals and mathematically determining how to deploy workers to specific projects based on their skills. The goal being to optimize productivity of those commodity workers to achieve 100% productivity. In this post, I’ll share my immediate thoughts and reactions.

One argument from IBM -- in support of using their software tools – is that since these tools will make workers more productive, the market would reward the workers and enable them to negotiate better pay.

I don’t buy the argument for one minute! I can see how those elite workers at the top would be able to negotiate their pay, being perceived as talented stars, but would commodity workers have any negotiation leverage? My specific concern: When does something increase in price (implying greater perceived value) when it is commoditized?

If – and I think that this is a big if – white-collar work can be actually be broken down so discretely so that tasks can be divided into days, hours, or even minutes, the result will be the white-collar equivalent of piece work. Would you want to be a commodity worker?

This also doesn’t sound like the creation of an environment of informed, motivated employees who are also expected to help drive innovation that will spur continued growth of the company. In fact, it sounds like what Susan Lucia Annunzio was warning about in her book “Contagious Success – Spreading High Performance Throughout Your Organization.” And that is to avoid over-emphasizing productivity to the point that you drive out the ability for workers to contribute more through innovation and creativity.

You need to look no further than Google in support of allowing workers to contribute through innovation and creativity. Google’s software engineers spend 20% of their work time – one day per week – on projects that interest them. And it is paying off. According to Marissa Mayer, Google's Vice President of Search Products and User Experience, half of the new product launches originated from this 20% “innovation” time. (Source: Wikipedia)

Will commoditizing work actually optimize productivity? Not so, according to a recent BusinessWeek post, Surfing the web at work increases your productivity. According to this post, people who gave themselves quick rewards after completing mini-tasks were more productive, to the tune of being 9% more productive in a day. Will someone who thinks that you should be tracked down to the minute give you the space of surf the web at your own discretion? I can't picture that happening!

Let's continue on and assume that you are a commodity worker who is being pressed for 100% productivity all of the time. How will you stretch and grow into a star? Will management be responsible for even identifying potential? If so, how will this be accomplished?

I suspect that proving yourself will be done by doing things on your own time, on your own dime. And employees will want to generously donate their efforts towards a company’s success because…?

In the near term, companies will need to think long and hard before adopting this concept. If a company takes this too far, I believe that it will be difficult to succeed as there will be too few who are able, willing, and incented to contribute innovative thoughts and creative ideas on behalf of the company.

I’ll take the plunge and dive into greater speculation: The likely outcome will be the emergence of a true, virtual corporation. Why? I'll quote Newton’s Third Law of Motion:

For every action there is an equal and opposite reaction.

Newton was talking about the physical world and I'm talking about people, but as we all know, people react. The backlash of treating employees as commodities will likely encourage increasingly large numbers of people to become independent, where they have more control over their work hours and destiny. This of course will open up opportunities for web-based project solicitation and bidding. Hmmm…

At any rate, I’m predicting that these independent workers will choose work on a project-by-project basis, managing their own careers by selecting attractive projects and re-investing their own money and time into keeping their skills sharpened.

This will tighten and focus corporations significantly, as they will be unable to assign work for low-value activities. There won't be anyone within the corporation with any bandwidth to take on those tasks, and there won't be anyone willing to take them on as an independent contractor, either. Low-value tasks won't contribute anything towards improving skills and the value proposition of an independent worker.

Another opportunity in all of this will be an increase in telecommuting and greater need for network-based collaboration tools. Of course, there will be a reduced need for large, commercial office space, something to consider if you are in the commercial real estate market. (Again, I’m having a little fun predicting here, I’m interested in your take.)

Will corporations resist this? Interestingly enough, I doubt that they will. Corporations will find this work arrangement attractive because they will have far less people on their actual payroll, limited to those who will be responsible for defining and shaping the core business along with defining and farming out a majority of the work. Between this and other technological advances (cloud computing for one), corporations will have the easy, ready ability to flex their workforce up and down, based on immediate needs.

The real trick for corporations will be to identify and those who are willing and able to manage the business and set direction that will drive growth. One issue is that there will be less of an internal talent pool to draw from and develop.

I feel that there are challenges and opportunities for both the individual worker and corporations in the commoditization of work. The world certainly isn’t standing still, but I feel that technological advances will drive fundamental changes in how everyone approaches work in general.

Is Commoditized White-Collar Work on the Horizon?

May 15, 2009

I thought that I would share something that I consider to be both alarming and a warning. It came in the form of a BusinessWeek book excerpt for the book "The Numerati" by Stephen Baker.

The excerpt covered a chapter describing how IBM is building complex mathematical models of 50,000 technical consultants, compiling extensive data about their skills, experience, meetings, etc, and then calculating how to best deploy them. This is an extreme attempt at capturing and reducing the nature of white-collar work to something that can be fed through a computer to optimize productivity and "automate management."

The ultimate goal (as described in this excerpt) is to enable an IBM manager to fill out a form that describes a particular project, target dates, budget, and the skills required. The computer then spits back a recommendation for a particular team. If an adjustment needs to be made based on budget—like the availability of a very knowledgeable and highly skilled star employee, but who is too expensive – the computer will recommend someone else.

Should you be worried? It depends upon who you are. If you are the high-priced star in the example above, in IBM’s world you can safely remain “on the bench,” awaiting the correct opportunity to apply your talents when and where they are truly needed.

It is the everyday worker who becomes a “commodity worker,” someone whose work is not really distinguishable from another. The real shocker was the notion that a company should keep its commodity workers laboring as close to 100% as possible.

Where is this leading?

I’ll confess that I haven’t read the book – yet. Maybe there is more to this than what the excerpt provided. Part of this appeared to be centered discovering informal networks and decision-making, implying that at least of portion of this assumes existing work arrangements. The optimist is me sees the potential for those who are truly making things happen to be recognized. The pessimist in me sees the ready opportunity for adoption and abuse of this by those managers who aren’t really interested in developing people.

IBM’s argument in support of this is that since these tools will make workers more productive, the market will reward the workers. The tools will also provide the ability to map out careers and provide ready access to information that would allow someone to calculate their own net worth with greater precision, negotiating better pay in return.

Will some work be commoditized in the future? Unfortunately, I absolutely believe that it will. I noted that this same “worker as a commodity” line of thinking surfaced in another article on the ("The World in 2009" November 19th, 2008 by Lucy Kellway) In it, Lucy predicts "In 2009 a more elitist shift will occur: companies will worry about the performance of those at the top of the pyramid, while everyone else will be managed like a commodity."

I’ll post my reaction to this in a few days.

One More Key for Successful Software Projects

May 8, 2009

Several of us recently went through a couple of days of presentation skills training. Our final presentation needed to be in the five minute range, and believe me, five minutes makes for an extremely short presentation! I needed a topic that was very focused, yet rich enough to fill in five minutes.

Since I have a software development background, I elected to discuss one key that I feel is essential in software project success:

Smaller is Better

Why do I believe this to be true?

The classic definition of success – as customers perceive it – is determined on four dimensions:
  • On Time
  • On Budget
  • Of High Quality
  • Delivered with the Expected Features
My premise is simple; the larger the project size, the greater the likelihood that the project will fail on at least one of these dimensions.

Why is this so?

Large projects mean that there are many features involved. Features by themselves are not a bad thing, but a large project – particularly one that has a high feature count relative to the size of the project team dealing with that feature count – is where trouble begins to creep in.

As the team begins to deal with all of the individual features, there will be less time spent on each feature. Sure, the team might get out of the gate vetting every feature in great detail, but as time goes on, people will get distracted, temporarily lose focus, and gloss over at least some of those features. There will be a loss in precision and explicit detail. People are human, after all.

When this loss of precision and explicit detail occurs, assumptions or ambiguities will exist. And they will show up at unexpected times, and in unanticipated ways.

Sooner or later, a programmer will be translating a written specification into working code. An incomplete feature specification means that dangerous assumptions could find their way into the code. And if the programmer does the right thing and raises a flag to resolve an ambiguity, this will be occurring at unplanned-for points in the project, slowing down progress.

This leads to another problem. There will likely be impacts to related features. Resolving ambiguities with one feature “on the fly” may cause teams to overlook how one change will impact other features. It takes experience and discipline to evaluate the full impact of changes made to one feature on other features.

Finally, large projects require more people. This increases the lines of communication – along with the greater potential for miscommunication – as well as requiring more overhead in terms of keeping everything and everyone coordinated.

Smaller projects that have a smaller, well-prioritized feature set will have shorter time frames and the ability for all involved to have their heads wrapped around the effort in a collaborative, participative manner that is increasingly difficult to achieve with larger projects.

Smaller truly is better!