Tag Archives: agile management

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.

Related: Software Process and Measurement Podcast With John HunterFuture Directions for Agile Software Development (2008)Assigning Story Points to Bug FixesDeming and Software Development

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

Related: Visual Management with Brown M&MsMaking Data VisibleDeming and Software Development

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.

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

Related: Assigning Story Points to Bug FixesMistake Proofing the Deployment of Software CodeChecklists in Software Development

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

Related: John Hunter’s professional life timelineJohn Hunter onlineJohn Hunter LinkedIn profileTop Leadership blogsTop Management and Leadership blogs

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

    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

Management Improvement Carnival #125

photo of cypress trees in swamp in South Carolina

Photo of Cypress Trees by John Hunter

The Curious Cat Management Blog Carnival selects recent management blog posts 3 times each month. You may submit a link to the management Reddit to have it considered for inclusion in our carnival. More photos from Cypress Gardens, South Carolina.

  • 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.”
  • Systems in Place to Prevent These Medication Errors? Seems Not… by Mark Graban – “We’re taught in the Lean methodology that ‘standardized work’ is not just a matter of writing procedures. We need a culture and an environment where standardized work is actively managed.”
  • Driving Out Fear and Other Similarities Between Drucker and Deming by Kelly Allan – “[Drucker] Inherent in the managerial task is entrepreneurship: making the business of tomorrow. Inherent in the task is innovation. Innovation is above all, top-management attitude and practices. [Deming] The moral is that it is necessary to innovate, to predict the needs of the customer.” (Deming on Innovation – John Hunter)
  • 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…”
  • Continue reading

Assigning Story Points to Bug Fixes

Agile software development has teams estimate the effort to deliver requests from the product owner. The estimates are done in points (in order to abstract away from hours – as estimates have plenty of variation in how long they will really take). Then the teams capacity (velocity) is determined based on looking at how many points they complete in a “sprint” (a set length, often 2 weeks). Then the product owner can prioritize all of the requests with an understanding of how much effort each is estimated to take and the historical capacity of the development team.

I think it is good to add point estimates to bugs. It may well impact how bugs are prioritized – if it is known to be simple a program manager may say, yes I want these 6 first then… If then know the first 2 are likely to take a bunch of time, they may think, ok, I am not going to get these 4 for awhile… They might just accept that, or may wish to shift more hours to bug fixes this sprint. Or they might say well if it is that big an issue maybe we could do x instead…

In practice I rarely has us estimate emergent bugs we are going to fix in the current sprint, but we do it for bugs that are in the backlog. I sometimes will have us estimate a current bug if I think it is may take significant time – to help determine what we really want to and what the impact may be on the teams output for the sprint. We do not have many emergent significant bugs so it isn’t much of an issue for us.

We do have more difficulty accurately estimating bugs, compared to new stories, but we still provide actionable estimates (they are not perfect, but are usable).

We use agile software development principles at work and they have been a great help in letting us be much more effective than we had been previously. The discussion of priorities and delivery expectations are much improved by such methods I believe. And unrealistic expectations can be reduced. For various reason, without adopting some form of agile/lean… software development methods the common pattern I see is software developers being frustrated by unrealistic expectation of their customers (project managers…) being frustrated by failure to communicate what it is reasonable to expect and status updates. A big part of this is the failure to acknowledge variation (and the related difficulty in estimation). Agile/Kanban… are systems that take the variation into account, and therefore the variation is dealt with as natural instead of leading to bad outcomes for developers and their customers.

Response to Should story points be assigned to a bug fixing story.

Related: Future Directions for Agile ManagementMistake Proofing Deployment of Software ApplicationsChecklists in Software Development