Software Teamwork: Do the Right Thing

A few months back, I wrote about the need to have faith in the process that was being used to build a product. This was recently reproduced in the Cutter E-mail Advisor, and generated a question about the diagnostic I referred to, and a question about how to build that faith that I alluded to in the article. Here are a few thoughts on the topic.

I’m sure it happens in any industry, yet it never ceases to amaze me. Once someone gets a bit of prominence, once they have discovered the secret handshake, many people will stop questioning what comes out of their mouth (or fingertips if online), and take their missives as gospel. Crazy, but true, and costly in the technology field.

 In many shops, big or small, software or otherwise, agile or traditional (as if that were a true dichotomy) we see fabulous energy in projects where people are committed to delivery. Unfortunately, in too many shops, we also see the down side of fatigue. Sometimes after the project completed (if you’re lucky), but often while the project is trying to progress to completion, the many symptoms of fatigue can have tremendous costs.

Proposed approaches to building products, software or otherwise, will come and go. One thing that seems to be constant through all this change is that the voice of the latest and greatest is convinced that they have solved the problem once and for all.

There is no shortage of indicators that we are in for in for a rough stretch ahead. While there are some that are still debating whether to call what we are going through a recession or a depression, it is clear to everyone that this is no time for frivolous spending. I would argue that we should always be aware of where we spend our money, and always spend with an understanding of the return we expect.

In many sectors, 2008 has been a tough year. There are very few people that expect that 2009 will be much better, and most indications are that the foreseeable future will be at least as challenging, if not worse. How people and organizations deal with these difficult times is a strong indicator of how well off they will be as the situation improves - or whether they are still around at all.

Pair programming is one of the agile practices that has most polarized people on both sides of the fence: sitting two people down at the same screen and keyboard to develop a piece of code. Having experienced this practice over 25 years ago and finding it to be extremely productive, I'm in favor of it being applied more than it is now. In fact, I would advocate pairing up (or more) for almost any practice we apply in the process of building our products.

Almost everyone is familiar with Dr. Bruce Tuckman's team model of Forming, Storming, Norming and Performing. This describes a sequence of stages that teams will naturally go through, whether this is consciously managed or not. Some teams never quite make it past Storming, and some seem to get through it relatively unscathed, only to lapse back later. As with many models, teams often exhibit traits of more than one of these stages at the same time, so its linear presentation may be a bit misleading. That stated, though, the model is a succinct and extremely applicable way of describing overall team growth. If we tie this model to a couple of others, though, we get a few more very interesting insights.

Often, out of the sea of different opinions of how things should be done, there rises a few techniques that make it to the level of becoming a standard way of doing things. They can be codified in a Body of Knowledge, if such a thing exists for that discipline, or become generally accepted as a 'best practice', though we all know that these things are quite rare. Even when they are raised to that level, there is danger that they can become overused: while every technique has it's niche, no technique should be used too broadly. Such is the case with Work Breakdown Structures and Gantt charts.

Particularly for small, startup organizations, it is important to come to grips with who you really are. From my perspective, too many startups see themselves as software companies, or end up accidentally becoming software companies, and this can get them into serious trouble.

Over the years, I have seen two distinct analysis schools of thought. There is the 'let's get this over with so we can start doing the real work' school and the 'let's work through the tough problems now so that our implementation is straightforward' school. There appears to be a gradual migration from the first to the second in the industry, but the first continues to be fueled by a lack of appreciation for the value of effective analysis in the educational system.

When I let one of my kids know they've got 10 minutes before we need to be out the door for one of their activities, it's a safe bet that the response I will get is an "OK Dad." Unfortunately, it is also a pretty safe bet that we'll be getting out the door more than a few minutes late. It's a dance we have fallen into that happens all too often with technical teams as well. I can't trust them to be good to their word, and I have fallen into the trap of just letting that happen.

Recall back to your college days, there was likely a time when you needed to calculate the maximum value for a given 3-dimensional function. There are a number of algorithms available, but many fall into the trap of only finding a local peak, rather than the absolute maximum. I'm sure that most of you asked yourselves whether you would ever use this in the real world. I'm sure I did, even the second time I took that infernal course. It turns out that the problem of reaching local maxima seems to occur in a team environment all the time, where it is not as rigorously understood that it is even a problem. While there is far less math involved, the solution can end up being just as difficult to implement.

