Services We Provide

My boss (that would be me) tells me I must make some money in order to afford to spend time on this blog. So forgive a short post with advertising.

We provide Lean-Agile coaching. See here. Or contact us (contact info is at that site). From one day to 400 days. This is what we do; we're good at it. We do many varieties of coaching.

We also provide Lean-Agile training. In fact, we just opened a new site, http://leanagiletraining.com/ We have been doing training for years, but this site is new. Not as pretty as we would like, but that will be improved iteratively. And more content to add to it.

Within training, we provide both public courses (see that site) and in-house courses (contact us). The public courses are being updated all the time (we have some scheduled that are not showing yet).

You may wish to subscribe to our training course newsletter (monthly)...see on the right-hand bar (Can we help you?) or see the mailing list page at leanagiletraining.com. The newsletter also includes 3 or 4 new ideas each month, which we hope you find useful even if the courses are not interesting at the moment.

...well, maybe not as good as a Super Bowl ad.

Now back to our regularly scheduled programming.

Up the creek. Without a paddle

My friend Mike Vizdos has a blog with cartoons called ImplementingScrum.com.

His latest cartoon is titled "Up the creek. Without a paddle." See here. The idea is that, if you want a specific change to happen or even to stay, you have to keep paddling.

Very simple idea. Very true.

Agile (Lean, Scrum, XP, etc) is a change. A hard change, although also fun a lot too. If you do not keep paddling, then Agile will be viewed as "the flavor of the month". And things will revert to the mean (probably not good Agile, would be my normal guess).

If you stop paddling, things will continue to change. But not in the direction of better and better Agile.

To me, it is a shame to see people stop paddling in the direction of their dreams. Doing one's best is hard, but it is something to be proud of. Something to live for. It may not always be fun, but in a deeper sense, joyful. Every success you have is an example for every other person who feels partially defeated. And the customers around the world need the great stuff you can create. Real customers. Real people. Kids, grandparents, mothers, brothers, sisters, fathers.

(As an aside, let us admit that even customers are not perfect. Many can be pretty bad sometimes. But we still feed even the lesser ones despite their weaknesses. Let us not pray for justice, for who would escape whipping. Let us pray for more generosity than that. The wiser ones have told us: It is more blessed to give....)

So, I hope you will see the value of Agile (of Scrum, XP, of Lean, and related ideas). If you do (and of course it is your choice), prepare yourself for the relentless pursuit of perfection. Prepare for the long march (my phrase for it). Keep paddling.

And have fun doing it. We should enjoy even the struggle part, as it makes us better.

What is the scope of impediments?

Last night at Agile-Carolinas we had Israel Gat, VP of Distributed System Management at BMC Software. He spoke on "Leading the Disruption". He is giving this talk also in Austin, TX (and maybe elsewhere). If you get a chance, I urge you to go. Or just contact him.

After that meeting, I had several conversations. And then thought about them this morning. All that results in this post. Or at least, this question?

What is the scope that defines what might be an impediment?

By definition in Scrum, an impediment is anything that keeps the team from being more productivity. And I personally add that everything is imperfect, so by my definition everything is an impediment to some degree, and the trick is to identify the one or two biggest impediments today.

Scrum has also said that the scope is wide, including such diverse things as engineering practices and personal issues.

What I have not seen talked about much is the scope from an end-to-end Value Stream perspective. So, I would argue that anything that reduces the business value of what the Team produces (or the speed with which the value is realized) is an impediment.

So, as a simple case, imagine you have a Dev team in Charlotte and an "implementation" team in Chicago. (In this context, implementation means all those services around the software that make it actually useful in production.) The Dev team completes their work. The Implementation team is not ready (certainly not as ready as the runner to the right). So no business value can be realized.

I am suggesting this is an impediment. Perhaps the top one for that Dev team. And that Dev team (and their ScrumMaster) need to assure it is fixed (understanding that "a dead ScrumMaster is a useless ScrumMaster"). They probably can't fix it themselves, but they can make many efforts to get others to fix it. Perhaps they need to enlist a manager's help.

To me, this is similar to what Toyota found, ie, that to get the full benefits of Lean, they needed to aggressively train their partner firms upstream and downstream from them in the Lean ideas around flow, pull, JIT, etc, etc.

Does this make sense to you?