Search results matching tag 'change'

Change: Knowing When, Knowing How

Anonymous — Sat, 19 Dec 2009 20:34:54 GMT

Workshop Kurt Lewin said, “There is nothing so practical as a good theory.” A gift from pioneering family therapist Virginia Satir is a good theory about how people process change. The Satir Change Model describes the: five major stages of a change; transition between stages; effects each stage has on feelings, thinking, performance, and physiology; and interventions [...]

Selling Your Ideas to Management

Anonymous — Tue, 08 Dec 2009 03:28:26 GMT

DAVID: Ruth, I think we should buy the ABC software to track trouble tickets and issues. RUTH: There is no budget for that. DAVID: But it takes me days to put together the information you want about the state of the product. And without an automated collection mechanism, I think many problems aren’t being reported. RUTH: Provide the [...]

Relationships Rule

Anonymous — Wed, 22 Jul 2009 14:36:00 GMT

Getting better in software development requires change and change is hard and change is unpleasant. Most of all, it doesn’t seem like we actually change. We talk about change, we start change initiatives, they pay people to teach us new ways, we may even read books, but at the end of the day we seem to be unchanged (except a bit poorer). Do we need to change the way they go about making changes?

I started addressing this question in my earlier post called Logic Loses. I described how facts, fear, and force, while giving the appearance of short-term change, did not seem to result in long-term desired behaviors. If that doesn't work, what does?

In Alan Deutschman book, Change or Die, he combats the approach of facts, fear, and force with his own three words (but his start with the letter R): relate, repeat, and reframe. Let's start with Deutschman’s short definitions for his R’s.

Relate: You form a new, emotional relationship with a person or community that inspires and sustains hope.
Repeat: The new relationship helps you learn, practice, and master the new habits and skills that you'll need.
Reframe: The new relationship helps you learn new ways of thinking about your situation and your life.

The best selling book on leading change is, of course, John P. Kotter’s Leading Change where he lists out his eight-stage process* to creating major change. The second step in Kotter's process is about creating a guiding coalition. This mirrors Deutschman’s first R: relate. Change seems to require that somebody outside ourselves has to believe that we are capable of making the change. That somebody, or some group, gives us a glimpse of what we can be and makes it impelling to us, not only because their facts or that they draw on our fears, but because our relationship to them is as compelling as the data.

Change, it seems, needs another human being whom we can connect with but who is not like us. The connection need not be affection only. Respect, awe, admiration, and the like seem to be equally fine kinds of connections. Fear as the sole basis for the connection seems to be insufficient for long-lasting change. (Though it is pretty darn good for short-term change!) The bigger and tighter the connection, the more you're likely to change and that change to last.

But it just can't be one of our mates who thinks just as we think. Just as in Kotter's third step, they need to have a vision of what we can be that we ourselves cannot quite believe yet. “You can automate those test cases.” “No, we don't have to constantly work massive overtime.” From small things to massive change, our connection to them and their belief in us gives us the hope, and therefore the energy, to make the change.

But that connection cannot be fleeting. Deutschman’s second R: repeat echoes Kotter's fifth and sixth steps. Practice makes change perfect (at least in the old-fashioned meaning of the word: complete) and this is the reason why most cold turkey, sheep-dip approaches fail. Doing the new thing once or twice is often not enough to create habits of mind that will make the change last. Change needs training and coaching.

In order for the repetition to be successful it also needs to be seen to be making progress. If I'm trying to find a better way to do requirements, I need to have some signs that I’m actually doing better lest I totally give up. The signs need not be massive, just little things like a better written requirement statement or a comment from a tester that my requirements are much easier to use. I need short-term wins.

Building habit through repetition and short-term wins drives me to Deutschman’s third R: reframe (Kotter’s seventh and eighth steps). Because I see myself doing it and doing it better, I stop relying on my connection’s vision and start developing my own. My old way of thinking, that there is not any better way to do requirements work, starts to give way to my realization that I am already doing a better way. Things I thought impossible before, or at least unlikely, now seem completely doable. Now statements like, “Requirements are about the problem space and design is about the solution space,” don't seem like nonsense but statements of deep truths.

