The Choice of Not Being an Elephant

Lou Gerstner described in his book Who Says Elephants Can't Dance?: Leading a Great Enterprise through Dramatic Change
how to make even a very large organization more agile, more adaptive to changing conditions. IBM had no other choice since some of their old business models stopped working. When I speak with people who were decision makers in the 1970s they unanimously told me that there was a time where the sales guys in dark blue dresses almost walked in to their customers and just said "sign down here". The customer had little choice.

Even if these stories are exaggerated - I'm not a sales guy but I'm sure their stories are always true! - there is one interesting aspect to this. I'm also mentioning this since I just came back from a trade show and there I spoke to a manager of one of the largest vendors in that particular industry. Somehow that person made me think of those stories from the past about IBM.

Like IBM in the IT industry this person's company is a key player in their industry. And the way the person came across was almost as if he was saying: "We know what is good for the industry, for you. Just do what we say, sign here and everything will be right." Sounds to me a little bit like "We are the center of the universe and all other companies better lign up around us."

The conversation left me wondering by when their CEO will write a book about how she had to turn their company around? Maybe they haven't noticed yet that the downturn in the industry probably requires them changing their attitude as well. But maybe I'm totally wrong and they still have full order books and the customers are lining up to the horizon. Not long ago, however the news were saying they are in the process to make a large number of people redundant.

That doesn't sound to me like full order books... The news of redundancies along with the attitude of the person I spoke to appear more like a company that isn't yet set up flexible and adaptive enough. Maybe reading Lou Gerstner's book helps.

---

Also check out "Manfred's DotNet Blog"

How Pair Programming Reduces Distraction

Pair programming is not for everyone. Some people love it, some people hate it. It almost seems there is nothing in the middle.

I'm more in the camp of people preferring pair programming. For many different reasons but I keep the discussion for a different post.

In this one I'd like to describe an example for what happened to me yesterday. I was working with one or my fellow software engineers, Jason, and while we were looking through a nasty C++ link problem we discovered a small item in an adjacent code area that we felt should be cleaned up. So I took a card and wrote it down as a story and returned back to the problem at hand.

Jason was surprised and made comment saying that by taking a note we would actually avoid being distracted. Although I have worked like that for years my colleague is newer to pair programming and that was probably the reason why he noticed what I did. For me it was just normal mode of operation. I did it unconsciously.

Based on my colleagues observation I think there is a lesson to be learned: First there is the specific case. When you come across something that should be done then just take a note (create a 'story' card). Don't let yourself get distracted. That way there is only a small interruption and then you are back on the problem at hand. Secondly, don't assume that the way you work is normal in the sense that everybody knows all the techniques you are using. It pays off to make yourself aware of this and sometimes it takes a good observer like Jason making a comment to become aware of what you are actually doing. So keep your ears open!

How fast do you adapt?

Here is a quote from today's online edition of The Wall Street Journal:

President Obama said that Chrysler has been "a pillar" of the industrial economy but that the company moved too slowly to adapt to a changing market.

(Source and more details: The Wall Street Journal, retrieved 01 May 09)

What caught my eye was the word "adapt". By the looks of it - I agree with the assessment - Chrysler didn't adapt fast enough. Now it has filed for Chapter 11, a bankruptcy process that protects it while going through a restructuring.

I'm not happy to see anything like that because many people will be severely affected in their personal lives. However, this is an (extreme) example of what can happen if you don't move fast enough as a company. Chrysler's product mix is no longer a good enough fit for what the market demands. The economic downturn just amplified that.

What can we learn from it? If we don't adapt fast enough to changing market demands and conditions it could mean very bad times for the company or the end of the company. Need any more incentive to adapt?

Can you make it right for everybody?

Yes, you can try as hard as you want. Don't we all try to provide an environment that allows people to grow and be their best professionally?

I think this is an important ingredient for a high-performing team. There are limits, however. For instance if you have a team member who isn't particularly keen to actively support changes. Not that I would be surprised by that. People have different personalities and while most are fine with change for a good reason occasionally there are people who resist all kind of change since they may have different preferences and experiences. And that's fine.

