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.

In the studies I have conducted with over 700 respondents, only about 5% have noted that they had organized training to bring them into the fold of their current position. The lion's share, over 73%, had responses split almost evenly between between 'there was a plan, but there was on-the-job learning as well' and 'I was left to my own devices'. With that 36% that were left to fend for themselves and an additional 1% that said they still were not sure how they were learning, there might be some opportunities for improvement here. Anyone care to estimate the cost to the industry from this issue alone?

I know that whenever I visit a new company, I'm smacked upside the head with all sorts of jargon, acronyms and euphemisms that have become part of that culture. For my role as a transient visitor to this foreign language, it is usually sufficient for me to inquire about a couple of these things that seem to be salient bits of information, while I let the remainder sail right past me. For employees, though, this would be a dangerous practice. Most places that I visit don't even have something as simple as an acronym list or glossary for terms they use frequently.

Think about the process of bringing someone on board. You finish the paperwork in HR (or if the company is small enough, your manager will handle this), get the quick tour of all the critical things like washrooms and the coffee station, and are shown your desk. You have been introduced to a bunch of other people, start to understand who the go-to people seem to be, and might even meet some other new hires if there is serious growth happening. If you are lucky, it won't be too long before you have access to a computer and e-mail (or again, if it is a small company, maybe a directive to order your new machine from Dell), and away you go.

