Jan 222014
 
Meryl Streep

Cover of Meryl Streep

Do you remember that movie “The Hours” with Meryl Streep?  Me, neither.

Last week, I was talking with some colleagues on LinkedIn about the utility of estimating tasks in hours.  For those of you with a Scrum background, you know it’s kind of tradition to estimate user stories in story points (or something like them), but then you break them into tasks.  The tasks are estimated in hours, and the total of all those hours forms the basis of your burndown chart.

I’m not saying my experience should govern everyone else’s, but I haven’t estimated tasks in hours in a very long time.

First of all, the whole thing begins with the premise that we can accurately estimate our tasks in hours, and this tends not to be the case.  There’s a common misconception that, if you are trying to estimate a smaller activity, that your estimates will be better.  This is not true.  It is true that the actual hard units of deviation will be smaller (being off by 2 hours is a smaller hard time span than 2 weeks), but there’s no reason to believe your estimate will be better just because the scope is smaller.  You might say at this point, “Well, ok, but it’s not really going to affect the project that much if I think it’ll take 2 hours to set up some database tables, and it takes 3.”  That’s a 50% deviation, but ok, sure, that extra hour may not affect much in the grand scheme of things.  But what if you’re off by an hour for all your tasks?

That’s being generous.  What is pretty common is to have a task that you think will take 4 hours, and it ends up taking 20.  You take these extremely common incidents of being wrong and you put them together, and you can easily end up with days or even weeks of error per sprint.  The absolute units of time give the appearance of precision, but it’s a false appearance – perhaps all the more dangerous for its compelling nature.

Because the units of time are small, this seems like a small problem, but that’s only because you’re thinking of one task.  When you look at the cumulative effect of this problem, it’s actually pretty serious.  It sets unrealistic expectations.  Your burndown chart whose entire raison d’être is to visually represent sprint progress is like a clock that loses 5 minutes every hour – it doesn’t take long before that clock is worse than worthless, because it’s misleading.  Have you ever had a burdown chart stay level or go up during a sprint?  More often than you’d like, right?  Maybe that’s a signal that your workflow isn’t being managed well, but those same things can just as easily happen for no reason whatsoever, just because your hours remaining started wrong and are correcting themselves.  This isn’t even taking into account the fact that, when people see hours, they expect those mini-deadlines to be hit.  Patience for spending 20 hours on a task wears pretty thin when you’ve told everyone it would take 4, initially.

This leads me to my next point – estimating in hours takes a long time to do.  All that time spent on being wrong could have been spent coding, getting acceptance criteria, or anything that would have moved toward delivery.  Hell, even using that time to make the world’s longest paper clip chain would have been at least as profitable.  Note, I’m not saying it’s a waste of time to break stories into tasks.  That process helps you understand what’s expected of you, ferrets out oversights, and helps in swarming.  But what are you getting by putting hours on those tasks?

“Well, the hours can help us verify if our sprint commitments are reasonable.”

Can they?  First of all, even the Scrum Guide doesn’t use sprint commitments, anymore, but let’s pretend that’s still a good idea.  If you can make some kind of equation between story points and hours, then why not just skip the whole story point process?  Just break everything into tasks, get your hours, and base your planning on that?

“Well, relative measurements and velocity are more accurate planning tools than hourly estimates.”

Exactly.  So how are those hours helping you, again?  You are using the less accurate tool to critique the more accurate tool?  Is there anything at all those estimated task hours help you do that relative measurements or empirical metrics can’t?

If you’re a Scrum sort, try an experiment next sprint just to see what happens.  Break your stories into tasks, but don’t put hours on them.  If you want to burn down, burn down story points (or whatever you use).  Just try it.  See if your workflow or end result is meaningfully impacted.  See if you miss them.  You might find that you’ve made a significant improvement in your practice.

Enhanced by Zemanta
Aug 272013
 
Retrospective 5 (Pinestone)

Retrospective 5 (Pinestone) (Photo credit: .:fotomaf:.)

Kanban does not prescribe any particular meetings.  It leaves it up to the workers to decide what meetings have value and how often to do them.

One meeting that I’ve found has value nearly everywhere I go is the good ol’ Retrospective made famous by good ol’ Scrum.  As long as we think of retrospectives more generally as a regular time for the team to talk about improving itself, you’ll find retrospectives many places you find Kanban and/or Lean practices, including Toyota.

Having extensive experience with the traditional Scrum retrospective, though, I think there are some things that can be changed to make it flow better with Kanban’s intent and, in fact, I think it even produces better retrospectives for Scrum teams as well.

The traditional Scrum retrospective basically follows the format of each team member stating what things went well (things to keep doing), what things did not go so well (things to stop doing), and what things could benefit from change (things that could benefit from change).  The Scrum Master records all these and, ideally, the team selects some to work on for the next sprint, and they talk about these items as part of the next retrospective.

You don’t have to be a Scrum Master very long before you watch these meetings devolve into a dry, useless mirror of the daily standup where no real value is added or degenerate into an unfocused whine-fest.  The value of the classic retrospective tends to drop so quickly that, if you head over to LinkedIn and start rummaging through the threads in the various agile and Scrum groups, you’ll see tons of threads asking how to do retrospectives differently.  In these threads, hilarity ensues because 90% of the consultants and coaches only learned the practice but never really understood the purpose, so you get surreal ideas like, “I use Legos in my retrospectives.  I buy everyone ice cream.  I dress up as Sailor Moon.  I have my retrospectives underwater in SCUBA gear.” and so on.  Ideas that try to make the meeting more engaging instead of changing the meeting to better accomplish its intended purpose.

I would like to share with you what I think is a good way to change the meeting to better accommodate the way Kanban effects organizational improvement.  It is not the objectively best way, nor is it a good thing to do in every organization, but here it is.

The first part of the meeting is to go over the metrics – specifically, we review the Cumulative Flow Diagram and the “Control” Chart.  Together, we discuss flow.

Did you catch that?  We don’t talk about making low numbers higher or high numbers lower.  We talk about the flow of our work.  What does the data imply about where things are not flowing smoothly, and why might that be?  Are there communication issues?  Too many handoffs?  Is there a small part that is affecting the whole?  Is the whole thing screwed up?  We are concerned about the areas where work is not flowing smoothly and taking cues from areas where it is.  We talk about where we would like to be and how our situation is different than that.

Notice this is very similar to talking about what is going well, what isn’t going well, and what are areas for change.  The main difference is that we are talking about an objective situation as a team as opposed to navel gazing into our personal feelings.

Once we have talked about these things, we discuss as a team what we believe the one area is that needs the most love.  Usually, the data strongly suggests an area, so there is little debate.  Then, we brainstorm ideas of how to improve that area.  We vote on one idea, enact that, and see if it made a difference when we get together next time.

Here are the key points:

  • The discussion stays about our work, not things or people outside our work that we can’t control.
  • The discussion stays objective.  The metrics are what they are, regardless of what our individual feelings might be.
  • The metrics are a catalyst for discussion and inquiry, not a substitute for it.
  • The focus is on improving our flow, not going faster.  Take the kinks out of your hose, and the throughput will increase.
  • The focus area and the solution both come from the team, not from the outside, creating instant buy-in.
  • One and only one change is introduced so it can be measured.

One might argue these are the basic intents of the Scrum retrospective, and that may be, but I would then counter-argue that the traditional format is not the most efficient way to accomplish those intents in many cases.

Enhanced by Zemanta
Aug 142013
 
Kanban in miniature

Kanban in miniature (Photo credit: jhritz)

For some years, now, David Anderson has vocally separated Kanban from “agile” or “agile methodologies” like Scrum, XP, and so on.  I never really understood why this was.  Although obviously Lean is found in several industries as is the use of various elements we find in Kanban, easily the most common place to find Kanban in the wild is in software development, and specifically software development teams trying to become more agile.

Also, you have to understand that I came to Kanban as a progression of sorts from Scrum.  Scrum helped me achieve a lot of the things I was trying to get out of a more agile software development experience, and when I came across Kanban, I saw it as (in my opinion) a better way to get at those same things.  But I didn’t see it so much as a different kind of thing from Scrum; just something that did some of the same things better.  So, in my head, Scrum, DSDM, XP, Kanban – these were all the same kind of thing, just with varying approaches and doing some things better than others.

But now, after having engineered the use of Kanban in a few different organizations and observed its power and value, as well as doing research trying to accumulate something intelligent to say about its differences with SAFe as it bulldozes its way into the market like a hyperactive wrecking ball that just demolished a Pixy Stix factory, I think I’m beginning to see what David’s been on about.

Agile and agile-ish methodologies can link their spiritual heritage to the concepts that became embodied in the Agile Manifesto – the signatories of which are names that you’d recognize in the field, like Ron Jeffries of XP fame and Darth Sidious of Scrum.  This Manifesto articulated principles and concepts of what agility was looking like in software development (and specifically software development, I might add – it says right there in the preamble).  People began to create and collate practices and systems that, in their minds, did good jobs of expressing in practice and technique those agile principles.  You do these things, and you are getting closer to expressing those principles more fully and more comprehensively.

What I have been discovering over time, though, is that Kanban actually makes nothing more agile, nor does it improve anything.

Rather, Kanban is an efficient, effective way to show you where you can improve, the best places to improve, and what the impact will be.  In other words, Kanban gives you everything you need to improve quickly, efficiently, predictably, and get the most bang for your buck.

When I was a kid, dentists would sometimes give you these red tablets for you to swirl around in your mouth after you brushed your teeth.  They tasted like they were made from Hell’s own brimstone and the ground up bones of dentists that had passed on, and perhaps they were, but when you spit the stuff out, there would be red areas on the surfaces of your teeth that you missed while brushing.  They didn’t clean your teeth; you had to do that.  But the red tablets drew your focus immediately and visibly to the areas that needed your attention and the severity of your lack of attention.

Kanban is like that.

Making your work visible, limiting your work in progress, measuring the flow of your work, making policies explicit, and managing to flow are all designed to give you exactly what you need to apply your improvement brainpower.  Where do these improvements come from?  From you, of course.  Nobody knows how to do the work better than the people doing the work; not an agile coach, not a consulting company, not a manager of the people doing the work – the actual people doing the work are your best source of ideas for improvement.

Organizations usually don’t lack opinions about how to improve; what they lack are ways to get their work situation under control so they can meaningfully study it, ways to sift through the good ideas from the not-so-good ones, ways to know what their priorities should be, ways to project the impact on the work, and ways to measure the actual impact to see where adjustments to the good ideas need to be made.

So, why is Kanban not agile?  Because Kanban doesn’t increase your team’s agility one single iota.  What it does it create the conditions and foundations necessary and  provide you with all the intelligence you need for kaizen – an ongoing journey of improvement, driven by the people doing the work, but always viewing how it improves the system as a whole.

Enhanced by Zemanta
Jan 282013
 
English: It shows that agile methods are focus...

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:

  1. 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’.
  2. 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?

Enhanced by Zemanta
Mar 282012
 
A scrum

A scrum (Photo credit: Wikipedia)

EDIT: Changed some language so as to not give the impression the Manifesto came before all Agile methodologies.

Before the wide adoption of Scrum, there were a group of very smart developer types who discussed values and principles that, if observed and implemented, would lead to delivering high-quality software more quickly than most approaches that were dominant at the time. These people created an Agile Manifesto and articulated the principles that drove it. It is this body of values and principles that is meant when we talk about being Agile, using Agile, etc.

It is important to note that those writings do not specify any specific practices, implementations, or methodologies. It basically says, “As long as you are pursuing these goals and relying on these principles to help you achieve those goals, that’s being Agile.” By and large, this defined itself over and against Waterfall – a process articulated by Winston W. Royce in 1970 as a hypothetical example of a flawed model that would not work for software development but inexplicably became the dominant model for software development and the undergirding of project management for software projects.

If you look at the Manifesto and the principles behind it, you will find nothing about time boxed iterations, sprint planning meetings, or anything that is a specific technique or methodology. Agile is something that is back of, transcends, and critiques methodologies.

This body of principles is reflected in people taking a crack at implementing these things in their software development. In fact, many of the things reflected in the Manifesto came out of some of these attempts. XP attempts to embody these principles. Lean / Kanban also does. Scrum also does.

That last bit bears repeating: Agile is a set of values and principles. Scrum is one particular methodology among others built around those values and principles.

For reasons that I suppose boil down to excellent marketing, it is both widespread and regrettable that Agile is used as a synonym for Scrum. Sometimes, this leads to very entertaining claims made by people who ought to know better such as Agile being invented seven years ago or “Agile projects always operate within a ‘Time-Box.’”

The cause has not been helped by the fact that when Microsoft uses the word “Agile” for their TFS templates, they inevitably mean “Scrum.” Even the Scrum Alliance shows what it really cares about by frequently using Agile as a synonym for their own methodology in their articles and materials (NOTE: This is borderline reprehensible, because they really do know better, which means this is deliberately deceptive in order to snag more Scrumbots who won’t know any better).

This isn’t just some pedantic issue.

For me, personally, one of the things I bring to the table is – as a developer, a mentor, and an instructor – a belief in Agile principles. I used to do this with Scrum. These days, it’s more the Lean / Kanban variety. Someday, it’ll probably be something totally different. But the principles will be pretty much the same; it’ll just be about finding more effective ways to implement those principles.

As a professional, it’s very annoying when people assume that everything I say or do or put on a profile regarding Agile is actually about Scrum. It’s very annoying to try to market myself to companies that say, “Oh, we tried Agile, and it didn’t work here,” when what they mean is they tried Scrum. This distinction becoming hazy in the marketplace has an economic impact on those of us who are very pro-Agile but do not practice Scrum trying to market our services and expertise to a world that no longer knows the difference and may have antipathies toward Scrum.

The other issue is that the equation of Scrum with Agile means a whole lot of ignoramuses are coming in under the Agile banner.

That is not to say that every Scrum advocate is an ignoramus. There are extremely intelligent people implementing, using, and coaching teams on Scrum and they are kicking butt. However, a phenomenon occurring in the marketplace today is that people learn Scrum and they become Agile Coaches, which is somewhat akin to me learning the recipe for clam chowder and going around telling restaurants the best way to make soup (which, invariably, is clam chowder). These people will comment and blog freely and often, filling the Information Superhighway with epistemological roadkill. They write articles. They give conference talks.

All these things reveal to anyone who knows better that these people have no clue, but this is the public face of Agile, now. Learning Scrum gave them a license to be Agile experts, so that’s how they see themselves, that’s how they market themselves, and that’s how the market encounters them. For every one Agile coach who knows what they’re doing, there are twenty who became Certified Scrum Masters, and their ability to sit in a room for two days has now given them Authority (I am a Certified Scrum Master, incidentally).

I feel bad for anyone who is a real Agile Coach trying to market themselves as an Agile Coach, because 90% of the time, Agile Coach is a nice way to say Clueless Scrum Master. And whenever I read a blog or hear a presentation or see an online discussion that is full of Agile fail, I know the person who wrote it is coming from the Scrum camp. The equivocation of Scrum and Agile has given them a license and a platform to address issues they do not fully understand, which has produced awesome advice such as some things I’ve seen in Agile Coaching blogs the past couple of months: “Don’t have too much interaction with the client because it interrupts the team,” “Make sure you’re updating the Scrum Master in your stand up and not the Product Owner,” and “Don’t use TDD on small projects.”

Any Scrum person who truly understands Agile probably cringes at those statements as much as I do, and that just proves there’s a problem.

Scrum may be Agile, but Agile is not Scrum. If you are going to claim to talk about being Agile, make sure you know the difference.

Jan 172012
 
Waterfall Model

Image via Wikipedia

In recent discussions with groups of agile coaches, mentors, Scrumbots, etc., I’ve noticed a sort of ad hoc dividing line between people who really know what they’re doing and people who are still struggling with it.  It’s not the only line, but it’s one of them, and that line (how many times can I use the word “line” in the opening paragraph?) is this:

Does this person confuse processes with principles and/or value processes over principles?

Businesses love processes because they are comforting.  You can document them, replicate them, measure them, and enforce them.  You don’t have to rely on people thinking very much, because there’s a process.  As much as people might try to deny it, the overwhelming majority of people actually like being told what to do.  It takes a lot of pressure off.  So, I do get the attraction and, for some of the reasons above, I’m not anti-process.

However, a process should always be built around certain principles or goals and critiqued by their effectiveness in maintaining those principles / achieving those goals.  It is never ok to stop asking the question: Is our current process still the best way to accomplish what we’re trying to accomplish?  Once you stop asking that question, the process then becomes an end unto itself.  It is now inherently good to follow the process.

Remember the story about the goose who laid the golden eggs?  The reason you valued the goose wasn’t because geese rock; it was because it laid golden eggs.  What you really valued were the golden eggs, and if the goose ever stopped laying golden eggs, you wouldn’t think anything more about that goose than any other.

This is similar to processes and principles.  What you really value are the principles.  Processes only have value if they effectively deliver on those principles.

This applies to many, many aspects of life, but in software development, it applies a lot to companies putting implicit faith in a process rather than critically examining if the process is actually accomplishing what they wanted in the first place.

A commitment to Waterfall obviously comes to mind, but far more insidious is a commitment to old school, textbook Scrum.

Companies want to be more agile.  Scrum is a process that purports to bring you agility, so companies trade blind dedication to one process for blind dedication to another – something Scrum tends to encourage, incidentally.  You even have a person (the Scrum Master) whose entire mission in life is to make sure everyone is following the process.

Companies don’t want to critically think about why they aren’t agile and what things they might need to correct to get them there – they want someone to tell them what to do.  “Do this stuff, and you will be agile.  You will deliver working software faster.  You will value people over processes, with the possible exception of this one.  You will be able to call your team agile.  All you have to do is follow this process to the letter, and magic will happen.”

Unfortunately, that’s not how it goes.  Enforcing Scrum to become agile is like trying to cure all sickness with penicillin.  You can’t just follow the process and assume faster, higher quality software will be the inevitable result.

I’m not anti-Scrum per se, but I am very much anti-making Scrum the new Waterfall.  Don’t stress about your process.  Don’t stress about the integrity of your process.  Think about your actual goals for your team and constantly correct your course to get there.  Change often.  Improve constantly.  There is no textbook procedure that will guarantee a cornucopia of agility just by virtue of being implemented.

Oct 122011
 
Eager Scrum teams

Image by mnordin via Flickr

When we last left our heroes, I was talking about some of the recurring issues I’ve found that Scrum seems to foster – most of which revolve around timeboxed iterations as the primary means for limiting work in progress and generating metrics. So, if you were looking for a solution to those issues, what would you do?

Ditch the timeboxed iterations in favor of something else? Ayuh.

Everybody thinks in terms of features.

Kanban uses individual features for limiting work in progress and calculating metrics, and this is great because features are something everyone understands. When I have a conversation with the business about which features are where in our pipeline, they understand that. When I talk about which sprint we’re on or which sprint we’ve targeted for feature X, that’s not at all intuitive. More conversation needs to happen just to fill them in on what a sprint is and how it works.

However, with Kanban, all conversations revolve around features, themselves.

It’s important to note, too, that business users will always make their changes with regard to features, not sprints. They will not ask to change the priority of sprints or add or remove sprints to the work queue – they ask all those things in terms of features.

Reporting progress becomes very easy. A Kanban board is intuitive and the derivative metrics are easy to provide. Have you ever tried to show a business user a sprint burndown chart? Did it answer their vital questions? ‘Nuff said.

Metrics are tied to features.

With Scrum, metrics are tied to timeboxed collections of features. With Kanban, metrics are tied to individual features. This is great because, instead of offering what sprint a feature is slated for, I can give a projected date for that individual feature.

Since change requests also happen in terms of features, I can easily demonstrate how the removal or addition of a feature will affect the timeline. Reprioritization has absolutely no effect on my planning or timeline, because I’m not scheduling features in blocks of time. With Scrum, reprioritization requires me to restructure the content of my sprints, but with Kanban, we have no sprint to restructure. We just keep getting to features as they come up in the workflow like always. That backlog could be a seething cauldron of reprioritization, and it will have no effect on us at all.

This also helps when incorporating other teams to help us get the job done. For any particular feature, I can give a projection of when we’ll need that completed, so we can schedule them as far in advance as we need with a good degree of accuracy. Sure, that date could change based on user requests, but that’s always the case no matter what process you use.

There are no Hell (insert time increment).

There are no artificially imposed deadlines in Kanban. You have projections, but you don’t have any sense of “by date X, amount of work Y must be done.” The projections are based on actual metrics based on your actual rate of speed, not promises based on what you think you can get done.  In fact, the presence of a Hell Whatever in this process is an indicator that you have a bottleneck or need to revisit your work in progress limits as opposed to being a natural by-product.

With Kanban, I set limits for each stage of work in progress, and those act like floodgates to my workflow. Are people too idle in a particular phase? Increase the limit. Are people swamped? Decrease the limit.

The whole point of the Kanban board is to visualize the workflow for the whole world, and if you aren’t getting a nice, even flow, this is immediately visible to everyone, and you can see exactly where you need to make changes to get a nice, even flow.

With Scrum, this visibility is just not there, and the structure of the process just takes the Big Deadline Problem and distributes it into the Lots of Smaller Deadline Problems.

Kanban is not process-heavy.

That doesn’t mean there’s no process; it just means a lot of the implementation details are negotiable.

There is no KanbanMaster. There are no specific roles that must be filled with specific responsibilities. This allows you to establish these as your business environment sees fit. It can accommodate teams with or without project managers, self-directed teams or externally-directed teams, people with multiple roles or people with granular roles.

It used to be that, when people said, “We tried Agile, and it didn’t work for our environment,” I used to automatically assume they just did it wrong.

While I admit this is still the case an overwhelming majority of the time, I now ask if they tried to do Agile via Scrum (for many orgs out there, “Agile” is a synonym for “Scrum” – I blame successful marketing), because a strict Scrum operation might indeed not work easily in some environments.

Do you need a Product Owner? You don’t. You need a Voice of the Business, and that can take many forms, from one person to a group of people to a (ugh, please don’t do this) requirements document. Kanban recognizes there are principles an agile process needs to implement, but prescribes few implementations.

This is as opposed to Scrum which codifies its implementation and demands that your organization change to accommodate it. People who modify Scrum to fit their environment are viewed with a sort of derision, said to be practicing “Scrumbut.” And I get this, because in order for Scrum to have a chance of being successful, you pretty much need to do all of it or none of it.

Kanban and lean can be done with incremental optimizations. You certainly can uproot your entire methodology and establish a new, streamlined machine, but you don’t have to. You might, for instance, just set up a board to make workflow visible. If that’s helpful, you might start branching out with other lean optimizations here and there. Or you can just say, “Hey, I think we’ve gotten to a point where we’re agile enough. Let’s just cruise with this until we hit pain points, then we’ll optimize some more.” These things are simply not great options with Scrum.

I could say more, but really, most of this boils down to what the central unit of your workflow is going to be. Is it going to be a feature, or is it going to be an increment of time’s worth of features? I think the former unit of measurement and conversation is way more useful to organizations.

Oct 112011
 
The Scrum project management method. Part of t...

Image via Wikipedia

First of all, I’m not “down on Scrum.” I cut my agile teeth on Scrum, I’m a certified ScrumMaster, and it’s really an ok process. Many businesses that want to escape the iron fist of Waterfall but aren’t quite ready for the Serenity-like frontier life of lean and Kanban find Scrum a very helpful transition point. If a client is just fired up about Scrum and, no matter what I say, wants to become a Scrum shop, I will help them do that and not feel dirty.

As time has gone on, however, I’ve become critical of certain key, foundational presuppositions of Scrum.  I still keep doing the bits that I think are great – daily standups, periodic demonstrations and retrospectives – but Scrum en toto is no longer my preferred way of trying to implement agile principles in a business. Here are some reasons why.

Nobody thinks in terms of sprints.

Troy Tuttle once remarked in my hearing, “Nobody ever asks for two weeks’ worth of software.” This sums up the problem nicely. The most natural and ubiquitous way people think about software in progress is in terms of features – what features are done, which ones are being worked on, and which ones still remain. Using sprints to define and communicate your work in progress is, simply, counterintuitive for everyone – especially business users. It is extremely difficult for them to wrap their arms around your workflow.

If your team has to work with other teams, the problem multiplies unless they, also, are organizing their workflow according to sprints.

Metrics are tied to timeboxed iterations.

This dovetails with the above point. Business users don’t ask things like, “How much will you have done in the next two weeks,” they ask things like, “When will the new product search screen be ready?” Unfortunately, all my metrics are tied to sprints, not to individual features.

So, I can say something like, “The product search screen is worth 8 story points. We have 22 story points worth of work prioritized before then, so according to our current velocity, we should tackle that feature two sprints from now. So, not before the next two weeks, but sometime before the next four weeks.”

That’s not that bad, in a sense. I’m able to give a projection that’s of some value, and that may be good enough for most situations. In my experience, however, when the business side hears something like that, they are often befuddled. Most of that is incomprehensible gibberish, and what they get out of it is, “The product search will be done in between two to four weeks,” and maybe that’s enough precision for them, maybe it isn’t. If your sprints are longer, then the problem is even worse.

Timeboxed iterations lead to Hell days.

In the days of Waterfall, developers complained about Hell Week – that week before the deadline when everything was supposed to be done. Corners get cut. Late nights. High pressure. Eventually, your work gets released relying on code that looks suspiciously like a combination of coffee dregs, motor oil, and human hair. This has become such a fixture of developer culture that most companies expect this of their developers.

Scrum breaks Hell Week up into more manageable increments. Instead, this happens at the end of an iteration for a brief period of time as developers rush to get their sprint commitments in. Now, before the Scrumbocops remind me that the proper thing to do is fail and adjust the sprint commitments for next time (I totally agree, btw), I have found virtually no one will do this. Not only does it leave a bad taste in the business users’ mouths, but our Waterfall scarred developers have virtually no concept of it being ok to fail a commitment for the purposes of better management of work in progress. You kill yourself to meet your deadline, then you do it again. This is what a “professional” does.

This also totally screws up your metrics, because your commitment was unrealistic to begin with, and you just made it work. In other words, you’ve institutionalized Hell Day as part of your normal work flow.

Scrum is process heavy.

You have predefined roles and predefined rules for virtually everything, and Gaia help you if you stray from the path. In fact, the role of ScrumMaster is primarily defined as “the person who makes sure everyone follows the Scrum process.” I talk to Scrum shops, and they ask questions like, “We have a project that looks like X, and we’re having trouble figuring out who the Product Owner really is.  Who should the Product Owner be?” Discussions about workflow end up sounding more like some of the Mishnah passages of antiquity with long diatribes about what you can and can’t do on Saturday.

One of the key ideas driving the Agile Manifesto is that people are to be valued over processes. I’m not saying Scrummers fail to do this, but there is an awful lot of emphasis on the integrity of the process. I do admit there are some lean folks who are also this way at heart, but Scrum’s documented dedication to process makes it a little more flagrant.

These are some the key reasons.  There are others.

In my next blog, I’ll go through these reasons and illustrate why I think a lean/Kanban approach alleviates most of these issues in a better manner than Scrum.

Aug 242011
 
Palpatine

Image via Wikipedia

Of my own free will, I would like to issue an apology for satirically associating Jeff Sutherland with Emperor Palpatine.  No one is forcing me to write this.

Any similarities between Emperor Palpatine’s plans for galactic domination and Jeff Sutherland’s plans for galactic domination are entirely coincidental.  I did not mean to imply that Jeff Sutherland, in actuality, destroyed planets or shot lightning bolts from his hands.  Although, I did see him shock a cat, once, with static electricity.  I think it was on YouTube.

I also did not mean, by implication, to portray the Scrum Alliance as a legion of Imperial Stormtroopers.  There are several key differences between the two entities. The SA members do not require oil, for instance.

I hope this clarifies my thoughts on this fine, fine man and his fine, fine disciples.  I, for one, am eager for their rule.

Aug 232011
 
Jeff Sutherland, co-inventor of SCRUM.

Image via Wikipedia

In order to bring you the best information about Agile available, we’ve brought in Jeff Sutherland* (pictured right), one of the co-writers of modern Scrum practices, to answer your questions about agile methodologies.  Let’s get started.

Q: I’m used to dealing with an extensive requirements document in a waterfall process.  Where do the requirements come from in agile?

Jeff: First, I do a scan via satellite of a planet’s surface.  This allows me to ascertain the terrain and any large defenses.

Second, you need reconnaissance troops on the ground.  Depending on the terrain, I might use biker scouts, probe droids, or even AT-STs.  By this point, you should have a good idea of what will be needed to conquer the planet.

It’s important not to commit too early to your preconceived notions about the project.  It may be best just to blow the planet up.  Whatever the case is, make sure your trusted generals do your planning, so you can eliminate them if they fail.

Q: Do agile methodologies scale well?

Jeff: In my own experience, I have to control legions of legions of stormtroopers, and that’s not even counting all the specialized variants or odd-looking ships.  Your scenario may be different.  In my case, I’ve found it to scale quite well.

The key is having teams that can essentially run themselves.  This is what makes robots and clones so handy.  Then you have members of each team report up until, eventually, the heads of all your groups are reporting directly to your Sith apprentice.  He can then choke people at a distance as necessary.  I usually handle any lightning, myself.  I never want to be totally hands off.

Q: How do you fund an agile project?

Jeff: I like to use a two-pronged strategy of muscling in on corrupt merchant guilds and raw oppression.  This usually brings in the funding needed.

I find few people bother me about deadlines, but I do get concerned about them, myself, so I sent my assistant in to demand things like doubling our production.  I remember, once, I paid a personal visit to the Death Star, and Vader (our project manager) informed the General of the station to double the rate of production since I was coming.  Why weren’t they working that fast, before?  I always wondered that.

Q: What are some pitfalls to watch out for?

Jeff: A really big issue for my team was an exhaust vent that led directly to our central reactor.  It was a bad architectural decision, and we paid big time.  We could have at least put a grate over it or something, but that’s the beauty of Agile.  You won’t always do everything right the first time, but you learn from your mistakes and improve with new iterations.

Well, there you have it straight from the man, himself.  I hope this helps my enormous audience of readers as they implement Agile in their own organizations.

*No, we haven’t.