Agile » The Cutting Ledge

Capacity Planning – The Capacity Chimera

May 282013

Karma Chameleon (Photo credit: Wikipedia)

The Capacity Chimera is in the same zoo as the Karma Chameleon.

Capacity Planning is the practice of a person or a group of people estimating how many available hours they have to work. Then, they estimate how long each of their work items will take. In theory, this tells them what they should have done by the end of the day or week or sprint or whatever time period they pulled the capacity from.

For example, let’s say I have a team of six, one of whom is only 50% dedicated to this project. For a week of work, that’s 40 hrs. for 5 people and 20 hrs. for one person, giving my team a capacity of 220 hrs. for tasks. Of course, we all know it’s unrealistic to assume everyone can put it a full 8 hours dedicated to task work. There’s phone calls, emails, little delays, etc. So, let’s say a “full day” is six productive hours in terms of completing tasks. That gives me 30 hrs. for 5 people and 15 for the sixth.

Then, you take all the things that need to get done and estimate how many hours each one will take. You assign them to people until you have “spent” each person’s capacity. You should now feel confident that all those tasks are very likely to get done by the end of the week. Or I should say, you do feel confident, but you probably shouldn’t. While capacity planning is probably better than no work limits at all, it’s still very unreliable.

In the first place, it requires you to accurately predict your capacity. So, you take out your PTO, your meetings, and some token amount for daily incidentals. Well, meetings run over and they run short. Incidentals are sometimes nothing, and sometimes they eat up your entire day. Sometimes, that email exchange turns into an on the spot meeting. Sometimes, kids get sick. Sometimes, servers go down and all hands have to work to get them back up. Sometimes, people get fired. Or hired.

In fact, I’d venture to guess that a week where -nothing- unpredictable happens is far, far less common than a week where something does. I’m not even sure I could definitively say what my work will look like for one day. I can tell you what I intend to do, but who knows if it’ll actually fall out that way? Much less a week. Much less a team of six such people. And that guy who has 50% capacity for my project? Somehow, that 50% always ends up looking like 30%.

So, your pool of available hours per person is already unreliable, and possibly unreliable by a rather large margin.

In the second place, capacity planning requires you to accurately predict how long your tasks will take, down to the hour. This probably isn’t happening, either. Not only are people bad at estimating, but many tasks (especially in software development) have a measure of unpredictability to them. I -think- adding a new database table will take an hour, but what if I accidentally add it to the wrong database and don’t realize it for a while? What if someone else accidentally drops my table with a restore from a backup? What if a persistent error on the database or in my SQL takes me two or three hours to chase down? Or, what if it goes even more smoothly than I thought and takes thirty seconds?

One could argue that, while my estimate in hours could be off, it’ll rarely be off by a factor of days, and that’s probably true most of the time. But you add up these little deviations – an hour here, a half hour there, two hours there – with each task, and eventually you’ve shaved off a whole day you planned to have available to get tasks done.

Much like estimates based on exhaustive requirements, capacity planning offers an illusion of security. When the smoke clears, it’s still just guesses about unknowns. It also tends to take a lot of time – a rather lot of time spent getting things wrong.

If you use capacity planning, and it never quite seems to pan out, you might consider ditching the whole guessing thing in favor of using your teams actual rate of getting things done to project what things will get done.

Improving Time to Innovation: Process is Not the Enemy

How Do You Know if Agile is Effective?

Agile, Business Processes, Kanban 2 Responses »

May 242013

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.

KCDC 2013: The Aftermath

Agile, Announcements, Kanban No Responses »

May 072013

Me presenting at KCDC 2013

Thirty-six hours before the first KCDC precompiler session began, I got a call from Kansas City’s premiere Lean/Agile expert asking if I could fill in for him at the Agile and Lean Workshop precompiler due to an emergency. Twelve hours before the session began, the United States’ premiere Lean/Agile expert was delayed by snow and told me he couldn’t make it to the session until lunch. That left me and this guy, or in other words, George and Ringo, and Ringo had a conference to run.

And it went great! We had a really good group who gave us good questions to work with. We played some games. We talked about Scrum. We talked about Kanban. We talked about all the hot button Agile topics like estimation, bidding, and ongoing maintenance. It was a good, energizing talk that reminded me how much I enjoy that sort of thing.

