"Business Agile": Built Upon Sand

You’ll meet them where they are.
You’ll work with them where they are.
And when you leave, they’ll still BE where they are.

The Right Side is the Wrong Side

Looking around the Agile2017 conference, especially at what Chet calls “The Right-Side Lounge”¹, and what they probably call the vendor area, troubles me. The conference and vendors are more and more about “Business Agility”, more and more about tools like Jira, Rally, and Version One, more and more about big companies like Deloitte and Accenture, more and more about “scaling Agile” to the big company. “Agile” is less and less about Agile software development, the subject of the Manifesto. It’s more and more about “Agile Project Management”, which isn’t even a thing as far as I know.

Business Agility isn’t Agile Software Development

Similarly, when I skim the surface of the Internet reading what’s happening with Scrum and therefore “Agile”,² I see a lot to be concerned about. Again, it’s about “Agile Project Management”, and it’s being done very poorly. Organizations rename someone to “Product Owner”, parse their existing requirements document down to stories³, and start demanding that their teams go faster and faster. I call this Dark Scrum, as constant readers will recall.

This attention to “Right Side” issues loses the essence of the ideas in the Agile Manifesto. Worse, it often – I’d say usually – results in poor performance for the organization, and suffering for the people doing whatever “Business Agility” is.

We’re here about software

While it’s true that Agile approaches can be used to run your neighborhood bake sale, in many situations – I believe most situations – people are using “Agile” to manage software development. The present situation is out of balance: we’ve got lots of “Agile” and not much “Software Development”.

Agile software development is different.

Agile software development is different from what developers⁴ typically know. To be effective in Agile software development, developers and teams need to learn and practice certain development skills. These skills are generally not taught in schools, and most developers aren’t exposed to them in ordinary software development. While there are training programs available for Agile software development, the qualified instructors are very few.

Training is costly in time and money.

Even a decent beginner course requires a week of dedicated time, and the cost for hands-on training of this kind will be between $2,000 and $3,000 per student. That first week just scratches the surface. It provides enough experience and training to give a developer a taste of what the practices are and a taste of how well they fit the rapid-delivery style of Agile software development. The courses act as an invitation to months and years of advancing one’s skills. You can’t learn software development in a week, and you can’t learn Agile software development in a week either. The courses open doors, they don’t work miracles.

Time and money are hard to get.

At that cost in time and money, it’s unlikely that a large company trying to “go Agile”, will invest in training their thousands of programmers. While the payoff is there if they do, it’s not immediate and the initial expenditure is daunting. In most companies, it’s just not going to happen. More to the point, it isn’t happening.

Learning Agile takes an extended period of time.

A week of “CSD” or equivalent training isn’t enough anyway. It’s a great introduction, and the developers get a decent sense of what the practices are and how they fit together. But just as software development itself takes months and years before we’re good at it, the Agile practices need to be, well, practiced for quite a while as we make them our own. Most of us will benefit from help in the form of additional study or coaching, as we go along.

Without technical learning, Agile often harms both the enterprise and the developer.

To an increasing and distressing extent, the “Agile” approaches today, with the best of will, are creating an environment for software development which does not effectively serve the enterprise, and which is often literally harmful to the work and personal lives of the developers working under these approaches. Because developers are not yet skilled in the practices, progress is slower and defects are higher. Management’s expectations are not met. Pressure increases. Productivity declines still further. This is the vicious cycle I refer to as Dark Agile or Dark Scrum.

Weak technical practice is building upon sand.

With software as a critical component in the enterprise, building on weak technical practice is building on sand. Things will not go well. This is harmful to the developers, to the enterprise, to Scrum and Agile as ideas, and to the companies that teach and support Scrum and Agile.

Right-side Agile is not good for anyone.

Remember, specialized skills are needed.

Reviewing, developers require specialized skills to work in an incremental, iterative fashion. They need to be able to start with a simple design, and to elaborate it smoothly as development goes on. They need to be able to develop features, not just infrastructure, from the very beginning. They need to be able to deliver running tested software every couple of weeks. They need to learn how to select the right amount of work from the Customer’s list, and to reliably complete it. They need to learn to do all this, every two weeks, without slowing the pace of delivery and perhaps even increasing it.

This is not easy. It is not something developers are born knowing how to do. The current way of trying to fill this need is a course that few people even attend, and that is only an introduction. We need to do better somehow.

Agile’s current direction is not helping anyone.

I’ve mentioned before that Kent Beck once said that he invented XP to make the world safe for programmers, and that that idea motivates much of what I do. The current direction of Scrum and “Agile” may be improving productivity a bit, but that direction is not improving the lives of people on the development teams. Often they are making things much worse.

Self-directed learning is critical.

