Tag Archives: agile management

Management Improvement System Flavors

ASQ has asked their Influential Voices to explore the question “Is Agile the new Lean?” I have participated with the program since 2012: see my past blog posts as part of the ASQ Influential Voices program.

No Agile is not the new Lean.

On this blog, in 2008, I wrote about Future Directions for Agile Management:

As I learned about agile software development, what I saw was a great implementation of management improvement practices focused on software development that was very compatible with Deming’s management philosophy and lean thinking practices.

There are many useful concepts, tools and practices within what people refer to as agile software development. And the same can be said for lean. But they are distinct approaches (the links in this post flush out this idea more for those interested in learning more on that topic). That isn’t to say an organization cannot design their own solution that adopts ideas found in each approach. In fact doing so for software development makes sense in my opinion.

I have written about why trying to find a management recipe to follow is a very bad idea. You need to learn, experiment, adjust and keep iterating doing those 3 things.

Another way agile and lean are similar is that often organization try adopting the slogan name (agile or lean) and a couple concepts or practices they haphazardly pick from those methods and then create a management system that is not good.

What those seeking to improve management should do is to study concepts like lean and agile and then create a management system that works in their organization. To transform to what I would consider real lean or agile (instead of just using the name) requires that how management operates, and how work gets done, changes. This rarely happens other than in a small, though sometimes visible ways. Successful transformation requires continual iteration of improvements to the management system itself.

In my opinion the best starting point is to study W. Edwards Deming’s ideas and use that to create a management system that is continually improving. But I believe lean is the next best starting point and for software development I believe agile is the next best starting point.

If you decide to transform your management system using lean management practices as a focus I think you can do great things. I would delve deeply into lean and also learn about Deming and agile software development. And if you decide to create an agile styled management system then do that and learn from Deming and lean as you continually improve. In either case continually iterate and improve they management practices that are used.

In 2014 I wrote about my efforts to manage using ideas from Deming, agile and lean in: Building a Great Software Development Team.

I have explored agile and lean in previous posts: No True Lean Thinking or Agile Software Development (2010) – Agile Software Development and Deming (2014) – Applying Toyota Kata to Agile Retrospectives (2016) – Management Improvement Flavors (2005)

Good Project Management Practices

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.

This post is in the style of my Good Process Improvement Practices and Practical Ways to Respect People posts.

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.

image of the cover of Managmenet Matters by John Hunter

Management Matters: Building Enterprise Capability by John Hunter

Grow the capability of the organization while making progress on projects.
Use data wisely (data can be extremely valuable and should be used much more, but it must be used with a critical eye).
Use retrospectives during the project and at the end of the project to continually improve the process of managing the project (and the capability of the organization to manage projects overall).
Practice respect for people
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.

Tips

Continue reading →

Applying Toyota Kata to Agile Retrospectives

HÃ¥kan Forss, King (interactive entertainment games), presentation at the GOTO Copenhagen 2015 conference.

I strongly recommend Mike Rother’s book: Toyota Kata.

Description from Workshop description “The Toyota Kata Experience”

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.

I think the great number of worthwhile conference presentations we can all now get sitting wherever we are provides us a great opportunity (and lets us avoid missing out of good ideas because “How could they know“).

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.

Continue reading →

Agile Software Development and Deming

Part two of three of an interview of me with Bill Fox has been published. See part one: John Hunter on PDSA, Deming and Strategy. From part two, Lean, Agile, Deming, Leadership and Management Systems:

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.

Read the full interview with more on how the Deming management system fits with other management strategies.

Magnetic White-Board Kanban Card Options

Just some quick ideas for Kanban whiteboard magnetic card options from a question I answered on Reddit.

Here is the best lean solution: Trying Out My Agile Kanban Board from Jon Miller.

kanban board with magnetic whiteboad cards

Magnetic kanban board from Jon Miller.

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).

More links with kanban board options: Magnetic whiteboard cards (50-pack) – Physical Taskboards – I think just magnetic symbols (not magnetic white board card) but could use magnet with icon to stick paper to the board

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.

Software Process and Measurement Podcast With John Hunter

In my podcast with Tom Cagley, Software Process and Measurement Cast: John Hunter on Management Matters, as you might expect there was a bit of a focus on software development and agile software development as related to the ideas I expressed in Management Matters: Building Enterprise Capability.

Deming: management system, continual improvement, respect for people (the 3rd point I said I would mention, but didn’t)
Why do so many management improvement efforts fail?
The proxy nature of data
Building Adoption of Management Improvement Ideas in Your Organization

photo of John Hunter at the Borobudur Temple

John Hunter at the Borobudur Buddhist Temple in Indonesia.

Continue reading →

Agile Story Point Estimation

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).

These thoughts were prompted by: Story Points Considered Harmful – Or why the future of estimation is really in our past…

Continue reading →

Pull Consulting: Immediate Management Consulting As You Need It

2013 Update – New method for by the minute consulting with John Hunter.

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 🙂

home page of MInute Box with John Hunter graphic

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.

Management Improvement Blog Carnival #156

The Curious Cat Management blog carnival highlights recent management blog posts 3 times each month. The posts generally focus on the areas I have focused on in the Curious Cat Management Guide since 1996 (Deming, evidence based management, lean manufacturing, agile software development, systems thinking…)

The Key Questions for a Minimum Viable Product Project by Anthony Panozzo – “What are you trying to learn with this particular MVP?
What data are you collecting about your experiment?
What determines the success or failure of the experiment?” [bold added – John]
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.”

Sunset over Andaman, Khao Lak, Thailand. By John Hunter

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.”

Continue reading →

Avoiding Tragedy of the Commons for Software Development

Kanban and Tragedy of the Commons

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:

I think the “tragedy of the commons” analogy works. As long as the users don’t have pay for use (or decide to prioritize) the danger exists for the abuse. So if you have a developer team and everyone just gets to dump tickets on to them and then whine if they don’t get what they want, when they want, I see the analogy as accurate. If people can just treat a resource as though it was suppose to just serve them and the resource is overwhelmed I see that as tragedy of the commons.

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 →