P.S. If you were at that workshop, please take a second and leave a rating for me at SpeakerRate. Much appreciated.

Friday morning, Dan “Kan-Man” Vacanti gave a terrific keynote about how we serve our customers better with pull systems for doing our software development as opposed to push systems. He also gave my own session a quick shout-out for which I am grateful, because without context, most people don’t get too fired up about a talk called “Lean Metrics.”

Next, I gave a talk called “Lean Metrics.” Standing-room only with some people sitting in the aisles. It was a huge fire hazard and OSHA violation, but it charged me up.

We talked about why estimation fails us and how keeping metrics can overcome some of the weaknesses of estimation, providing a better foundation for our planning and projections. Then, I demonstrated control charts and cumulative flow diagrams, explaining how each one can help us in not only estimating, but also continuous improvement as well as challenging elements in the organizational culture that dampen agility.

Here are the slides for that presentation, and if you were there, it’d be cool if you left me a rating for that talk at SpeakerRate.

After this was over and I was carried out on the shoulders of screaming fans, I spent a little bit of time catching up with contacts from KCDC’s various sponsors. This was an especially good KCDC for sponsors. We had 850ish people there, which meant that, even between sessions, there was a continuous flow of activity to the various booths, unlike previous years where booth visits were pretty bursty in between sessions.

I attended an eye-opening talk on UX from John Alexander, a talk on the enterprise use of HTML5 and various JavaScript libraries from the Keyhole team, and a truly thought-provoking talk on what other languages have to teach us about object-oriented programming by Jessica Kerr.

That night, dinner and drinks with a huge crowd of people I usually only see once a year. Also, Sugar Ray gave a concert nearby. Nobody noticed.

I did not get to attend on Saturday, but I hear good things.

I think the venue worked out great, the crowd was numerous and diverse, and the variety of speakers and topics made sure there was at least something for everyone. It may have been our most valuable KCDC yet in terms of investment. If you didn’t go this year, dude, go next year.

The Agile Event Horizon

Agile 2 Responses »

Apr 152013

Illustration of the event horizon (Schwarzschild radius) (Photo credit: Wikipedia)

The idea of an event horizon comes from general relativity, but if you’ve ever heard of an event horizon, you probably know it either from black holes or from that weird Laurence Fishburne movie. With black holes, the event horizon is that boundary around a black hole that marks the transition from “you could conceivably still get away with enough force” to “you’d better tell your friends you’ll be late to the bar.” Black holes are always pulling at the things around them, but the event horizon defines the difference between having to deal with a black hole and actually being inside one. Interestingly, from the outside, objects that pass the event horizon seem to disappear completely.

Event horizons are the ultimate black box. They are the universe’s embodiment of that fight or flight moment. You can get in, or you can stay out, but you can’t stay there. In fact, the force required to stay in an event horizon increases to infinity. The longer you try to remain neutral, the harder it becomes until it’s impossible.

When an organization decides to increase their agility, this effort also has an event horizon. Generally, these efforts either originate in management and spread out, or they originate in an implementation team and spread out. The latter is far more common. Management might mandate the agile effort, but the actual transformation begins in an implementation team.

Regardless of where it starts, this effort has a boundary that attempts to suck in everything else around it. Agile transformation efforts are not static. You can’t just take, say, a team of software developers, get them all agiled up, and expect this to have no ramifications for the rest of your organization. What you have done is created a singularity that, given enough time, will draw in the entire organization.

This is actually what you want. This is one of the benefits of truly agile efforts; they can’t stay in their little box. That event horizon is defined by the boundaries of contact between your “agile teams” and the rest of the organization.

Does your project management have distinct, Waterfallish phases? The event horizon will eventually touch that. Do you budget your projects on a cost-based approach where you have to allocate all the money up front? The event horizon will touch that. Are you constantly changing priorities at the top? The event horizon will touch that. Do you have tons of processes solely designed to protect the company from itself? The event horizon will touch that.

