There’s a lot of whinging going on about imposing ‘Agile’ methods and practices. These whiners just don’t know how to do imposition correctly. Me either, but here’s what I’d try.

If, for my sins, I were condemned to be “in charge” of a software development organization, and somehow held responsible for success or failure, I would certainly want that organization to practice “Agile Software Development”, whatever that is. I would feel that to be my only chance.

Since it would be my survival at stake, going “Agile” would be necessary. I would of course advise everyone, educate everyone, try to lead everyone to go this way. However, my survival is at stake. If they don’t want to go Agile, well, I have no choice. I have to make them go Agile.

This would, of course, be bad. I don’t like to follow orders, so it is my personal rule never to give orders. Look up Veil of Ignorance in your copious free time. Look it up later, right now, we’ve got stuff to do here. If they don’t want to do Agile, I have to impose it.

How can I impose Agile and appease my admittedly pretty wimpy conscience at the same time? And which is the best Agile method to impose? Would it be best to impose a really simple one, like Scrum, or go all the way and impose something really comprehensive like SAFe? These are important questions.

My answer is “no”. Here’s what I’d do. I’ve written this as if I’m giving a presentation, with questions from the audience. If you have comments or questions, I’d love to hear them via email, on the Agile Mentoring Slack, or even Twitter. Twitter’s likely to get lost. Agile Mentoring is likely to have more back and forth discussion. Your choice, though.

How we’re going to build software here at XYZ

Hello everyone! Let’s talk about how we’re going to build software here at XYZ.

TL-DR, we’re going to build everything with small teams. By small, I mean most likely less than ten people, including all the necessary skills to build whatever we’re building. That will include domain experts and business experts, as well as developers. In some cases, a team may need to rely on a staff function, such as Legal or Finance, but the general idea is that each team has readily available all the knowledge and skill they’ll need to build the product.

What if there’s no one available with an important skill?

Three things come to mind. First, we’ll build our teams in priority order, and if we run out of some important skill, that will be a key indication that we’ve got too much to do. Second, I’m very interesting in helping people learn new things, and a shortage of some skill will be a signal that we need to build up in that area. Third, if the effort seems really important, we could staff for it. What we’ll try hard to avoid is dividing people between efforts. That’s not good for the people or for the effort.

What about small ongoing efforts, will they each get a team?

Most small maintenance will be associated with a product, and that product’s team will do the small stuff. It’s possible that we’ll have some kind of small ongoing things that aren’t associated with a product. I don’t have a strong opinion on how those should be done, and will likely leave it up to whoever owns that product responsibility. The main idea will be to focus on the important things and streamline that work as much as possible. We’ll discuss small but important items when they arise, and figure out what’s best.

What about big products that need more than one team?

Sometimes we might actually partition the product itself. We could split out credit and debit processing from the accounting function of our home accounting software, for example. Then we could have a team for each. Or we might consider the product to be integrated and assign two teams. I plan to be guided by you people, and the need.

What if we really need one big team?

My take is that teams lose effectiveness as they grow. So we’ll be working to keep them small and split them when they start getting too big. We’ll be guided by experience and the situation, and work out what’s best for the people, the product, and the organization, pretty much in that order. Maybe there’s something that requires one big team, but frankly I think that’s not the case, and we’ll work to avoid it.

What will these teams be doing?

Basically, we’ll typically have a single business- and product-focused team with the authority and responsibility to build one (or more) of our products. By working with actual customers and users, each team will determine user needs and solutions, and build them. They’ll have an overall product vision that we can all understand, and we’ll review the actual software very frequently, examining what it is, how well it works, how well it satisfies the users. We’ll discuss what the team should do next, and the team will decide what to do and do it.

How will decisions get made?

Over-simplifying, we have two basic axes of interest, the success of the product in pleasing our users, and the many technical details of devising and building solutions to the customers’ needs. There’s a fairly clear divide, at least in my mind, between customer-facing activities and what I’ll call technical activities. Right now, that’s reflected in our Product and Marketing organizations on the one side and the Development organization on the other side.

However, what’s needed and how to do it are intertwingled, and frankly, I’d like to see those divides removed wherever possible. Let’s consider a one-team product for simplicity. I’d like to create a new single team, with people from Product and from Development, who are dedicated to that product. Their combined mission is to create a viable return for that product.

Yes, but how do they decide what to do?