Working with a couple of groups that are striving for a certificate in Project Management, we have run into an interesting situation. While the deliverables that contribute to the grading in the course focus on hard-skills implementation of a realistic, but simulated, project (most have selected to go with a PMO implementation), the one document they produce that is not directly part of the grading is turning out to be the most relevant to the success of many of the teams. It is their team agreement.

I was working through a requirements session with an IT team from a large global company this week, and several times the topic of agility came up. There are as many perceptions of where analysis practices fit within the ill-defined boundaries of agile practices, which always makes for interesting discussion. One of the areas where this occurred is the analysis of the quality requirements for a system, which led me to consider the notion of a quality spike.

I read an article from Cutter's Agile E-mail Advisor this week that sparked my interest. In it, Jens Coldewey concluded that "rather than being an opposition to software engineering, agile development is an alternative draft of software engineering". In the context of Jens' article and some presentations earlier in the week at the PNSQC, here was my response.

I gave a couple of presentations at the Pacific Northwest Software Quality Conference in Portland this week: a case study about a rousing success we had with HP in Barcelona, and a presentation about what each of us as individuals can do to improve overall quality in collaborative teams. The conference uses green, yellow and red cards to allow people to rate the talk immediately, with the option of providing some written feedback. While both talks were very well received, one person responded to my 'individuals' talk with the following comment on a red card: "the correlation chart, the last entry about length of employment - you mean active engagement - the substitution of length of employment is why age discrimination mean I expect to lose my job - may you rot in your smugness". Woah! Let me respond...

How we decide to go about our daily lives has a significant on the outcome, both immediate and long-term. Over the years we have come up with all sort of alternatives for communicating with others, and I fear that we tend to lean towards those forms that go against the nurturing of our relationships, in the name of multi-tasking. For the most part, we are not doing our eyesight any good, either, as we spend most of our work-day (and much time outside of the office) staring at our screens.

We can look at what has happened in the past on projects, what is currently happening, and what is happening in the future. If we are sloppy with our records, we can easily have different versions of the past. If we are weak in our communications, we can even have different perspectives of the present. With care we can avoid both of these issues, but it is safe to say that when we are looking into the future, we can never be certain of what will happen. This is a limitation we need to appreciate.

I have heard all sorts of reasons for taking on projects. If you dissect these reasons, many boil down to rationales that are actually irrelevant. It may be that we have found some cool new technology that we can justify solves a problem if we can get it to work, or that we always kick off a new project after the last one ended, so it is time to get going on this one. Insert your inappropriate justification here. In the end, there needs to be 2 reasons for running a project: it benefits us as a business, and there is a net gain in benefits for the stakeholders over the competition (which begets the first reason).

We're all familiar with customer service, and likely have all kinds of stories to tell about disappointments with transactions we have had. I've changed cel phone carriers in disgust several times, and will never get my car serviced where I originally bought it. I have actually had a few positive surprises that have dramatically strengthened my relation with some service providers, but alas, these are outnumbered. This idea of customer service is more pervasive than we might first think.

I spent quite a bit of time studying martial arts in the past. While I wouldn't say that this made me more capable of coming out of a bar fight unscathed, the effort kept me (relatively) physically fit, introduced me to my future wife, and taught me other valuable lessons. Two lessons that translates quite nicely to the workplace are the notion that you don't become agile overnight, and that true agility transcends things like flexibility.

For a long time now I thought I understood the adage that in order to best help others, you need to be able to help yourself. It turns out that there are some things that you don't truly understand until you experience them in action.

I ran into an interesting situation yesterday, as a mentor for an intensive PM program. The session had just started this week, and I was face to face with a person that was adamant that she did not qualify for the program, while I saw things quite differently. This was quite the opposite of most situations of this type, where the candidate is overstating their qualifications to get into a program.

As we gain more experience and expertise in our selected domains, there becomes a stronger tendency to lean primarily on that knowledge to solve problems. Sometimes this works, but sometimes we tend to lean too far in that direction and forget that we should be listening before we start solving. There are times when we need to remind ourselves to get our ears on.

I asked teams in a workshop this week to come up with issues they faced, and one group identified their biggest issue as a failure to communicate. As they listed their root causes for this extremely broad issue, ESL came up in the list. More importantly, though, came an insight that expands on that theme of using a different language on each other.

