Tuesday, April 8, 2014

Agile, Post-agile, Beyond Agile... Where do we go next?

XP and Scrum and the agile methods are about delivering. Frequently. Sooner than that. More often.

In order to do that, there had to be a lot of adjustment. You can read the wonderful XP books (explained, installed, etc) from Addison Wesley, and you can follow a lot of the reasoning on the c2 wiki (you know where/what that is, right?)

They came up with a very simple system with almost no overhead compared to all the development "methods" or "methodologies" that preceded, and they delivered all the time.

Of course XP is offered for free with full disclosure (even caveats!) for anyone who wants it. No certification, no official certifying body, just solid results. Of course, it languished while other orgs who can afford more marketing and franchising opportunities went large, and now it is making a comeback.

XP practitioners were key signers of the Agile Manifesto, and I like to think that the manifesto values and principles are particularly descriptive of XP rules. I hope the comeback is big and noisy.

But as I look at the world, I see that there are a lot more ideas and practices that also contribute to simplicity and safety. Each of them requires a lot of change in how you think about the work you do, and how you arrange the practices and teams to support that work.

Continuous Deployment requires and provides a lot of safety, especially with all the work being done in devops and all the cool server tech and virtualization we have these days.

Lean Startup brought a lot of safety to the realm of product management. Suddenly it is possible to know more about market demand and fitness to need before you invest heavily in building a feature, and certainly along the path from MVP to fully-built-out features. All those options and pivots have helped many entrepreneurs launch successful businesses.

The beat goes on. The constants that predated Agile methods, that empowered and grew those methods, and which have gone well past their original moorings are safety and simplicity.

I think this is natural. I've noticed a path for technologies that goes something like this:
  1. Some activity X becomes possible which was unthinkable before.
  2. People rush to implement.
  3. People note the madness and competition, and try to build a solve-all comprehensive implementation.
  4. Sick of the complexity and learning curve of solve-all implementations, people rush to build a simple implementation that doesn't have all that "crap" in it.
  5. Sick of complexity and learning curve of the simple solution, people rush to build a simpler solution.
  6. Sick of the design flaws that make the simple implementation too slow to use, people rush to  innovate even simpler and more performant implementations.
  7. GOTO 1.
We started with 1. Our processes went through all these stages until we got to XP and its fellow travelers. But XP and Scrum were sufficiently magic to start a ripple again at 1, and people are rushing to make it more complicated and comprehensive for large scale companies.

Can we just cut to 6? Probably not. But most of us don't need to.

I wonder if maybe someday we'll be mature enough as a market to stop talking about waterfall, scrum, scrum-but, wagile, scrummerfall, scaling agile, etc. Maybe we can get to the point where we build our entire discipline on safely, simply, repeatedly delivering working stuff.

Safety and simplicity are hard. Simplicity requires more clear-thinking than most of us can afford, and safety requires us to admit that what we're doing is risky, and then requires that we make the effort to change our system.

Those who will bend themselves to the task, can get to steps 5 and 6. It's just work. 

A future built on safety and simplicity holds a lot more promise than one filled merely with stand-ups, ideal day estimates, planning days, and hardening sprints.

This is why I say that the only "post-agile" or "beyond agile" I'm interested in is work that takes the safety and simplicity that XP brought to us and extends it well beyond it's known reach.

How do we get there? I'll try to let you know how I am trying, and how about you tell me what you have in mind?

Wednesday, April 2, 2014

Ignorance + Inspiration = What?!

The goal is always to inspire, to sometimes ridicule the naysayers, to bolster confidence, what have you, and the form is fairly common:

For years we were harangued by the nonsense story that bees can't really fly according to the laws of physics, but they do it anyway because they don't know they cant. The real story is  less inspirational.

Bumblebees are not ignorance-powered. Probably neither is your team.

These little pro-ignorance platitudes are so common and well-shared that I even hear people bragging about how little they understand what they do, and that they don't read or research or study or even try to keep up. Because, as you know, that's not really important; all you need is ignorance, inspiration, stack overflow, and a fat copy-paste buffer.


I offer this alternative inspirational nugget:

I suspect that "ignorance + inspiration" is really not the surefire recipe for success that inspirational speakers and feckless back-patters declare it to be.

