How Serving Is Your Leadership?

I once worked for a manager who thought everyone should bow down and kiss his feet. Okay, I’m not sure if he actually thought that, but that’s how it felt to me. He regularly canceled his one-on-ones with me. He interrupted me when I spoke at meetings. He tried to tell the people in my group what to do. (I put a stop to that, pretty darn quick.)

He undermined my self-confidence and everything I tried to accomplish in my organization.

When I realized what was going on, I gathered my managers. At the time, I was a Director of Many Things. I said, “Our VP is very busy. I think he has too many things on his plate. Here is what I would like to do. If he interrupts your work with a request, politely acknowledge him, and say, “Johanna will put that in our queue. She is managing our project portfolio.” If he interrupts you in a meeting, feel free to manage him the same way you manage me.” That got a laugh. “I am working with him on some customer issues, and I hope to resolve them soon.”

My managers and project managers kept on track with their work. We finished our deliverables, which was key to our success as an organization.

My relationship with my manager however, deteriorated even further. In three months, he canceled every single one-on-one. He was rude to me in every public meeting. I started looking for a new job.

I found a new job, and left my two week notice on his desk. He ran down the hall, swept into my office and slammed the door. He slammed my notice on my desk and yelled at me, “I don’t accept this! You can’t do this to me. You can’t leave. You’re the only director here accomplishing anything.”

I said, “Are you ready to have a one-on-one now?”

He said, “No. I’m busy. I’m too busy for a one-on-one.”

I said, “I’m leaving. We have nothing to discuss. You can put your head in the sand and try to not accept my resignation. Or, we can make my last two weeks here useful. What would you like?”

“You’re not done with me, Rothman!”

He stalked out of my office, and slammed the door on his way out. I got up and opened the door. I was never so happy to leave a job in my entire life.

Some managers don’t realize that they are not their title. Some managers don’t realize that the value they bring is the plus: the management, plus their relationship with their peers, the people they manage, the systems and environment they enable/create. This guy had created an environment of distrust.

That’s what this month’s management myth is all about: believing that I am More Valuable Than Other People.

If you are a manager, you do provide a valuable service: servant leadership. Make sure you do so.

Posted in management | Tagged , , , , , | 3 Comments

Pragmatic Manager Posted: Time for a Decision

I published another Pragmatic Manager this week, Time for a Decision. It’s about program management decisions, and collaborating across the organization.

Do you receive my Pragmatic Manager emails? If you think you are on my list, but are not receiving my emails, let me know. Some of you long-time subscribers are not receiving my emails because of your hosts. I am working on that. Some of you don’t subscribe yet. You can subscribe. I write something valuable at least once a month. I post the newsletter on my site when I get around to it, later.

I hope you enjoy this newsletter. If you don’t already subscribe, I hope you decide to sign up.

Posted in program management | Tagged , , , , , , , , | Leave a comment

Scaling Agile? Think Out, Not Up

I taught the Influential Agile Leader workshop with Gil Broza last week in Edinburgh. (That’s why I was quiet. I was traveling and teaching. No time for writing, blogging or tweeting.)

Possible Small World Network for Nine Agile TeamsOne of the participants asked me what I thought about scaling agile. Before I could explain about small-world networks, not hierarchies, he said, “I am sure the way you scale agile is out, not up.

Well, blow me over with a feather. He said it more simply than I did.

If you look at my picture of a technical program team, you can see that’s how it works.

Technical Program with Communities of Practice

Technical Program with Communities of Practice

The technical program team has feature teams alone, if they can be alone. Joe, Tim, and Henry all have stand-alone feature teams.

If they need to be “collected” because they work on related features, they collect themselves. Sally has collected feature teams.

The teams scale out, at the technical level, not up. The technical program team does not have to get to bigger. When I ran programs in the past, I emailed the program team meeting agenda (it was a problem solving meeting) to everyone, and say, “Here are the people I need to attend. Everyone else: let me know if you are attending.”

Now, there’s a limit to how big a program can get for the software program or the hardware program. At some point, the it’s so hard to coordinate the interdependencies, it’s not worth the bigness.

If the teams are delivering small features all the time, you don’t need as many people as you think you do. The smaller the batch size, the fewer the people required. Your momentum will be greater. If you don’t believe me, think about that for a minute or two.

When you think scaling agile, think out, not up. You use small world networks, and when you say, “think out, not up,” it’s a very nice catch-phrase.

