Library of Alexander

Sunday, June 16, 2013

For the last few years I have been hearing one basic question with increasing frequency, "How do we scale Agile?" More specifically, how do we scale agile product development for a single product across more than a handful of teams?I can't help but wonder if we should instead be asking ourselves a different question all together: Should we scale Agile?What Agile frameworks like Scrum point out is that it can be incredibly difficult to scale development beyond a couple teams. This has nothing to do with an inherent inadequacy of Scrum, it has to do with the fact that the communication overhead required to coordinate the activities of multiple teams increases at an exponential rate. The percentage of investment dedicated to coordination continues to rise with each additional team involved in an effort.Maybe the first question to answer when considering how many teams to dedicate to a product is: Is increasing the size and complexity of this software development effort worth the additional value we will create for users of our software?

I have seen scarce few examples of massive development efforts that create a level of value commensurate with the size of the team building it. But maybe I just haven't been looking in the right places. What do you think?Update 8/23/2013: Just discovered Martin Fowler's opinion (at least in 2003) about the same matter at http://martinfowler.com/articles/canScaling.html. Reminded that I need to spend even more time on his site! It is a truly great resource.

Monday, June 3, 2013

Prediction: Enterprise software, as we know it today, will be largely dead in five years.Specifically doomed is the model at companies like Oracle, where hitting revenue targets has become significantly dependent on the persuasiveness and drive of a sales force that is more than 50% of its total employee count (As of December 2012, Oracle's sales force was around 63,000 strong, compared to a total employee count of ~118,000). More on the larger trend in a later blog post.Earlier this year, Oracle announced that it had missed Q3 revenue, and blamed that miss on its sales force and a lack of urgency. As a product-focused guy, it feels weird and a little scary to pin my success on my sales force's sense of urgency?John Burke, Oracle's group vice president for global sales support and new product introductions, attributed this to his observation that "salespeople don't often know the real stories behind why their customers bought and how their customers actually use their products." They are too far removed from the software to actually know its value to users and customers. Their goals have been reduced to hitting a number, rather than delivering value to customers.This is not a unique perspective. Former employees have echoed the same sentiment on public forums for years. Even the employees that seem to like working at Oracle betray its lack of customer-focus.The writing is on the wall, and has been for some time. Success in enterprise software will be led by a shift in focus back to the customer and the user. Back to people wanting to use your software, rather than being convinced to. Back to driving value for customers.If Oracle and other legacy enterprise software companies don't change their focus, there are plenty of customer-centric companies that will happily displace them in enterprise IT stacks.

Monday, February 25, 2013

On January 25th, 2013, Wired published an article by Leslie
Lamport describing the need to build software like we build houses. This wasn’t the first time I heard
this argument, but I was surprised that a publication as forward-thinking as
Wired would publish such a backwards-looking article. It absolutely doesn’t
make sense to build software like we build houses.

In his article, Lamport describes the need for
specifications to help software developers “think clearly about what we are
building.” Strangely, he seems to think that programmers don’t like thinking. In
my experience, programmers are proud to do work that is so cerebral, and they
enjoy opportunities to think deeply about their work. Another surprise is
Lamport’s conflation of thinking and specifying; the two are hardly one and the
same, and there are more ways to think than by writing specs. In general,
though, Lamport’s point is that software should have specs so that programmers
won’t make mistakes and software won’t be so hard to change.

Lamport’s overall argument is weak; he tries to make points
through metaphors more often than he does through logic. I won’t dwell on this,
though, as it’s been covered at length in the article’s comments. Instead I will point out what is implied by and missing from Lamport’s
apparent worldview.

Lamport's Worldview

Lamport seems to believe that making mistakes is a big problem
in software development and that writing specs is the best way to avoid it. This
thinking rests on the assumptions that the writer of the spec knows exactly
what the final state of the software should be – what it should do and how it
should do it. It assumes that requirements are fully understood, technology is
fully understood, and business conditions do not change. Over the past few
decades, the software industry has come to realize that this is not often the
case. I’m surprised that Lamport hasn’t
been made privy to this discovery, and I wonder whether the nature of
his own programming work at Microsoft Research has somehow shielded him from
it.

The software industry now understands fairly well that processes
with up-front investment in things that aren’t working software – things like
specs – work great for situations like accounting, cooking, and building
houses. Some people call these “defined process control models.” These
processes, while great in other industries, fall down on their faces when it
comes to software development, where we don’t often have a lot of certainty
about what we are building in, or how it will be built.

The Modern Worldview

In software we look instead to the empirical process control
model, which emphasizes inspecting and adapting (i.e., feedback loops) instead
of planning and then executing. This is what’s called for when we don’t know exactly
what our work product will ultimately look like or how it will work.

In empirical processes, instead of being asked to clearly
and unambiguously describe the exact output desired, a customer describes what
needs to be accomplished. Developers work in short iterations to incrementally
build what is needed, involving the customer all along the way, until the necessary
solution is discovered. The result of
these processes is typically better software.

Programming is Nothing
Like Housebuilding

Building a house is arguably uncreative work. We can
categorize houses fairly simply based on their attributes and current state of
degradation. Houses, for all their variations, are largely the same and
generally serve the same purposes for anyone that lives in them.

Software development, on the other hand, is incredibly
creative work. The process of developing any two pieces of software will be
quite different, as will its ultimate outputs. Thinking one can accurately
define the exact output of a software development project is at best ignorant
and at worst arrogant.

We can’t know exactly what will be created at the beginning
of a software development project and that is okay. Instead we involve the
customer in the process so they can see exactly what is happening as we move
along. Lamport might call the evolution of the software in concert with
customer feedback a series of mistakes, but anyone who has developed software
this way knows there is actually incredible value in these iterations. Users
don’t need to visualize how the software will work because they can actually
use it after each iteration of development. And neither they nor developers
have to waste time investing in specs that will rapidly become obsolete.

And despite what Lamport said, well-built
software is incredibly easy to
change. Using techniques like TDD allow us to leverage the strengths of
software creation, and avoid the limitations inherent in the production of
physical objects.

Thursday, May 10, 2012

I greatly enjoy watching high-performing teams, in all walks of life. Watching a team function at such a level is like watching a choreographed dance. I recently watched the local hockey team playing at home, and they were a great example of this seemingly effortless efficiency. The team functioned so well that you might be tempted to assume the whole game was a carefully rehearsed act. There were certainly conflicts (it was hockey, after all), but the individuals on the team seemed to function as a single unit in pursuit of its goal.

It takes a lot of practice to get to the point where people can work together efficiently. Unfortunately, high-performing teams seem to be all too uncommon, and teams that can sustain their high performance over a long period are almost non-existent. So how does a team achieve a high-level of performance and sustain it for the long term?

A New York Times article(1)that I recently re-read a few days ago on sustaining human relationships -- in particular, marriages -- caused me to revisit this idea.

The article reminded me of a high-performing team I had the good fortune to work with years ago. The team had been incredibly successful for a long time, and members seemed to be almost selfless in their support of each other. The sports analogy would be a team with a high number of assists, fairly evenly distributed amongst the team members. The article suggests that the success I saw might be explained by the self-expansion model(2) of psychology, which says:

People are motivated to increase their physical resources, social resources, knowledge, perspectives, and identities.

People achieve this motivation by forming close relationships in which their partner's physical resources, social resources, knowledge, perspectives, and identities are treated to some extent as their own.

What this says is that people are self-interested beings, but that self-interest is partially satisfied by the knowledge and resources of his or her partner - or in the case of a member of the team, their teammates. If individuals on teams can begin to identify the skills of their team as their own, they see themselves as more valuable and capable as part of a team than individually.

Once team members can identify the skills of their team as their own, those individuals can support their own development by supporting the development of their team members. The more self-expansion a team member experiences, the more committed to and satisfied with his team he becomes. And it isn't unreasonable to expect that the team with these dedicated, high-performing, and satisfied individuals would be higher performing as a result.

So how do you support self-expansion on your team? Some things I have seen that seem to work include:
- Recognizing capabilities of the team, rather than of individuals.
- Supporting collaboration.
- Helping individuals establish personal goals to improve themselves, and help the team support the individual in achieving those goals.
- For software teams, minimizing technical debt so the team can work on more new and exciting things, as opposed to bugs and maintenance tasks.
- And finally, ensuring your teams have established methods for dealing with stress and conflict to prevent motivational erosion that comes after a team has been together for a long time.

The above might help you develop teams that support each member's desire for self-expansion to help create meaningful, satisfying and sustainable jobs, for committed team members, on sustainable high-performing teams. Teams that you would actually enjoy watching work.