If you have a team member with an excellent skill set and huge amount of knowledge and experience that's fantastic. But what if that very person isn't able to proactively work with other team members to help them becoming better as well? What if you have a team member who doesn't attend the first daily stand-up meeting (aka daily Scrum) and comes in late once the meeting is over? What if on day two the same person comes in late but doesn't join the Scrum although it is still on? What if on day three the person is in the Scrum but doesn't participate actively? What if on top of that you observe that it even seems to have a negative impact on the rest of the team?

I think at some point you need to consider your options. Having one-on-one's for coaching is important and helps in most cases. Attempting to consider individual preferences is good, too. But once the overall team performance is affected, you need to act. And don't let anyone hold you hostage. As a leader and coach you need to keep in mind the future of the entire team and the project and objectives the whole team is working on.

An agile environment is not for everybody. There are organizations that work differently and it seems to work for them. Based on my experiences, however, I believe that agile principles work better if properly applied. In some cases this could mean that you may have an individual on your team who has a different perspective, and you should be prepared for that individual moving on. That's just fair and part of the overall change process for the team (and in fact for that individual, too!). Both the individual and the team are most likely better of.

If you have tried everything you can think of and still it doesn't work out, don't feel like a complete failure. You are not! Think of your team and about where you want to take them. And then adapt and move forward. Don't look back unless you want to learn from the past!

Projects - Do you need them?

In some companies projects are an important concept since they represent a piece of work, well defined at the beginning, maybe with a business case outlining the commercial benefits, with a project to sequence the tasks and to track progress, and with known deliveries at certain milestones and at a specific date. So far so good. There might be a problem with that, though.

What if your projects are too large? And by large I don't mean the projects that run for several years. More than a month can already be too large depending on your circumstances.

For example suppose you would like to be in a position so that you adapt as quickly as possible to changes in your environment. Customer's preferences can change. While maybe two years ago best use of limited resources was important maybe today it may be cost reduction to get through the recession.

For instance here in New Zealand the new fiscal year has started at 1 April. Many companies have taken this as an opportunity to rethink their position and options. I have spoken to many friends in different companies and to recruiters. It seems as if quite a few companies have made substantial changes triggered by the planning of the new fiscal year and as part of the approval process for new budgets.

There are many other events that change the environment in which you operate. And it appears as if those changes come in shorter intervals than maybe ten years ago.

A project of 2 months might already be too large as it might force you to lock in your team's capacity for that entire time frame. Then what do you do if something changes and you'd like to direct your team onto a different piece of work? Put the project into the bin?

Maybe there is a different notion, a different concept that you can use. What if you could split up the work required to be done by the team in even smaller chunks. For example in the company I currently work for we have many customers who work with us as a partner. Through this work, based on mutual trust and interest, we gain a lot of insights into how we can improve our products. Many small though very valuable enhancement requests are generated through this process, many of them only a few days work, a couple of weeks at most.

What if you'd look at the set of enhancement requests as a stream of small work items (one item batches) as opposed to projects that combine many such requests (large batches). Moving towards using smaller batches, ideally one item each, works better if you optimize towards processing those. Toyota calls this one-piece flow.

I think that is worth considering. Thinking small instead of massive grand schemes. There is more to that, in particular how you get started, what tools to use, and how to make it work. Stay tuned!

Navigating: What do you mean, captain?

OK, I can't speak for all industries but I can understand that you'd like to hear a few more concrete things you can do navigate these times. Let me share a few things from my software engineering perspective.

One of the options you could look at would be virtualization of parts of your development environment. An area that often proves to benefit is everything that has to do with testing. For instance if you have physical machines to test your application it might be very time consuming to set it up from scratch. You can speed this up by using an image that you can play back on the test machine. With virtualization you can become even more flexible or faster.

Some solutions allow you to create templates of virtual machines. Examples include a server with a specific database server product or a client machine with a particular browser version. If all it takes to select one each and instantiate it you can significantly speed up testing by reducing the setup time. And on top of that some virtualization products have features that allow automating a large variety of setting up virtual machines. And if you don't need them anymore just throw the VMs away. Just like that!