Of course what ever new worldview we end up in will probably need changing in the future and will have to go through the 3Rs again. And we will try at first: facts, fear, and force. And we will scratch our heads wondering why we cannot change.

[* Kotter’s eights steps are: 1) Establish a sense of urgency; 2) Create the guiding coalition; 3) Develop a vision and strategy; 4)Communicate the change vision; 5) Empower broad-based action; 6) Generate short term wins; 7) Consolidate gains and produce more change; 8) Anchor new approaches in the culture]

Logic Loses

Anonymous — Wed, 08 Jul 2009 15:21:38 GMT

I have recently read a book called “Change or Die” by Alan Deutschman that has some good insights on how people change deeply held behavior. I like to share some thoughts inspired from (and some outright lifted from) the book.

We spend a lot of time talking about change. We want to become more agile or we want to improve quality or time-to-market. Each one of us has something we want to change about the way we are go about making software. So how do we go about initiating that change?

Most of us take the same approach. We use facts, fear, and/or force. We often start with facts. We find some source who has statistical information or powerful stories about what we want to change and we put that information in presentations, e-mails, and hallway conversations. We expect that those who hear the conclusions of our research and our brilliant analysis will quickly submit to our logic and adopt new ways.

Unfortunately, logic loses.

The reason why logic loses is threefold. First, those who are doing things that are contrary to clear logic (at least our clear logic) have great defenses. These are the classic ego defenses of denial, idealization, projection, and rationalization. The denial defense in software sounds like, “this is just the way that software is done .” People in software development denial did not believe that software can be created any better than the way they are doing it today. Of course, the kind of software they produce is unique and the suggestions, even if the techniques work someplace else, wouldn't work here. Idealization often occurs when the person you're trying to convince helped create the current way of doing things. They can't imagine there being any more perfect way to doing development for their shop than the way they thought of doing it. Projection says that, while there may be problems, it is not the fault of the current way of doing things, it is somebody else's fault. Rationalization suggests that while your idea is good, “they won't let us do that.”

Of course, those same ego defenses of denial, idealization, projection, and rationalization are at work in us too so that our incredibly important change is just as blinded as their stubborn refusal to move on.

The second reason logic loses is that our insightful change doesn't even sound logical. To tell somebody who believes that the world is flat that you can sail around the world doesn't even make sense, it's illogical (I bet you pictured Spock saying that). Each of us has a frame of reference that helps us decide what is true and useful and what is silly and should be ignored. If our beneficial change idea does not fit within the frame of reference of the audience, it makes no sense to them. It is not a logical idea, it is silly talk. One great example of this is the estimation rule of thumb that to decrease the schedule for a software project you often have to increase the estimate. The logic behind this rule has to do with the reality of unplanned rework and is documented elsewhere. However, to somebody who just wants to go faster, lengthening the estimate makes no sense at all.

Just as in the first instance, if their ideas are outside our frame of reference, they sound like a madman.

The third reason is that, by my estimate, roughly 1/2 of our ideas are just plain stupid and should be rejected. Not that we think they are stupid at the time. Actually, we think the idea is quite wonderful and it works great “on my machine”, or my work area, or in my ivory white tower. It is more like creating a bit of functionality and not considering any error routines or doing testing. We may think it's done but it is not done-done. When we start promoting half-baked ideas we often end up doing far more harm than good.

Another reason our ideas should be rejected is when we approach the change with an all or nothing total transformation. “Let us switch from waterfall to agile in one big swoop,” we might say. Or, “Everybody must start doing code reviews immediately!” More often than not, at least in my experience, a quick change over often leads to a quick change back. Rather than flip-flop around, it is best to ignore this change approach.

