Tag Archives: agile management

I find myself working as a project manager, or a program management consultant more frequently in the last few years. As would be expected by those reading the Curious Cat Management Improvement blog, my project management views are based on the management improvement principles I have discussed here for over 20 years.

Good project management practices include

Deliver a working solution quickly; add value as you have time. Don’t aim to deliver a final product by the deadline and risk missing the deadline. Deliver a good solution early, adjust based on feedback and add more as you have time.

Prioritize – do fewer things, and do them well.

Limit work in process (WIP) – finish tasks, avoid the problems created by splitting attention across numerous tasks.

Consider the long term from the start – build solutions that allow iteration and continual improvement. An initially very good solution that is difficult to adapt as desires change is not a good solution.

Coach people on good management improvement practices as those opportunities present themselves as the project moves forward. This will let them be more effective on the project and also build the capability of the organization for the long term. Don’t just “trust” people to succeed without giving them the proper training, coaching and authority.

Select the right people for the project – the decision makers and those working on the project need to include those most knowledgeable about end users for the what the project will deliver. Those involved also need to have the right knowledge, personality, skill and roles in the organization.

Kata means pattern, routine, habits or way of doing things. Kata is about creating a fast “muscle memory” of how to take action instantaneously in a situation without having to go through a slower logical procedure. A Kata is something that you practice over and over striving for perfection. If the Kata itself is relative static, the content of the Kata, as we execute it is modified based on the situation and context in real-time as it happens. A Kata as different from a routine in that it contains a continuous self-renewal process.

A point made in the presentation that is very simple but still constantly the source of failure is that the current system isn’t supporting improvement. Retrospectives are a good method to help improve but if there is no time to think about the issues raised and come up with experiments to improve and review of whether those experiments worked or not and why failure to improve is the expected result.

Creating a culture where it is expected that any improvement ideas are tested and evaluated is one of the most important changes on the path to a company that will be able to continually improve. If not, what happens is some changes are good, many are not and soon people lose faith that any effort is worth it because they see how poor the results are. By taking care to evaluate what is working and what isn’t we create a process in which we don’t allow ad hoc and unsuccessful changes to demoralize everyone.

I see that agile is very consistent with Deming. Agile has all sorts of variants, so to different extents, they fit in. But one of the things I find really interesting is the agile folks, and of course the lean software folks, they much more than any other group of people I’ve seen traced the agile ideas back to find Deming’s ideas.

So it seems to me many of the leading agile and lean folks have tracked it back to Deming and then incorporated some Deming’s thinking. Now, the majority of people that are doing agile stuff have no idea that so many of the ideas track back to Deming so well. But I think that agile stuff is largely very consistent with Deming.

And it’s even largely very consistent with Deming when the words don’t match up correctly. So, one of the agile tenets is people over process. That’s not at all what Deming would say. But, in my opinion (from when I read a bunch of the agile stuff and was trying to figure out how to fit things together), what they really said was that the work that people are doing should not be prescribed from on high by processes that prohibit them from doing the work effectively.

In the software development world, they were used to processes being driven by heavy handed business ideas that don’t fit very well with how software development should be done. So that they see the word Ã¢â‚¬Ëœprocess’ as tied to heavily prescriptive ideas from people that don’t understand software development imposing process on software development.

Why, well mainly I am kidding about it being the best, but if you don’t read his Gemba Panta Rei blog you should! Go add it to your RSS feed reader, before you continue with this post.

Ok, welcome back. In addition to thinking his blog is great the solution from his blog is very flexible and easy – though it isn’t quite a packaged solution (as asked for on Reddit). Also that post provides some good insight into the thinking behind the board (as well as how to create your own).

Another silly site, that sells some sort of solution, blocked my access because they don’t sell in the country my computer reported being located in. So I didn’t give them a free plug (assuming their product was decent which it might be?). Very dumb design if you ask me; well even though you didn’t ask, I told you anyway.

Localization that impedes users rather than helping them seems far far too common in my experience. Mapping (and related – find closest…) uses are about the only localization stuff I find useful – country based localization I nearly always find annoying or crippling. And showing my location on a map is totally awesome (especially as I travel around as a tourist – or really in whatever capacity). Such bad design and poor usability decisions cost companies money.

In agile software development tasks are documented as user stories. Then the level of effort for those stores can be estimated by assigning each story points. The velocity that can be produced in a period (called a sprint, for us 2 weeks) can be estimated. Thus you can predict what can be delivered in the next sprint (which can help business managers make priority decisions).