Another area that is worthwhile exploring for becoming leaner is everything that has to do with documents in particular internal documents. Look at all graphs for instance that require manual updating. Is there a graph that can be replaced by a simpler version or by a graph that is automatically generated and updated? Also, in some cases you may be able to simply some documents by replacing some text by tables.

Tools is yet another one. Are there tools that you can upgrade or add that will help your team to off-load more tasks to the tools? Do you use an out-date version control system? How about your automated testing tool? Automation and simplification are key regardless of whether you look at processes, tools, technology, or others. Can you simplify the design or implementation of your product? Can identify a technology that you use in your product that has outlived its usefulness?

There are plenty of options. Keep your mind and eyes open. Observe. Challenge. Put practices under scrutiny. Do they still make sense? Experiment. In small doses. Try out. Maybe you fail. But chances are that what you try will help you to focus even more on what is important in these difficult times.

And at at the same time you will become even more flexible in terms of how to respond to changes in these uncertain times. It's not the changes that hurt. It is how we respond to them.

I'm sure you got my point and are able to translate this into your industry and your specific situation. In particular in difficult times it pays off to have plenty of options for how to navigate through them!

Navigating Difficult Times

I chose the word "navigating" deliberately. The current economic climate is very difficult for many people and companies throughout the world. And chances are that you are affected in some shape or form as well.

It appears that no 'rule' that worked in the past applies to the current situation. Is that really true? I think it doesn't really matter. The important bit is that if you carefully choose an approach that lets you quickly respond to whatever is waiting for you around the next corner then you will be better off in all likelihood.

Some people and companies still try to come up with a grand plan for how to go forward. And as long as that plan is really more like a description of the direction and the principles to be used I think that is fine. But what good would it do to you if you would spend planning time right now on what you would be working on in 12 months time if all that matters is what you are going to do next month, three months from now, or six months from now!

Respond and adapt. Do both as quickly as needed (but not faster!). Instead of locking down your plans for the next 12 months use rolling plans (a planning tool, actually), e.g. for the next 3 months or for the next 6 months. Then update these plans on a regular basis, either monthly or triggered by new relevant information that warrants a revisit of your plans. If your plans cover 3 months they are much easier and faster to adapt to new insights than plans at the same level of detail that cover 12 months. Trying to update plans that cover a larger time frame tends to result in a lot of waste.

Navigating these difficult and uncertain times is definitely easier if you choose an approach that allows for much faster response and adaptation to the changing environment. At the same time you will be much better off once your markets start to improve again.

Encouragement

How do you know your team is making progress? And how can you support them in doing so? I think it is not that hard.

One technique is to observe what they are doing and how they operate. Keep a log of your observations in particular of successes and to a lesser degree of the failures. Of course not in the sense of big brother. But more in the sense of helping people realize where they are coming from, what journey they have already behind them, what successes they had, etc.

A few weeks ago I noticed that one of my teams started to use a backlog for prioritization and planning and a burndown graph for tracking progress. Recently I observed the first stand-up meeting that took place in the team area instead of taking place in a meeting room with everybody sitting down.

It is successes like these, and acknowledging these, that helps people seeing things in perspective and understand how they are moving ahead. Encourage your team if you see positive things happening!

MindManager 8

I have written about MindManager before (here, here, here and here). A few months ago I finally took the step and tried out version 8. I never bothered installing version 7 let alone trying it out after I have received comments that other users had similar issues (in particular performance) in version 7 that I observed in versions 5 and 6.

Now here is the nice surprise: Finally the software is a useful tool from a performance perspective. And I don't have to switch off hardware acceleration.

And apparently some more work went into improving the tool. It has become easier to to selection the handles to modify the curves representing a relationship between two nodes. In previous versions it sometimes took selecting other elements, then selecting the relationship again to be able to hit the handle. It's not perfect yet but at least usable.