In ways you never even intended, the singularity will try to draw all aspects of your company into it, and the event horizon marks that boundary of change. Objects pass into it, and that’s where you have the critical moment of decision: do you allow accounting, management, project management, the executive team, and sales to pass through the event horizon, or do you expend force to keep them outside of it?

The answer to that question says a lot about the ultimate success or failure of an organization trying to be agile.

The LinkedIn Evolutionary Chart

Agile, Humorous (to me) 2 Responses »

Mar 192013

PhotonQ-Homer’ s Evolution Theory (Photo credit: PhOtOnQuAnTiQuE)

The Random Language Cloud (Confusicus Maximus)

Example Quote: “Does anyone Scrum the backlog issues into maximum value for the business process? What are the risks and how do you number the point enhancement?”

Description: Maybe it’s because English isn’t their primary language. Maybe it’s because the contributor has a very complex concept in their head and has trouble expressing it clearly. Maybe it’s because someone wanted to spark a discussion and increase their influence for the week. Whatever it is, the Random Language Cloud is commonly found starting discussions with questions that make no damn sense. Sometimes, they will also interject into a discussion, but that is a much rarer sighting.

Natural Predators: None. Virtually nobody interacts with an RLC, although I’d give someone five bucks if they’d just post a reply to one that said, “…what.”

The Guy You’re Not Even Sure How to Start Fixing (Falsus Presuppositionus)

Example Quote: “In agile, what is the best file format for the BA to give me the up front requirements document? Or do you prefer an electronic tool? I’d really like to minimize the amount of communication the team has to do.”

Description: Great care must be taken with the GYNESHSF, because some of the time, deep down, is someone who genuinely wants to learn and genuinely has no clue. They are only difficult because there is obviously a long string of knots that need untying before you can even start to address the issue they raised, but in the long run, the effort is usually worthwhile for both parties.

There is another breed of GYNESHSF, however, that is bound and determined to cling to their original presuppositions and want you to say things that will fit it. A common sign is the comment, “Well, X wouldn’t work here.” This is actually a great way to troll agile discussions, but a very bad way to have a real one.

In either case, when this species moves from asking questions to offering advice, get ready to grab a mop and a bucket of napalm.

Natural Predators: Theoretical Agilists – these guys will spend all day with the second breed of GYNESHSF. Experienced Agilists will spend all day with the first.

The Humble Noob (Genuinius Noobicus)

Example Quotes: “I’m just starting out trying to be more agile, and I’m having problems understanding how to do relative estimates.”

“I’m actually new to all this, but we tried Practice X, and it seemed to work all right. I’m not sure if it’s the best way to do things or not.”

Description: A reasonably rare sighting, the Humble Noob is great. They genuinely want to learn and are aware that they don’t know very much. They are careful with their questions, and the advice they offer is suitably qualified with the idea that they may not know the best answer, but they’re just trying to help.

Natural Predators: Theoretical Agilists love these guys because they can rattle off answers from The Textbook without any fear of challenge or contradiction. It validates their credibility and releases endorphins. Experienced Agilists, in their best moments, also have a bit of Humble Noob in them throughout their career.

The Theoretical Agilist (Armchairus Quarterbackus)

Example Quotes: “Kanban is no good for software development.”

“Apple is more or less an agile company because Steve Jobs was a Product Owner.”

“Do you have a Product Owner? Why don’t you have a Product Owner? You need a Product Owner. Preferably a certified one.”

“This article by Ken Schwaber answers your question. You should seriously read this book.”

“That’s Scrumbut.”

“Process is the enemy of Agile.”

“Agile coaches should never help with the team’s actual work.”

Description: The Theoretical Agilist has read books and perhaps has gotten certified. They are, surprisingly, often Agile Coaches and Scrum Masters. They may even be advising actual teams. However, the common characteristic they share is that they really don’t know what they’re talking about because all they know is what they’ve heard or read. They do not learn from their experience, if they even have any, but instead force their theoretical knowledge upon their experience to try to make it fit. They are often very good at selling themselves and presenting themselves as subject matter experts, but very poor at articulating the foundations for their views or practical applications. Professionally, they will happily charge you money to provide no real value except by accident.

Pantheon: Ken Schwaber (the one true inventor of Agile, which is usually a specific process), Mike Cohn (his greatest prophet), Steve Denning (the Real Business Expert)

