Feb 062014
 
Ed Sumerfield and Chris Nelson of Gaslight Sof...

Ed Sumerfield and Chris Nelson of Gaslight Software presenting “Why Agile Fails” (Photo credit: RubyNuby)

How the fuck is this coming around again?

George Westwater on Waterfall

Every so often, someone will put forth the idea that agile practices are great and all, but they fail at certain things like providing an up-front budget, a well-researched scope before work begins, a full project timeline with milestones, etc.  These sorts of things are such staples to the way most orgs approach their projects that there’s a certain tension to make agile practices better at providing them, and the path of least resistance to trying to supply these is to use the practices that used to provide them – typically some type of phase-gate approach like Waterfall.  You hear things like this:

  • We complete all the requirements and design up front, but then we do our development in an agile way.
  • We do agile, but in a way that can be managed with Microsoft Project.
  • We’re agile, except we do our testing at the end, but at least we release every six months.

And so on.  The basic idea is that doing a project without these traditional Waterfall additions is somehow inherently more risky or will fail to provide a company what it needs to make intelligent project decisions.

I’ve already spent a lot of electronic ink on this blog talking about how the benefits Waterfall purports to offer are largely illusory (kind of like the illusion of security offered by being employed at a large company) and how various agile methods can actually do a better job at providing intelligence to the business, so I don’t want to rehash all that.

However, the point I want to make here is that Waterfall and Agile arose from very different systems and operate off very different assumptions about the work.  For instance:

Waterfall’s Assumptions

  • The work to be done is mostly static.  Changes are rare and always occasion for re-examination.
  • Business needs / the market is not volatile; our priorities and methodologies today will be very similar three years from now.
  • The work is extremely similar to work that we have done before.  Almost everything is a known quantity.

Agile’s Assumptions

  • The work to be done changes often and progressively as more clarity is gained or needs evolve.
  • Business needs and the market is volatile.  The thing on the front burner today might be on the back burner in three months.  Our methodologies are evolving.
  • The work is to develop something new.  Similar technologies and methods might be used, but the business problems we’re solving technically have not been solved before.  Otherwise, we’d be using that.

The problems with Waterfall are not necessarily inherent to Waterfall as a methodology.  On paper, it looks all right.  The problem is that the set of circumstances under which it operates best is pretty rare in software development.  Are there software development projects where the domain is pretty static, changes are rare, and the business changes very little?  Sure, those do exist, and Waterfall would work just fine.  In fact, it or something similar might be the best choice for those kinds of projects.

However, a lot of organizations believe Waterfall’s assumptions to be true of their situation, and they are not at all.  Most real organizations have work that looks more like that list of Agile Assumptions, and in that context, agile methods will probably fare much better.

The issue with combining the methodologies isn’t a religious one; it’s that you’re trying to combine two things that are appropriate in two very different contexts.  You’ll end up crippling Agile by trying to make it more Waterfallish because you’re trying to drag in a context that doesn’t apply.  It’s like adding a sail to your car.  Sails are pretty good in their context, but they’re not objectively good for all contexts.

The fact is, becoming agile will challenge a lot of illusions and assumptions we make about our work that are not accurate.  If you’re hearing something like, “Agile makes it difficult to budget for the whole project up front,” that’s your cue to examine if budgeting a whole project up front is really the smartest thing to do as opposed to paying for value as you go.  If you’re hearing, “Agile makes it hard to set project milestones,” that’s a good opportunity ask yourself why you feel you need project milestones, what value they offer, and could you get that value in better ways?  Agile is meant to change your understanding, your values, and ultimately your practices at an organizational level.  It is not designed to accommodate them.

So, before you decide to add a sail to your car, just give driving the car a shot.  You might find that it doesn’t need that sort of improvement.

 

 

Enhanced by Zemanta
Jan 292014
 
Anecdotes and Data DSC_9869

Anecdotes and Data DSC_9869 (Photo credit: Plashing Vole)

I’ve started to see a statement crop up more and more in blogs, on Twitter, and in person on discussions about what does and doesn’t work in becoming agile: Anecdotes are not data.  Typically, this happens because someone is explaining their views or practices as derived from their own experience.  You’d think that wouldn’t be a controversial move, but agile coaching/consulting is one of the most armchair-dominated fields out there.  It behooves people trying to make money in this field to cast aspersions on experience in favor of their “data.”  You can tell story after story about what you’ve run into in the field, but it’s not “data,” and therefore can’t be used to establish anything.