With regards to the performance I need to be more specific. The load time is now a little bit of an issue. I sometimes think for a moment whether I really want to close the program since starting takes quite some time. I'm not sure what it is doing, maybe counting each bit of my laptops memory? Once it's loaded working with maps is very smooth.

There are items in version 8, though, which would benefit from putting some more thoughts into them.

The Outlook addin doesn't seem to be up to it's job. After I installed it Outlook became very unstable. After I disabled the addin things went back to normal. So in the meantime I'm not using the Outlook addin. And quite frankly: I'm not missing it! What exactly were the benefits of the addin?

Another area worth considering is how call-outs can be placed in a map. Sometimes I wish I could place them further out on a map or close to the node that it is related to. However, if that node has many children and all are expanded the call-out has to be above or below all of them in terms of vertical position. That way the call-out ends up to be very far away. The layout algorithm should allow more freedom for call-outs.

So bottom line we are now looking at a product that has reached the maturity that as a leader you would expect from productivity tools. A few minor areas remain that MindJet should consider. But for now MindManager 8 is a very valuable piece of software and I use it on a daily basis.

Note: I'm not affiliated with MindJet or have any financial interest in the company or the product. The opinions expressed in this post are entirely my personal view and are not paid for.

Changing People's Mindset

One of the biggest challenges with building and fostering an agile team is to change people's mindset. It didn't take me long to realize that brain washing is not an option, although it is very tempting!

There are different approaches. One approach is to wait until a good opportunity comes up. For instance if there is a particular bug that was extremely painful and maybe somebody suggests to add one more step to the build process.

That's your signal! Ask what that additional step is and ask for more details. Then ask whether the additional step can be automated. And if the answer is 'yes', then ask to add the automation of that step to the build masters backlog. You don't have a build master? Well, then you have just identified yet another item that the team should put in place. You don't have a build master backlog yet? Well, there you go! Yet another opportunity.

So bottom line: This one single event can trigger the introduction of no less than three agile techniques: Automated Testing, Build Master, and Backlog.

The more I work with teams the less I see the need to push things out. Instead there are actually quite a lot of opportunities that present themselves. In other words: You don't have to wait long until such an opportunity is there. And then you can suggest the techniques that worked wonderfully in the past.

And by asking the right questions, again and again, including "How can we test this?" and "How can we automated this?" you drive your message home. Asking the same questions again and again will make sure that people start to change their minds. I have seen it more than once. Just keep insisting on answers to those two and similar questions. Be gentle but insist on those answers. It will pay off!

Introducing new tools

As a leader you may find yourself in the situation of having introduced a new tool. And then maybe you observe that the team doesn't know how to use it. The reason might be that they haven't yet fully understood the underlying principles and so if they hit a road block they might not be able to adapt.

Resist to the temptation of then doing the work for them. It's not worth it and doesn't scale. Instead work with the team and demonstrate to them how the tools is supposed to be used. Then give them another try encouraging them to come back to you for more assistance if they get stuck.

For instance: Assume you have introduced a spreadsheet based tracker (for an example see the Agile Tracker) including a backlog and a burn down graph. One way of introducing this could be to identify a significant portion of the work that is very similar and of which the items can be counted. The resulting backlog may not contain all the full piece of work required. Hence you and your team don't know yet whether the work can be completed on time. Ask them to include every single piece of work that is required. Ask them to prioritize - or if necessary triage - all tasks. If they struggle how to do that, use a few examples to demonstrate the use of the tool (the tracker in this case), then ask them to try the rest by themselves.

I believe this works better than if as a leader you would be involved all way through. Be available when needed. Make sure it is understood that asking for assistance is not a sign of weakness but a sign of strength. Briefly discuss their experience so far. What went wrong? What worked? Then provide just enough to get them going again.

Some Non-Cash 'Carrots'

Leadership sometimes requires finding a 'carrot' to make things happen. Not always does the 'carrot' need to be cash or other monetary items. Let me give you two examples.

In one case I worked with development team that wasn't keen to try pair programming. However, I observed that they were using pretty old computers for development and they were not happy with the performance.