Posted in program management | Tagged , , , , , | 1 Comment

Spike It! Article Posted

One of my clients was having trouble with estimating work they had never done before, so I wrote an article explaining spikes. That article is up on agileconnection: Need to Learn More about the Work You’re Doing? Spike It!

It was a little serendipity; I taught an estimation workshop right after I explained how to spike in email. That article almost wrote itself.

You can use a spike in any project, agile or not. Spikes are for learning.

I also explain what to do when managers say, “Use the code in the spike” and you think, “Oh no!” See for yourself.

Would-be authors: want to write an article for agileconnection.com? I’m interested.

 

Posted in project management | Tagged , , , , | Leave a comment

Design Your Agile Project, Part 5

This post is what you do when you are a program manager and not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change? (In the book, I will talk more specifically about change and what to do. This post is the highlights.)

Project management and program management are all about managing risks. How do we bring the management of change and management of risk together in an agile project or a program?

Let’s review the principles again:

  1. Separate the business decision for product release from the software being releaseable all the time. That means you want the software releaseable all the time, but you don’t have to release it. I talked about this in Design Your Agile Project, Part 1.
  2. Keep the feature size small for each team, so you can see your throughput.
  3. Use the engineering practices, so you don’t incur technical debt as you proceed.
  4. Understand your potential for release frequency.

Are you doing these things now? Are they part of how you work every day? If not, you need to change.  I’m going to address what the program needs to do to succeed.

Your Program Represents the Teams

In a sense, the program will represent the state of agile for the teams. Think of it as Conway’s Law exposed. (Conway says the system design reflects the communication structure of the designers.)

You might think you need to standardize your approach to agile or lean. You might think you need to be rigid about how you move to agile.

You would be wrong about the process. You would be more correct about the engineering practices.

You need to create the most resilience for the organization. Here’s what I mean.

CynefinIf you have autonomous, collaborative teams, you will have uncoupled, collaborative code. If you look at the Cynefin framework, you get that on the right side, without too much trouble. (I’m not saying this is easy. Just that it’s more possible.)

But, what if you have geographically distributed teams, or your teams are new to agile/lean, or you are still responding to requests from all of the program because the rest of the organization doesn’t quite understand agile? What happens then?

You are on the Complex or Chaotic side of the Cynefin framework. Maybe you don’t use the Good Practice that we already know for program management, right? Maybe you don’t use what we already know about for the projects, because they won’t scale for the program.

That’s why each team needs to review Part 2 and Part 3, especially if they are part of a program.

That’s why program management needs to be servant leadership at the core team level. See Which Program Team Are You Managing? Some program managers think they are managing technical teams. They might be. But, they might need to manage a core team in addition to a technical team.

What Does this Mean for a Program?

  1. If you are trying to change everything, you have many unknowns. You are not in the right side of the Cynefin framework. You are somewhere on the left side of the framework. Agile “out of the box” is not going to work.
  2. Teams need to practice being agile as a team, before they are part of a program. They can come together in service of a program. And, because each team designs its agile project, no manager can change people on a team, unless the team requests that change. No “I can move people like chess pieces” business. Managers serve the teams.
  3. Beware of hierarchies. They will slow your program. What is a hierarchy? Scrum of scrums. Hardening sprints, especially where other release teams integrate for the feature teams, can create hierarchies. Why? Because it’s too easy to say, “My part is done.”

If you are designing your agile project to be part of a program, you want to consider, “How will we make sure we deliver on a consistent basis to the rest of the program?”

This is not about maximizing throughput. This is about meeting deliverables, and making sure that the teams know about their interdependcies long enough before they have to meet them. Then, the teams can meet them.

In a program, you always have interdependencies. Always.

Design Each Team’s Project to Optimize at the Program Level

If you are part of a program, it’s not enough to design your project for your team. You have to consider the needs of the program, too.

Each team needs to ask itself, “How do we deliver what the rest of the program needs, as the program needs it?”

You might want to watch Phil Evans Ted talk, How Data Will Transform Business. In a hierarchy, we have too-high transaction costs. (In geographically distributed teams, we have too-high transaction costs, too, but that’s a different problem.) Note how he says “Small is Beautiful.” Hehehehe. Gotta love it.

Hierarchies are slow to respond. They impose barriers where you don’t need any. The problem with programs is that they are big. You want to decrease the problems of bigness where you can. One way to do that is to decrease the effects of hierarchy. How? By not involving hierarchy whenever you can. That means using small world networks to solve problems between and among teams. That way you solve problems where the problems exist.