Here’s the catch, though: where does that “data” come from?

Let me tell you where it doesn’t come from.  It doesn’t come from a researcher, an organization, or a group of peers coming up with a hypothesis, defining the control parameters to test that hypothesis, then running experiments on a broad range of companies within the confines of those parameters, observing and recording the effects every day, then publishing those results after peer review.  So, whatever agile consultants mean by the word “data,” they don’t mean what the scientific method means.  They don’t mean actual empirical data.

Since no one has ever done an actual scientific analysis of various agile practices, what do people mean when they talk about data in this field?  Well, they mean things like the Chaos Report or various organizations’ “State of Agility” surveys.  In other words, they are referring to collated survey data, and unfortunately for the anti-anecdote wags, a survey response is anecdotal.  People are reporting on their own experiences, and the way in which those experiences are reported is further filtered and conditioned based on things like the questions asked, the questions not asked, the answer options, the quantification mechanism chosen, the response rate, and the survey base.

So, data in the agile community is typically nothing more than a collection of anecdotes.  One might argue that these collections of anecdotes yield more certainty than, say, one person’s collected anecdotes.  Maybe that’s so, but at what point do anecdotes magically transform from “Bob’s experience” to “actual data?”  Is it five people’s anecdotes?  How about twenty?  A hundred?  A thousand?

The only difference between anecdotes and data in this context is one of degree, but not one of kind.  Critiquing someone’s anecdotes because they aren’t data is like critiquing a full bathtub because it isn’t a swimming pool – maybe you can’t fit everyone into it, but there’s still a lot of commonality.  All these various reports and surveys are just collections of stories.  That doesn’t make them invalid, of course, because these stories are really all we have to go on until a hundred corporations volunteer themselves for experimentation by the agile community.  But it does mean personal experience has both meaning and weight.

Even in what we think of as the hard sciences, the experiences behind anecdotes carry value.  Do you think a heart surgeon who has never done surgery is just as good as a heart surgeon who has done a hundred surgeries because they both learned the same material?  If the hundred-surgery surgeon started giving advice to the no-surgery surgeon about what the real deal is like, do you think, “Sorry old man, but anecdotes aren’t data” is a valid response?

If someone is being hidebound and closed-minded because of their past experiences, I think a much better observation to make is, “Your experience isn’t normative.”  In other words, people may have experienced different things that lead them to different biases, actions, and even different ways of interpreting “data.”  For instance, not too long ago, I criticized the popular use of burndown charts on the grounds of what I’ve actually seen happen.  I would never, however, tell someone that burndown charts are universally inappropriate or should never be used under any circumstance.  Why?  Because my own experiences have led me to see them as a low-value activity, but another practitioner might have experienced a lot of benefit from them, and it serves the community as a whole for us to share those anecdotes and the views they espouse so that we can improve and the people who bother to listen can also improve.

Anecdotes are data, and if you discount what an experienced veteran says because it didn’t jive with someone’s survey, you’re taking a very risky path.

Enhanced by Zemanta
Jan 282014
 
Galaga

Galaga (Photo credits: Giphy)

Thought I’d pick up a little of that sweet, sweet physics traffic with that title.  FYI, you can increase your change in position or decrease your time.

Now that’s out of the way, this is a question that crops up every so often in different forms.  I put it in the Scrum form, but it all basically boils down to, “How can I get my developers to move faster?”  This is a timeless question that has answers that generally revolve around adding people, forcing overtime, or instituting measures to make sure they aren’t all secretly playing Galaga.  I will contend, however, that if you really want more to get done more quickly, you’re asking the wrong question.

When you first start learning to play tennis, they don’t teach you how to hit the ball as hard as possible.  You can always tell when your opponent has decided power is the most important thing to the game, because the ball ends up wedged in the fence, over the wall, out of bounds 80% of the time, and generally anywhere on the court except the places that would actually enable them to score points.  But, boy, does it get there fast!  Tennis Coaching 101 is to teach control and placement.  Power follows as a logical consequence of easily and confidently putting the ball where it needs to go.  A less powerful player with consistent placement will beat Johnny Randomcannon every single time.  The key to greater power is greater consistency.