There are as many opinions about how to improve your business as there are consultants - likely more. While it may appear on the surface that there are large groups with the same message, you will find that as you dig deeper, everyone's message is nuanced with their own experiences and biases. There is a right answer for you out there, but you need to watch that you don't get bounced around like a pinball.

For most teams, there is plenty of room for improvement in terms of efficiency. Particularly in the larger shops, discussions of improvement usually get around to discussions of ROI, or Return on Investment. Unfortunately for most, two things usually occur: full lifecycle costs are not considered, and prioritizing alternatives to invest in becomes a game of minimizing the I rather than maximizing the ratio of R/I. It doesn't have to be that way.

There is plenty of chatter in management literature about risk and risk management. It usually takes one nasty "I should have thought of that" moment for a project manager to learn his or her lesson: a risk register becomes part of the standard toolkit from that point forward. While a great tool, a disciplined approach to risk is still not perfect. We need to recognize that there will always be blindsides.

In many shops, I have seen situations where one person (or perhaps a few, but it is always a minority) appears to be getting in the way, and the perception is that they need to be sent on their way for the good of the team. While this actually is true in some cases, I think that more often than not it is more a case of failing to appreciate what others bring to the table.

I sat down to lunch recently with a good friend, and we talked about challenges we face in staying motivated, and in keeping the troops motivated as well. On reflection, I think it is a matter of keeping everyone jazzed.

Generally in software development, process has been described as the steps we take to get things done, and is often captured as a specified approach to building our products that involves some sort of lifecycle, a collection of roles and responsibilities, a series of artifacts we produce along the way, perhaps some milestones, and some checks and balances to keep the whole thing going smoothly. There is more than meets the eye if we want our approach to be successful.

Have you ever run into a situation where all else seems to fail, so you resort to measures that you hope will work, but really don't know if they will make a difference? Of course you have. If you have ever worked on Windows before, you probably know the most common pet trick of all: ctrl-alt-del.

Any project manager that has managed (or worked on) even a single project knows that every project will veer off of the planned route in some way. For many projects, this initial deviation is the start of a cascading effect of chaos and reactive decisions that results in delays, dropped scope or reduced quality. Rather than fight it, we should be preparing ourselves to deal with the inevitable unplanned events as best as possible.

I'm just finishing my first round facilitating an intensive project management program with a local university. If there is one thing to distill out as a common challenge among the teams is that there isn't nearly enough depth of reflection as we move through the project phases. There is a lot of administrative reporting.

There are a lot of things that I like about the agile movement, many of the things I have been doing myself or recommending to clients for years. Short iterations, plenty of interaction, early value and strong leverage of change. A critical new improvement is that it is now OK to talk about how you are going to approach a problem, to talk about process without thinking that the whole thing is a waste of time and money: a nasty stigma has been removed. One thing that is still holding us back, though, is the argument by many agilistas that you have to jump on the bandwagon or you won't be successful.

It happens more often than we would like to admit. We understand that capturing some form of information should provide some benefit, we follow the prescribed guidance and a decent template to provide structure, and apparently get the job done. Unfortunately, at the end of the day, we never realize that deep value we were looking to achieve. Chances are we have completed the exercise to the letter only.

I see many companies that start out with a compelling idea for solving a nasty business problem, but somewhere along the way their implementation gets a lot fuzzier. In more than a few situations, we are best served if we remember to go with our strength.

One of the many lists that I lurk on, the Agile Leadership Yahoo Group, became active a few days ago, with a thread that ranged from quite thoughtful to somewhat disrespectful, as these threads often do (which is why I generally only lurk). At one point, a question was posed: if you were teaching in, say, the Masters program at Carnegie Mellon, how much time would you dedicate to teaching about the past and how much about the processes for the future? I took a bite, here's a paraphrasing of what I had to say.

Usually, when I'm talking about different requirements practices, I use traceability as a practice that adds quite a bit of value for things like impact analysis. In most shops, though, the cost of developing and maintaining exhaustive traceability, whether real or perceived, far exceeds any potential value. That's not always the case, though, and sometimes it takes a different approach, risk analysis, to understand how that value reaches the tipping point.