Therefore I purchased a couple of high-end workstation, shiny, brand-new and fast, along with really nice large flat panel displays. I also got a desk for each of them so it would be easy for two people to sit next to each other on those desks. And finally I announced the rule that these boxes are dedicated to pair programming hence the powerful machines.

It didn't take long for the 'carrots' to show an effect. Slowly first but then more and more people tried it. Some only for a short time, some for more. And eventually I had to get more such machines and the team was totally hooked.

In a different case I was working with a team that was sitting on very old C++ code. The available tool set was appalling, and so I gave the team the direction to get onto Microsoft .NET, in particular C# where a much better tool set would be available, including good refactoring support, unit testing, and better libraries. And all the memory management crap would disappear as well.

Again it was close to impossible to get there. And some of the reasons given were just fine. For instance there were significant technical obstacles to make that shift easy.

Therefore I asked one of the team members to find out how to move the native C++ code to Managed C++. Sure, that wasn't straight forward either but it was an enabler and good step in the right direction. As a consequence it became much easier for the team to mix and match Managed C++ and C#. And since the tool support in C# was much better, more and more code was eventually written in C#.

These are just two cases where using an appropriate 'carrot' helped the team to move faster towards a desired outcome. Sure, in particular the second example is a bit special. Yet, I am sure that you are able to find more 'carrots' which work in your particular situation. I'd be interested in what you find out!

Two More Thoughts About Selecting Tools

In a previous post I shared a thought about selecting tools, in particular whether you should decided for a tool just because you happen to be a partner of the vendor.

Here are two more thoughts about selecting tools.

Driving Towards A Decision

The first one deals with ensuring that the decision making doesn't take forever. Sometimes teams discuss about tools for weeks or months without coming to a conclusion. As a result they don't have the tool. And as a consequence they don't enjoy the benefits.