I want my kids to be prepared, attentive, experimental, brave, eager.  I think that all the wishful positive thinking in the world, taken alone, is not worth one RTFM.

A better pat on the back, IMHO, is "the world is far bigger than any of our heads, so lets figure out how to do this together." Experiment. Prepare. Read. Study. Try many things. Remember what worked. Show interest in why things didn't work. Practice mindfully.

It doesn't make for great one-liner inspirational quotes. It's unlikely to appear on a Hallmark card.

Thursday, March 27, 2014

Can I Start My Software Career As A Scrum Master or Coach?

I don't want to be a downer, but I need to give an observation (out of love) which will cause everyone to not like me for about a week.
Nobody is an expert "to begin with." It's to your benefit to let go of that idea.  You shouldn't be paid to lead/teach/coach things you don't know how to do. That happens too much in this industry, and it's a failure mode, not a career path.

But anyone can become great if they apply themselves and work with an open heart, paying attention to what works and what doesn't, what opens people up and what shuts them down, what comes from fear and what comes from love of the work.

I shouldn't be a javascript teacher tomorrow, because I have hardly any javascript experience. Rather than "begin my career teaching this language" I should go write a whole lot of Javascript and read a lot more than I write. I should read blogs, articles, books by experts. 

Then I should start teaching right away so that the students can help me discover my weaknesses -- and then I should work harder to improve. Teaching is a good way to consolidate and clarify the things you know, and a great way to reveal and expose what you do not.

If you have the qualities that make a good SM, you should work on *becoming* a professional scrum master by developing/growing/proving your raw talents and training. You should not start your software career as a professional SM.

Extra points, if you've worked in the field for years and are switching from management, testing, programming, etc to coach, SM, Trainer, or change champion. All relevant experience counts.

I am not here to dissuade you. I think we need more people leading the charge to build safer, stronger, simpler, more human systems that actually deliver value. There is no reason to put your plan on hold or to discard it. 

If you have the drive, I want you to chase the dream and settle for nothing less.
You can start your career toward being a change agent. I wish you well. 
If you instead start as a change agent, I wish your teams a speedy recovery.

Wednesday, February 19, 2014

3 Ways We Can Revive Agile

We recently started talking about Taking Agile Back.

I was surprised to hear how much response came from this. Now we have a community on google and presence on linked in and yahoo groups and twitter. People are coming from the woodwork to say that they're also sad about the state of agile practice and they either yearn to return to agile values, or they lament that they never were able to enjoy really practicing those values.

But what do we do?

I think that there are at least three immediate steps we can take.

  1. Remove barnacles
  2. Reinstate values
  3. Move forward

Remove Barnacles

The first is a tad negative. We should call out the things that have grown on the skin of agile (shallow, peripheral issues) and have obscured the heart of the principles. 

I've already addressed some of the noise that has grown up around velocity and estimation. I've been suppressing a number of opinions on metrics and disengagement. 

You can love or hate Linked-In, but I have found kindred souls there, teaching and answering questions and calling out practices that divert from the real goals of creating a human system that actually produces all the time. I think it's always good to have some time spend in dialog on the forums there.

There are google groups and yahoo groups where people ask good, honest questions, but they're often the wrong questions. It would be good to have people there to help scrape the barnacles from their view of the agile world.

You don't have to publish in magazines or blogs or even twitter. Scrape the barnacles where you live, where your teams are producing software today. 

While we have issues with some distracting practices, please be aware that taking back agile is the work of many people. If you make us seem to be all anti-whatever, then we'll always be fighting to beat the image of being a bunch of haters trying to return to the past. More on this later.

Reinstate Values

This is the good stuff. 

The first step to building the values is to live them intentionally. If you need reminders, visit the agile manifesto site and put a printout of the principles up on your own wall. Focus on being the most heartfully-agile person in your space. 

Then take to the streets. You probably have a blog or a twitter account. You probably go to user groups or company lunch-and-learn meetings. You could probably start some of these if you don't have them.

We need stories of how living these values changed our work, after all "working software is the primary measure of progress.".  Other benefits are important, but the overwhelming pragmatism of the agile approaches should get more play. Remember that XP was built on two questions:
  • What has worked really well in the past?
  • How can we do these things much more intensely?
As much as agile work has helped humanize the workplace, the practical advantages have always been the entree.