Instead of asking, “How can we go faster?” start by asking, “What keeps us from performing consistently?”  If you don’t have a predictable flow, it’s very hard to know if you’re improving.  If speed increases, but it’s unpredictable, who knows why you went faster?  Who knows if you’ll be faster next week?  Your results don’t mean anything because the variability is high.  Although it may sound counter-intuitive or just plain distasteful, it is better to be slow and predictable than fast and unpredictable, at least in terms of getting work done.  Obviously, the ultimate goal is to be fast and predictable, but one comes before the other.  Just like you wouldn’t focus on power before precision, focusing on speed before predictability can end up with you all over the place except the targets you’re actually trying to hit.

In the first place, most businesses prefer predictability to speed, despite what they say.  You can plan around predictability, even if the predictions aren’t what you’d like.  You can’t plan off variability no matter how fast you are.  If you offered most businesses a choice between a consistent amount of work delivered in a consistent time period versus a completely erratic delivery that could be much faster from time to time, they’ll pick the first one.

In the second place, there’s no way you can meaningfully measure if your improvements are helping if you’re already highly variable.  To use a Scrum example (I feel so dirty), let’s say I deliver 5 story points one sprint, 18 the next sprint, and 10 the next sprint.  My team decides on an improvement, and the next sprint, we deliver 14 story points.  Did our improvement help?  You have no freaking idea.  If you take that same scenario, but the team’s deliveries were more like 12, 16, and 14, then the next sprint you delivered 18 or 20, the odds are pretty good that your improvement is helping, or at least not hurting.

But how do we reduce variability in software development?  Isn’t it extremely variable?  Well, yes it is, and I have found the practice of trying to get all deliverables to the same “size” to do more harm than good.  It’s better to accept that some things will be big, some things will be small, and most things will gravitate to somewhere in the middle, relatively speaking.  You can’t control that.  What you can control is flow.

How fast does new work come to your team compared to how fast work gets delivered?  How many things is your team trying to finish at one time?  How often is something in progress stopped because of roadblocks?  How often is something not in progress started because of whiplash priority changes?  You can’t control the variability of what you have to deliver, but you do have quite a bit of control over the flow of these deliverables into and out of your team.

If you manage to flow instead of speed, the speed will come.

Enhanced by Zemanta
Aug 262013
 
gray wolf

gray wolf (Photo credit: U.S. Fish and Wildlife Service – Midwest Region)

When I was in school, I bought a wolf adoption packet.  I don’t even remember what it was called, but the idea was to prevent the extinction of a specific kind of wolf.  You bought one of these packets that had a photo of your wolf and such, and your money went to an organization preventing their extinction.

When I told one of my friends about it, she said, “I can’t believe you spent money to save a wolf when there are so many children dying of starvation out there.”

You’ve probably seen something similar in your own life, when one person assists a cause, and that effort is criticized by someone on the grounds that there are other, more important causes out there.  Usually this criticism comes from someone who is doing nothing about either situation.

Obviously, there is the fact that people can care about more than one thing.  Of course I care about children dying of starvation.  Caring about one thing doesn’t mean you think it’s the most important thing, nor does it mean you can’t care about anything else.  But people do something for causes for a lot of different reasons.  In my case, someone presented an opportunity to me to do something about it in a way that made it easy to help.  People have different backgrounds, gifts, and preferences that draw them to certain causes, but I’d say the common factor in all of them is that people feel like they can actually make a difference in that area through their efforts.  This is why the Peace Corps has many members and the Giant Asteroid Hitting the Earth Prevention Society has so few.

In the Agile and Lean communities, we tend to talk a lot about processes – the pros and cons of different processes, how to tweak them, how to analyze them – and it usually isn’t long in such discussions before some wag pipes up, “Hey, guys, remember.  Individuals and interactions over processes and tools!”  Usually this is someone who is contributing nothing in either category.

I actually find this sort of thing both offensive and stupid – chronically short-sighted at the very least.