To its credit, the Scrum Alliance is working to generate a focus on life-long learning for people doing Scrum. There are plans forming for introductory material, new courses, new levels of certification⁵. There is an increased effort toward educating organizational managers and leaders, which may someday cause trickle-down of a more true form of Agile. This is good, because the success of the ideas depends on people learning more and more about them and how to apply them.

Certification is lucrative.

Currently, someone who offers the Certified ScrumMaster certificate can often teach as many courses as they want, charging as much as $1000 or more per student. Even the lowest-cost CSM course brings its instructor from $3000 to $5000, which is pretty decent pay for two or three days’ work. For at least some trainers, the CSM has been a money machine. I don’t begrudge them this, because the course attendees get far more than their money’s worth if they apply the ideas they hear about. It’s worth it.

The economics must change.

As we try to guide people toward life-long learning, it’s unlikely that they’ll spend a few thousand dollars every year for more Scrum training, even though that might offer good value for money. The need for different economics is true for those in management or product management. It’s far more true for the people on the development teams. Few companies are going to shell out $2000 and a week of time in courses, every year, for ten thousand developers. To attain life-long learning, people will need to read books, watch videos, undertake on-line courses, all at much lower cost than in-person training.

Unfortunately, selling inferior Agile is too lucrative.

Scrum and Agile training and coaching are big business. There has been a trend toward consolidation in the first and second tier Agile companies, and as those become larger, the quality of their offerings does not always improve. In part this is simply due to the lack of people who have actually experienced Agile ideas at their pinnacle. If all you’ve seen is “pretty good Agile”, you’re not likely to take people to really awesome Agile. And now, we’re seeing big consulting firms “merging”⁶ with those consolidated firms. This may spread a little bit of Agile Jam into the consulting company, but it’ll be getting thinner and thinner. We need stronger Agile Jam, not weaker.

You’ll meet them where they are. You’ll work with them where they are. And when you leave, they’ll still be where they are.

Big “Agile” organizations need vast tracts of money. They can’t stand on principle. They can’t demand the kind of significant change that Real Agile™ requires. By the nature of their business, they’ll engender compromise between what needs to be, and what their clients find palatable. Heck, even the moderately-sized first and second tier companies compromise. Even individuals compromise. Even I compromise. We tell ourselves that if we get kicked out, the customer will get no benefit, and if we stay they’ll get some benefit. And we’re right. And as we do it, the quality of “Agile” declines more and more.

Arouse in the other person an eager want.
– Dale Carnegie

I believe that if “Agile” is to improve, it must be at the hands of people who are doing it, not at the hands of those who are selling it. The sellers will say “don’t confuse selling with installing” and conclude that they can say anything to get in there, say anything to stay in there, so that they can “do some good”. Maybe they’ll do some good, I don’t know.

What they are unlikely to do is to engender the real change that Real Agile™ requires. What they are very unlikely to do is to get tens of thousands of development team members set on the path of learning the many things they need to know if they’re to really deliver the possible benefits.

Somehow, we need to arouse, in the real practitioners, an eager want to know more, to do “Agile” better and better, learning and practicing and enhancing their skills. And at the same time, we need to make the available materials affordable, easy to access, and able to be consumed at one’s own pace. Some of those things are out there. I’m thinking of things like the videos and web materials of people like Joe Rainsberger, Jim Shore, Jeff Langr, and others. There are somewhat affordable, very good materials available from Industrial Logic⁷

Though I say it who shouldn’t, there’s even the very affordable Agile Mentoring Slack group, where you can talk with me, with Mike Vizdos, and with a growing number of your fellow practitioners.

Instead of spending thousands for a week with Joe or Jim or Jeff or even me, you spend “Pandora Money”, Spotify Money”, “Apple Music Money”, “Tidal Money”, and you get access to huge amounts of material. But it’s going to take lots more material, and there needs to be some way of finding the material you need, ideally in some kind of curated fashion, so that you can be pretty sure how it fits in with Agile ideas, and how close it is to the center of those ideas.

Furthermore, it’s going to take real support from organizations like the Scrum Alliance, and its trainers and coaches. They’re going to need to see that they cannot fill the need with in-person contact at thousands of dollars a day, and that the need must be filled. They’ll have to begin to push – to sell – ideas, support, and products that don’t bring them direct revenue. The payoff is there for them in the longer term. If Agile ideas are applied well, they’ll tend to work, organizations will be more successful, and there will be more demand for the hands-on training and coaching that will remain quite important.

Unfortunately, unless those organizations and individuals get behind this smaller more incremental model, Scrum and Agile efforts will continue to deliver bland results, continue to engender Dark Scrum™, and the high-income market will not thrive. I think that’s the path we’re on today, and I think that path needs to change.

How can we make this happen? How can I help? How can you help?

Notes: