We continue to see a lot of “Agile” proponents and coaches offering simple approaches, modern approaches, personalized approaches. That’s good. They tout their approach as if it were quite generally applicable. I’m not sure that’s quite as good. There are two reasons. First, expert coaches are expert. Second, structure helps, especially when you’re new and on your own.

Expert Coaches are Expert

First of all, if you can get an expert coach on board, it really doesn’t matter where you start or what your approach is called. An expert coach may have a few tricks close to the top in their bag, but even if they do, they’re expert coaches and they’ll look at your team and see quickly what’s really needed. And if the thing at the top of the bag doesn’t work, they’ll help you detect that and they’ll help you decide what to do next. And if they’re really good, all the time they’ve been helping you, they’ll be sure you’re understanding the issues and choosing the things to do, albeit in the presence of great advice.

Simple but not easy

There is a problem here. Many expert coaches are so good, and so immersed in how to do Agile well, that they forget that Agile is simple – but it simply is not easy. They forget, in their skill at helping the team decide for themselves, that the team isn’t even remotely doing it by themselves. They’re doing it while immersed in a walking talking ocean of Agile skill, observation, and thinking.

We did X and got away with it.

Together with that, even the greatest coach (I assure you: I know that individual) is vulnerable to thinking that something they did actually worked, was valuable, and should therefore be done again. They may well be right: but they may well not. “We did X and were successful” does not imply “X helped us be successful”, much less “X is the best choice we could have made”, much less “X is therefore something that you should do”.

So the trap that the expert coach falls into is to imagine that since it went so well when they were there, and they feel they did so little, and they feel that their four-sentence writeup of Everything Agile is so good … that any team that gets the sticker will do just fine.

My belief is that a randomly selected team who are interested in Agile and know what a randomly selected team knows will do better in a more structured situation than left to their own devices. Even if they have some cool stickers.

I could be wrong, of course.

Structure Helps

The two straw man ideas that come up in discussion are of course Scrum – which is a competitor to most of the people chatting – and “kanban”, which is an open idea with the great advantage that you can start doing it without actually doing anything other than maybe drawing some squares on a whiteboard.

With “kanban”, you get no Agile guidance, nor does the process itself push you in some of the Agile directions that give important payoffs. You do get some real advantages like the suggestion of limiting work in process, and looking at the delays in your value stream. These ideas may not come up with other approaches. Or they may, depending on what you read and who you know and listen to.

I’m thinking of a team on its own.

When I recommend things, I’m generally thinking of a team, chosen at random, with no on-site coaching, probably not yet entirely cross-functional, not particularly educated in Agile ideas, not particularly adept at Agile practices, but interested in trying to do better, and open to the idea that “Agile” is likely the direction to try. Beginners, in other words. And I’ve met a lot of beginner teams and have a pretty good sense of what they’re like.

I’m thinking about me, with so much still to learn.

And, when I recommend things, I think about myself. When Agile came along, I’d been developing software with teams for 35 years, and had done so very mindfully, reading everything I could on process, and trying all the ideas that came by, with a mind to helping the teams (and myself) to improve.

Then came Kent Beck, Ward Cunningham, Alistair Cockburn and other people who would one day be the founders of Agile. And I, with my three and a half decades of experience, my Masters degrees, my millions of dollars in software sales, learned things. I learned things I had never imagined. I learned things that I couldn’t believe were even possible.

Now I may be wrong, but I think I’m fairly clever, and if there are things in Agile that I never thought of, I suspect that a lot of other people will also not think of them. And as for things I didn’t believe … I had to see those to believe them.

I always imagine everyone is like me.

So when I imagine a randomly chosen team at some randomly chosen bank or insurance company or IT shop, I expect it to be populated by people more or less like me, who are bright and learning and still have not imagined what’s possible when you really learn to do Agile well. And if that team is uncoached, as most teams are, I want them to have the best possible chance to learn and to begin to experience what this stuff is.

So if one alternative is “start where you are and try to improve” and the other is “start with a cross-functional team with a business connection, plan and build in one- or two-week cycles, show everyone your real, running, tested software after each cycle and after each cycle sit down and devise real ways to improve” … well, I’m going with the latter. Let me emphasize that:

My suggested starting point, especially for uncoached teams, is: “Start with a cross-functional team with a business connection, plan and build in one- or two-week cycles, show everyone your real, running, tested software after each cycle and after each cycle sit down and devise real ways to improve.”

But we just can’t start there …

And, before you stop me with “but not all teams can start there”, hey, this is where I believe we should start. These are goals. If we can’t start there, these are clear goals to work toward. Are we not cross-functional? Are we not retrospecting? Are we not able to deliver software in a week or two? Well, then these are things to work toward.

Now, if some excellent coach is there, it won’t matter whether the team have these goals: the coach has them, and many others, in their bag of tricks. They’ll bring the lack of concrete running software to the team’s attention, or the need to review how things are going, or the need to have close contact with the business. They’ll bring other ideas. Having a great coach is really wonderful.