If the Saw movies have taught us anything, it’s that you can’t change a person.  People have to change themselves, and it’s something that takes a long time apart from some traumatic experience.  I can’t consult someone into a more agile mindset.  I can’t consult an organization into trusting each other more.  I might be able to point out these needs, but ultimately, I am very limited into what I can do about it.  I can’t change people by making them fall backwards into their co-workers’ arms, and I am unwilling to set up an elaborate chain of deathtraps to help them all see that they’re valuing the wrong things.  I can inform them, but that’s really where my power to change stops, more or less.

So, placing all my efforts in the people/culture bucket is kind of like joining the Asteroid Prevention Society.  It’s an important issue that I can do relatively little about – at least, directly.

At the same time, we all know that individuals and interactions are more important than processes and tools.  Absolutely.  100% agreed.  By a long shot.  So the question is, as a consultant, how are you best serving the individuals and interactions as opposed to being a process or tool vendor?  I believe the answer is in focusing on the things that will enable the people and the organization to change themselves – most notably, educating them, changing their behaviors (or processes if you will), and letting the results of that be the levers for creating the true people and culture changes that are the core of what will benefit an organization long term.

I have seen this path work several times – culture and people changes that cascade from education and creating more enabling processes.  It’s like irrigating dry soil, making it ready for the seeds of true growth that would inevitably die otherwise.  I have never seen lasting cultural change come from an initiative specifically designed to change the culture.

So, the next time you hear someone seeming to focus on processes or tools, don’t automatically dismiss that interest as misplaced, especially if they aren’t selling said process or tool.  It may be that they care about individuals and interactions far more than you know.

Enhanced by Zemanta
May 242013
 
English: Simon Cowell at the National Televisi...

English: Simon Cowell at the National Television Awards at the Royal Albert Hall, London, October 2006. (Photo credit: Wikipedia)

How do you know if your chosen agile initiatives are working?  How do you know if you’re agile consultant is actually helping or just telling cute stories and quoting books they’ve read?  How do you know if your agile teams are actually agile or just call themselves that?

This is a dicey question, and there are a fairly large number of agile consultants who will tell you that you can’t measure such things.

Like most falsehoods, this has a seed of truth to it.  When you are dealing with complex systems that are primarily people-powered, you can’t quantify everything, nor should you try.  This is one of the many reasons why managing by the numbers is so wrong-headed.  You have to be in the midst of your people.  You can’t quantify things like communication, collaboration, trust, habits, or many of the multifaceted aspects of the way people work with other people.

It is also true that any change in business as usual will actually create a dip in productivity (and possibly morale) as people have to leave the familiar and struggle to form new ways of working together.  Unfortunately, this stage (sometimes called the “storming” stage) is where most people abandon their agile initiative because things got worse, and they never reap the rewards of riding through that dip and coming out the other side into the new normal of greater productivity.

However, it is my view that some aspects of agile effectiveness can be measured, and it basically comes down to this: are you delivering more value more quickly?

Companies increase their agility to make more money.  Full stop.  For all our fancy mission statements and talk about disruption and whatnot, every for-profit organization has the overarching goal of making money.  Things that help companies make money, save money, or protect money from risk are seen as improvements, while things that cause companies to lose sales, lose money, or put their money at risk are seen as detriments.

Agility is not exempt from this.  In fact, if agility isn’t helping you in this department, what’s the point in doing it?

There is no inherent value in conforming to “agile rules” or even the Agile Manifesto, so trying to measure that is a waste.  There’s no inherent value in conforming to a plan, so trying to measure that is also a waste.  That alone sweeps a ton of possible metrics off the table.  There’s no point in assessing agile effectiveness by things like if you’re doing Agile Practice X, if you’re following the Scrum rules, or how well your estimates match up to actuality.  None of that truly matters.

There is inherent value in delivering items of value, not wasting time reworking those items, and removing obstacles to delivering those items.  Therefore, if you want a measurement of the effective agility of your team or organization, here are the metrics I think are not only most important, but are actually measurable.

1. How much value are you delivering over time? (Throughput, Lead time)

2. How much rework are you having to do? (Quality, Time spent on bugs)

3. How are work items flowing through your system? (Flow, Amount of work over time in each stage, Amount of work coming into and leaving the system)