For instance you are considering adding a particular type of test tool to your tool set. Of course there is the danger that you may select the wrong tool (I'll discuss below how to mitigate that risk). On the other hand even a tool that is not a perfect fit but at least does a perfect job is better than no tool at all. No testing tool is even worse than a testing tool that may be usable only for very specific test cases.

Therefore it is important to drive to a decision. And the best technique is time boxing. Give your time a time box and insist on a decision by a specific time. Only extend the time box if an excellent reason is given. That way as a leader you can steer the team towards a decision.

And if the the team can't come to a conclusion? Well, you can always use the threat to make the decision yourself....

Homeworks

While it is important to reach a conclusion you also want to make sure that the team makes a proper assessment of the different options. I usually expect that the major player are being looked at and compared. As a tool I recommend a decision making matrix by which the columns are the different products and the rows are the selection criteria.

To get the team started I describe to them how the tool works. Don't assume they already know. Make sure they do. Next I also tell them that I won't provide them with the full list of selection criteria but that I expect them to choose those as well before they start the assessment. I guess the management speak for that would be "empowerment".

Usually I make a small number of selection criteria mandatory. For tools these are:

• Ability to be launched from a command line
• Ability to deliver the result as an XML file (or other standard format)
• Price for chosen configuration, e.g. based on number of license required

The first two items are important from my perspective since a tool needs to be easy to integrate into automated processes. By using command line and standard-format based files (XML preferred) only little 'glue code' is required if at all.

Why the decision making matrix? First, you will notice that the team will then have a recipe for their assessment. They know what questions to ask and what to find out about the tool. Second, the team will gain an overview of the major players for each tool. Often team members have different backgrounds and experience with different tools. By working together the decision will become data-driven and facts-based as opposed to 'I like tool A more than tool B'. Also the team will have a basis on which they can have a meaningful discussion. The result is much more detailed and specific.

And finally, you will observe that all the sudden all major vendors are looked at and a better decision is made. You can take the outcome including the decision making matrix to create the business case that you may need for the purchasing process anyways. And even if such a business case is not required it still is an excellent exercise to go through some number crunching to determine by when a particular tool is fully paid off and what ROI it creates.

Decision Making Styles

Making decisions is probably one of the most important activities of any leader. There are plenty of different ways to make decisions. I like the way how it has been described in Peter Senge's book "The Dance of Change":

• Telling: Make a decision and just tell the team.
• Selling: Make a decision, explain why you made that decision, then tell them to do it.
• Testing: Identify a problem, present your solution and ask for the team's comments.
• Consulting: Identify the problem, tell them you don't have a solution and ask them for their suggestions.
• Cocreating: Identify the problem, then come to a decision as a team.

While cocreating probably creates the most buy-in from your team, you may have to make decisions using one of the other styles occasionally. For instance you may have become the team leader only recently and a problem is so pressing that any further delay creates a lot of additional damage. Then it might be right to just make a decision, explain it and then have the team execute it (Selling).

One of the factors that may influence the style you want to use is maturity of the team. In very mature and homogeneous teams consulting or cocreating might be very fast approaches. On other teams different factions may simply not converge even if you give the team a generous time frame.

Again, it pays of to adapt to the situation at hand. The more of these styles you can easily work the easier it will be to select the most appropriate one, and still get decisions made both fast and properly.

A Thought About Selecting Tools

Once you are an XYZ partner (replace XYZ with your favorite partner vendor) this means that you should be using all XYZ tools. After all you get them all cheap or even for free. So choosing them must be right!

Wrong! Check what the primary reason is why your company is in business. Is it being an XYZ partner? Or is it delivering good products and services to your customers? I bet that it is the latter.

And if you deliver good products and services to your customers using XYZ technologies or tools might be the right choice. But maybe it's not. If you believe you can choose only from XYZ's product list then chances are that you miss out on the best opportunities to improve what you do and how you work.

For example, XYZ may just have large monolithic applications that require training for users and specialists for configuring and maintaining it. And maybe those large applications that try to be everything to everyone become so flexible that all that flexibility makes it hard to change and quickly adapt your processes to your environment. Do you want your tools to support your processes? Or do you want your tools to dictate your processes?

Bottom line: Don't let you limit yourself by being an XYZ partner thinking that you can use only their tools!

Getting Started

Now you are a new member of this team of smart, experienced, and very talented people. How do you get started?

Sometimes it looks to me that the most difficult part is to make sure that the team starts to shift its mindset. This does not mean at all that everything that the team did in the past or everything they are doing today is wrong. Quite the opposite.

A mindshift helps looking on everything in a new light. For instance it might help to rerun an experiment that failed a few months ago because one of the tools wasn't up to the job. If you have a new version of the tool this time the experiment might have a different outcome.

A mindshift also helps you to move to a different approach while - maybe - continue operating the same. For instance when you are used to larger and more complex projects or tools or designs then it can be quite challenging to move in the other direction. What about smaller and simpler?

A mindshift might also require challenging some of your assumptions. What if you are assuming that you get punished if an experiment fails? Maybe that assumption was correct many years ago and you internalized it so much that you are not even aware of it. What if the assumption is incorrect?

Getting started can be very difficult and sometimes it takes a lot of courage. Yes, it is good to know all those reasons why something cannot be done. In engineer's terminology this is the list of rists. But then: aren't we engineers to to make things work despite other people saying it cannot be done?

So try small experiments, maybe a couple of people for a couple of days. Maybe the experiment fails. No problem. Then you know yet another way that doesn't work and you have learned more about the challenge.

But maybe the experiment is successful. Then you have started to move. Admittedly just a tiny little step but you have moved. And you have learned as well. And maybe after you have moved you can identify the next thing already that is worth trying which was hidden or impossible before your move.

Let's look at a real life example to illustrate my point: Let's assume you have that mixture of unmanaged C++ and .NET code and you want to move all of your code to the .NET world. Then switch on that /clr flag and see what happens. Maybe it is successful and maybe then the code for communicating between the two worlds can go away, and maybe then you start seeing new options for what the next best move can be.

Product Manager as Team Members

There is that aspect of agile approaches that emphasizes the "whole team". For more details see here, here, here, here, and here. In my opinion this includes every person that works towards a deliverable of your project. Other people may call that a cross functional team since it not only includes the developers but other professionals as well.

So you may also need subject matter experts (SME's) for different areas. Maybe your application is extremely sensitive to security. Then you may want to include a security expert. Or your system might need to process a lot of data in which case you may want to include a performance expert. Or your system needs to interact with that old mainframe application in which case you want to include a person who is sufficiently familiar with that. In all these cases you may want to add the person full time or part time on an as-needed basis.

One of the most important people on such a team is the subject matter expert (SME) for the business side of the application. E.g. for a hotel reservation system you would want to have a person on the team who is familiar with that industry.

In some companies that domain expert is equal to the product manager. OK, I'm simplifying here a bit. But stay with me as the simplification is for illustration purposes only.

So with the above mentioned concept of the "whole team" you'd assume that this product manager is part of your team as well.

Well, just until a few weeks ago I would have said yes.

In the meantime I have come to the conclusion that I have to qualify this answer. And here is the reason.

To some degree, the product manager is part of the team in that she provides the input that is required from a product perspective for example the business side of the software.

But then, the product manager is also a customer. Do we treat customers the same way as we would treat our fellow colleagues?

Sure, it definitely would be nice and desirable if the relation would be just the same. We could have Friday afternoon drinks and have all the fun by telling all the war stories from the week. But wait! Is this really what you want?

Here is something to think about: Your customer is the one with the money (or budget). So here is something that is different. Your customer wants to spend money only on items that make sense to her. Your customer doesn't want to hear about that database problem that you encountered this week because it might actually mean - in her perspective - that the project is at risk, and all the sudden this anecdote, shared over a beer on Friday, takes on a life on its own.

Does this indicate a failure of the process? Does this mean you should exclude your customer from the team? I think that would go too far.

I think, based on my experience over the last 12 months, the customer (e.g. your product manager) is probably the most valuable person on the team. That means that person needs special treatment. Does that mean you should say "yes" to everything? No, it doesn't. Does it mean that the customer gets her way all the time? No, it doesn't.

So what does it mean? It means that you can still share most of the information with your product manager that you would share with your other team members as well. But it might mean that you rethink the way how you represent things.

Depending how you communicate with the product manager you craft her perception of you and your team. Say the same things, but say them in such a way that considers how you may influence perception. Don't walk on egg shells either. You still need to be self-confident, and that means for each conversation it is good if you have prepared a view. Don't go into a meeting without a view.

I have changed my model for how I look at internal customers in that I try to provide to them the same service I would provide to external customers. Although there is no written contract, a product manager (or any other business domain expert) is a customer to you, and the way you treat your customer will have a huge impact on the outcome of your projects. Work for your customer, work with your customer, come with solutions instead of problems, and ultimately make your customer happy.

Can Agile Keep You From Being Successful?

It certainly depends on what kind of career you are looking for. But sometimes if you want to become a leader you may find that being an expert on a non-leadership subject can actually keep you from being successful.

Some authors - I don't want to give reference here since I was looking at German authors - use a model that takes different thinking styles as a starting point. The knowledge focused thinker tries to become and stay an expert on a particular subject. And a person that is an expert may even have the fear that someone comes along who is an even better expert. So they frantically work on become and staying the "best". They may start to defend their beliefs and knowledge, ultimately coming across as defensive, academic, or even arrogant. Non of these perception will help if you want to become an agile leader.

As a leader you are still a subject matter expert. However, instead of being an expert on Crystal, Scrum, XP, or the like, you become an expert on agile leadership. You can delegate the agile practices to people in your team. After all: If you have coached your team over an extended period of time there should be more than enough methodology champions in your team anyways.

So you can let go without losing influence. You are no more under the pressure to create the perfect implementation of Scrum or XP regardless of what "perfect implementation" means. If XP or Scrum doesn't work perfectly it is not you who has failed. The team as such has not yet managed to adopt and adapt it sufficiently. Depersonalize the particular area from yourself.

A question that might help you to make this change towards re-inventing yourself could be: How do you define success? Is it to get pair programming rolled out through-out the organization? Or is it something different? Maybe you want to provide the best possible service to you customers. Maybe you no longer think in terms of black and white, right or wrong, works or doesn't work. Maybe you want to introduce a third category saying: it helps.

Bottom line: To make the shift towards an agile leader you might actually have to let go of trying to be an expert on an agile methodology to be successful!

Do You Need a "Quality Program"?

My answer to this question would be: It depends.

It depends on what you mean by program. If you mean an elaborate and detailed plan it will be highly likely that by the time you get to start executing it the conditions have changed and many of the details are no longer valid in the changed context.

And here is a related question: Is Quality Improvement a one-off? Again, it depends. If it means that once you have rolled out the quality improvement - you ticked off all the items on the list - you are done then in all likelihood your organization will fall back in terms of quality again even if it doesn't degrade.

But if you understand Quality Improvement as a process, if you construct it as a set of guiding principles and values, then you are on the path towards a sustainable approach.

And here is how it might look in practice.

Option 1 might be: Create a detailed program so that you cover all aspects of what is going wrong. This may take weeks or even months just to get this plan set up. And it will take some more time to roll it out. And then it will take even some more time to show results.

Option 2 could be: Create a laundry list of things that may have an immediate impact. Your people know what's broken. Poll their views. Then make small, incremental changes. Observe. If it works, do more of it. All of this can be instigated, modified, or cancelled within days or weeks. Yes, you might be wrong. But with small items all of them suggestions from your people who are as close to the problems as possible you will get the majority right. And for the few that don't work, you can react extremely fast and can cancel it.

I personally would go for option 2 since it would help showing results very fast and very early. Each small item that is cleaned up will uncover or emphasize other items that are broken. And this could be a bug that you fix, or it could be a small change in the process that you apply. With small incremental steps you achieve short term results, you don't have to flush down major changes that go wrong, and you plant the seeds for a continuous improvement and learning process.

Let me give a very concrete example. And this one amazes me again and again because it is so blatantly obvious that it is surprising that there are still companies out there who don't do this. Let's assume you have a system of a significant size. This can be an in-house solution, a one-off, or a commercial off-the-shelf (COTS) product. Assume further that you have an issue with the bug level. There are just too many of them. Then here are the rules that you can put in place to address the problem, fix it, and prevent it from reappearing:

1. Each bug must be reproduced by an automated test.
2. The automated test is to be included in the automated (regression) test suite
3. The code is modified until all tests pass.
4. A new version, e.g. a patch, can be sent out only if all tests pass.
5. If the bug is fixed on a support branch it also has to be fixed on the main development stream (potentially other streams as well but I think that's a business decision)

With this set of rules in place, meticulously followed, you can expect the bug rate to fall noticeably within a short time frame. In one case that I'm aware of the bug rate reduced by 30% within 12 months (starting with zero tests!). I'm sure that some improvement was already visible after 3 and 6 months.

Bugs are not the only type of lack of quality. You can equally find lack of quality around processes, requirements, tools, etc. The approach would still be the same. Instead of a sledgehammer or Ben Hur sized quality program, try a continuous stream of small incremental changes. It's slow at the beginning since there is so much to clean up. But then it will gain momentum, and when it has become a habit your organization has changed it's behavior. Quality has been established as a process, as a part of the culture.

So, no, I don't think you need an elaborate program. Small, incremental changes, observation, then adapt, are extremely lightweight and can be introduced today. But you need certainly guiding principles that help your team understand that you mean business when you talk quality.

Quality!

What is the important bit about quality?

Just calling for it doesn't do the job. You've got to put your money where your mouth is!

So when you ask for improving the quality it might pay also off to think about W. Edwards Deming's "Red Beads Experiment" (description for example here). Why is this relevant?

In essence the experiment describes how you limit the quality any process can achieve by not allowing the employees to improve the tools and processes to do their work. In fact allowing for continuously improving tools and processes is one of the most powerful mechanisms to improve quality. And as Deming points out, the decision to empower or prevent employees from doing this improvement comes from management. So, if you ask for quality improvements and at the same time deny your team tool or process improvements you shouldn't be surprised if the quality level doesn't go up at all or not as quickly as you'd like to.