Start there, or move there.
Don’t stop there.

But, by the hypothesis here, the team we’re talking to don’t have a coach. They just have our advice. You can advise them “Don’t use story points”, or “Be excellent to each other”, and those are both decent ideas. My advice is more concrete: cross-functional team, busness connection, deliver in short cycles, and running, tested, software. Start there if you can. Move there as fast as you can if you can’t start there.

And then, move beyond if you can. Increase the team’s ability to do more of the job; become more closely connected to the business and the customer; deliver daily or hourly rather than every week or so; reflect more continuously on how to improve. It’s hard for me to imagine wanting less of those things

Practices apply forces – toward success, and away

Every practice we use as part of our work puts forces on us, and generally those forces can push us toward or away from more successful ways of doing things. Let’s look at an example.

Cards encourage conversation.
Jira, not so much.

Consider the use of a tool like Jira compared to cards on a wall. The Jira tool allows and encourages people to update individually, and to refer to Jira instead of having conversations. “Put more information in Jira” becomes the response to the need to know more about what’s going on.

The cards on the wall won’t even allow for more information. And they can only be updated by people coming to the wall. And they can only be read by people coming to the wall. The cards enable conversation and they encourage it. Arguably, cards require conversation.

But it’s not all one-sided.

Now Jira produces better documentation. Cards allow for the possibility that details will be lost. It’s not all one-sided. But because I value people working together, I would prefer cards on the wall as the place to start, because they’ll bring the people together, and, together, the people will figure out what to do about any drawbacks of the cards. The drawbacks of Jira will not so easily be resolved, because the people aren’t together, and because one gets a commitment to Jira because it’s a system, it’s standard, the boss likes it, and so on.

Funny story: I once got fired before lunch on the first day of a few day training consultation. The boss kept asking me about the desirability of an on-line system for keeping track of requirements and bugs. I kept saying no, cards on the wall. Turns out he had just paid $35,000 to buy an on-line system. Well, so be it. Cards on the wall are still my answer.

Point is, the practices apply both good and bad forces, and I choose the ones that seem to me most likely to encourage people toward an Agile way of working.

Now let’s quickly look at the practices of an approach like I recommend above, and the forces they apply. The approach looks a lot like Scrum. I didn’t invent Scrum but I like it and think that, done my way, it’s a decent place to start. We’ll use some references to Scrum, for familiarity.

Cross-functional team …
Invent it, or adopt it?

Scrum asks us to have a cross-functional team, capable of building a running tested increment of software without outside help. A key issue with this is even getting permission to form such a team. Kanban or a similar “start where you are” approach would let you work with whatever random team you have. You would discover soon enough that there were hand-offs and delays due to not being cross-functional. And you’d have a political problem on your hands moving people around. So it’s harder to start Scrum, but in doing so you have a big advantage. If you can’t start there, at least when you’re following my advice, or failing that, the advice of Scrum, you have “official” support in your desire to work together.

Connect with the business …
Now, or later?

Scrum says to have an empowered, responsible business-side person as part of the team. Again this is hard to do, but the result of doing it is that you increase communication with the people who want the software, and you have a better chance of having them take up their end of the responsibility, which is to choose what to do – and what not to do – to deliver the best possible product. A “start where you are” approach leaves the business-technical interface wherever it is, good or bad.

My advice is to start with a business-side team member. You’ll discover the need for it sooner or later, but why wait?

Slice features …
Or leave them as is?

Scrum has time boxes. The whole argumentXXX conversation that triggered this article started with a discussion of cadences … whether they should all be aligned with an iteration, or whether one could just do a sort of continuous flow kanban kind of approach. One big advantage to time-boxed iterations is that a typical team will have great difficulty getting anything done inside the one- or two-week interval, because they’re more likely used to building things over many weeks or months.

They could, of course, give up. That would be bad. But if they don’t, and they look around the Internet even a little, they’ll discover that the trick is to slice stories very thinly, so they can be done, not just in a week or two but in a day or two. And doing that produces an amazing result: the Product Owner (that business person who’s on the team) comes to realize that some parts of what they wanted aren’t worth doing, and they begin to manage the work by choosing what’s really valuable.

The result is that iterations improve the team’s performance by facing them with a difficult problem that they’d likely not even consider without them. And they improve the business result by causing the business-side people to see more clearly what’s important and what’s just nice to have.

You could get those same results starting without the Scrum-style structure but you’d have to discover the need for a business connection, solve the political problem to get them, then discover the ability to slice stories apart, then discover that some slices are less valuable than others.

It could happen, but it’s likely to take longer and quite likely – in my opinion – not to be discovered or to be quite difficult to do.

Time boxes, plus a commitment to ship visible software inside each time box, requires the team to learn something that’s well worth learning. If you start without that cadence, maybe you’ll learn it, maybe you won’t. My choice is to give the best advice I know, and that’s to start with a short one or two week delivery cadence.