I have found estimation to be worthwhile. In doing so, we accept there is a great amount of variation but points give a hint to scale. They can help prioritize (if you have 5 things you want but 1 is much harder you may well drop that to the bottom). I have always accepted a great amount of variation in the velocity, worry about the variation I don’t find worthwhile. I do think trying to act as though the velocity is precise can lead to problems. At the same time having a measure of velocity, even accepting understanding variation was present, was useful.

Over time reducing variation (probably largely through better estimation and perhaps a few better tools, reduced technical debt, better documentation, testing…) is helpful and laudable. We made improvement but still lots of variation existed. The biggest help in reducing the measured velocity was breaking down large stories to more manageable sizes. The challenge of estimating user stories, I suspect, has some fairly high variation (even with good system improvements that can help reduce variation).

Large stories just can hide huge variation in what is really required once getting into implementing it.

The way we did estimation (discussing in a sprint planning meeting) did take some time (but not a huge amount). It was agreed by those involved that the time spent was worthwhile. Sometimes we did slip and spend too much time on this, that was an area we had to pay attention to. The discussions were educational and helped provide guidance on how to approach the story. The value of discussions around estimations was probably the biggest surprise I have had in implementing any agile ideas. The value of those discussion was much higher than I imagined (I basically anticipated them just as non-value added time to get the result of an estimate, but they were a source of learning and consensus building).

As happens in this fast paced world this service is no longer available. The company has shut down their web site.

I think the potential for consulting as you need it is great. I actually was looking into creating an application to support the ability to provide this service with someone else; but we just had too many other things going on. I have now made myself available for consulting you pull as you need it through MinuteBox. You can get consulting when you need it for as little time as you need.

So if you are trying to apply the ideas I discuss on this blog and run into issues you would like to get some help with connect with me and you can get some immediate coaching on whatever you are struggling with. I am offering a special rate of $1.99 a minute, for now. The graphic on the right of this post (any post on this blog, actually) will show if I am available right now (as does johnhunter.com). If so, you can connect and get started. If not, you can leave a message and we can arrange a time.

I am featured on MinuteBox with this cool graphic, isn’t it nice 🙂

John Hunter feature on Minute Box homepage

One advantage of this model is that those of you following this blog have a good idea of what topics you would like to delve into more deeply with me. If you have any questions on a particular topic you would like answered today or arranging coaching on specific topics over a period of time or help planning a project or someone to bounce your ideas off give this consulting as you need it model a try.

For those of you management consultants reading this blog (I know there are many) you can create your own Minute Box account easily and provide this service also. And even if you are not a consultant if you have advice worth sharing (and I know there are many of you also) you can also set up an account.

Less Process, More Discipline by Charlie Martin – “Without it, you lose everything agile methods promise. The key to agile methods is this: You may have less process, but you must have more discipline.”

Evaluating Executive Performance by Art Smalley – “One interesting thing that I will note that was considered in Toyota in Japan by the HR department when evaluating executives was how their previous departments fared after they had left. If the department continued to improve then this was generally a good sign.”

The evolution of design to amplify flow by John Hagel – “If we want to remain successful and reap the enormous rewards that can be generated from flows, we must continually seek to refine the designs of the systems that we spend time in to ensure that they are ever more effective in sustaining and amplifying flows.”

The “Tragedy of the Commons” archetype often manifests itself through “Shared Services”, when a small number of people with specific skills, work across different teams. Each team in isolation gets benefit from the Shared Service, but when demand for the service exceeds its capacity, then nobody benefits. At a smaller scale, a team with a low “bus factor”, or a hero, can also suffer from a tragedy of the commons, when too much work is dependent on a single person.

One of the comments on this post suggested that the tragedy of the commons wasn’t an accurate description. My comment:

There are many ways to manage that problem (some manager deciding the priority for example). Then you may have other problems, but may avoid the tragedy of the commons scenario (in reality this setup is often done, but most don’t accept the prioritizations and just expect the development team to get everything done – which means you don’t avoid the tragedy of the commons problem).Continue reading →

What Next? by David Ing – “The underlying problem is that it seems to come down to having to completely change the culture of an existing business. This can be done internally, and often is done by heroic souls today, but like the advice of how to eat an elephant (‘one bite at a time’) after a while anyone’s going to get pretty sick of tasting just bad elephant every day.”

The second death of agile by Niklas BjÃ¸rnerstedt – “Agile should evolve, but I think it should not loose its focus on software. If you are interested in “agile” outside of software you should study systems thinking. Why reinvent the wheel? The combination of systems thinking and agile is much more potent that some new bloated variant of agile.”

Lean’s Fork In The Road by Bill Waddell – “They are driven by the idea that the future is unknown, but if you continually improve the processes for getting work done you will be in good shape, no matter what the future holds. Do the work well in terms of minimal waste, excellent quality, driving yourself to take the best care of customers, and things will turn out all right. Better than all right, in fact…”