One warning, though; don't try hard to seem an expert. Instead, be very transparent and open-hearted about your goal of becoming more expert all the time. Always be in transition, and never even pretend to have fully arrived. The humility of a seeker will win you much more mindshare than the appearance of authority.

In this light, I'm planning to put together a positive blog this week describing how I have seen the agile methods pick up on rather old and new ideas and create greater project safety. I believe that agile methods are safer for developers, managers, customers, and all members of a product community. I'll tell why.

Move Forward

I don't want to return to the technology of the 1990s or the 2000s. 

I don't want to be answering questions that people are not asking anymore. 

In the time between the manifesto and now, the world of technology has changed. We need to carry our values into the future and even modify them if we find them dated or unhelpful. 

Now we have influences from Lean Startup, cloud computing, mobile development, social computing, mob programming, etc. 

If we aren't moving forward, we become irrelevant. I believe that these values are timeless, in which case they work just as well in 2020 and 2030 as they did in 2010.

We have a manifesto that still works. Let's all go manifest it.

Wednesday, February 12, 2014

I Want Agile Back

Are we getting tired of the kind of "agile" where you don't really have any particular technical practices, change (and improvement) is entirely optional, and you pretty much do waterfall with additional overhead of meetings?

Are we tired of seeing "sprints" and "iterations" used as ways to pressure people into working harder and longer, with no training or learning or even autonomy? Are n-week death marches the ultimate expression of our values?

Are we tired of the kind of "agile" that's all about buzzword compliance and rituals and motivational posters?

I know we can do better.

We've done better.

I want my "agile" back.


Tuesday, February 11, 2014

David Gray on Russ Ackoff

David Gray wrote a great article in a funny place, as a comment to a really great YouTube video.  

I took it upon myself to reproduce it here because you need to read it and I do too.

Dividing work.

Division of labor, as Adam Smith pointed out in the 1700s, has the potential to increase productivity. But division of labor also leads to interdependency: every worker relies more heavily on others to do her job, and as the number of handoffs increases, so does the potential for dropped balls. As the number of divisions grows, so grows the interdependence.  
This interdependence creates a need to synchronize and coordinate the work.
Traditionally this has been the job of management and bureaucracy. We coordinate the work through measurement and control.  
As you increase the number of divisions, you also increase complexity. One of the goals of these divided and interdependent systems is making work more efficient and systems more consistent, predictable and reliable. The goal in many cases has been a perfect system; a system that’s idiot-proof. If something can be automated, you automate it. If you can’t automate it, you constrain it to the minimum possible variation. 
Of course, the more idiot-proof the system, the more you will constrain behavior, forcing people in many cases to act like idiots, against their better judgment. Even when people know there’s a better way to do something, they will often be constrained by policies and procedures that were designed to reduce variety in the system. If your system needs to solve problems that you can’t anticipate, then you have a problem, because automated systems and idiots can’t solve problems. 
In addition, although dividing work may make the system more efficient, by dividing work into ever-more specialized tasks, we also disconnect people from the meaning and purpose of what they are doing. From their small, constrained box, people can’t see the big picture so they must make decisions and act within a very limited and constrained perspective.

Standardized, interchangeable parts.