Natural Predators: Me. Seriously, I lose my s whenever these people show up, and they become more numerous with every Scrum Master certification class. I am trying to work on this because occasionally in these self-proclaimed experts is someone who really just wants to learn but is insecure expressing that, and I don’t want to turn those people away. I also don’t want to be a jackass to anyone, but I so, so am when this happens. So, opportunities for personal growth there. But if you ever want to troll me on LinkedIn, the best way is to jump into a discussion about agile and say that Kanban won’t work in software development and support this by quoting Steve Denning’s blog.

The Experienced Agilist (Mythicus Unicornus)

Example Quotes: “I’ve tried Practice X at four different companies and it worked really well. It didn’t go so well for one company I tried it at, and I think it’s because it wasn’t a good fit, there, so I tried Practice Y and that worked. But usually, I try to go with Practice X if I can.”

“Let me show you the change in delivery metrics of this team over the past six months.”

Description: These people have been forged in the fires of adversity. They, like the Theoretical Agilists, have usually read a lot, are often certified, and sometimes work as full time Agile Coaches or Scrum Masters. The key difference is they have been at this a long time and can articulate the differences between The Textbook and An Actual Business. They can also tell you when The Texbook is dead on. They can also tell you under what circumstances their favorite techniques don’t work well and what better measures are. They can demonstrate their successes numerically and do not shy away from talking about their failures and what they’ve learned. They don’t just know What To Think, they also know What To Do. They know when to let an organization come to their own realizations, when to push them in the right direction, and when to go, “Look, guys, what you’re doing is just stupid. Stop it immediately and do this other thing. Just trust me on this.”

Natural Predators: Theoretical Agilists swarm these people like sharks, because 99.999% of the time, their advice varies to some degree from Holy Orthodoxy. They are also both appreciative and critical of leaders in their field, which does not sit well.

Where do you fit?

Penitence For The 7 Agile Sins

Agile Adds More Stuff

Agile No Responses »

Mar 182013

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.

Do You Need Teams to Be Agile?

Agile, Business Processes No Responses »

Jan 312013

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.

What’s Wrong with the Project Approach?

Agile, Business Processes, Kanban No Responses »

Jan 282013

English: It shows that agile methods are focused on different aspects of the software development life-cycle. (Photo credit: Wikipedia)

I haven’t had much time to write, lately, but I thought I’d assist the pithy Bob Marshall in preserving the following paper by Grant Rule. It’s a paper that’s like pretty much completely right. You can quote me on that.

What’s wrong with the project approach to software development?

January 11th, 2011 Author: pg_rule

Pretty much since “software” was first invented (60 years ago?), numerous folk have been promoting an ‘engineering-led’ approach to ‘software projects’. Yet this advice goes largely unheeded, with the result that the relative success of IT projects is poor, and has improved very little during all my years in IT (38 and counting). Given that such admonishments seemed to have had such little effect in all that time, I also find myself asking, “Do I think it likely that further exhortations to those involved in ‘software projects’ to change their project practices is likely to achieve improved value delivery to stakeholders?”

And I have to conclude that the answer is “No”.

Following Albert Einstein’s adage that, “The definition of insanity is doing the same thing over and over again and expecting different results”, it seems to me that we need an entirely new approach. A new approach which goes to the root causes of what actually goes wrong in the end-to-end process. Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?

Observation of what actually happens in organisations suggests there are two root conditions to the problem:

Those responsible for business strategy are disengaged from, and know relatively little about, software- intensive systems and technology. So they structure their organisations so that software & technology people are segregated into silos. In those silos, the inmates talk amongst themselves in whatever arcane language they choose. But importantly, they don’t communicate (or interfere) with the ‘real business’.
Everyone conspires to pretend that software-related activities should be managed as ‘projects’. That is, as chunks of work that start and end (on more or less clear and agreed dates), that have more or less well- defined goals, that contain a list of activities (tasks) that are assigned by a ‘project manager’ to a project team to which ‘resources’ are assigned for a limited period.

The results of studies too numerous to mention shows that most software projects are ‘challenged’ or ‘fail’. One study suggested that the majority of experienced project managers (and I am sure, folk playing other roles) expect at least 1 in 3 of the projects they lead to fail! As systems become more complex, and larger, they employ more teams combining projects into programmes… which further reduces the likelihood of successful achievement of the overall goals.

My conclusion is that we need a complete change of mindset. We need to move away from the inherently batch & queue concept of the ‘project life-cycle’ (as promoted by organisations including BCS, APM, PMI, OGC, SEI, NCC, ISO, IEEE, IET, etc. etc.) to a different approach.

I suggest that the required new mindset will accommodate the ideas of flow production and lean systems thinking that first began to be developed systematically (in e.g. automotive engineering) around 100 years ago. (Of course, one can trace elements of flow production & lean at least back to Carthage c.300-200 BC, but let’s ignore the history for now.)

I posit that Tom Gilb’s Evo method, and other agile methods such as XP, Scrum, Flowchain, and software Kanban, etc., begin to achieve ‘better’ results compared to ‘traditional’ big-design-up-front, wholly batch & queue methods, precisely because they encourage workers to focus on smaller batches of stakeholder value. In other words, value in terms the software developer can get to grips with.

Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create & throw away know-how, at – it seems – every opportunity. And crucially, they allow the C- suite and ‘business-side’ managers to ignore their responsibilities for the system of work and for the desired outcome.

Flow production (toward which Evo, Flowchain and Kanban currently make the nearest approaches IMO) would:

A) Make the entire end-to-end, whole-life, ‘concept to consumption & retirement’ process of defining, deciding, acquiring, designing, developing, operating, supporting, maintaining & replacing software- intensive systems a visible, inherent part of normal business operations… forcing issues onto the management horizon so they can be addressed as business issues – and not just something technologists worry about.

B) Because it would be apparent that software & IT issues were causing interruption to (or even cessation of) the flow of value, C-suite executives would have to recognise the pressing need to engage with software & IT related issues just as much as they do with other kinds of business issue. Conversely, the engagement of the ‘systems and software engineers’ with ‘the business’ would also be stimulated, the role of each and the communication between them finally becoming acknowledged as a main artery of the organisation’s lifeblood.

Flow production can only work effectively with the active engagement of all involved. For this reason it is a far more sustainable business model than other, perhaps more familiar, approaches. It embeds the ability to flex and respond to market forces deeply into the organisational culture. The focus on ‘the unforgiving minute’ forces constraints and problems out into the open where everyone can see them. It won’t allow problems to be swept under the carpet, or passed from one department to another like the proverbial buck. Hidden problems will always result in debts in one or more of the five kinds of capital. And such hidden debts, whether financial, technical, intellectual, social or environmental, all too often bite you when you least expect it. They will injure or kill the project – and destroy stakeholder value. Even if the project avoids repaying its hidden debts, this usually means that the debt has been passed-off onto one or another unsuspecting stakeholder group (sometimes, the end-customer or taxpayer). Which must be judged as unethical behaviour.

Unfortunately, not only have most people in the software industry been taught to sit in their silos and focus largely on coding, they and their masters have developed a cultural love affair with the project concept. To the extent that everyone assumes that all work has to be compartmentalised into projects, the very epitome of batch & queue thinking. Tell me what you think. Has the software project had its day, or is there another way of revolutionising workpatterns in the software industry?

Henry Ford Comes to Town – A Play in One Act

Agile, Hard Core Miscellany, Humorous (to me) No Responses »

Dec 212012

Portrait of Henry Ford (ca. 1919) (Photo credit: Wikipedia)

FORD: Behold! The automobile!

(FORD unveils automobile)

FORD: The driver sits here and maneuvers the car with this wheel. He uses this pedal to accelerate, and this pedal to decelerate. It is an amazing new way to travel.

SHIRLEY: Where does the saddle go?

FORD: Pardon?

SHIRLEY: I don’t see a place to fit a saddle.

FORD: This doesn’t need a saddle. You sit in the seat, instead.

SHIRLEY: No saddle? Sounds unsafe. I can’t imagine traveling without a saddle.

BRIAN: Seriously, Ford, is this some kind of joke?

FORD: No, see…

BRIAN: You can’t travel without using a saddle.

FORD: Yes, if you’re riding a horse, but this is a car, you see. The paradigm is completely different.

BRIAN: I don’t see a place for a bridle, either.

FORD: But there is no need.

SHIRLEY: Oh, right. We just use bridles to control direction. No big deal.

FORD: But this uses a wheel to control direction.

SHIRLEY: Of course. That’s why everyone else uses a wheel to control direction.

BRIAN: Ford, nobody uses a wheel to control direction.

FORD: That’s because everyone else rides horses. This is a car.

BRIAN: There’s a reason everybody rides horses, Ford.

FORD: Yes, because they don’t have cars. This is a car.

SHIRLEY: We have a lot of money sunk into a saddle-based infrastructure. Do we just throw all that away?

FORD: Well, I guess you could make something else out of the leather, or use the saddles decoratively.

BRIAN: DECORATIVELY?!

FORD: I don’t know. The point is, you don’t need saddles.

SHIRLEY: All our laws regarding travel are built around horse riding. If you can’t feed this car or tie it to a post or saddle it, how are we supposed to control it?

FORD: Well, there will have to be new laws.

BRIAN: So, we’ll just scrap a bunch of old laws and make new ones. That sounds safe.

FORD: It’s not like murder will be legal, it’s just that new paradigms mean lots of things have to change.

BRIAN: So, murder will be legal.

FORD: No, there’s no reason to change that law.

BRIAN: I don’t see why not. That’s basically what you’re proposing. All the laws and saddles and hitching posts that have served us so well up to this point are just stupid compared to YOUR idea. Your one single idea that nobody else is actually doing.

SHIRLEY: I mean, I could understand cars working on a small scale, but they’d never work here.

FORD: What do you mean?

SHIRLEY: Well, there’s no saddles, for one thing.

BRIAN: I’m not saying the whole idea is bad. I like those lights in front.

SHIRLEY: Yes! Maybe we should take the best of both worlds. Ford, could you stick those lights on a horse?

FORD: Not really. You kind of need a power source.

BRIAN: You could harness the horse’s motion.

SHIRLEY: I like where this is going.

FORD: So, you want me to rig up an elaborate structure that will most definitely slow the horse down for the purpose of attaching lights to its head.

BRIAN: I thought you said cars were faster than horses.

FORD: Yes, but….

BRIAN: So, which is it? Are cars faster or are horses faster?

FORD: Cars.

BRIAN: So, what’s the problem?

SHIRLEY: Why don’t we just try the light thing, and if it makes our horses faster, then maybe we’ll consider using more of the car.

BRIAN: And see if you can figure out how to fit a saddle and bridle on it.

SHIRLEY: That would be ideal.

[curtain falls]

Conversations Over Beer

Agile, Humorous (to me) No Responses »

Dec 122012

Jim (Photo credit: stan)

Jim: We actually had an agile coach come out two years ago to get us going doing Scrum.

Me: How’d that go?

Jim: Well, he got us going on sprints and all that, and, I don’t know. I think it slowed us down.

Me: Well, anything new is going to slow you down.

Jim: Yeah, that’s what I told people, but the problem was that the business expected us to be able to tell them when things were going to be done, and whole sprint thing didn’t make a lot of sense to them.

Me: I’ve also found that.

Jim: Well, I’d be interested in hearing your thoughts on that, because I asked this coach or consultant or whatever, and he told me that Scrum doesn’t actually fix anything, but it raises issues, and it was up to us to figure it out.

Me: He told you to figure it out?

Jim: He was more diplomatic than that. He said something about beginning a journey of learning.

Me: Did he take you on a journey?

Jim: No, I elbowed him in the face and said, “Welcome to a journey of learning! Figure that out!”

Me: *laughs*

Jim: No, I just did that in my head.

Older Entries

Related articles

Related articles

The Random Language Cloud (Confusicus Maximus)

The Guy You’re Not Even Sure How to Start Fixing (Falsus Presuppositionus)

The Humble Noob (Genuinius Noobicus)

The Theoretical Agilist (Armchairus Quarterbackus)

The Experienced Agilist (Mythicus Unicornus)

Related articles

Related articles

What’s wrong with the project approach to software development?