I was getting there. If it came down to a tough call of providing this capability or that one, I guess I’d say that call belongs to the Product person. In my mind, I call them the Product Champion. However, if it ever did come down to the point where the Champion had to make a call, I would consider that to be a bit of a failure. Their job is to have the expertise and understanding to lead the team, not to command it. And they should be building the team’s understanding as well. I’d very much prefer to see consensus decisions, or at least consent decisions, rather than commands.

Isn’t that rather idealistic?

Yes, it probably is. And it’s what we’re going to learn to do, because all of us are smarter and stronger than some of us. But there’s more. Let’s talk about the development cycle.

We’re in the business of meeting customers’ needs with software. That software’s job, of course, is to serve the wants and needs of our customers. Since software is what we’re up to, that will be the primary focus of our management and guidance of our efforts. We’ll focus on the product: what it is, how it’s changing, how it’s accepted. The way we do that will be different from what some of you are used to. Others in the organization will recognize these ideas, because they’re already doing them or are on the road.

The rule is this: Every product team will be responsible for having a ready-to-ship, integrated, working, tested product all the time, containing all the solutions that the team has chosen to be in the product.

Every couple of weeks, your team and its stakeholders, including me, will get together and review your product. You’ll call our attention in particular to the new features and changes. We’ll discuss the market, the customer needs, the possible next steps and you’ll use that discussion to inform your future decisions. Based on that feedback, you’ll decide what to do next, do it, build it into the product, and we’ll meet again in a couple of weeks.

Wait! We’re supposed to put out a new version in just a couple of weeks?

Yes. This is perhaps the most difficult part of how we’re going to be doing things. Some of our current products are very light on their feet. Some, especially some of the older ones, everything seems to take forever and we can only release a version every six months or even more. So that means our bi-weekly meetings are going to be rather boring. I’ll ask to see the product, the Monolith team show me the same old current version, I’ll ask what’s new, they’ll say there’s nothing new in there. I’ll look sad. They’ll try to tell me that yabbut there’s some really good work going on Version Next. I’ll ask if it’s working, integrated, tested, running, ready to ship, and in the version in front of me. They’ll say no, and I’ll say then don’t tell me about it, I’m only interested in what we can put in customer hands right now.

I might even be a real jerk about it and build a dashboard or some charts, showing other products adding some features every two weeks, and showing the big monolith not growing at all for months at a time. Frankly, the Monolith team is going to be embarrassed.

But we can’t do that! We can’t add stuff every two weeks.

If the team doesn’t know how to build a version every couple of weeks with at least one new thing in it, we’ll get them the help they need to learn to do it. My experience suggests that mostly, they already know what they need, they mostly need a little time to get into that mode. But whatever it takes, I’m sure we’re going to solve it, because the Monolith team is pretty expensive, and the company deserves to see what they’re up to and to get the benefits of the work sooner than six months out.

I’m very committed to this. I’ve been doing this kind of work for a long time, and every time, I’ve found that the team can find ways to ship new value every couple of weeks. Possibly there is an exception, and if there really is, we’ll deal with it. But we’re going to assume that every team can product an increment of software every couple of weeks, and we’re going to invest whatever it takes to make it happen.

Now let me ask a question myself, so that no one in the room has to stick their head up too high. “Ron, this sounds as if you’re trying to ram some kind of Agile process down our throats. What if we don’t want to do it?”

Good question, Ron. But the fact is that I don’t intend to ram anything down your throats. I don’t care how you build the software, at least not much. I do have a lot of experience, and some decent ideas about ways to do it, and I’ll make experts available to you to help you do what needs to be done. But I am absolutely not telling you what process you have to use.

What I am telling us–all of us–is that we’re going to measure our product teams based on their ability to literally deliver value every couple of weeks. To the extent that a team can do that, they’ll look good, and to the extent that they can’t, they’ll not look so good. And we’re going to invest whatever it takes to make it possible for every team to look good by that measure. With some teams, it may take some time. As they get better at doing it, they’ll look better. Once a quarter is better than twice a year. Once a month is better still, and it’s nearly every couple of weeks. I have reason to believe we can do this and I’m committed to providing what we need to make it happen.

The bottom line here is that we’re not imposing a process on anyone, though we’ll help you improve your process if you need and want help. What we are doing is providing an enabling constraint on what you produce, not how you do it. Let’s talk about why.

I want to succeed here, and I want all of us to succeed, and I want the organization to succeed. We’ll do that by providing solutions to our customers that they need, appreciate, and will pay for. Their needs change, the market changes, our understanding of what is needed and how to do it changes.

