Tag: kanban

Posted on by

Discipline

Premise 1: Self-discipline is the only meaningful form of discipline.

Premise 2: Simpler solutions are usually preferable to more-complicated solutions to the same problem.

Premise 3: Without self-discipline on the part of those using it, no process model or method or framework or tool of any kind provides the value its proponents believe it can provide.

Premise 4: A formal process that imposes strict rules tends to teach people to follow rules rather than to cultivate self-discipline.

Premise 5: The longer and more deeply a person invests in a given idea or habit, the more difficult it becomes for that person to let go of the idea or habit, or even to question it.

Premise 6: In the diffusion of any innovation, the main reason Innovators and Early Adopters achieve better results than Late Adopters and Laggards is the former are predisposed to try unfamiliar things and take risks, and not primarily because the particular innovation is intrinsically better than whatever it replaces (even if it happens to be a little better on the merits).

Premise 7: The factor that makes an innovation useful is that it comes at a time when it is needed, in a context where it is needed, and to people who are in a position to make use of it; not necessarily that the innovation itself is “best” in a general or permanent sense.

Continue reading Discipline

Posted on by

Handling Unplanned Work (Webinar)

Most software development teams today are using a process based on the idea of iterative development and incremental delivery.

Exactly how long the iterations are and how big the increments are may vary. Whether the iterations are treated as time-boxes or are used to establish a cadence may vary, too. But in general, teams are no longer using an end-to-end linear process for software development and delivery.

The details of various process models and frameworks differ, but the overall shape of the process is that teams carry out planning in waves or stages, zeroing in on near-term work close to the time they will start on it. Then they plan to bite off a reasonable chunk of the planned work and deliver it within a certain time frame.

We want to get in front of risks and external dependencies so that we will not stumble over them at the last moment, but on the whole we defer detailed planning and design until close to the time we will implement the software. That way, we avoid investing a lot of time in details that are subject to change.

We all know the mantra, “Plans are useless but planning is essential.” We all know that our plans are a best guess at a point in time, and nothing more. And yet, we all feel stressed when our plans are disrupted.

We know that unexpected things happen in the normal course of work. Priorities change. Urgent requests come in. Production issues occur.

And the processes we use – Scrum, Kanban, “Scrumban”, or some customized variation of these – include mechanisms to handle unexpected work gracefully.

Despite all these things, we still tend to react to unplanned work as if it were an emergency.

Is everything really an emergency? And what should we do when the unplanned work pushes our planned work aside?

In the context of software development, what’s an emergency, really? Is every unexpected occurrence a genuine emergency? How can we tell the difference in the heat of the moment?

Is it realistic to think a development team can take on more work than their capacity, just because the new work is deemed more important than other work in progress?

Is it sensible to gloss over software engineering principles, testing, refactoring, and general attention to detail in order to push code to production in a rush?

What are the mechanisms built into processes like Scrum and Kanban to handle unexpected, urgent work that wasn’t planned?

Why do people react as if they are required to complete everything that was planned in addition to every urgent, unplanned item?

What are practical ways to respond when an unplanned item comes up, that ensure we are delivering the maximum possible business value – with emphasis on the word possible?

Join us in the next First Monday Webinar to explore these questions and to consider the unique problems you are facing in your own organiztion. Two sessions with the same content are scheduled:

There’s limited participation, so that we’ll have time and capacity to explore your real-world situation. See you online!

Posted on by

Does your organization need an agile scaling framework?

In collecting information for the ebook, Choosing an Agile Scaling Framework: A handbook for decision-makers, I was surprised to notice that the Kanban Method kept bubbling up to the top of the list of choices in nearly every scenario. For every business need except one, it was the best or one of the best choices. (The exception is the case when the organization only intends to pretend to change. For that purpose, less-expensive alternatives are available.)

Why would that be true? I wondered.

Continue reading Does your organization need an agile scaling framework?

Posted on by

Lean Kanban France 2012 will take place 18-19 October

Lean Kanban France 2012 is coming up in a couple of weeks. The conference will be hosted on 18-19 October by Valtech at their offices in the heart of Paris.

I’m honored to be included on the program of an event that features so many luminaries in the field. My small contribution will be a session entitled Structural Impediments to Lean. The premise is that the conventional organizational structures and basic assumptions regarding roles and procedures tend to present obstacles to the effective use of Lean thinking in companies. It’s a subject I started to explore in earnest a couple of years ago at Lean Kanban Europe 2010 and have continued to explore in my work since then.

Here is the session description from the program.

Continue reading Lean Kanban France 2012 will take place 18-19 October