A thought experiment to help you decide on an effective course of action

Consider how your organization is currently developing products and/or services. As a thought experiment, consider how to make things worse. For example, have people work on too many things, don’t have a process where you resolve multiple requests, have product managers create requirements

for the team and just hand them off in written form, have developers and testers be in separate organizations, have managers makeup schedules and then berate developers when they are not met, … You get the idea.

I’m pretty sure you can see that things will get worse. Now, consider where in your organization you are doing some of these ineffective things. Could you stop doing some of them? Even partially? If it became worse when you started doing these wouldn’t it get better if you just stopped doing them? Sometimes improvements are easier to achieve just by stopping doing things incorrectly.

Of course, making these changes is no guarantee of improving your process, but generally, improvement will occur if you do them. As always, you must run any improvement as a hypothesis of it being a better way and validate that it is.

Learn more at Understand Your Options.

If you’re having problems sequencing your work items, this is most likely why

There are several concepts needed to do this:

  1. The items to be sequenced must be both the smallest batch of work that can be realized by the customer. They must also include all the work items required for the realization. Note that epics are too large, MVPs are about discovery of what’s of value and features often do not realize value on their own.
  2. A vision on what we’re trying to achieve that the owners of the work being prioritized can agree one. This has to take place at the leadership level.
  3. A way of comparing two items based on cost-of-delay and time to complete.
  4. Being able to implement the items quickly in the order they are sequenced. This provides motivation for the other two. This requires working on smaller sub-batches of this work. Having 3 months of work will not get us to attend to the delays between teams.

Whenever I see people having problems with prioritization, I know one or more of these items are missing.

What’s obvious or quickly learned as it’s pointed out #4

#developer. When you are given a requirement, always ask, “how will I know I’ve done that?” no matter how simple the requirement is. You’ll be surprised at how often you are surprised at the answer.

#productOwner.  When you give a requirement, always add how they will know when they’ve done it. State it as an actual result or example that illustrates the rule. 

I tag each insight with one or more roles that it will relate to. I will provide a link when more information is available.

You can see the accumulated insights here.

The best way to get these as I add to the list is to subscribe (see upper right of this page).

What’s obvious or quickly learned as it’s pointed out #3

#developer. When you finish something look for something else to help folks finish. See Manage Work-in-Process (WIP) by Focusing on Finishing

I tag each insight with one or more roles that it will relate to. I will provide a link when more information is available.

You can see the accumulated insights here.

The best way to get these as I add to the list is to subscribe (see upper right of this page).

What’s Obvious or Quickly Learned As It’s Pointed Out #2

everyone. Consider the cost of people being too busy. There is a toll of multi-tasking on them, but it also means they are not available to other people. This means one person being overly busy impacts everyone else they interact with. This slows down the work to be done. Our goal is not to have busy people but to get things done quickly. Large delays don’t happen at once. Rather they are the result of a cascading series of small delays.

Continue reading “What’s Obvious or Quickly Learned As It’s Pointed Out #2”

What’s Obvious or Quickly Learned As It’s Pointed Out #1

#everyone. Working on too many things creates both multi-tasking and delays in our workflow. The causes of this include: interruptions, a lack of focus on finishing, have too large work items, product managers focusing on getting things started instead of finishing them and poor organizational structure.

Continue reading “What’s Obvious or Quickly Learned As It’s Pointed Out #1”

Teaching/Learning Business Agility a Step at a Time

I am a big believer that people are more capable and know more than they (and especially many consultants) give themselves credit for. They can tap this knowledge in several ways. One way is to mention insights that people already almost know or even do know, but have never explicitly stated it. The second is to provide new concepts that they can readily verify from their own experience. Continue reading “Teaching/Learning Business Agility a Step at a Time”

What to look for in frameworks and their providers

  1. An explicit starting point tailored for your organization.
  2. A statement of objectives for each part of the organization that allows for making local decisions in the global context.
  3. A support system to help you with challenges that arise so you need not reinvent the wheel
  4. A method of improving over time so you need not transcend the framework.
  5. A systems approach in guiding the adoption of the framework. This includes how to talk to the different roles in the organization.
  6. An increasing number of practices from which to choose without adding complexity to the framework

Does incorporating a few Agile practices into waterfall make waterfall Agile?

Of course not. But yet we hear people infer that incorporating a few Lean practices into Scrum makes it Lean. It doesn’t.

Waterfall is not just based on its practices, but on its mindset of being able to predict and plan out ahead. Putting an Agile practice into waterfall will likely improve things, but it doesn’t make it Agile. The reason is that waterfall =mindset + practices. The practices are done within the context of the mindset.

Continue reading “Does incorporating a few Agile practices into waterfall make waterfall Agile?”