If we can only offer new value to our customers every six months, they’ll benefit slowly, we’ll benefit slowly, and, worst of all, we’ll learn slowly. That puts us all at risk. We need to speed up our cycle of learning and our cycle of delivering value. The foundation of doing that is to provide visible increments of value, which we can see, talk about, learn from, and provide to our users.

Sometimes doing that will be easy. Sometimes it will be more difficult, but we’ll work and learn to make it easier. We’ll work it out together, and we’ll benefit together.

Won’t this put us under incredible pressure?

My intention isn’t to increase pressure, but to reduce it. I don’t believe that pressure helps us work better, but that it’s more likely to cause trouble and slow things down. There will be learning involved, lots of it, and sometimes learning is painful–wow do I know that–but we’ll try to keep the pain and pressure as low as we can. And I’ve found working in the way I’m asking to be fun, and I surely hope to make it more pleasurable for everyone.

To have time to learn, people need some slack. I’m well aware of this and committed to it. I do expect that we’ll all work hard, but we won’t be trying to fit ten pounds of work into a five pound sack. We’ll find a sensible balance between progress and learning. If you find that you, or your team, are out of balance, I want to hear about it and I will work to fix it.

We may encounter some emergencies and have to bear down a bit. Life seems to work like that. But every day can’t be an emergency, and we’ll invest to keep that sort of thing to a minimum.

What about long term planning?

I do expect each team to have a coherent current view of where it thinks its going. We can call that a plan if you wish.

Your plan should speak in terms of the needs of your customers or users, and the solutions you plan to provide. It should tell me enough to get a good sense of the need and the solutions you intend. We’ll work together to improve the communication.

However–and this is very important–we’ll not be measuring you on following your plan. We’ll be measuring ourselves by how well what we actually do satisfies our customers. Part of your continuing work is to suss out what your customers want and need, to provide solutions to those wants and needs, and to be on top of how satsified your customers are with what you’re providing.

The way I think of it is that each team has a view of its surroundings, and where it wants to go next. Each time something new is built and deployed, the team is in a new place and now has a new, different, and more complete view. I expect your team to have such a view, to keep it current, and to communicate it with your stakeholders.

What should that view look like?

Honestly, I don’t think we care what the view looks like. I’d prefer not to view an hour of PowerPoint slides, so I advise against that. But if that’s the best way to communicate your view, I’ll try to deal with it. Your team owns the problem of creating and communicating the view, and that includes finding out from your stakeholders how well the view is working for them.

I’m sure we’ll come to have some favorite ways of presenting the view, and I’m hoping that Grand Opera will not be one of those. That would be even worse than PowerPoint.

Summing up, we’ll be creating customer and product focused teams, with the full responsibility and authority to address some set of customers and customer concerns. Those teams will create a rolling view of the customer and product landscape, and they’ll decide what to build next based on that view. They’ll produce new versions of their product every couple of weeks. They’ll share what they’ve created with their stakeholders every couple of weeks. We’ll talk about the current view and the current product, and about what to do next. The teams will decide next steps and repeat.

Our focus will be on creating concrete new solutions for our customers every couple of weeks, reviewing those running, tested, shippable solutions, getting them quickly into the hands of our customers, and using results to guide future decisions.

Any questions?

This still sounds like you’re imposing some kind of “Agile” process on us.

No. I am, however, setting forth, as clearly as I can, the results we need to see from whatever process you use: an improving view of the customer and solution landscape, rapid production of customer-ready solutions to their needs, and continuous communication as to what’s going on and how it’s going.

As for the process you use, we are imposing nothing. We’re asking for a certain kind of results, which the company needs, and we’re committing to helping you learn how to produce those results.

Isn’t this just some kind of covert way to force us to go “Agile”?

Well, we’re asking for running, tested, shippable software every two weeks, delivering what you set yourselves to deliver two weeks ago. It does happen that I only know one basic way to do that, with cross-functional teams with all the needed capabilities to do the job. It does happen that I believe those teams will find comprehensive unit and acceptance tests to be key, that they’ll want to learn to evolve their designs smoothly with refactoring that they’ll need to keep their systems integrated all the time, and so on.

Since we’re setting a two-week planning and review cadence, you may want to consider adopting process elements that are conducive to that, and you’ll likely find them in the “Agile” thought space. I’m sure you will be able to find many ways to do that, and can point you to some options if you need them.

But you are absolutely free to use any process you want, so long as you’re giving us what we need: a clear product view, and shippable product every two weeks.

My intention is to give you everything you need to give me what I need to ensure the organization’s success. And what I need is running, tested, shippable product, built according to an evolving view of customer and solution, every couple of weeks.

Any more questions? You know where to find me.