I have often heard different perspectives on how long you can expect to wait before a new hire is productive. Usually the numbers come in around 3 to 6 months, and in many shops where there isn't a sound infrastructure for communicating the company's business sector, products and practices, this seems a reasonable timeframe. What is important to recognize, though, is that in those initial months, we should at least make sure that this new hire is not a liability.

I wrote a couple of weeks ago about what can happen when a team agreement is hastily put together: it can actually be worse than no team agreement at all, and can serve to tear a team apart. It is one thing to observe this and note that the team agreement was part of the root cause. What tests can we apply to our team agreement to determine if it is good enough to pass muster to begin with?

I'm in the process of putting together a project that will involve a number of external resources from different disciplines. The intent is to build a product that will require technical, sales and marketing resources, and likely some branding and analytics effort, most of which will come from external consultants that I know. Being a consultant myself, I have learned the cost of totally missing the mark with a proposal, but I think this is the first time it has happened to me. I feel I have not been listened to, I feel insulted. I realize that this is the concern I often have to battle against with prospects, that they are going to feel 'consulted'.

Here's a draft of my reply, one of those 'better sit on it overnight' things. Names have been changed, of course.

What happens when something that has been hastily crafted to hold a team together is used in ways that were never intended? A team agreement can easily become a Weapon of Team Destruction.

It never ceases to amaze me how many different ways we can come up to fight change. Whether it is dropping a few pounds, kicking that nasty smoking habit, shutting off the lights as we leave a room or getting better at developing software, we are clearly at our most inventive in finding ways to just stay put.

What we often call process improvement is actually change management. The fact that most process improvement initiatives fail or disappoint is primarily due to the lack of appreciation for what matters when attempting to drive change in an organization. It has nothing to do with suggesting new practices or telling people what to do.

It is all too predictable. Whenever my son and daughter are playing together, it is only a matter of time before I hear raised voices and one of them, if not both, will come to me complaining about something the other one did (this could potentially be a long spring break). I've settled into a response that usually works quite well: to ask them to consider their contribution to the situation. What is most fascinating about this is how often a similar dance occurs in the business world.

I recently sat down for a discussion with a prospect about why they should use our services. I have faith that we are the right people to develop the application they are looking for from the technical perspective. From the purchaser's perspective, though, everyone they talk to will have that same spin. How do we engender a measure of trust when we're an unknown?

After working with a group on requirements issues over the past couple of days, one person queried me on a particular challenge they were having. It seems they build their products in phases, and in doing so they generate a separate requirements document for each phase. Three phases would generate three separate documents, each with the information from the last phase, plus any new feature for the latest one. This generates quite a bit of duplication, a lot of copy and pasting from the first to the successor documents. What to do?

A colleague of mine posted a question on LinkedIn a while back about how to develop a business case for improvement in soft skills for developers. I was too late to weigh in on the question there, so I'll take a stab here.

In this neck of the woods, there appears to be a real shortage of tech labor. The local industry association is citing the demand for new talent to be around 15%, and job postings on local boards are soaring. I expect this situation is repeated almost anywhere these days, and we are in the midst of a heyday for recruiters. Are we doing everything we can?

The debate rages on about whether traditional approaches to software development are the best for a project, or whether the more recent agile approaches are better. I’ve always thought that the debate is the wrong one to have in the first place: pick your favorite lifecycle, and chances are good that the selection is moot anyways. Most projects, regardless of the lifecycle selection, are run in a way that the uncertainty and risk will overwhelm whether you have decided waterfall or scrum. At the risk of alienating zealots from all camps, here’s why.

Once in a great while, I find myself in a position where I wonder what to do next. This is rare, of course, as usually there are more than enough things to keep me occupied. With technology companies, it is almost always the case that there is way too much to do, and even worse, it is almost always someone else that seems to be calling the shots. From what I have seen, there is a better way.

One of the products I offer that has been in most demand is software requirements training. A great course to deliver, with lots of information about the things that you could do (if the situation warranted) in software projects. Certainly not dogmatic or pitching a particular approach, one of the key messages is to consider your product, culture and environment, and choose accordingly. Over the years, though, I would sometimes get some pushback along the lines of "we do hardware (or firmware, or drivers...), this isn’t relevant for us". I disagree.