Away you go - but to where? The first week is filled with a ton of questions (with a very gradual decay thereafter), with few apparent answers. The typical approach to deal with this is to muddle around until curiosity overcomes embarrassment, and you go ask for help. You will check in with your boss if your teammates seem too busy (and if they're not busy, why the heck were you hired?), and she'll often answer your question. That response might be to go check with someone else that has the real answer.

And so it continues. Not only is your learning curve excruciatingly slow, that process is dragging many other people down along with you. There is a good chance they have answered the same question you have each time a new hire has come in the door since they arrived, and it seems like an unfortunate part of doing business. It is not inconceivable that in your initial few months, there is a significant net loss in productivity around you.

Not that you should bear the blame for this, responsibility for productivity of the team is not on your shoulders. The low-level bleeding of time consumed by short little interruptions doesn't seem like a lot, but it adds up quickly, and is for the most part avoidable.

Consider a different approach for new hires. Day one, once they have settled in and brewed their first pot of coffee (or made their first Starbucks run), they get their first assignment: given what infrastructure there currently is to support new hires, their task is to flesh this out based on their experiences over their coming weeks. Don't understand what an acronym stands for? Go find out and capture that information. No acronym list in existence? Start one, and put it in the right location. That location is not identiifed? Figure out a reasonable structure that will work. And so it continues.

This activity needs to be managed, of course. Check in every week or so with progress and discussion of issues, make it a critical task, not busy-work. Be clear that it is a task that never disappears, but should quickly consume far less time than during that first week. The next hires will have a stronger basis on which to work from, and their task will be easier because of it. Everyone else will benefit from the fact that they won't be asked for the umptheenth time what that acronym meant, or where to get that information, or how do we do this here.

Eventually, your whole team will have a healthy respect for this infrastructure they have built`, will appreciate its value for both consistency and efficiency, and everything will run more smoothly. Better than telling that damned new kid the same old story about how we check in code around here. - JB [top]

Shirking Responsibility (Compendium 7.11)

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.

Whenever a relationship goes sour, even a little bit, there are two sides of the story. It is human nature to pay most attention to the details as they are seen from our perspective, often to the point where we are blind to the idea that there even can be another perspective at all. Those details, from our perspective, usually will suggest that we have been wronged, that our actions were innocuous. Unfortunately, that is rarely the case. Here are a couple of interesting examples, based on working with clients using our diagnostic product over the years.

The first case comes from a group that performs better than most of the teams I have worked with. While not always performing to that level, they have dramatically improved over the years, to the point where they are quite a strong example of the effectiveness of conscious focus on practical implementation of reasonable practices and continuous improvement. They are also one of the few companies that has been successful at leveraging outsourced resources, by carefully managing subcontractor performance. Indeed, they are able to do so only because they are one of the few companies that has a quantified handle on their own performance.

Running the diagnostic with this group, we split the responses so that we could compare the development team to the test team, and both to the outsourced team in India. The question we always start out with is to get people to identify, from a list, their major sources of pain. In this case, the strongest response from the development and test teams was that their subcontractors were causing the most pain. Interestingly, for the group in India, it was the customer that caused the greatest spike in responses. For a group where everyone acknowledged one of the strongest outsourcing relationships around, there were certainly some remaining challenges to deal with, and both sides perceived that it was the other side that was the challenge.

The second case is with another company located only a short distance away from the first group physically, but almost diametrically opposed to them in terms of performance. This group had been struggling for some time to deliver quality product, and had literally been spending the lion's share of their time dealing with client-reported issues. Here, when asked about their greatest issues, the interesting responses came from a selection called 'other', where respondents could answer in freeform text. While the technical people indicated there were issues that they could deal with, such as a need to do more testing or a lack of understanding of the user's needs, management responses fell into a different category. All their responses indicated that the problem was outside of their sphere of influence: the war in the Middle East, the weakening economy, the weakening US dollar (this, mind you, was several years ago). With that attitude, all they could do was throw up their arms in despair.

Unfortunate, because there really was quite a bit they could have done to better manage their circumstances.

Whether we are refining our already strong performance and dealing with relatively minor tweaks, or battling stronger demons in a fight for survival, it is in our best interests to be able to step back when we look at our issues to include our own contributions as part of the mix. If we look at all the respondents to the diagnostic to date, 27% have indicated that their customers were a significant issue they had to deal with. While we could look at that and suggest that those customers were indeed an issue, we could also step back and consider that perhaps there were things we could do to better manage that relationship.

In any challenged relationship, there is always something that we could have done differently. The fact that we are in the midst of such a struggle should give us pause to consider our own behaviors. Indeed, one of the most powerful tools I can bring to work with clients is often a mirror. - JB [top]

Find, Hire, Grow and Keep (Compendium 7.7)

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?

I'm not so sure. The emphasis appears to be on finding new talent and competing successfully against others to hire this new talent. Unfortunately, if everyone else is doing the same thing, we fall into that zero-sum trap again. If we have won at finding a great resource, someone else has lost. Whenever someone has offered a better compensation package, we feel we have lost. While it can be important to seek new talent to fill gaps with our resource needs - to bring in unique expertise or experience in a niche that we are expanding into - we rarely differentiate this from the situation where we are looking to add more resources that look a lot like what we have already.

That same industry association study that indicated a local talent gap of 15% cited that on average, 1.37% of salaries are used for training, and that more than 50% of respondents only allocate 2% of salary for training at all. We hire in the best we can find, don't spend a lot of time nurturing them once they are here, and find ourselves in a vicious circle when these talented people leave for greener pastures. The grow and keep portions of the overall talent equation are woefully neglected. While it is important to understand how to find and recruit new resources (and local technology associations can do a great job here), we need to get a whole lot better at nurturing the team we have, which in turn will help us retain them.

Here come those stats again. In software companies, stats show an average of 30-40% of time spent in rework (I've measured it with one company locally to be over 70%, and anecdotally, many others feel it to be 50% or more). Unfortunately, almost nobody measures this, making it an underlying malaise that's not top of mind when we try to figure out how to get more work done. It's safe to say that startups that are usually at the higher end of this waste - running hard and cutting the wrong corners. If we don't know the numbers, if we can't see this massive pit of costs, we also can't see it as an opportunity, either.

For astute companies, greater emphasis on training and operational oversight can easily reap that 15% additional resources that are cited in the study above. What is most important about this approach, the grow and keep approach, is that companies that work this way extract themselves from much of the zero-sum talent battle, and dramatically reduce the risk and cost associated with recruiting. It's not completely eliminated, but becomes important only when we are looking for different and unique talent, not for more of what we already have. If we are simply looking for greater capacity in development or testing or management, in a generic sense, we should first look to improve internal efficiencies rather than throwing new and untested people into the talent pool.

It is important to attract more talent to the region (which is probably true wherever you live), and tech associations can provide quite a boost here. As individual businesses, though, getting better with the talent we have is something that is entirely within our control, and is more likely to bear the fruit we need to thrive. Wherever possible, grow and keep should be emphasized over find and hire. - JB [top]

DIY (Compendium 7.3)

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.

The experience of producing one element of a larger system can be harrowing, extremely rewarding, or anywhere in between. When we are tasked with getting something done, especially if we work in the context of strong information regarding what the content should be, and effective guidance in the form of a template or example from a previous project, it can appear deceptively easy to get the job done. Work breakdown structures help us remember everything we need to consider when building out a project schedule, document templates will give us an outline that allows us to simply fill in the blanks, even the defined structure of a daily scrum meeting gives us guidance on who needs to participate (everyone) and what they need to cover.

Unfortunately, when we are doing these things on our own, it is too easy to fall into the trap of following the letter rather than the intent. For collaborative events such as scrums, we can still think of this as a DIY activity if it is only the scrum master that considers whether the intent of the collaboration was achieved. With one person thinking about whether we are done, it is easy to satisfy our own preconceived notions of what is done. We will often be working to some deadline, and the task often becomes an exercise of making sure that all the fields are filled in with something within the time constrants, then polishing if you are lucky enough to have any time remaining (and there isn’t any other pressing tasks to deal with).

That’s great, and we can often check off the completion box on that task, but are we really done? As others are in the same boat, review is often superficial, and deep issues only arise much further downstream. For most tasks on a project, if you were to hand them out to be completed independently by different people, you would easily find that everyone would complete the task, believe they had done a good job, but provide wildly different solutions for the task. A great example of this is the production of a vision statement for a project: a simple expression of who the key client is and what problem is being solved, along with an identification of the key competitor and the primary differentiation. Ask each person on the team to complete this independently, and it is guaranteed that you will get very different results, each one being complete. This is a problem.

If done in a collaborative fashion, the dynamics are completely reversed. The differences of perspective are exposed early, highlighting the need for further discussion and clarification. The team works together to come to a common understanding, rather than the team inheriting one viewpoint and having to live with it, as occurs most of the time. Done this way, these discussions occur with the right people at the table, at the right time in the project. Compare this to the late-in-the-project discovery that there was no alignment in vision.

As we split into more and more detailed roles on a project then, we need to think of the things we each need to get done as things we are responsible for ensuring they are done, rather than things we need to do ourselves. In this way, we make sure that different perspectives are appropriately balanced. With broader participation, everyone has a stake in the production of the artifact, and with that stake comes a stronger feeling of ownership: it becomes 'our plan' rather than 'his plan', or 'our tests' rather than 'his tests'. Big difference. It helps break down the silos between departments, the handing over the wall of artifacts between different roles, the carrying down from the mount of the stone tablets that drive our work.

The whole group becomes responsible for a successful project. Even if one person has the lead in ensuring something gets done, that person should never be alone in the activity. Nobody likes to be told what they should be doing, or what they have to do. It is far better to be part of the decision making process, to have the opportunity to see what is needed and step up and volunteer for the task. The stake and ownership itself will tend to provide success far more often. The counter-argument of not having enough time to collaborate on these things just doesn’t fly. I’m not suggesting that everyone participate together for every component of every task, but anyone affected by a decision should be involved in the decision-making process. If we do things on our own, the collisions downstream because we don’t involve others will cost us far more in the long run, even if we don’t account for these costs against the original activity.

Regardless of your role, don’t get caught in the trap of thinking that you are solely responsible for the products of that role. A better way of looking at things is that you are being tasked with making sure that the decisions your role is in charge of actually get done, but get done and agreed upon taking everyone’s perspectives into account. The perspectives of others can only be clearly understood if they participate: don’t do it yourself. - JB [top]

Followers (Compendium 6.52)

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.

The typology presented essentially divides followers by their level of engagement within an organization. It starts by distinguishing those who are not actively engaged, isolates and bystanders, separated by whether or not they are even aware of the environment around them. The remainder of the types are all active followers with differing degrees of participation, and passion that carries this engagement: participants, activists, and diehards. This is an interesting typology, to be sure, and thinking of ourselves and those around us, this facilitates our understanding of distinctions between different types of followers. I find that I have evolved over my career to be more engaged in my role as a follower (being a follower is not intrinsically bad in itself), and I would expect that most of you would see your own form of evolution as well.

While the article starts to make some distinctions between good and bad followers, invoking some of the traits of what we perceive as good leadership, I would take this even further, and add another perspective before we can really understand whether the situation can be judged as good or bad. To my mind, all of the traits that we would tend to use to describe a strong leader apply just as well to strong followers, and are independent of where we sit on an org chart or some other hierarchical relationship. Certainly, if many of these traits are tied intrinsically to personal values, and many people are simultaneously a leader to some while being a follower to others, then it seems to reason that we cannot easily swap these traits in or out as we wish. If we already behave in alignment with traits that make us effective leaders, we will already have the traits that make us effective followers, and vice versa. These are traits that are not the exclusive domain of one or the other group, they are traits that make us effective in any relationship we are in. If we carry these traits, if we are congruent in honestly behaving according to our stated (or implied) values, then we are on the right path. The importance of whether we are a leader or a follower in any given situation diminishes significantly, the playing field is leveled.

Which brings us to a very important element that helps us discern good vs. bad. Your perception of whether someone is an effective follower or leader is largely based on your perception of their behaviors, whether or not you believe they are acting in congruence. The challenge that we have is that quite often, values and goals are merely implied, not explicitly stated. If one person is in a leadership position but does not carry explicitly stated values or goals, we are left to interpret the situation (and their behaviors) in the context of our perceived understanding of what they stand for. If we don’t see alignment, this could be because the leader is not acting in congruence, or we are off the mark in guessing what is driving them, or both. In any case, we will be in a situation where we don’t see this person as an effective leader (or follower). After all, we usually go on the assumption that our guesses are right, don’t we?

If we don’t explicitly expose our goals and values, then, we run a high risk of being seen as ineffective. As a leader or as a follower. The team will break down. To avoid this, it is imperative for everyone on the team, leaders and followers (and quite often, you will bear both roles simultaneously), be explicit and open about the goals and values that are driving behaviors. This gives everyone the opportunity to judge these behaviors with the appropriate context - and trust me, you will still be judged even if you don’t provide this context. More importantly, it allows everyone to compare goals and values among the group to determine if there is enough alignment to move forward as a cohesive team.

The distinction between leaders and followers is less important now than it has ever been, particularly for knowledge workers where anyone in the organization may have the critical information to drive the team at any point in time. We all need to be actively engaged in a manner that is congruent with our goals and values, while ensuring this meshes with those around us. What is critical is the conscious and explicit expression of goals and values for everyone involved, the ongoing management of the evolution of this information, and the important discussions and decisions that will result. - JB [top]

Actually, It IS All About You (Compendium 6.51)

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.

There are several reasons for neglecting specifics about the human element, but also some deep challenges in failing to do so.

First, the complexity of dealing with the human element when we are dealing with teams and processes can be daunting. Teams come in all shapes and sizes, and there are at least as many different motivating factors for participating on projects as there are people. There are many complex emotions that come into play, and this entire mix is constantly changing. It would be impossible to capture the essence of this complexity and to provide a generalized solution on par with a description of practices and team behaviors. In order for the description of the approach to be attractive, it needs to be simple enough to be easily assimilated without losing the audience’s attention.

Secondly, most of these branded approaches got their start with a handful of people who had success on a handful of projects. While there may be some discussion of elements such as trust and fearlessness, these are generally dealt with through hand waving and generalities, not explicit practices that are defined. For the most part, concrete emphasis is on the practices themselves. In almost any retrospective I have been a part of, discussions about what worked and what needs to change focus almost exclusively on the team practices. Things like defining scope and planning, design practices, implementation and validation approaches. Even if symptoms of dysfunction such as the team not getting along are raised, the solution space generally consists of practices we see as within our control – those same team practices described above.

Implicit in the success of most teams is the relationships that have developed among the team members. Indeed, when you are asked to think back and describe the approach used on a project that you would have considered successful, there is a good chance that you would describe elements like a change management process, or nightly builds, or test-first development, or tactical access to a customer. If you look deeper, though, and consider how the team worked with one another, you will find other, more important elements. The team surely cooperated well with one another, demonstrated a level of trust and shared a common goal. Everyone felt like they belonged, and actively participated in working toward that project's success. In working with teams, the one common element that everyone has identified as part of their successful project experience was that they had fun.

Nothing about tools or technology, nothing about lifecycles or methodologies. These are necessary, but insufficient. Success is primarily dependent on the relationship between the team members. This does not simply go without saying. It is absolutely critical, and needs to be consciously managed. As a team member, it is all about you.

There will be relationships between team members whether or not these are consciously observed or managed. Regardless of our selected approach for developing software, people will have to interact with one another, and each of these interactions will be successful or not based on the trust, respect and shared vision of the participants. If all of this is left to chance, how much of an impact can one selected approach have over another?

If we really want to improve the way we develop software, we need to start by understanding the team itself - what each participant brings to the table. We need to bring all this out into the open, discuss our goals, reflect on our cultural distinctions, celebrate our combined strengths. The better we understand each other on the team, the stronger our trust will be, the more genuine our relationships will be, the more effective our interactions will be. With a consciously managed inventory of our skills, experiences and attitudes, we are better equipped to select which approach will be most effective for completing our projects, and indeed how we should deploy this refined approach with the team.

This all takes time, to be sure, but consider the cost of miscommunication, disappointments, broken trust and other forms of interpersonal dysfunction on most projects. In that light, the effort to better appreciate everyone involved on the project starts to look much more like an investment after all. - JB [top]

Filling the Toolbox (Compendium 6.47)

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.

In the technology world, there is certainly no shortage of tools, and more become available all the time. As geeks, we love our gadgets: our utility belts are stuffed beyond capacity. The calculators of the ‘80’s were replaced by the PDAs of the ‘90’s. There were the slide rules before that for those of us who care to admit it. The beat goes on.

Project managers can sling a mean Gantt chart, analysts deftly wield their class diagrams and ERDs. As we expand the notion of tools from the physical devices to the conceptual ones, the options available to us increase significantly, the number of intractable challenges diminishes. Problems arise, though, when we learn a new tool and suddenly believe we can now fix anything.

If a tool is one way we can get something done, one way to achieve a goal, there are a couple of important considerations. First, it is likely that there is another tool available that is just as reasonable to achieve that same goal. Particularly as we consider conceptual tools, there is rarely a situation that must be resolved using one specific approach: quite often, there are a number of approaches that will suffice. Second, all tools will have their constraints and limitations: there are some situations where a particular tool is only marginally applicable, some where use of that tool is downright wrong. I can’t think of a failure mode for a VCR where a hammer makes sense.

We get into trouble when we become proficient with one tool at the expense of all others. There are many project managers that will dive into Project at the first hint of trouble, and CFO’s that will do the same with Excel. Analysts can fall into the trap of thinking Use Case for everything they need to understand, every role in an organization seems to have its default tools. For most complex jobs, though, it is not a question of which tool makes the most sense, it is more a question of what variety of tools do I need to deal with all elements of this problem, and what is the most reasonable order for applying them.

The products we develop today are at least as complex as houses or automobiles, sometimes more so. We wouldn’t think of trying to understand one of these with a single analysis tool, or attack every development problem with a single implementation solution, but in the software world this happens on many projects. While we can tinker with backyard sheds and go-karts, our skills and repertoire of tools will be exposed as lacking when we try to scale up to real world problems. Many shops have discovered the equivalent of that Ikea hex key, and struggle with many challenges where that key doesn’t fit.

Whenever we run into a situation where we have a problem that doesn’t easily yield to the tools we are most comfortable with, we need to step back and reconsider rather than attack the problem more vigorously with the same approach. It is usually a safe bet that for any problem we encounter as we are learning about our product space or implementing our solution, there is a tool that exists that fits that challenge very well. We need to constantly appreciate and learn how others attack and solve problems they face. If we are stuck in a rut, we are probably applying the wrong tool, and we should step back to reconsider our approach. - JB [top]

Recognizing the Structure of Power (Compendium 6.45)

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.

As with other sessions at the conference, the setting was experiential, and much of the structure was left to the participants. In this case, we were split into groups and to come up with a definition of power that worked for the whole group. What made this interesting was the meta-request, that we capture all the examples of use of power during this exercise. There were the examples one would normally expect, as someone would get the ball rolling with a suggested approach to solve the problem, or someone might break into the conversation to be sure that they got their point across when they really wanted to. There were also examples that were not so obviously application of power, as some of us consciously chose to remain silent to increase the pressure to get to closure, or the weight we felt on our shoulders as people from another group innocently came to observe what we were doing.

We wield power through our actions, our gestures, our words, our mere physical presence. Sometimes that power is wielded by what we don’t do, rather than what we do. Indeed, anything that can influence the senses or expectations of others can influence the turn of events. Showing up to work on time, taking sides in a discussion, not choosing to run that set of regression tests after the last change. Power is applied in degrees: it is not a boolean on or off, but rather a broad scale of application. We can be heavy-handed in trying to influence a situation, or we can let off on the gas if we see that the light ahead will be turning red before we get to the intersection. While we normally think of the obvious application of power, it is the more subtle forms that can be more influential – as in a musician that conveys just as much meaning with the rests as she does with the notes. The please or thank you, acknowledging a colleague for a job well done.

Most of us go through our lives with little conscious focus on the application of power, and little awareness of the measured use of power that takes place around us. Indeed, we are often only obliquely aware of the power of our own actions as we work with others, and don’t understand how our unconscious application of power can have both positive and negative effects on those around us – and on ourselves. Often without conscious application, it is the negative effects that will predominate. With focus, though, we can understand many elements of power, and learn to better harness power to everyone’s advantage.

For one thing, we can start to take more control in situations were we may currently feel helpless. When we start to recognize we have choices, when we consciously decide to wield power to do things that are more congruent with our values, we can avoid many of the stresses that otherwise might take hold. With practice, we can learn to recognize the application of power by those around us, and we can improve our ability to consciously manage our own approaches to using power and influence. Use of power and influence can be congruent or not, and we need to be careful to avoid the use of power at the expense of others.

We were asked initially in the session how we would feel if we knew an adversary had ten times the power we did. My first reaction was that this would be a bad thing, but on reflection, that knowledge is power in itself. Having this knowledge allows me to potentially identify ways to leverage that other person’s power, identify areas where we have a common ground (and I think we have that common ground more often than not) so that this person’s immense power could be used to magnify my own influence. When combined, our power would be daunting. Using our own sources of power increases our influence linearly, while combining our power with others increases our power exponentially. To take a group and harness all their power in the same direction can be an awe-inspiring experience. I have seen this occur several times in the software industry, but its rarity is one of the reasons that it stands out so distinctly from the norm.

Everything we do or don’t do, say or don’t say, is an expression of power. This is true whether conscious or not in application, or positive or negative in its form or result. We need to cultivate our awareness of the power we wield, harness its strength to influence change in a positive way, and understand how we can collaborate with others in a way that multiplies our power many times over. As a driver for change, for influencing a desired result, the conscious use of power is one of the most effective tools we have at our disposal. - JB [top]

The Complexity of Change (Compendium 6.44)

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.

One of the best introductions to the Satir model comes from Steven Smith, one of the hosts of the conference. The model is simple and clear, but most importantly makes sense because we can instantly see ourselves in the model. We naturally have an affinity for the status quo, and for myriad reasons, change is something we detest. Quitting smoking, traveling to exotic places, developing software in a way that differs from the way we’ve done it in the past (in some places, that 'past' can span decades). There’s the unknown, the anticipated chaos, the displacement from our current way of doing things. It is easier to just stay where we are, even if we can envision a better place at the end. As a physicist I know how to express the strength of inertia through formulae. From the perspective of change, we all feel the inertia keeps us in our place of familiarity, whether or not it is comfortable.

Change is far more than simply deciding to do things in a different way. The greater we appreciate and understand all the complexities and nuances, the more effective we can be at fostering effective change at home and in the workplace.

Most critical of these issues is the recognition that change is embodied in a clear sequence of stages, and that for meaningful change to stick, you can expect to go through all these stages in turn. Deep change will drop us out of our comfort zone, our status quo, and carry us through a stage of disruption and chaos. Quite often we will see this as bad, and leap back to our old ways, back to that soothing place of familiarity. It can take significant effort to continue on our path, to find some mechanism or transforming idea that allows us to recognize the value of seeing the change through. If we have done well, we will reach a point where we have been successful in changing. This can be a tough journey, and at each stage of change we can find new reasons to fall back to where we started.

Often, though, we attach change in ways that make the journey tougher than it needs to be. At the conference, it was interesting to note that several people saw their role as one of a change 'inflictor', and indeed this is the way many people foster change as consultants ("You guys need to adopt Scrum...", or "I can help you get to CMMI Level 3..."). While simply recognizing the sequential nature of change is important for accepting that it’s not as trivial as switching on a light, there are other ways to simplify things, to make change easier to swallow.

A critical element of driving successful change is controlling the magnitude of change. Often, in software development or in life, we take on ludicrously large elements to change: we’ll go from a totally chaotic ad-hoc approach to development (often in the form of every participant using their own preferred successful approaches from previous jobs), to a complete single way of developing software. Great in theory, but extremely disruptive in its implementation. Whether agile or not, this complete system is made up of a collection of individual elements, each with their own change profile. Some of these may have little chaos and huge return, while others may be extremely chaotic, and actually have a net negative impact. Throw them all together, and you will have washed out much of the value of the best elements, and imposed an overall change that can be quite daunting. The team can easily find the status quo quite attractive in comparison. We need to find those atomic elements that will provide us the most value with the least disruption. If we select them correctly, we will find far less pushback, faster adoption, and we also benefit from demonstrating to the team that this change stuff doesn’t have to be so painful after all.

The other side of simplifying or making change more attractive is cranking up the engagement from the participants. Last time, I talked about the challenges of jargon as a barrier to adoption: we have to be careful to present the potential change in a way that is clearly understood in terms that people understand. In addition to this, we need to avoid simply handing this change over as a task for them to do. While we may not see these elements as disruptive, this is because we have already made the required journey, we have already internalized the value and overcome the disruption. Any change will be easier if the participant is carefully supported, given the time to acclimatize to the different way of doing things, reminded of the value of the change in making their life easier. Each participant needs to understand how the change brings them more closely into alignment with their own value system. They need to see what is in it for them, and this attraction will vary dramatically across the team.

In the minds of most people, change is frightening and diametrically opposed to remaining in the status quo. If we are careful in how we present change, selecting the low-hanging fruit and fostering the change through our teams, we can dramatically reduce the barriers we often face. Indeed, we can get to the point where change becomes an attractive ongoing way of doing business, we can become a true learning organization. We can remove the apparent dichotomy between change and the status quo. - JB [top]

Engagement Beats Handoff and Jargon (Compendium 6.43)

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.

A few weeks ago, I wrote about a company that has had great success in developing systems working to a fixed price where others have failed, and delivering on expectations. One of the critical strengths they bring to the table is an uncanny ability to understand the problem space through strong analysis techniques, but there is more here than meets the eye. If we look closer, they are not just building up a massive class diagram and passing it back to the client for validation. They are doing something that gets to the essence of successful collaboration – they are building the model of the problem space along with the engaged client, in close collaboration, in real time.

This serves a couple of purposes. First, as the client is engaged in the effort and can see their contributions affecting the outcome of the analysis in real time, they are more involved, and have a stake of ownership in the results. This is absolutely critical, and is a technique that can strengthen the production of any artifact that involves a number of different stakeholder communities. Everyone can say "this is my product".

More importantly, though, is that this is a situation where the client is getting their first exposure to the notation being used to produce this model. It is pretty safe to say that until this point, UML has not been part of their vocabulary. Indeed, they probably still have no idea what UML stands for, and don’t know any of the back story of how this set of notations grew out of an industry consortium that finally got together to produce a standardized way of modeling aspects of software systems (instead of each guru having their own perspectives represented in a set of views named after them). I’d say they really don’t care even now about all this, and shouldn’t be bothered with it – they don’t need that knowledge to do their job.

Instead, they had someone approach them and ask questions about their system, their way of getting the job done, and the challenges they have had in the past. As they explore the situation in this conversation, this outside person started to capture their responses on a whiteboard (virtual in this case), with a few boxes, some lines between these boxes, a few labels, maybe some annotations about how many of these things could exist. As each new type of element appeared on the screen, it was done in the context of what was currently being discussed, and had immediate relevance for the client. It was clearly a way of capturing exactly what they were expressing, and they could provide immediate feedback about whether it made sense or needed adjustment. Very quickly the model grew, and it formed the basis for discussion and continued growth. Inconsistencies appeared where they were hidden before because of this new way of looking at the system as a whole, the client quickly identified where there were holes in the model, and the analyst could see whether they could develop the system from this understanding of what the end point should look like. A couple of hours (literally, in this case), and the client still does not know what UML stands for.

Compare this to how we often conduct business with other communities. We will often develop our understanding of the system, using these same diagrams, but based on our understanding of what we think the system should be. We’ll then hand the client this completed view, maybe even reference UML or call it a class diagram or database schema, and ask for feedback. Put yourself in the shoes of the client at this point. You might recognize a few of the labels, and with some effort be able to infer some of the rules governing cardinality or relationships between the symbols, but the overwhelming feeling you experience is just that: you are overwhelmed. It is almost impossible to provide deep, insightful feedback, as there is just too much to absorb at one point. From here, as analysts, we take this shallow feedback as either our model is pretty good, or the client isn’t that interested in providing useful feedback at this point. We forge ahead and build the system, and we get stressed when the feedback at the end is essentially that the system is wrong. If it wasn’t for our client, we’d get a lot of work done around here.

You’ve probably been there. We do this all the time in software development, and it is not just with the end user. We have developed a vast array of terminology shortcuts, of notations, and of patterns that allow us to express ideas within our community in a concise form, but we stumble when we try to communicate our message elsewhere. We often fail to recognize that even within the software development world, communities that can share a short form of expression often have to be trained or grown over time: there are still many software developers that don’t know what UML means, or don’t understand the distinction between an 'extends' and 'includes' notation on a use case diagram (hence the suggestion by many that we should keep things as simple as possible). Most people would have to refer to the Gang of Four (the authors, not the musicians) to understand the nuances of a Decorator Pattern (I know I would). Throw on top of that the acronyms that most shops develop for their products, and from outside the software arena, we have moved quite a distance away from commonly applied English. Use this with other groups and feedback will sound a lot like "huh?"

If that Gang of Four reference flew by you, you've just been victimized by this very problem.

We need to use our terminology only when it serves us to facilitate communication. As we expand our engagement to other teams, we need to drop the jargon and collaborate in a manner that will allow us to get the information we need (and to provide the information back as necessary, without the clutter). If we see that use case analysis is probably going to help us understand the problem, it can be dangerous to approach a user group and say "Let’s do a use case workshop". Indeed, I experienced pushback against use case terminology this week from a technically savvy hardware person – it was seen as 'software-speak'.

Instead, engage them in a conversation about their systems. Keep your understanding of the structure of use cases in your back pocket, but talk in their space. "So what are some of the goals you would want to achieve using this system? What other people or systems would need to be involved to? How would you go about working with the system to achieve that goal?" All the while, you are building a use case diagram, explaining that box as the system boundary, what an actor is, and capturing their goals in those funny ovals inside the box.

Over to another flip chart. "Okay, lets take this first goal. How do you see working with the system to achieve this goal?" Start drawing swim lanes, maybe use some post-its to capture the initial flow of actions and responses. Explore some alternatives, add other lanes as necessary as other actors get involved in the use case. More flip charts, more use cases. Ask about what could go wrong (exceptions), or what order things need to be done in (pre and post-conditions) along the way, but park the jargon at the door. Your client will love you for it.

We’ve developed a powerful set of notations and terminologies to express the different perspectives of the systems we build, but we need to recognize that this is a language that we have developed for ourselves, an internal shorthand that will only fluster others that have not been indoctrinated (and many have no interest in the indoctrination at all, they have other things to do). If we learn to read our audience and use these notations as a means of sharing understanding and engage others without the noise of our own jargon, we will all be much better off. - JB [top]

Fine Wine or Crusty Loaf? (Compendium 6.37)

I was swapping e-mail with someone recently, and in one response he lamented that his age was a factor that might make organizations less interested in him (my guess is he is a few years older than me). I know he has a similar breadth of experience as I do, having worked on the same large system as me, though at different times. He also worked with a couple of other organizations that I have dealt with as clients.

His comment threw me for a loop. While there aren’t too many professional athletes in their mid 40’s or beyond, I don’t see the same breakdown of utility for knowledge workers. In fact, I would say that it is just the opposite: as you get older, you have more time in the field to learn from your mistakes, to expand your knowledge, and to continuously gain and grow from your collected experiences.

It is not age that is a driving factor, it is attitude.

With youth can come an exuberance and confidence to take on the world, but this needs to be balanced with a recognition that there is far more to be learned than can possibly be covered in an undergraduate curriculum or a few years on the job. You can’t distill years of real experience into an MBA program, and in reality, degrees and certifications should be viewed as a learner’s permit – they provide the basic foundation for further study in a discipline, and they qualify the holder to participate in the field, but the learning is far from over.

Sometimes that exuberance can be costly, when it turns to arrogance. Caution to the wind, full speed ahead. It usually doesn’t take a lot of time for the school of hard knocks to come along with a dose of reality. Just ask almost anyone that was a CTO in their early twenties during the last boom.

It could be argued that the younger people in the industry are better with the latest languages and platforms, but this is more a function that they are more likely to have recently graduated, where emphasis on these elements is strong. For every young graduate that can sling some mean Java code, I know a seasoned veteran that knows the syntax and recognizes the pitfalls of any technology. Give me the wise, experienced veteran.

With age, we have an opportunity to gain from the wisdom of experience, though not everyone takes that opportunity. Through the years we learn to recognize when something really is too good to be true, it becomes more difficult to snow us with a rationalization that just doesn’t fit the evidence, and we can more readily perceive the difference between the difficult and the impossible. That is, if we carry the right attitude with us. And yes, I have worked with some youngsters whose maturity and apparent wisdom belie their age. They are a pleasure to work with, and are a rare find.

It is not age that makes someone an unattractive candidate, but rather a number of factors that are often associated with age. People can become cynical over time, they can be stuck in their old ways of getting things done, they can lose interest in continued learning. People will sometimes grow weary of the treadmill. Generally associated with age, but I’ve seen the same characteristics in people of all ages.

We will all grow old, time marches on. The distinctions come in whether we take advantage of all this time: whether we learn from our mistakes, whether we continuously focus on personal growth. Hell, I’ll be 50 in a few years, and I’m still not sure I have peaked out yet. I’m still inquisitive, more hungry for learning than I ever was. As long as we stay engaged in our activities, as long as we have something that drives us to ‘get to it’ every morning, we will retain a youthful attitude.

At some point in your future, will you look back and see your ageing process as developing a fine wine, or leaving a crusty old loaf of bread to grow moldy? It is a personal choice. - JB [top]

Selling (Compendium 6.36)

Some things sell themselves. Tell an eleven year old that Apple has a new iPod on the market, and she’ll save her allowance money for months. The same goes for seven year old boys and Pokemon cards. If you have kids around that age, you will certainly understand where I am coming from.

The same principle holds true in the software industry. Tell a young group of developers that you are going to give Scrum a try, and you are not likely to see a great deal of resistance. They are all over it like...well, pick your favorite attraction metaphor here. Get a bigger group of more established (read...older) practitioners and wave the CMMI in front of them, you will often see a similar response. Give almost anyone in the industry a software tool as a means of solving a problem they are dealing with, and...you get the picture.

The problem is that it is not quite as easy to sell these things to everyone on the team. Simply waving the brand around is insufficient to capture the entire audience, and you need to engage that whole audience in order for many practices to truly work. There is still hope for bringing good practices into your project, but you need to step away from the hype.

Senior management and many marketing people aren’t interested in Agile approaches. In fact, from what they have heard they are probably afraid that they will have less control and visibility into what is being built than before (these rumors are likely to have come from weak implementations of good practices, unfortunately). On the other hand, if you talk about giving them a continuous stream of new features, keeping the product running so there is no big-bang integration, and giving them a voice in the prioritization of these new features, you will hook them quickly.

Talk to an end user about a use case workshop, and their eyes will glaze over. Ask them about the different kinds of users for the product, what each of these users will want to achieve, and dive into discussions about the steps that make the most sense for them to interact with the system to achieve their goals, and you will have an engaged crowd. You can even discuss alternative ways they might achieve their goals, what they might expect when for some reason they can’t get to where they want to be, and what state the system should be in before you get started and when you are done, and you have pretty much covered the breadth of use case issues (but you haven’t scared them off with the terminology).

Tell a development team you are seeking a CMMI rating or ISO certification, and you will have a bunch of disillusioned people expecting to waste much of their precious time building needless documents (again, perceptions based on experience can be strong). Talk about getting together to agree on an approach that will improve predictability on your projects, simplify planning, ease maintenance grief and shorten schedules to boot, and you might get them to sit up and take notice.

If you have a challenge with a co-worker and suggest that the two of you walk through a six-step approach for conflict resolution, and their opinion of you will likely drop lower than it already is. Head into the discussion ready to learn something about the other person’s perspective and get them to acknowledge that you really do see where they are coming from before proposing solutions to the challenge, and you’ll be amazed by the connection you make.

Whenever we work with others, we need to sell reasonable approaches to solving problems first by understanding who our audience is. There is a strong chance that they are not motivated in the same ways you are, and it is critical that you know WIIFT – what’s in it for them.

Once you know that you are well on the way. Pitch to their needs, show them how these approaches address their needs, and the pushback that often occurs with change will dissolve. As an added bonus, this approach will help keep you honest about doing the things that are right for the team as a whole, and prevent you from being swept up in the hype surrounding trends that might happen to be in vogue today. When you are selling, you need to play to the needs of the audience. - JB [top]

Harnessing Down Time (Compendium 6.30)

We all have far more that we would like to get done than we have available time to do these things. This is true in the workplace and outside as well. Wouldn’t it be great if we could take advantage of all the down time we seem to have during our day to accomplish more?

Think of all those moments that seem like stolen time, where we are waiting for someone to arrive or something to happen. You actually get to a meeting or training session on time, but it takes others another 10 minutes to show up, usually rushing from their previous meeting (remember, though, that when the shoe is on the other foot, you are the one stealing time from them...). You may have made it through all the security checks at the airport only to find that your flight has been delayed by another hour. Perhaps you are building your system, and the entire process (which is automated, right?) takes 20 minutes or more.

We all have moments like these, every day. There are a few steps to take so that we can actually get things done during this time, and end up with a lot more accomplished at the end of the day.

To start with, you need to have a list of things that need to get done. Not something that is committed to memory (as most of our lists are way too long for that), but something in writing. My preference is the task list that is synchronized between my laptop and PDA, but a paper-based solution can be just as effective. It is important to have everything on that list. Just as it is important to manage all potential drivers for change on software projects on a common basis, the same holds true for your task list. If you keep some items to do on Post-its stuck to your screen, some as e-mails left in your inbox, some in your head and some on a task list, there is no way you can manage them effectively.

You need a list, just one comprehensive list. The nice things about managing it electronically are that I’m not constantly carrying forward items as I used to when I used engineering journals, I can automatically handle repetitive tasks (I have one for this newsletter that fires off weekly, for example), and it is easier to sort and prioritize the list. The bigger tasks on the list will usually be too large to wrestle with, and often get continuously deferred, even of they are quite important strategically. Break down the big ones into smaller, manageable chunks.

Sort and prioritize the list in a way that works for you. Some will have hard deadlines, some will be dependent on others before they can be started. You may find it valuable to estimate effort in some way, I tend to just break the bigger ones down until each one is something I can finish in an hour or two. I find that going to more involved project management approaches is overkill: I never build a network of dependencies between tasks, though there are times when activities on my task list have been derived from a more comprehensive project plan that sits elsewhere.

If you have all your things to do on this list, it can then become the driver for what you plan to accomplish for the day. Start each morning by reviewing the list, identifying the ones you want to bite off during the day. Ideally you can carve out chunks of time with specific things to get done in those slots. Don’t plan out your whole day, we both know that there will be surprises and interruptions to deal with.

There will always be some tasks on your list that can be done in fits and starts, with proper preparation. Ideas for newsletter articles, reviews or edits of some of your peer’s work, catching up on that stack of reading that never gets smaller, killing off the new items in your inbox. Some things will require that you are online, but many are simpler to accomplish.

I always keep my task list close at hand, and always carry a file folder with the things I would need to work on things if the moment arises. A draft of a paper that needs reviewing is in there, as is a magazine that arrived today and a couple of business cards for people I need to contact. Depending on my frame of mind and the length of time I have available, I could attack any or all of these, because I sat down at the start of the day and made sure that I had these things with me.

I’m not so stressed anymore if someone is late for a meeting, and when my flight was delayed last Sunday, I managed to get quite a bit done. It takes a little organization and preparation, but I find that I’m far more able to stay on top of things that otherwise would seem to pile up. Knowing that these opportunities will arise during the day, doesn’t it make sense to take advantage of them? - JB [top]

Judgment (Compendium 6.29)

In the early stages of relationships, when there has not yet been enough investments of time for deep roots to take hold, breakdowns can occur for many reasons. Certainly prejudices can stop the relationship from ever getting off the ground, and even rumor and innuendo can waylay progress. While it is likely that most of our relationships won’t endure the test of time, most are ended before deep roots have formed, so there is a limited sense of loss.

As time rolls on, though, these roots do form. For relationships that have grown over years or decades, in the workplace as in personal life, there is a richness of shared experience that can deepen the bonds. That stated, we need to be careful to always appreciate that even if we are in the same place at the same time, experiencing what seems to be the same thing, we are each experiencing it from our own perspectives, and these perspectives will never be identical. No relationship is ever immune to being broken without this appreciation.

Our perspectives are formed based on our entire lifetime of experiences and attitudes that are formed from those experiences. Perspectives are very complex beasts, to be sure. Two people can see the exact same event, from the same physical viewpoint, and walk away with two very different perspectives of what happened. The closer the people are to participating in the event, the more personalized these perspectives will be. If the event involves two people interacting with each other, the difference of perspectives will often make the same event appear as two entire different ones.

All the more so if we cannot appreciate the other person’s perspective. If we draw conclusions about what the other person was thinking or feeling or intending based solely on our own frame of reference, we can easily pass inappropriate judgment. No matter how deeply rooted a relationship is, this judgment can erode the strength of the relationship. Left unchecked as a flawed assumption, the relationship may never recover.

In the judicial system, we lean on experienced, unbiased, and objective judges to arbitrate cases that make it to court. They generally get to that position after some time as lawyers, being trained in what is right and wrong, based on written law. Working within a system of right and wrong, they will pass judgment only after hearing both sides of the argument and determine that there is clearly an appropriate conclusion. In most jurisdictions, we are innocent until proven guilty, and we don’t draw conclusions based on assumptions about motives or feelings or intent. We seek out reasonable evidence before we find someone guilty. I personally like living within this system.

Unfortunately, most of us don’t deal with our own relationships that way. We seldom have the complete picture of what has occurred (as would be drawn out in a court of law). We are often too close to the action, with a personal stake in the outcome, and will pass judgment based on our own very biased perspective rather waiting to objectively seek out all perspectives.

It is one thing to pass judgment on whether someone robbed a bank, another to determine whether the offence merits our being offended at all. Much of what is governed by law is expressed in black and white, while interpersonal issues are often much more hazy. There are shades of gray, we’re not good at recognizing this so that we can extract the important deeper information, and we make hasty decisions.

Quite often we will deal with relationships in a guilty until proven innocent approach, not trusting others until they 'have earned it'. Other times, if there was an event that has offended us, we will break the relationship without ever uncovering the root of the behavior that caused the offense. Sometimes we fool ourselves into believing we have given the situation all we could to resolve it, while in reality we have only played it out in our own heads, from our own perspectives, so many times we are sick of it.

We throw our hands up in exasperation. "I give up trying to work with them", or "they are not putting the same energy into this relationship". More often not, you will here these same arguments from both sides, as neither side has really taken the time to understand all the perspectives. The mere fact that there is an 'other side' indicates that there is a bias that remains unresolved.

In most challenged relationships, there is contribution to dysfunction on both sides, and it is the failure to appreciate the other side, to walk a mile in their shoes, that is the root of the problem. We fail to appreciate that our behavior is offensive to others, or we don’t understand why the other person is behaving this way, perhaps assuming that they are doing so by conscious choice, while in reality they are likely unaware of the offensive behavior or even unable to control it.

For casual relationships, it is easy to walk away, to take our toys and go home. For deeper relationships, whether in the work environment or in personal relationships, the cost of arbitrarily or hastily passing judgment can be high, and there may be no getting over the accompanying sense of loss. Considering the investment and value of these relationships, it is worth considering whether it makes sense to pause before passing judgment. - JB [top]

Candor (Compendium 6.26)

I’ve always been convinced that failure to communicate is at the root of almost all challenges we face in software development. Process and procedures are a means of ensuring that we do the right things at the right time, analysis models help us communicate different aspects of our product in more precise forms than the English language can convey.

Beyond the engineering solutions to the communication issues, we also have to deal with the nuances of relationships and teamwork to provide us with more tools. Understanding individual motives and honing our skills in active listening and conflict resolution make it still easier to communicate, but there is still more.

As we engage as part of a team, it takes more than technical skills and interpersonal techniques to ensure we are all working together effectively. We need to engage others with candor.

Communicating with candor is more than merely telling the truth. Candor involves full disclosure of all information that you are aware of (and indeed, disclosure of the areas where you don’t have all the information), both positive and negative. In order to do this, everyone on the team needs to feel safe in their environment. If there is any lack of trust among the team, or any issues that have not been completely dealt with in the past, it can become too easy to hold back. Candor and hidden agendas are like water and chocolate (if not in that order).

While there are some individuals that have the self-confidence to be able to walk into almost any situation and speak with complete candor, it is a very rare team where everyone exhibits this trait. In the stages of team development (forming, storming, norming and performing), it is only when a team has achieved that elusive stage of performing that we have built the infrastructure of trust, of openness and caring that sets the stage for candor. For teams that have been there, most know that it is all too easy to backslide from this state. It takes effort to get to the performing stage, and effort to stay there.

Why is this important? It is at this stage where the team is firing on all cylinders, working together effectively as a group, and having a good time in the process. With complete candor, the shared memory of the team is more complete, more consistent. Fewer balls are dropped, and improved efficiency opens the door for the team to be more creative.

For those working within the agile principle that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation, candor is a must. If you are not consciously maturing your team dynamics to the point where candor is possible, your agile projects will be in grave danger.

It is interesting that the term candor has come up twice recently, with different groups, both in the context of working as part of a team. It is a term that is rarely heard these days, so to hear it twice in short order made it stand out all the more for me. It conveys the essence of what is necessary to reach the peak of performance for a successful team: to be in an environment where you can safely communicate with candor.

As you are engaged with your team, at all levels, have you achieved that goal? Are you able to communicate with candor? - JB [top]

Why I Write (Compendium 6.22)

People are often surprised when I explain that I put out a weekly (once a week, if not always on Sunday) newsletter, and have done so for almost 5 years now. It is admittedly a difficult effort to sustain at times, and there are times when I wonder if there remains value in continuing.

I see this newsletter as different from most blogs, in a couple of important ways. This isn’t a stream of consciousness thing, and I try to write something that is relevant to people that are in the business of developing software. Few readers would have much interest in how many bran muffins I had for breakfast, or that I had read or seen something interesting somewhere else. There are some very prolific bloggers out there, I wouldn’t suggest that I’m on par with them, or that there is a better or worse: we’re just different.

Probably the most important difference from the traditional blogs is that I’ve stayed true to the weekly schedule, rather than posting something whenever the muse hits. While this stems the tide on those occasions when I have a flurry of ideas, it also forces me to produce something even when I’m challenged to come up with a topic.

I’ve learned the hard way over the years that it is very important to keep to a schedule of practice if you wish to improve at something (what would I tell my kids about their need to keep up their piano lessons if I didn’t stick to my writing?). There was a point a couple of years ago where a partner wrote perhaps a dozen issues, over maybe a 6 month span. The most amazing discovery from this was not that I had a welcome respite from the weekly deadline. On the contrary, I found that falling out of the weekly habit actually made it a lot harder to get back in the saddle when it was my turn again.

Five years ago, I placed an article in the Cutter IT Journal, one of the better industry journals that you probably have never heard of (unless, of course, you have placed an article in it and received a free year’s subscription). At the time I had not yet experienced work with a professional editor, and the feedback I received for my first draft was devastating (also known as a six-pack evening). It took a while for me to overcome the initial shock and realize that the feedback was actually very constructive criticism. In embracing that feedback, I came to learn a bit more about writing effectively.

As I am finding out now however, the shock of having your writing critically reviewed never really goes away completely.

It was just after that experience that I started writing this newsletter, and perhaps 200,000 words later, it is still something that I look forward to on a weekly basis. Subsequent articles placed in the Cutter IT Journal went through a lot more smoothly, an indication that I am actually learning a thing or two. Practice, practice, practice, but the goals here encompass far more than simply getting better at writing.

When I started, there was perhaps a handful of topics that I could write about, and I initially thought that a weekly piece may be a bit too aggressive. What I have found is that there is no shortage of topics to write about, almost all of them are based on experiences I have with clients.

If I’m caught in a training session unable to reasonably answer a question, an article is a great way to step back, clarify my thoughts and figure out what I might have said in the first place (because it is a safe bet that the question will come up again in a future session). I’ll often write about behaviours I see with clients, both good and not so good (more of the latter, so the former really stand out), and I have found that these observations resonate with a wide range of readers, indicating that our experiences are rarely unique, despite what we may think.

I’ll often write as a means of discovering how I stand on a certain issue, though I try to be sensitive to the concern of stepping on too many toes. There are a few things that I have a pretty strong opinion about, but it is important to recognize that opinions do not equate to facts, and my views are sometimes not aligned with the views of others. Perhaps that is another difference from many blogs, where the blogger often doesn’t seem to care about the views of others. There have been a number of blogs that I have unsubscribed to after seeing one too many ad hominem arguments.

Yes, there is certainly the element of marketing in my blogs. A number of the issues have been picked up by the Cutter IT E-mail Advisor, and it is always interesting to see links from around the world back to the website. These clearly drive a large number of viewers to the website, and while I know that at least some business has come directly from my writing, it is more often the case that the weekly visit to readers’ inboxes is a gentle touch point that serves to keep me top of mind, should a need arise.

First and foremost, the goal is to provide at best a useful service, at worst an interesting diversion from an otherwise chaotic workday. I try to keep the content informative, and avoid the salesy pitches that can be found elsewhere.

Like a lot of activities that may seem to be a bit hair-brained on the surface, there are a wide range of reasons to invest the time and effort on a weekly basis. If I couldn’t find those reasons, I’d likely find other ways to spend my time. Just thought I would pass along the reasoning behind my doing this every week - I hope you are continuing to find this valuable in some way. - JB [top]

Decisions Not Made (Compendium 6.15)

When you get right down to it, we spend a lot of time every day making decisions. From the clear decisions of how we are going to spend our time, whether we are going to do this or that, to decisions that are not as consciously performed, like how we’ll make that first coffee in the morning or choosing our route home in the evening.

On projects, the decisions we make on a daily basis determine the outcome of the project. Some more than others, of course, but like a butterfly flapping its wings in the Amazon, many of our decisions have far greater impact than we might think.

Even more than those small decisions we do make, though, it is the decisions we often neglect to make on our projects that can have the greatest impact at all. it’s unlikely that this impact will be positive.

Many of the decisions we don’t make fall under the category of assumptions.

Assumptions never cease to amaze me in training sessions. When I set a group loose on an exercise, I rarely get a question about my instructions (even after I raise this very point). Far more often, though, when it is time to debrief the exercise results, many of the questions I have to field are actually about details that weren’t even understood up front. The group has forged ahead with implicit assumptions.

We all go through life, everyday, supported by a large number of assumptions. We build routines, standard ways of doing things to reduce the number of decisions we need to make. While chances are that these decisions were appropriate as a basis for our routine assumptions when they were formed, there’s a good chance we are running on a bunch of decisions that are now, over time, seriously flawed. It wouldn’t make sense to always question everything we do, but at least once in a while, we should step back and consider if our assumptions are still valid.

One great way of validating our assumptions when we are interacting with someone is to paraphrase what we thought we heard. If they can confirm you got it right, you’ve made reasonable assumptions.

On projects, another type of decision we don’t make are the ones where we simply choose the first good looking option that comes to mind.

We take the first words out of our end-user’s mouth as gospel rather than analyzing whether this is indeed an appropriate requirement. Our system design is usually not the one chosen after comparing a range of potential options and selecting the best, but more likely the first one that pops into our head. I would guess that few of us have given much thought as to whether a bubble sort or a selection sort would be more appropriate in a given situation after we had to answer that question on an assignment back in school.

We look back on these decisions and lament "why hadn't I thought of that?". It is usually better to select from a range of possibilities that we have generated than to just go with the first thing that pops up.

Still another type of non-decision occurs when we delay making a decision until we have run out of options, and there is only one way left to deal with an issue. This is often forced on us during projects as we discover late in the project issues that were injected in the early stages, but have been lying hidden, typically because we haven’t hunted them down. If we find a requirements flaw early, we have a wide range of approaches to fixing the problem, but when we catch the same problem a week before we ship, it’s far too late to adjust the architecture to address the issue.

Frighteningly, I know people that routinely use this as their standard time management strategy.

Finally, there are those decisions that are made without the right people involved in the process. A set of requirements written by an analyst, without consulting the developers for feasibility, the testers for testability, or sometimes even the customer for...well, you get the idea here. Taking the opportunity to decide on something when the person who should be involved is on vacation. Making promises that something will be delivered in a given timeframe, despite what you know the people doing the work would say.

This seems to be, sadly, making the proverbial "executive decision".

Outdated assumptions, taking the first thing that will work, running out of options, and not involving the right people in the decision-making process. Each approach can be devastating to your project, and we are all guilty of these on occasion. Which ones are going to come back to haunt you later in your project? - JB [top]

No Apparent Problem To No Actual Problem (Compendium 6.14)

However we would like to frame it: an approach to problem solving, a progression of learning, or simply how we grow over time, there are stages that we pass through along the way.

We evolve from no apparent problem, through these stages, to the point where the problem no longer exists. Some of these stages may pass by imperceptibly, while others may be stumbling blocks that we struggle (or fail) to overcome.

We start out blissfully unaware that a problem even exists - it is not even on our radar. Certainly in our youth, there can be a stage where we believe we know it all. In software development, this is the point where we have yet to discover that the end user has a challenge to overcome (often after they have begun to use our product). For many of us, this is where we were perhaps a decade ago with the issue of global warming. Today, even though few of us remain unaware of this issue, we are still a long way from solving the problem.

There are times when we hear about a new issue and meet it with skepticism that it is a problem at all. Perhaps we might even see the problem, but fail to see how it affects us. We can walk past the homeless in our own hometown with more of a feeling of disgust than passion, for example. A friend of mine recently noted, in this context, that "Where you see an addict, I see suffering."

The more we learn about a problem, though, the more likely we are to find that it indeed does affect us in some way. In software, a prospect with an issue is an opportunity to embrace, a disgruntled user of our product can teach us a great deal. With our gaining awareness comes the beginnings of personalization of the problem, and until this happens, we aren’t likely to devote serious effort to solving this problem.

For many problems, we can hit the point in our learning where the problem appears to be overwhelming, just too big to resolve. "I can’t possibly make a dent in that sort of issue, how the heck could I deal with that?" It can be easy to stop here, to use this as an excuse for not going further, and stay comfortable with our current habits. While this is not often a barrier in aggressive business situations, it can be easy to lean on this as a means of not taking action on the deeper issues we face as a society.

With deeper discovery, we can start to appreciate that there might indeed be a solution to the problem, but we are still not at the point where we can grasp that solution. In seeing that there is solvability, though, our learning takes on a different dimension. We can analyze to break down the problem into manageable chunks (the old ‘eating the elephant’ scenario), and discover alternatives on how to address the problem.

We’ve started to personalize the problem and have even broken it down into bite-sized pieces, but now we find that the approaches that make sense to solve the problem are uncomfortable for us. We haven’t done this sort of thing before. At the same time that we are starting to become comfortable with our understanding of the problem space, we struggle with the discomfort in the solution space. The solution can mean changing the way we do things.

As we progress from here, we are consciously applying the solution, fine tuning and gaining more familiarity with our approach. We often make mistakes the first few time we try to do something new, but this is really just an indication that we are truly learning. How many times have you read something, thought you understood it, then find the real issues when you try to take it to the next level? How many times have you applied a potential solution to find that it didn’t really fit that problem after all?

Eventually, we start to warm to the solution, fine-tune our approach, and gain comfort in doing things this different way. Our effectiveness grows significantly at this point, as we transition from thinking about the steps that we need to take and can think more about ensuring that what we are doing is actually the right thing in the context of the current problem.

Finally, we become completely comfortable with the solution. We have made it to the point where our habits have been adjusted, and we don’t even have to think to apply the solution to resolve the problem. Indeed, the original problem, the one that we had to struggle to even understand that it existed in the first place, is a problem no more. Here, we have to be careful to ensure that our new effective habits aren’t over-applied.

All along the way, we have adjusted, and rewired our thinking. We learn every step of the way, and we all go through these stages. This is true for software development issues, interpersonal issues, geopolitical issues. Not all of these stages are straightforward, some are downright difficult for us to get over, while others never seem to give us a problem at all.

As individuals, some of us have difficulty seeing things in a new light to understand that problems even exist. Others are challenged to change existing habits and approaches. We progress at different rates through these stages, and being aware that it is a grand progression is valuable in helping us understand what we are really struggling with at any point in time.

For me, I’m perhaps half-way through the progression with the global warming issue, but in dealing with the homeless or otherwise marginalized, I’m a mere beginner. For any other issue I face, I can easily identify which stage I am at, and knowing this clarifies what I should do next to progress.

As I was typing this, my son came by and marveled at my touch-typing technique. I’ve been at it for over 30 years now, and for the most part (I’m still a bit of hunt-and peck fellow with my right hand, a legacy of using a mouse for too long) I have progressed a long way in this chain of learning. I certainly don’t have to consciously think about the steps of typing to capture my thoughts.

In our careers, in our lives, we all have a wide range of issues in various stages of being solved. Which stages do you struggle with? Are there issues that you have yet to acknowledge their impact? Are you still struggling with consciously applying steps to a task that should be internalized? How many problems do you remain blissfully unaware of? Which issues have you tackled to the point where they are no longer a concern? How can you take your learning to the next stage in areas you have been struggling with? - JB [top]

Technological Heart Attack (Compendium 6.11)

Whirr-click...whirr-click...barely perceptible. I wouldn't have noticed it at all, except for the fact that I was starting to wonder whether my computer was going to wake up at all.

Apparently not. Even armed with a half dozen magical boot sequences, there was no way that this computer was going to respond. Sort of like kids who have been up too late the night before, only with less talking back and complaining.

OK. Mind into overdrive. I had a full day training session the next day, I had a number of other documents in progress, and this was not the time to be playing around with a rebuild of a computer. Things were not starting well.

The bad start on the day turned even worse. The incremental backups that I thought I had been diligent about were soon found to be incomplete, and the PowerPoint that I had produced for the next day had vanished off the face of the earth. The service department took a look at the computer and determined that it was probably a hard-disk problem (...thanks for the insight, Einstein...), but they were out of stock, and weren't sure when they were getting more.

Throw on top of that my slide down a muddy hill on my backside as I went to pick up my son that afternoon, and I was in no mood to deal with anything else that evening.

My son and I goofed around a bit, I went to bed early rather than sitting in front of the computer until much later, and slept quite soundly.

Despite the hassles from the day before, I woke up feeling serene. Rather than racing around the house, I calmly sat down with my coffee and reflected on what I was going to do that day. With paper and pencil, I probably generated as much material in an hour as I had done in action-packed, technologically-filled days. How to recover from this challenge, what to do for the day's training, and a flurry of other ideas and solutions to nagging problems.

I went into the day's training without the safety net of PowerPoint and a data projector. At one point I could have pulled up Excel to demonstrate a point, but chose to go to the whiteboard instead. I actually enjoyed the session immensely. Participants agreed that it was refreshing to focus on each other, and the training became more relevant and beneficial for all.

Maybe there's something to this.

I had heard before that when people race around at breakneck speed, something akin to a heart attack can be nature's message to slow down. I know that I was running at a pace over the past few months that was clearly not sustainable, and it was always 'in a couple of weeks' that I would slow down.

Many people I spoke with were remarking about how crazy the pace of business has been getting for them as well. It was with a perverse sense of pride that we would discuss the number of balls we would be keeping in the air, even though I know that we're not really juggling. Maybe this is Moore's Law of Technological Insanity, doubling the pace every 18 months or so.

Looking at my own situation again, I'm taking this as a wake up call and an opportunity. My schedule is relatively flexible over the next couple of weeks, so it is a great chance to reconnect with people that I have been too busy to make time for in the recent past. I remember how relaxed I felt the morning after the hard-disk failure, when there was no way I could just dive onto the computer and get busy. I could actually achieve things without the latest Intel processors supporting me like some dual-core crutch.

I've learned that I can achieve in a work environment the same sort of serenity that I have experienced out in nature in the past. In the zone. It is something worth embracing proactively, before a technological heart-attack forces the situation. Technology has its place, to be sure, but it needs to be carefully (and consciously) balanced with common sense and rich human interaction.

I know the pace will pick up again, and I know that I have lost a couple of files forever. Maybe these lost files will help me remember the lessons of all this. I'm sure a new monthly reminder in my online task list to step back and consider my pace will help as well.

I'll shore up my backup strategy, I'll monitor my pace. Today, though, I'll make some fresh waffles and take the kids out to a movie. - JB [top]

Getting in the Groove (Compendium 6.2)

These days, we are hammered with more information than ever, and expected to get more done in less time. For most of us, this drives up the pressure to juggle a number of tasks simultaneously, in a frail attempt to meet expectations. We are busier than ever, and there is no end in sight.

Generally, it is safe to say that this approach to working is not working well. While we are always busy, the fact that a lot of our time is taken up with context switching as we divert focus from one thing we are working on over to something else that pops up prevents us from being very productive. We can be great at juggling 5 or 10 things at a time, but we often find at the end of the day that we have only achieved closure on one or two of them, if any.

On top of the context switching that robs a great deal of time is the problem that much of what we are doing isn’t important. As Steven Covey suggests, most of us are caught up in the tyranny of the urgent, things that seem to be important (at least to someone), but really aren’t that important in the overall context of what we are trying to achieve.

We finish the day exhausted, barely taking the time to scarf down something for lunch, and have nothing to show for it. What to do?

We need to learn to get in the groove.

We need to organize, prioritize and focus our time so that we are working on the right things. These are the things that have strategic value for us. The tasks that, when completed, can provide tremendous external value, or can serve to simplify our lives so that we are less pressured in the future. We need to work on them, and we need to get them completed.

Here are a couple of steps to consider to be more effective with our time:

We need to make a distinction between the important and the merely urgent. Take all the things you are working on or have to do, and identify for each one how important they are, and how quickly they need to be done. Be careful with the urgency column – we are looking for when they actually must be completed, not when it would be nice for them to be done. Also for these, if completion of one task allows you to start another, the lead time required to allow the entire chain to be completed needs to be considered. If you look at where you are spending your time, you are likely to find that much of your time goes to apparently urgent tasks that are not really important: checking e-mail, responding to phone calls, surfing the web. Oops.
We need to clarify our priorities. With the list of tasks we need to accomplish and an understanding of their relative importance, we need to parcel out blocks of time that will allow us to achieve our important activities. Rather than blocking off a single huge chunk of time for the big tasks, break out chunks of an hour or so, not much more. The key thing here is to place them on your calendar, and to absolutely respect those times. One good practice is to book off times of 48 minutes, giving you an additional 12 minutes to relax before you forge ahead, or to get to your next appointment.
When we hit one of those strategic times, we need to set up the environment so that we can achieve our goals. Eliminate all distractions: set the phone to take messages, shut down your Mail client and IM, close the door, turn off the music. We want to ensure there are as few interruptions as possible. Set expectations with others that you are taking this time for yourself to be productive, and you will be able to get back to them after this period. If it is an emergency, they will reach you, but life will probably go on fine without you for an hour or so, despite what you might think. If your ego needs a boost, take 10 minutes to walk down the street afterwards, talking loudly into your Bluetooth headset...
Be sure that the problem at hand has been sufficiently broken down so that you can achieve something in the time available. For larger tasks, be sure that you have some mechanism for tracking where you are so that you can pick up and continue more readily when you start again. This may take the form of an overall checklist of elements to complete, a high level structure of the overall project, or something more detailed. Quite often, your first foray into finishing large tasks will be to build this structure so that you can track overall progress.
Take breaks. Focusing on a single task over an extended period is physically and mentally exhausting. Be sure to get up and stretch periodically, but don’t allow the breaks to become procrastination from getting the job done.
Celebrate success. For me, there are few things more satisfying than to have a complete list of things that need to be done, and to make strong inroads into that list over the course of the day. With mission accomplished, I can take a mid-day break for a squash game with a clear conscience, or call it a day at 5:00 and better focus on the family that evening.

Full-time access to information is one of the biggest time-wasters we face. How many of us have the Pavlovian instinct to check who sent us an e-mail each time we hear the little tone? Responding tactically to e-mails as they come in is the epitome of busy-work. We need to take charge of that interface, consciously choose when we will access the world (and when we will give access to us from the world). The same points can be made for the phone as well. If you are immersed in a task, focused and productive, one of the worst things you can do is to break your concentration by responding to what is likely a far less important issue. Studies have shown it can take up to 20 minutes to get back into the flow. This is a huge waste of productivity.

If we focus carefully on getting the important tasks completed in the workplace and in our personal lives, we can achieve greater things and have the freedom to enjoy life more fully. For most of us, there is plenty we can do to more effectively get in the groove. - JB [top]

Debate Without Dialogue Sucks (Compendium 5.51)

Back in February of this year, after attending a local presentation of the latest release of the Visual Studio Team System, I posted a rant titled Rigid Agility. In the post, I had expressed concern about a trend I had seen (and have seen more of since), where systems are being built to support tailorable processes with mechanisms to enforce movement through a set of states. I still see this as inherently non-agile in its implementations, despite the intrinsic value in the products and spin from the vendors.

A few weeks later, David Anderson (who was at the time the architect of the MSF methodology with Microsoft) posted a blog entry titled Who's Calling FDD an Oxymoron?, stating that I was not aware of the facts (he did admit that he was put up to posting from his boss). David has since moved on to Corbis, and seems to be taking a reasonable approach to introducing change there.

Here we are, 10 months later. His blog entry only came to my attention yesterday, even though I was explicitly named in a less than favourable manner.

Two very different positions have been posted. One based on my experience with a range of companies, tailorable frameworks, tool-based process enforcement, and a presentation of an early release of same from Microsoft. A rebuttal based on reading my posting and commenting, from someone deeply engaged in the framework and tool development for this very field. No dialogue, just two different perspectives. Bullets of opinion that can’t help but be taken out of context.

I have seen relatively few successful implementations of frameworks and methodologies. By successful, I mean practical for the business, commonly understood and bought into by the team, and appropriately followed for effective implementation, even when schedule pressures loom. As I have noted elsewhere, it’s not a concern with the original tool or framework, it’s a poor interpretation from the client side that leads to a weak implementation in most cases. This didn’t come across in my original entry. Taken out of context as it was, I could see David having trouble with my posting.

But enough of my opinions, that’s not what this rant is about.

The grief I have is that the explosive growth of blogging has given everyone an opportunity to voice their opinion, but there is precious little dialogue occurring.

David is likely more qualified to blog than I am, and I would call my newsletter perhaps a semi-blog. Sure there is an RSS feed, there is a somewhat random bursts of thoughts, and a feedback link at the bottom of each one. It is not run within a blogging tool, though, and there isn’t a threaded comments or trackback capability.

Whether we are qualified or whether this is a blog is not the point. The point is that there is a lot of stakes we all put in the sand, with little convergence. It is not just David and I, it is the entire blogosphere (sheesh, I detest that word as much as the spellchecker does).

Using this blogging mechanism, it is virtually impossible to resolve differences to come to a common ground. Postings are read without knowing the background of the post or the wealth of experience behind the words, people are quoted and referenced out of context, and comments tend to be polarized in the camps of violent agreement or violent opposition. I have seen the term ‘Blog Bile’ in a number of different places now. It can be as bad as those e-mails you wish you had never sent, but in a public forum, with permalinks.

Except for the ‘A-list’ bloggers, most posts on blogs will have only a few comments. If you are ambivalent, you likely don’t comment at all (for this newsletter, almost all actual feedback is in agreement with my perspective – I assume that the few prompt unsubscriptions are indications that I have rubbed someone the wrong way...). Everything is very one-sided, biased towards the site you are on at the time.

When we start from the position of making our own point, we are already going to be stepping on someone’s toes. We can’t possibly know the perspectives of our entire readership, except that the majority would be philosophically aligned, or they would head elsewhere to get their fill. Blogging then becomes more a case of building a following than converging on common understanding. Over time, our opinions are reinforced through the feeds we follow. The camps grow further and further apart.

I’m just as guilty as the next person with blogging. I try as much as possible to use this as a mechanism to clarify my thoughts on something I have experienced at a client site, to try to step back and to see if there might be a lesson learned here or there. There are times, though, when I