Another core idea from the industrial revolution is the concept of, interchangeable parts. Standardization does make it easier to mass-produce quality products. Standards also make it easier to connect things. 
For example, having a standard for electrical sockets assures that you can plug in any appliance, and having a single standard for web links makes it easy for any web page to link to any other. 
We run into problems, though, when we try to apply standards to things that inherently have a high degree of variety: for example, a customer service call. Customer problems come in all shapes and sizes, and even problems that might seem very similar on the surface can be subject to a lot of variability based on the context. 
We have gotten so used to the idea of standards as a good thing that we tend to apply them in the wrong places. For example, consider the idea of a “best practice.” The concept of a best practice assumes that there is one “best way” to solve a problem: that every problem can be isolated from its context, and a single best way of solving it can be described and shared. Unfortunately, this has caused a lot of problems in the business world, because it’s impossible to isolate problems from their context. 
A system is not just the sum of its parts. What makes a system work is not the parts in isolation, but the interactions between them, and the inherent tradeoffs that must be made to achieve different kinds of system performance. Standardization is something you apply to the parts of a system, not a whole. A best practice from one company, or from one part of a company, cannot necessarily be applied successfully elsewhere. 
Systems expert Russell Ackoff points out that “If we have a system of improvement that is directed at the parts, taken separately, you can be absolutely sure that the performance of the whole will not be improved.” 
Ackoff illustrates his point with the following example:
“I read in the New York Times recently that 487 kinds of automobiles are available in the United States. Let’s buy one of each and bring them into a large garage. Let’s then hire 200 of the best automotive engineers in the world and ask them to determine which car has the best engine. Suppose they come back and say the Rolls Royce has the best engine. Make a note of it. “Which one has the best transmission?” we ask them, and they go over and test and they come back and say the Mercedes does. “Which one has the best battery?” They come back and say the Buick does. And one by one, for every part required for an automobile, they tell us which is the best one available. Now we take that list, give it back to them and say, “Now remove those parts from those cars, and put them together into the best possible automobile, because now we’ll have an automobile consisting of all the best parts. What do we get? You don’t even get an automobile, for the obvious reason that the parts don’t fit. The performance of a system depends on how the parts fit, not how they act taken separately.” 
What’s true for the fit of the parts of a system is also true of the fit between a service and the context within which the service is delivered. Every interaction with a customer is different: sometimes in subtle ways, and sometimes in profound ways. Two interactions that look similar on the surface may be dramatically different, in ways that are hard to predict. 
Consider a customer walking up to an airline counter who has already been bumped from two flights and whose luggage has been lost. These previous interactions will have a major effect on the context of the current one. 
Managers think that standardization is a good thing to do. If we standardize, goes the idea, our costs will go down. But if your interactions are highly variable, as most service interactions are, then the opposite will happen. Attempts to standardize the work will make costs go up, not down. This is because standardizing the work reduces the ability of your system to absorb variety. We try to cage variety into nice neat swim lanes: For example, voice menus in an automated voice system. But when there is a lot of variety in your environment, these kinds of control systems are exactly the way to make things not work.

Thursday, January 30, 2014

Agile and Waterfall: More Different Than You Think

This is a mostly-verbatim post from a LinkedIn forum.  I thought it was worth sharing with the audience here, so you can help me refine my thinking.

In the forum, another member suggested that agile and waterfall are opposite ends of a spectrum. He further suggested that a team can choose its own position along the "sliding scale" between the two extremes.  This is when it dawned on me that maybe I understand why this is not true. 

Please pipe in with your insights, extensions, or corrections.

It is possible that agile and waterfall are not two approaches to the same thing. If they were two approaches to the same thing, I think mixing them would make sense and the sliding scale makes sense.

If, however, they are two different systems with different axiomatic bases, then the reasoning that is productive in the one will be surprisingly counter-productive in puzzling ways in the other.

I suggest that the systems are axiomatically different. Agile values continuous delivery of value and responsiveness to market. Waterfall values a comprehensive plan and compliance to the plan until the final delivery.

These are very different axioms, from different places, and I'm not sure you can do much more than borrow practices from each other and repurpose them to entirely different goals and values.

  • Not having a long-term plan in waterfall is sheer madness. 
  • Having a long-term plan in agile is pathology people are cured from. 

  • Not knowing the scope of a waterfall project before you start it is inviting failure. 
  • Not knowing the scope of an agile project is perfect -- you have a basis for collaboration. 

  • A month pre-worrying and developing docs for waterfall? Not remotely enough. 
  • For agile, a month without producing anything but documents? Abomination! 

  • In agile, refining the software model and structure is the way you become successful. 
  • In waterfall, changing the structure and model mid-project is disastrous. 

  • Agile keeps planning short and shallow to protect market responsiveness. 
  • Waterfall is about "controlling" change to protect the plan. 

  • Agile tends to find its home in product development. 
  • Waterfall tends to find its home in project deployment. 

  • Agile deploys every day, or every week if it can't. Or bi-weekly as a fallback. A month is forever. 
  • Waterfall deploys at the end of the contract. 

  • Agile is about customer involvement and delight through innovation. 
  • Waterfall is about contractual obligations and proving compliance. 

Go ahead and pursue it, but I think this is not the first attempt (see SAFe and ScrumFall and ScrumBut and a host of other attempts to blend) and I think there is a reason those other attempts are unsatisfactory.