If I ran all the programs in the world, what would I do?

  1. Have feature teams everywhere, not geographically dispersed project teams. I prefer collocated teams, but I realize in very large programs that is not always possible. (Sigh.)
  2. Have a core program team (cross-functional business team) that runs itself using kanban. If you need a cadence, use a one- or two-week iteration for the team’s problem-solving.
  3. For the technical program team, run itself using kanban. Same idea with problem-solving cadence.
  4. Have the project teams use their own approaches to agile and lean, recognizing that their job is to reduce batch size, get to releaseable all the time, and not incur any technical debt as they proceed. The more the project teams are autonomous in their approaches to agile, the more they will collaborate with each other. The more they will feel free to explore what they can do.
  5. Have the program architect (who represents the business value to the core team) look for examples of bad implementations of Conway’s Law all the time in the product. That will help create architectural business value. Yes, there is more that the architects do.
  6. Encourage Communities of Practice for the functional areas. Encourage cross-pollination between the communities. The “plain” developers need to know what the architects are thinking, as do the testers. The developers need to know what problems the testers are solving, and so on. Organizing and facilitating CoP might be a management job. It might be a program management job. It’s a servant leadership role. It’s definitely not a command-and-control role. (“It’s Tuesday at 4pm. It’s time to learn.” Ugh. No.) The word here is “encourage,” not mandate.
  7. As a program manager, you need to be aware when people need more training in understanding deliverables or what those deliverables are. Do they understand flow? Do they understand agile? Do they understand feedback? Do the teams need coaches? Do the teams need help in project management (yes, the teams are doing project management)? Do the teams need help in agile or lean? Do the teams need help in the interpersonal skills? Do the teams need help in the engineering practices that will help them deliver a clean feature every day or so into the code base?

Those are just your deliverables to the program. That’s nothing about what you deliver to your management team.

Keep these three words in your pocket for your teams: autonomy, collaboration, and exploration. The teams need to be autonomous. It’s their deliverables that you care about. Not the teams being in lock-step.

You care about the teams collaborating. How do you encourage that? With small features and product owners who have well-defined feature backlogs and roadmaps. The more often the teams check completed features in, the fewer collisions, and the more manageable the collisions are. You get momentum that way. I talked about momentum in Organizing an Agile Program, Part 3, Large Programs Demand Servant Leadership.

The exploration occurs when the teams (which include architects) spike or explore what the team(s) think the options are. Or, when teams talk among themselves to solve problems. Teams can first solve problems themselves. They do need a small world network and to know that you want them to solve their problems. They don’t need a hierarchy to solve problems. These people are smart. Isn’t that why you hired them?

Okay, all the previous posts in this series are:

Design Your Agile Project, Part 1

Design Your Agile Project, Part 2

Design Your Agile Project, Part 3

Design Your Agile Project, Part 4

Sorry this series took me so long. Travel and our new house interfered. Being a product owner is all-consuming.

Posted in agile | Tagged , , , , , , , , , | 2 Comments

Are You Running from Problems or Solving Them?

Back when I was a manager inside organizations, I had many days that looked like this:

  • Meetings at 9am, 10am, 11am.
  • Working meeting through lunch (noon-1pm)
  • Meetings at 1pm, 2pm, 3pm.

I finally got a chance to check my email at 4pm. That’s when I discovered the world had blown up earlier in the day! (This is before cell phones. Yes, there was a time before cell phones.)

I then ran around like a chicken with my head cut off until I left work at 5:30pm, because, yes, I had a family, and, yes, I had to leave at 5:30pm. I either made dinner or picked up children, depending on my agreement with Mark.

We did the family stuff until 8pm, and when the kids went to sleep, I went back to work.

No wonder I was exhausted. My decision-making sometimes suffered, too. No surprise there.

Luckily, I had some days that did not look like this. I could solve the problems I encountered. And, some of these meetings were problem-solving meetings.

However, I had jobs where my senior managers did not manage their project portfolios, and we had many crises du jour. My VP would try to catch me on the way to my next meeting, and attempt to get me to “commit” to when a patch would be available or when we would start, or finish a project.

I swear, one of my VP’s used to know when I went to the ladies’ room. He did yell at me through the door, just as in this management myth.

I finally put my foot down, and said I was no longer going to meetings that weren’t problem solving meetings. Have you read the chapter about meetings in Manage It! Your Guide to Modern, Pragmatic Project Management? I wrote it for project managers and for managers who run around like the proverbial chickens. I wrote Manage Your Project Portfolio for managers like me who had well-meaning senior managers who had trouble making decisions about which projects to do.

This management myth is something I see often in organizations. This one is the one where people are running around so often they don’t actually solve problems.

Many problems are a combination of several problems. You might have to separate the problems and attack them in sequence. But, you might have to see the whole first, because there might be delays. The overarching problem is this: if you don’t give yourself enough time as a problem solving team, you can’t tell what the problem is. If you can’t tell what the problem is, you can’t solve it.

Problem solving tends to go through the process of:

  • Problem definition: What do we think the problem is?
  • Problem discussion: Let’s get all the divergent ideas on the table. Brainstorm, whatever we need to do.
  • Select a solution: Converge on a solution, trying out the ideas, understanding the results of each potential solution
  • Determine an action plan, with dates and people’s names associated with each step

Your problem solving might vary from this a bit, but that’s the general idea.

If you never give yourself enough time to solve problems because you’re always running around, how can you solve problems? It’s a problem. (Like the recursion there?)

That’s this month’s management myth, I Can Concentrate on the Run. Maybe your myth is that you can concentrate in a 10-minute standup. Maybe your myth is that you can concentrate on your drive into work. You might be able to, for some problems. Complex management problems require more than one person to solve them. They require more than a few minutes thought.

How do you solve complex problems in your organization? Do the problems run around the organization for a while? Or, do you solve them?

Posted in management | Tagged , , , , | 1 Comment

Estimation and the Sunk Cost Fallacy

I’m not a fan of using schedule or cost estimate as a way to value the projects in your project portfolio. If you do, you are likely to miss the potentially transformative projects or programs.

In Manage Your Project Portfolio, I have an entire chapter devoted to ways to evaluate your project portfolio: business value points (not story points), waste, risk, to name just three. I wrote about cost of delay on this blog a while ago.

Last night, I heard Jutta Eckstein give a talk about Beyond Budgeting. That talk was the genesis for our Agile 2014 workshop, Diving for Hidden Treasures: Finding the Real Value in Your Project Portfolio.

Last night, I realized something while Jutta was speaking about estimation and sunk cost. One of the attendees asked about estimation. A paraphrase of that question is, “How can we start if we don’t know how long it will take?”

The projects that are worth doing have risk and are complex. What do you know about these projects? You can’t predict them. You cannot know how long they will take.

Remember the post Why Cost is the Wrong Question for Evaluating the Projects in Your Project Portfolio? If you don’t do the risky projects, if you only do the safe projects, you might maximize short-term gains. You lose the long-term market share, because you don’t do the risky projects.

Many managers find themselves in this position. The Operations committee or the PMO or “someone in charge” wants an estimate of the budget or when this project will be done. You provide a 3-point estimate: optimistic, realistic, and pessimistic estimate. Or, you provide an estimate with a percent confidence. (You have read Essays on Estimation.)

They don’t like that estimate, so they take the optimistic estimate, or they remove the percent confidence. That’s the first date you can’t prove you can’t make the project.

Never mind that the estimate is a guess. Never mind that you had caveats. Never mind that you had assumptions. Your estimate is now a commitment.

That date arrives. You are not done. You are in a variant of the 90% done schedule game. Why? Because you had an estimate. If you did not re-estimate, and update your estimate. Even if you did, your “in charge” people might not have wanted to hear your updated estimate.

Now, you might be in the sunk cost fallacy. The sunk cost fallacy says, “We have spent so much money on this, we may as well finish it. We can’t recover that cost. Our estimate says we only have xx much left to go.”

The difference between evaluating the project portfolio on value and estimates is that when you look at the business value, you ask this question first:

Should we do this project at all?

You always ask that question. It’s the zeroth question. Even if the project has been proceeding for a year. Because sunk cost doesn’t matter. You still have to support the system after you release it. Repeat that sentence: you still have to support the system after you release it.

If you evaluate the project portfolio based on estimates, you don’t ask the “Should we” question. You ask about the estimates. You don’t ask about follow-on after the release. You don’t go meta, which is the point of the question.

Sunk cost will catch you every time. Can you avoid the sunk cost fallacy? Of course. Do estimates cause the sunk cost fallacy? Of course not. They contribute to it.

In my experience, you are more likely to be caught by the sunk cost fallacy if you use estimation, because you are less likely to go meta on the value of your projects.

Is it okay to know if this project is bigger than a bread box? Of course. Should you use those estimates as a way to hold a project’s commitment to dates? No. Not if you want to work in an agile way and update the backlog as you work through iteration or flow the work. See Trust, Agile Program Management, & Being Effective for why you want to vary the backlog.

If you use estimates as a way to evaluate the projects in your project portfolio, beware of the sunk cost fallacy. You would be better off to ask, “How much value does this project have for us, compared to the other projects we have to do?”

Posted in portfolio management | Tagged , , , , , , | 8 Comments

Trust First, Email Second

I’m shopping for furniture for our new house. I need a chair or a sofa for our family room, lights, all kinds of things.

I was on Facebook, and there was an ad that looked interesting. I thought, “Should I click?” I clicked anyway.

The site wants my email address. I can’t see anything without logging in. First, before I see any furniture, I have to give them my email address.

This action violates the basics of anything about building rapport and trust. I don’t even know these people. Do I want to share yet-another-login and password with this site?

This is not an idle question.

I don’t know about you. I have way more than 100 logins and passwords. I use 1Password to manage my logins and passwords. But it’s still not easy.

This site—and any other ecommerce site—has to gain my trust before I share my email with it.

It’s the same with you. I offer you my Pragmatic Manager email newsletter. I show you past issues, both in chronological and by tag order. I don’t pressure you to sign up.

I offer you blog postings in the hope you will sign up for my email newsletter. I don’t pressure you to sign up. Why would I?

How can you gain trust in me and my offerings if I create a barrier?

It’s the same with that site. I have no trust in them. Why would I give them my email address? How can I possibly trust them?

When you build a product, when you create a team, when you do anything that has people who need to come together, think of how you build trust first. Once you build trust, the rest is much easier.

Posted in product development | Tagged , , | 1 Comment

An Agile Approach to a House Remodel

You might have noticed I’ve slowed my blogging in the past few weeks. I’m fine. I’ve been a product owner/customer for our new-to-us house remodel.

In the last several weeks, almost every single day, Mark and I have taken some time to go over to the new house to see the progress and provide feedback to the guys working on site. We do work directly with the site project manager. I don’t know how he meets with the subcontractors (painters, plasterers, tilers, etc.) All I know is that we provide him feedback just about every day.

He tells us when it’s time to select the: tile, faucets, bathtubs,  paint colors, new front door, decide on kitchen design, everything. We meet with the people who are our vendors. They send the specs or material to our builder.

When we were working on the design of the house, we iterated on it with the builder. We had at least three iterations on paper. Maybe four. We discussed how we would live in the house with him.

As we discovered things about the house, we modified the design. (Does any of this sound familiar?) Since it’s a house, we haven’t modified structural things, such as how big the addition is, or where the windows are. However, this week, we changed my bedroom closet. That was because I didn’t understand the initial design, and I called a halt to where we were.

Our builder is great. We are trying to be great customers, too. It’s a two-way street. This is why my blogging has been slow. I’m spending time at the house.

Today, I took these pictures, so you can see what I mean about making decisions about paint colors:

bedroom1 bedroom2 bedroom3 hallwayThe first three images with the blue colors are all in what will be our master bedroom. We were trying to decide between the more intense blue on the left and the other blue on the right. The painted-over colors are from when the painters mistakenly painted our bathroom colors on the bedroom walls.

The purple-gray colors on the right bottom image are from the hallway. We wanted to see what that color would look like in what has the potential to be a dark hallway.

You don’t have to like our colors. We like our colors. Our house is full of teal greens, blues, and purples. We like those colors. If you’ve ever seen me in person, you might understand why. Those are my colors.

Being a product owner/customer is a new experience for me. It’s time-intensive to do it right. You have to make a gazillion little decisions every single day. And, this is with a house, a product that is not malleable in every dimension. A product that is not changeable with a flick of the wrist.

Our house is supposed to be done at the end of May. It will be close. They might need a few more days. Why? Because the kitchen designer is not agile. She is also designing my office closet storage, although maybe not for long. I am running out of patience. (Me? What a surprise!)

Mark and I have really enjoyed the short cycles with this remodel. It’s been intense for us. But, it’s been great to see the house we want and need come together, and so quickly.

Agile works for house building, too. Don’t let anyone tell you otherwise.