So if our logic loses, let’s scare them into adopting our change; the fear approach. But fear is simply negative logic and it suffers the same issues as our positive logic. Fear can generate some short term action but it seldom lasts. In Deutschman’s book (remember it from the beginning of the post?) he points out that people with serious heart problems stop taking their medication—medication that they are supposed to take for the rest of their life—within one year. If I am not immediately in fear, if the pain is not currently present, then why change?

Our last trick is force. Make them do it the better way. The, “I told you so,” approach our parents used on us. Did the parental mandate engender genuine change on our part or merely compliance? When out of sight or out of the house, did many of us not actually adopt the very opposite of the ordered direction? Not that software development is analogous to child rebellion but forced change most of the time only lasts while there is an enforcer. Without changing individual frame of references, when the law giver leaves, the golden calf is created.

So how do people change given all these defensive ramparts? That is the subject for a follow-on post and your comments below. Only don’t suggest I am wrong, my ego defenses will put you in the illogical camp :-)

Re: Embracing Change

stevemcc — Sat, 23 Jun 2007 17:33:38 GMT

Another requirements related idea I like (which I know you already know about) is Tom Gilb's idea of the requirements "landing zone." Some requirements are binary -- the software meets the requirement or it doesn't. But others are "scalar." These are the requirements that are traditionally called "non-functional requirements" or "quality requirements." The software has "more" of the requirement or "less," but it isn't black and white. The definition of scalar requirements include several elements:

The "gist" of the requirement (this is what many organizations are currently treating as "requirements")
A "scale" for the requirement, i.e., some way to assess what qualifies as "more" or "less" of the requirement
The minimum acceptable level of the requirement
A range in which "more" of the requirement is "better"
A maximum at which "more" stops providing additional value

The range between the minimum acceptable level and the maximum useful level makes up the "landing zone." (There are a lot more details to Gilb's approach (called Planguage) than I'm describing here, but this should be enough to communicate the basic idea.)

It takes a mental shift to think of requirements this way, but Gilb has convinced me that it truly is possible to define a quantitative scale and a landing zone for every single scalar requirement. (As Gilb says, bad numbers beat good words.) Once you've done it for awhile, it doesn't take much longer than defining requirements in the traditional (aka sloppy) way, and the increase in clarity is striking.

A common example would be response time. You could imagine a system in which a response time greater than 2 seconds is too long. Therefore 2 seconds will be the minimum acceptable. An improvement in response time in the range from 2 seconds to 1/10 second is valuable. But once you get response time of less than 1/10 of a second, there's no additional value. For example, improving response time between 1/10 and 1/100 of a second doesn't add value to the system, so there's no point in developers working beyond that upper limit. This example is hypothetical, and real systems have different worst and best acceptable response times. But the point is that you define is explicitly instead of leaving developers to guess about what's useful.

The great "embrace change" support you get from landing zones is that they inform the development team about how much of each scalar requirement is good enough, how much is better, and how much is a waste of development effort -- and they can do that on their own initiative without further involving the business stakeholders. Moreover, when landing zones are defined across multiple requirements, it allows the developers to make technical tradeoff decisions as new requirementes are added about how to support the set of requirements as a whole, again without necessitating time-consuming back-and-forths about the old requirements with stakeholders outside the immediate dev team.

Re: Embracing Change

JerryD — Fri, 22 Jun 2007 15:18:09 GMT

David,

You provide some more good techniques for anticipating changes. Here's how I would summarize them:

Component Level Estimating
Estimating Best, Worst, Expected Cases
Using standard percentages for downstream activities
Active risk management to build your contingency
Re-Estimating when more information is known
Refactoring the plan to reflect current understanding
And the best technique -- Think First

[quote user="daviddaly"] You can take account of things that you think might happen by considering them as risks or using best and worst case estimates but you will NEVER be able to take account of things that you do not identify at the outset.[/quote]

Thanks for sharing your techniques and I look forward to hearing how other people anticipate change.

Re: Embracing Change

daviddaly — Fri, 22 Jun 2007 07:48:51 GMT

Hi Jerry,

Some good questions! I will do my best to answer...