The things that help you deliver more over time without increasing rework are enhancing your agility.  The things that impair this dampen your agility.  The whole reason to become agile is to deliver more, deliver faster, and deliver higher-quality.  It isn’t to become better people, hack our corporate culture, or make software development more pleasant.  All those things might very well happen and are probably desirable, but they are means to an end.  Ultimately, it’s all about the Benjamins or whatever the kids are calling money these days, and that is the final criterion by which initiatives can be measured.

If you aren’t measuring these things, I encourage you to do so.  A lot of people think their diets work, too, until they step on the scale.  A lot of people think they can sing until they do it in front of Simon Cowell.  Find out, and when you’ve found out, don’t use those measurements to beat yourself up (or anyone else for that matter), but use them as a catalyst for conversations about improvement.

Enhanced by Zemanta
Mar 182013
 
Organization Keeps you moving-Vin

Organization Keeps you moving-Vin (Photo credit: nist6ss)

When people think of agile or lean practices, they almost always think of getting rid of things.  Doing less things.

  • Less documentation
  • Less process
  • Less requirements gathering
  • Less governance
  • Less accountability
  • Less management

Leaning up does mean trimming the fat, so in many organizations, that characterization isn’t inaccurate.  You tend to get rid of the 100 page requirements document.  The team self directs as opposed to a manager handing out work to individuals.  Steps in a process that exist entirely out of self-defense but add no value and impede its delivery tend to get chucked.  Agile teams tend to need less direct oversight and management.  And so on.

This is true assuming an organization has a lot of non-value added activities in these areas.  If the goal is to deliver value often and quickly, you get rid of the stuff that doesn’t help you do that.

However, you also add the stuff that helps you do that.

For instance, being agile doesn’t mean you have less documentation – it means you have exactly the documentation that provides value, and you produce it when it will be the most valuable.  Some organizations might already do very little or no documentation, but an agile organization will identify where that might help deliver value and, if it does, they produce it.

Being agile doesn’t mean you don’t gather requirements up front – it means you gather exactly what you need at the time, and you get it exactly when it will add the most value (i.e. when you’re ready to work on something).  Otherwise, you don’t.  Some organizations might do very little requirements gathering.  In fact, the introduction of acceptance criteria – a common agile practice – is often a new addition to most organizations.

Sometimes, the best way to enhance the delivery of value is to remove layers of process that don’t really help, but it can also mean adding processes where there were none before, if and only if that process will enhance your ability to deliver value.

Sometimes, becoming more agile means removing layers of management or the impact of management.  Sometimes, it means much more engaged management.  Sometimes, both.

The idea that becoming agile always means less of these traditional elements is a shallow one that is only a hair away from being a harmful myth about agility.  Agility means less of these traditional elements that impede the rapid and frequent delivery of value, and Gaia knows there’s a lot of that out there that needs to go, but it’s borderline crazy to assume these elements are inherently bad, and increasing agility just means getting rid of them.

Depending on the organization, agility sometimes means more documentation, more detailed requirements, more governance, more design, more process, more management.  It’s about removing the roadblocks, but also improving the road quality and safety so you can increase the speed limit.  It’s about removing impediments to value delivery, but it’s also about adding things that enable value delivery.  It’s not just destructive, it’s also constructive.

Enhanced by Zemanta
Jan 312013
 
Look! It's paired programming!

Look! It’s paired programming! (Photo credit: Wikipedia)

One of the earlier moves most organizations perform to become more agile is to form teams, usually of the cross-functional and self-organizing variety. As the Elder God Scrum awakens from its slumber and draws more cultists into its tentacled maw, this has become such a common feature of agility that it’s hard to imagine any kind of serious agile effort without them. But are they actually necessary?

I’ve thought about this question a lot the past few days, and my current answer is: they shouldn’t be.

Self-organized, cross-functional teams are structures that address certain issues that dampen agility in an organization – issues like silos, communication, project visibility, and the granddaddy of work dysfunctions: too much work in progress.

Many organizations suffer terribly from these afflictions, and teams are a way to begin to reduce those issues. If you give a project to a team and they have an agile mindset, then they will swarm around a few issues at a time rather than break off and do different things, and this key shift in workflow cures a lot of the ills listed above. If I have a team with the same backlog, same priorities, same resources, and we are committed to delivering value as quickly as possible, then we will pour as much effort as we can into the most important thing, which requires us to collaborate regularly and give everyone visibility into everyone else’s work. The common purpose, shared knowledge, and self-organized tactical workflow will produce greater speed and quality, especially as the team learns to work together.