Posted in agile | Tagged , , , , , | 2 Comments

Design Your Agile Project, Part 4

If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want (working software all the time and expose the interdependencies), provide training or whatever other resources they need, you are likely to get what you want.

That’s why I wrote Design Your Agile Project, Part 1 for teams who are collocated, and can use any approach to agile. Design Your Agile Project, Part 2 is for teams who have many challenges, but are collocated, and can work through those challenges. Design Your Agile Project, Part 3 is for teams who are geographically distributed and have to think about what to do.

In the program, what you need is for each team to deliver, all the time. The program wants as close to continuous delivery as possible. You can reduce the interdependencies—or plan for them. You can certainly expose them.

Feedback is Necessary

Did you see Jason Yip’s tweet (@jchyip) the other day, where he quoted this, “”Large organizations…lose their resilience simply because the feedback mechanisms…have too many layers of delay and distortion.”

This is why you cannot standardize on anything for any team in a program. Why? A program needs resilience. It needs to be able to release early and often. Just because it’s a program does not mean it does not need to be able to obtain feedback.

Each team must know the principles:

  1. You need to see all the work in progress.
  2. You want to flow work through the entire team.
  3. You want to see working software, sooner, rather than later.

Teams use agile and lean principles. Management treats the people on the teams as if they are adults. The teams look at their own issues and design their own approach to agile/lean, always keeping in mind the idea that they need to deliver early and often.

Now, let’s talk about what happens when you want to meld these teams into a program.

Each Team is the Heart of the Program

You might think that things roll down from the program manager or the core team. Not in my world. This is where each team’s autonomy, each team’s ability to make its own decisions about how it implements its approach to agile or lean is key.

The teams are the heart of the program. All of the teams: the core team, the technical teams, the teams that the core team represents.

This is a change from traditional process thinking. It’s a change from traditional program management thinking. This kind of thinking requires that the teams know how to do agile already, and are new to the program, not to agile. This kind of thinking also means that the program manager is a servant leader.

In a program, you will have interdependencies. You want to minimize them. How do you do that? By reducing batch size, the size of each feature. By coordinating the features with a program roadmap. And, by looking at the value of each feature, not its cost (estimate).

That means the teams need to become good at delivering, not estimating. It also means the product owners need to become very good at creating ranked backlogs for the teams, and changing them. It means that the program needs a roadmap that can and does change.

Remember, agile is about the ability to change, because the teams get to done at regular intervals, whether those intervals are iterations or because the teams work in flow.

What If the Teams are New to Agile?

What if you want to have a program with teams that are new to agile or lean? You can do anything on your program. You need to assess your risks. Let’s look at the Cynefin framework to see where your risks might place you, if your teams are new to agile.

CynefinIf your teams are new to agile, and they are all in one physical location, and they know the domain of the product under development, i.e. you are only changing how they are developing, maybe you are just in the Complex part of the framework. You are changing the culture of the program.

However, if you have new-to-agile teams, who don’t know the product domain, who are geographically distributed or dispersed from one another, and you want to transition to agile, do you see that you might be in the Chaotic part of the framework? That you have no way of knowing the risks?

That is much more difficult.

Let me provide you an example. Imagine that you are working with developers in Europe who have a 15-person development team. They have only programmers on their team. They have never worked with testers. Why? They have never seen the need to do so. They have been successful, according to them, up until now.

You are in New York, where the product management is. You know the product domain. The developers? Well, maybe not so much.

Several years ago, I consulted to a company that had this precise organization. They were going to “revolutionize aerospace.” Only the product managers understood the aerospace information. The developers had no domain expertise and they were several timezones away. The developers had worked together before, but had never worked with testers. They had never seen the need. They had never worked on a regulated product before.

When I suggested they had “unknowable unknowns,” and that their risks were higher than they thought they had, the senior management laughed at me. I told them yes, agile was fine, but I thought they should use one- or two-week iterations with kanban boards to expose their bottlenecks.

They ignored my advice. The company went with four-week iterations, spent a pile of money, had no product to show after 18 months. Oh, the developers bandied words such as “refactoring” and “TDD” and “BDD.” What they did was BDUF (Big Design Up Front) because they had no idea what they were doing. The company went under.

What do you do when not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change?

Don’t panic! You work in ways to reduce your risk.

Stay tuned for Part 5.

Posted in agile | Tagged , , , , , , | Leave a comment