Sprints do have disadvantages.

Now of course it is difficult to know just how much work to take on in a week or two. Sometimes you’ll select too little, sometimes you’ll select too much. The start-where-you-are folks, and folks who enjoy objecting to Scrum will tell you that if you just pull stories one at a time and do them, you don’t get into all that trouble with predicting, and no one can hassle you about why you fell short, or pressure you to put more into the Sprint than you think you can do. The odious “stretch goals” and all that.

This is entirely true. You can have those problems. Are they really problems with time boxes, or are they problems with managers? Is it best to set things up so they can’t arise, or is it better to encounter them and deal with helping the managers improve? It’s not possible to say, in general.

I do believe, however, that if a team does start out with a time-boxed iteration, they’re more likely to discover the need for small stories, and more likely to discover how small stories can be, on their own.

Of course, with a good coach, you have the advantage that you’ll be immersed in their understanding. They’ll know how to slice stories, how small they can really be, and they’ll help you learn it. That’s a great situation.

If you can have a really good coach, I’d say to go with whatever starting position they recommend. If you have to start on your own, I think you may benefit from time-boxes. But it’s up to you, and if you’re reading this, you have certainly heard about how small stories should be.

Show results.

I suggest that if you’re delivering a batch of working software every one or two weeks, you should review it with your stakeholders every one or two weeks. The one-or-two week cadence, if you’re using it, works best when more people around you are synchronized to it. Suppose, instead, you feel that your business stakeholders are only available once a month. Well, that means that each month, you’ll show them … what? Four weeks work, slightly out of date, since there are four weeks and a few days in a month.

The stakeholders will naturally ask what you’re going to show them next month, and the next thing you know, you’re working on a one-month delivery cycle instead of one or two weeks. That leads to a much more lax rhythm, probably leading to a slow start and a push at the end. The one month cycle doesn’t put as much pressure on the team – or the business rep – to slice down to nice lean stories.

You’ll continue to munch along, but you’re not likely to be as lean and mean as with the tighter review cadence. My advice is to do your product review right at the end of every iteration, and to keep your iterations short.

Pressure?

Let’s digress just a moment to talk about pressure. Too much pressure is definitely bad, especially when it’s provided from “above”. But a bit of pressure, due to carefully chosen constraints, is a good thing. In my view, time boxes can provide the right amount of constraint to help us learn. But that’s not always true and there are arguments to be made on both sides.

In the end, what matters is the team’s focus on learning, and having enough flexibility and slack to be able to learn. With that, it matters less where you start, because you’re always moving forward. So let’s talk about that:

Focus on improvement.

Naturally, you’ll do retrospectives. If you’re great, you’ll do them every couple of days, or even on some impromptu basis when someone gets a good idea. But the end of your delivery cycle always gives a special opportunity for improvement, because everything is wrapped up. Nothing is in flight, all the votes are in, and if you have also done your review, you have stakeholder feedback to take into account.

Sure, you can decouple your retrospectives to some other cycle if you want to, but you’re not going to remember the last iteration very clearly by the next one. My advice is to do a retrospective right at the end of every iteration, after the product review, not to defer it longer. And by all means, catch every learning moment before it flies away.

Perspective matters. Some issues need to perk for a while before they’re ready to be dealt with. This suggests to me that although some daily retrospecting is of great value, we might benefit from setting a cycle for a more broad outlook. Maybe we even set a quarterly cadence for a “big” retrospective. Check out the forest, get away from the trees.

Summing Up

First, be aware that many of the experts out there – and they are experts – seem to be saying that “Agile” is simple and easy, all you do is these few things and be excellent to each other. The thing is:

  • If you have a great coach who has years of experience, it may seem simple and easy. You’ll learn by osmosis and it may all seem smooth and obvious.
  • If you don’t have a great coach, even a good coach, maybe no coach at all, things are likely to be more difficult. There will be less good stuff in the air to learn from. You can still learn, but it won’t be so easy.

Second, if you’re interested in my views, and if you’re not why are you reading this, I would recommend, by a small margin, that a team trying to move in an “Agile” direction would do well to start with a Scrum-like thing, as listed above, because it provides some constraints that are hints about what to work for: close customer collaboration, shipping real working software, reflecting often, and so on.

I emphasize, a small margin. If a team feels strongly about starting “where they are” and following a kanban-style approach, well, I’d rather they did what they want than that they try to do something they don’t want to do. That said, if I could place a lot of bets on teams starting one way or the other, with no further information, I’d bet on the teams that start with structure, and I’d expect to eke out a small living, with a few more wins than losses.

It’s far from certain, but I’d go with structure over no structure, if there’s no coach. If there is a coach, listen to them and think. If not, well, listen to the world, and think.

Probably thinking is the most important thing. Well, thinking and shipping software. Good luck!