In that sense, teams may be necessary in the same sense that surgery to remove a steel beam from your head may be necessary – you have a critical condition, and it’s hard to see how to get from Point A to Point B without addressing it in a specific and immediate way.

However, we need to keep in mind that teams are a means to an end. Ideally, an organization functions as one team – every facet is strategically aligned, working on the most important thing, limiting their work in progress, making their work and information visible, and doing the activities necessary to breed continuous self-improvement. In this scenario, “team” would just be an arbitrary designation to refer to a number of people very closely related in delivering something, sort of like “project” would be an arbitrary designation to group related items of value to deliver. The entire organization would be a box where requests for value would come in and actualized value would go out, focused on a united, rapid, high-quality value delivery flow.

As awesome as that sounds, it is incalculably distant from where most organizations are at, and trying to drop them directly into that state would probably kill them.

So, yes, form teams and use them. I’ll certainly continue to do so. But recognize that they are tools to enable principles and reach a goal; they aren’t ends unto themselves. I’d argue that, in the higher planes of agility, an organization would have no formal teams at all.

Enhanced by Zemanta
Dec 032012
 
5GW Waterfall Model

5GW Waterfall Model (Photo credit: Dreaming 5GW)

If you get into any kind of open forum discussion regarding the benefits of more agile or more lean approaches to traditional software development, it’s not uncommon for someone to say that the problems organizations experience with Waterfall are largely because they aren’t doing Waterfall right (incidentally, this is also what most of the Scrum folks say when organizations experience problems doing Scrum, but I digress). The idea is that, if organizations were disciplined and knowledgeable enough to implement Waterfall properly, the way it was designed, that most or all of the high risk issues in Waterfall wouldn’t be issues.

It reminds me of martial arts forums. Someone will post twenty videos of Bad Won Do practitioners getting their tails kicked, and someone will comment that what they’re doing isn’t “real” Bad Won Do.  “Real” Bad Won Do is actually quite effective (and apparently undocumented) and, if they’d just do the real stuff right, they’d be powerhouses.

But here’s the thing. Even if you did Waterfall with 100% perfect execution, it remains an extremely high risk, high fail project delivery methodology.

1. Testing Comes Too Late in the Process

Winston Royce, the man who brought a lot of visibility and popularity to phase-gate approaches to software development (and accidentally contributed to the success of Waterfall) wrote this in “Managing the Development of Large Software Systems:”

The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a l00-percent overrun in schedule.

In other words, since you’re testing the whole system at the end, you run a very high risk of major rewrites to fix issues.  This is Waterfall done right.

2. Value delivery comes at the end.

You release at the end of the project. Nobody gets any value out of your work until everything is done. This is a huge risk for a number of reasons.

First of all, the project might not get done. In fact, many projects meet this fate. Funding runs out. Priorities change. Dissatisfaction with the vendor. When this happens, the business is often left with nothing. They just eat the cost of a ton of work that got them nothing but stacks of documentation and some half-baked code. Since value wasn’t delivered incrementally, they have nothing.

Second, there is an enormous risk that what was valuable nine months ago is no longer valuable, either due to changes in the business or just the fact that the value of requests expires over time. It would have been useful when it was requested, but not nearly as useful now.

Third, the funder of the project has no real option but 100% success or 100% failure. You either get everything, or you get nothing, and this leads to some very unhealthy decisions like sticking with a vendor who isn’t performing or continuing to pump funding into a project that should have been abandoned or thoroughly revised months ago.

This is Waterfall done right.

3. Waterfall is predicated on a faulty premise.

Waterfall assumes that I can fairly accurately predict timelines and resource needs for a project that will involve several people extending over a large amount of time.  The entire notion of a phase-gate approach like Waterfall is the idea that I can get all the requirements, lock those down, do all my design, etc. And all the trappings of my project management revolve around this presupposition.

And this might have a glimmer of hope to it if software requirements were cookie-cutter kinds of things that all required the same resources, same effort, same complexity, same outcomes. But as we know, software development is way, way more variable than that.

Can you imagine a general making a battle plan for a year long campaign and sticking to that plan the entire year? It doesn’t happen. Yes, having a plan is important, but the plan has to be intrinsically adaptable because conditions on the ground are changing. Some are predictable, some aren’t – the variables in war are endless.