As our team size grows, we compartmentalize ourselves into more and more specific roles: project manager, scrum master, developer, tester, a wide range of others. With this often comes the assumption that each role has the responsibility to produce specific products or artifacts: a project schedule, a specification, the product of our roles. Problems arise when we take that assumption to mean that we are the sole proprietors of the products of our roles: that we have the responsibility of doing it ourselves.

In the book Artful Making, by Rob Austin (who also wrote Measuring and Managing Performance in Organizations) and Lee Devlin, the authors present similarities between how a theatre company prepares for a performance and how agile software teams do their job. The authors identify a number of parallels, but I am most impressed in how they are careful to repeatedly make the point that the approach is not appropriate in all situations. In reflecting on what the authors say, it is possible that no one approach is correct or sufficient for any project.

Particularly in the software world, we are inundated by absolutes. Someone will argue that one platform is always the best, someone else will unequivocally state that outsourcing never works. Always this, never that: a barrage of absolute positions that take on the fervor of religious debate. I have learned that the only right answer really is "it depends", in every situation save one. There is only one absolute: that everything else depends on a clear, common understanding of the context of the situation.

In the December 2007 Harvard Business Review, Barbara Kellerman presented a typology to help discern between different followers in an organization. While a distinction is made that most studies are focused on leaders, I think we are really talking about the same thing here. What is important is how all of this plays in the realm of relationships within an organization.

If we look at how most branded approaches for software development are pitched, we see that there is little active consideration for the team that will be dealing with that new approach. One could cynically suggest that this is because these approaches are being hailed as silver bullets that are independent of the participants, but I think it goes deeper than that.

It’s a scenario that gets played over and over again in software shops: the person designated as the analyst for a project, sometimes the CTO, sometimes also the project manager, heads into the birthing hut at the start of the project, and doesn’t come out until the spec is born. This analogy hurts in so many ways.

The Nokia Test is a quick assessment of practices to determine if your Scrum implementation is up to snuff, based on how it is implemented at Nokia. There is debate about whether it should be more or less rigorous or flexible. My thinking is that it’s great if you are doing exactly what Nokia does, which is true for very few of us. Let’s take it apart to see if there are any user serviceable parts inside.

Once in a while, I get the opportunity to work with a great team, in a company that 'gets it'.

For most of us, when we get right down to it, our focus is on solving our customers' problems (whether they are part of the same company we work for or not is irrelevant). If we are wise, we are constantly searching for better ways to get the job done, either more efficiently to save resources, or more effectively to provide higher value. We're always on the lookout to improve our repertoire of tools.

So you have an idea for a new product, what could be a breakthrough product for your organization. You might have built pieces of this product to confirm that it is feasible, you may even have managed to get someone to invest in your idea. This is a big step, this is something that will take you to the next level with your business. How do you make it happen?

In his book The 48 Laws of Power, Robert Greene explores a wide range of examples of the application of power and influence with others. The book has a decidedly dark feel about it, a Machiavellian leaning that can make for a bad taste in your mouth. Entertaining reading, but not something I would consider a guide to live by. This stands in stark contrast with one of the sessions of the recent AYE Conference, where we explored the nuances of power in a setting that is much more aligned with the idea of common good rather than a zero-sum proposition.

I participated in the AYE (Amplify Your Effectiveness) Conference in Phoenix this week, which is clearly not your run of the mill conference. No PowerPoint allowed, no stodgy rows of chairs facing a lone speaker in the front, very little nodding off, and only the people with iPhones were distracted from the sessions. Indeed, the line between audience and speaker is intentionally blurred and engagement is increased significantly. A highly recommended conference. The topic of change comes up frequently, and these discussions are often centered around the Satir Model for Change. We all deal with change in our lives, generally doing so by avoiding it at all costs. Change is not trivial topic to deal with, which is likely one of the reasons it is so intimidating to all of us.

Quite often when we talk about challenges in this industry, we lament that our customers don’t get it, or that those hardware guys seem to live in their own little world (that is, if we’re in software – for those in that hardware world, the shoe is often on the other foot). If we dive into the majority of those communication issues, one of the problems is that we have not really engaged with 'the other side' - we have been busy confusing them with our jargon.

There is great value in having a standard way of doing things we need to do more than once. This applies in the home, and can be extended to how we develop software as a team...to a point.