On that project the original estimates were created by breaking down the product into components and then estimating best and worst case effort for code and unit test of each component. My management required a single figure rather than a best and worst case and so this was “translated” into a single figure with sufficient contingency to cover the worst case. Standard percentages for design, system testing and project management were added. Risks were assessed separately and quantified so that they could be accounted for in the contingency as well. Justifying contingency to management was significantly eased by the use of best and worst case estimates and the identification of risks.

As one might expect once technical design work started in earnest it became apparent that the original component breakdown bore little resemblance to the work that was to be done. Once we had a firm technical solution separate areas of the design were allocated to each of the developers (enabling them to take responsibility for those aspects). Each developer was able to re-estimate their work based on this new information and these new estimates formed the basis of the plan.

I think that often plans are based on estimates that no longer reflect current knowledge about the work to be undertaken. My view is that when you start a project estimated to include 300 person days of development the plan may as well have a single activity of 300 person days to reflect this. Once a further stage of design is completed it will be possible to refine this. To start with more detail on the plan gives a skewed impression of how much is known about the state of the project at that stage.

As it happened all the development work was completed well below “worst case” effort estimate. However a problematic roll-out had not been accounted for anywhere in the estimates or risks. In the end the contingency was used for this. So on the one hand this proved the value of having contingency. On the other hand the justifications for contingency were proved incorrect! That is why nowadays I believe that contingency should be used to account for the unexpected and therefore adding a standard percentage is the most correct way of doing this. You can take account of things that you think might happen by considering them as risks or using best and worst case estimates but you will NEVER be able to take account of things that you do not identify at the outset.

David.

Re: Embracing Change

JerryD — Thu, 21 Jun 2007 19:25:54 GMT

David,

My observations is the same as yours -- the high-level requirements are pretty stable. I like your solution of giving the developers the freedom during coding.

Of course, your post raises several questions.

Are you using this technique on plan-driven projects? If so, how did you account for this in the plans? (e.g. Are you creating estimates off the high-level requirements that includes assumptions about the down-stream work? Or are you using some other technique?)
You mentioned contingency. How did you account for the uncertainity in your assumptions about the continency buffer?
One problem with buffers is many managers view them as unneccessary and delete them from our plans. Sounds like this didn't happen to you. Was it hard to sell the need for buffers to your management? How did you protect it from being cut?

Thanks for your insights and I'm looking forward to hearing more about your techniques.

Re: Embracing Change

daviddaly — Thu, 21 Jun 2007 18:21:34 GMT

Change is a very broad term. In my experience the high level requirement (i.e. an online ordering system) is rarely subject to much change. The detail of what has to be delivered changes enormously over time but a lot of this “so called” change is in fact the process of developing a high level requirement into a product.

I once led a team of four developers and gave them the freedom to change the functional specification whilst they were coding. This was done without seeking customer sign-off. Whilst this sounds dangerous, I genuinely believe that it empowered the developers to take responsibility for ensuring that the product met our customer’s requirements rather than just coding what the functional specification dictated (whether it made sense or not). The customer in this case was delighted by the results and the project was delivered within tight time constraints. I do not think we would have achieved that if we had insisted on time consuming formal sign off for every alteration.

In my opinion real “change” only occurs when you are not talking about a refinement of the high level business requirement. This could be a total alteration of purpose (i.e. online ordering system becomes radio controlled caterpillar) or, more usually, environmental changes such as developers leaving your team or a new operating system no longer supporting your development environment. These changes are very difficult to plan for and therefore I think contingency is the only way of allowing for it.

Embracing Change

JerryD — Wed, 20 Jun 2007 17:37:22 GMT

Change is inevitable on a project. It doesn't matter if you using agile or plan-driven techniques, you must embrace change. Agile embraces change by being very responsive -- they point out that the future is unknown, so they just look to the near term.

Plan-driven techniques are used when the customer values predictability. So plan-driven has to embraces change by anticipating them. Two common techniques for anticipating change are to include a change buffer in your plan and to use design-for-change design and construction techniques.

What other techniques have you used to anticipate change?

Thanks