I’m not saying software development is as volatile as war (most of the time), but the principle is very similar. I mean, what if I asked you to plan down to the hour your work days for the next year.  Could you do it?  What about the next month?  Next week?  I think you’d find this challenging, because each day of work brings up new variables, emergencies, challenges, etc.  So, I ask you, if you couldn’t even plan the hours of your work week in advance, how realistic is it to assume that you can do that for several people, departments, and resources over the course of six months to a year and expect the outcome to still be relevant to all stakeholders?

This is Waterfall done right, and this factor is, I believe the most problematic, because it gives an illusion of certainty that does not actually exist.

Enhanced by Zemanta
May 012012
 
Software Development Community Meeting

Software Development Community Meeting (Photo credit: Michael Kappel)

At a recent conference, I attended a seminar on being agile. It was actually a seminar on Scrum, but using Agile as a label for Scrum is the big thing these days, I guess.

Anyway, the speaker told a story about how the daily standups revealed to a manager that one of the developers was making no real progress and, as a result, that developer was fired.

How many developers out there are all fired up about getting agile, now?

This calls to mind a time I was doing a presentation at the C-level for a company about agility, and I asked the question, “What’s the value in having the people actually doing the work telling you what the relative effort is?” and the immediate answer was, “So you can hold them accountable.”

Not, “Because that sizing will be more accurate coming from the trenches than management,” but because people could be more effectively and harshly disciplined.

I want to be clear that I am in no way about to say that team members should never be reassigned or even let go. Sometimes, as a last resort, those kinds of things have to happen for a business to keep moving forward. I will say this, though:

Part of being agile is recognizing that you are all members of the same team working on the same goals, and you will succeed or fail as a team.

If a person seems to be stuck on a task that doesn’t seem to be that hard, that person should feel safe saying, “I thought this was going to be easy, but it’s pretty complicated, and I need help,” or even, “My dog died, yesterday, so I apologize to the team, but the truth is that I didn’t get a lot done.”

On the other hand, the team itself has a responsibility to reach out to this person even if they aren’t forthcoming. If a co-worker seems to be working on the same thing all week and it was a fairly small backlog item, go to them. Say, “Hey, I noticed that your item seems to be sticking. Can I help you with it? Do you want to trade backlog items?”

Agility promotes transparency, and this can either be terrifying for your team or it can be edifying for your team.

The purpose of transparency isn’t to more effectively blame people; it’s to more effectively help people. It’s a recognition that, at some point, we will all be the weakest link. At some point, what we thought was easy turned out to be difficult. At some point, a highly-skilled professional will find themselves in the middle of a problem and have no idea how to solve it. At some point, a manager will completely de-rail the project. Transparency shines a light on these issues so we can work together to resolve them, not throw darts more accurately.

Does your team work this way? Do managers and developers realize that they are working together to accomplish a goal? Does everyone realize that accomplishing the goal is more important than doling out blame or punishment? Does everyone understand that working together to solve a problem is far more valuable to the business than accurately blaming someone?

The person telling the story about the underperforming co-worker getting fired held this up as an example of agile success. To me, it was a sign of dismal failure.

Apr 252012
 
LMFAO at the Sunset Strip Music Festival 2009

LMFAO at the Sunset Strip Music Festival 2009 (Photo credit: Wikipedia)

(Original song “Sexy and I Know It” by LMFAO)

Yeah, yeah
When I iterate
Managers be sayin, “Damn, that’s great!”
Velocity increase
With how often I release, yeah
This is how I roll
I got production in control
When you got a good WIP limit
No reason not to stay in it

Ahhhh – Girl look at that whiteboard
Ahhhh – Girl look at that whiteboard
Ahhhh – Girl look at that whiteboard
Ahhhh – I burn down

Ahhhh – Girl look at that whiteboard
Ahhhh – Girl look at that whiteboard
Ahhhh – Girl look at that whiteboard
Ahhhh – I burn down

When I walk to the board (yeah)
This is what I see (ok)
Work items ranked
By priority
I got my workflow on the board
And I ain’t afraid to show it, show it, show it

I’m agile and I know it

I’m agile and I know it