Posts about Software Development

Root Cause, Interactions, Robustness and Design of Experiments

Eric Budd asked on The W. Edwards Deming Institute group on LinkedIn

If observed performance/behavior in a system is a result of the interactions between components–and variation exists in those components–the best root cause explanation we might hope for is a description of the interactions and variation at a moment in time. How can we make such an explanation useful?

A single root cause is rare. Normally you can look at the question a bit differently see the scope a bit differently and get a different “root cause.” In my opinion “root cause” is more a decision about what is an effective way to improve the system right now rather than finding a scientifically valid “root cause.”

Sometimes it might be obvious combination which is an issue so must be prevented. In such a case I don’t think interaction root cause is hard – just list out the conditions and then design something to prevent that in the future.

Often I think you may find that the results are not very robust and this time we caught the failure because of u = 11, x = 3, y = 4 and z =1. But those knowledge working on the process can tell the results are not reliable unless x = 5 or 6. And if z is under 3 things are likely to go wrong. and if u is above 8 and x is below 5 and y is below 5 things are in trouble…

To me this often amounts to designing systems to be robust and able to perform with the variation that is likely to happen. And for those areas where the system can’t be made robust for some variation then designing things so that variation doesn’t happen to the system (mistake proofing processes, for example).

In order to deal with interaction, learn about interaction and optimize results possible due to interactions I believe the best method is to use design of experiments (DoE) – factorial experiments.

Continue reading

Building a Great Software Development Team

twitter screen shot of the quoted conversation

Elliot: I worked with some of the best programmers I’ve ever known at the tiny, obscure ASEE

Adam Solove: Why do you think that happened? They hired for passion, rather than experience?

If I had to pick one thing, passion would likely be it but really it is a complex assortment of things. Passion for the right things, based on what we aimed to be, mattered a great deal. That took the form of being passionate about the user experience, being passionate about good software development practices, being passionate about good software itself, being passionate about treating each other with respect, being passionate about learning and improving.

I think there were several other important factors, such as: the skill to turn a passion for good software into actual good software. This required intelligence, interest and knowledge about software development but didn’t require specific experience (computer science degree, 2 years of Ruby on Rails development, certification or any such thing). Hiring based on experience is a big mistake. In my opinion hiring based on capability and potential (which is based partially on experience) is wise.

Another factor is that we had people (those first few hires were critical) that were really knowledgable about programing good software and that became a self reinforcing process. The gaps one person’s ability and knowledge could be filled by someone else helping them understand and get better.

The expectation was that we found great solutions. If we didn’t we kept looking and asked each other for help (another factor in creating a great team). We didn’t just accept that we were confident the solution wasn’t very good but couldn’t find any better options so I guess this is the best we can do.

We were interested enough in good results that we would push for better options instead of just accepting something that was kind of ok. This shouldn’t be such a big deal; but in practice it is huge. So many places just end up avoiding conflict to the extent that it is a huge detriment to results.

Without confidence, honest debate about ideas is suppressed as people are constantly taking things personally instead of trying to find the best ideas (and if doing so means my idea is criticized that is ok). Our group was great at this. It is something I find it a bit silly to say a workplace was “great” at but in most places I find the fear of someone being concerned stifles discussion to an unbelievable extent.

This is also one of many areas where the culture within the team was self reinforcing. As new people came on they understood this practice. They saw it in practice. They could see it was about finding good ideas and if their idea was attacked they didn’t take it nearly as personally as most people do in most places. I sought to understand if people we looked at hiring would be comfortable in such an environment.

Continue reading

A Good Management System is Robust and Continually Improving

imagine various people working within it, somehow swapping out gears and cogs without the clock stopping or slowing down even a little.

This is a fairly good quote on a good management system. Some people might not like the mechanistic model – comparing an organization to a clock, and I agree that isn’t the right model, but even so it is a good quote.

The quote, from a story about the San Antonio Spurs captures what should happen with a good management system. Things just keep running well as inevitable changes take place (and keep getting better in the case of a management system).

A good management system doesn’t rely on heroic efforts to save the day. The organization is designed to success. It is robust. It will succeed with all the variation thrown at it by the outside world. A good management system takes advantage of the contributions people offer, but it is not perform poorly when others are relied on.

A well run organization has graceful degradation (when one component fails or one person is missing the performance doesn’t suffer, bad results are avoided).

With software for example, a decently created web sites may use javascript to enhance the user experience but if javascript is unavailable the site works fine (just missing some neat features that are nice but don’t prevent users from getting what they need). Poorly designed software has critical dependencies on conditions that cannot be guaranteed to be present for end users and the software just fails to work when those conditions are not met. Ungraceful degradation is too common in software. It is also too common in our management systems.

An organization succeeds because of the efforts of many great people. But the management system has to be created for an organization to prosper as what we all know will happen, happens: people will leave and need to be replaced. And the people that stay will need to adjust to new conditions inside the organization and in response to external forces. A good management system is constantly improving performance, innovating, increasing the robustness of systems and increasing the capability of people.

Related: Bad Weather is Part of the Transportation SystemHow to Sustain Long Term Enterprise ExcellencePerformance dependent on specific individuals is not robust and not capable of continuous high quality performanceEuropean Blackout: Human Error-Not

Deming and Software Development

I am sometimes asked about how use Deming’s ideas on management in a software development context. My belief is Deming’s ideas work extremely well in a software development context. The main issue is often unlearning some assumptions that people might have about what the Deming management system is.

It really is surprising to me how many “knowledge workers” respect Deming ideas but then say his attempts to treat factory workers as thoughtful people who should be respected and involved in improving their processes doesn’t make sense for them because they are “knowledge workers.”

There are many good things being done to improving the software development process. I think many of them are very Deming-like in their approaches (but to me miss out on aspects of the Deming management system that would be helpful). I think Dr. Deming’s approach to software development would focuses on the system of profound knowledge (the 4 inter-related areas below):

  • Understanding variation – software development has quite a bit of variation, some probably innate [unique work] and some due to not having good procedures, batching work, not fixing problems right when they are seen, quick fixes that leave the system venerable in the long term (when you make one simple change to the code it has an unanticipated consequence due to poor practices that could have been eliminated), etc.. Many good coding practices are effective strategies to deal with this issue. And building an understanding of variation for managers (and business process owners/product owners) is very helpful to the software development process. The ideas in agile and kanban of focusing on smaller delivery units of work (one piece flow, just in time, cycle time…), customer value, maintainable code, sustainable work conditions, etc. are directly found in a Deming management system.
  • Appreciation for the system of software development. Don’t just complain about bugs. Examine the process of development and then put in place mistake proofing efforts (don’t duplicate code, use integrated regression tests, don’t put artificial constraints on that result in system distortions – unrealistic targets…). Use things like kanban, limited work in progress, delivering value to customers quickly, think of success in terms of getting working software to customers (not meeting internal delivery goals), etc. that take into account our experience with systemic software development problems over the decades.
  • Theory of knowledge – how do we know what we know? Are estimates reliable? Lets look at what users do, not just what they say (A/B testing…). Software developers often appreciate the value of usability testing, even though they rarely work for organizations willing to invest in usability testing. In my experience when software developers object to usability testing it is normally really an objection to overwork, and the usability testing is just going to give them more work or criticize things they were not allowed to spend the time they needed to do great work. That won’t always be the reason but it is the main one in my experience (I suppose their is also fear and just the psychology of not wanting to hear anything negative about what has been created – even if the usability testing shows tons of great results people will often focus on the negative).
  • psychology and respect for people – This pretty much seems like it is the same for software development as everywhere else.

Continue reading

What is the Explanation Going to be if This Attempt Fails?

Occasionally during my career I have been surprised by new insights. One of the things I found remarkable was how quickly I thought up a new explanation for what could have caused a problem when the previously expressed explanation was proven wrong. After awhile I stopped finding it remarkable and found it remarkable how long it took me to figure out that this happened.

I discovered this as I programmed software applications. You constantly have code fail to run as you expect and so get plenty of instances to learn the behavior I described above. While I probably added to my opportunities to learn by being a less than stellar coder I also learned that even stellar coders constantly have to iterate through the process of creating code and seeing if it works, figuring out why it didn’t and trying again.

The remarkable thing is how easily I could come up with an new explanation. Often nearly immediately upon what I expected to work failing to do so. And one of the wonderful things about software code is often you can then make the change in 10 minutes and a few minutes later see if it worked (I am guessing my brain kept puzzling over the ideas involved and was ready with a new idea when I was surprised by failure).

When I struggled a bit to find an initial explanation I found myself thinking, “this has to be it” often because of two self reinforcing factors.

First, I couldn’t think of anything else that would explain it. Sometimes you will think right away of 4 possible issues that could cause this problem. But, when I struggled to find any and then finally came up with an idea it feels like if there was another possibility I should have thought of it while struggling to figure out what I finally settled on.

Second, the idea often seems to explain exactly what happened, and it often feels like “of course it didn’t work, what was I thinking I need to do x.” This often turns out to be true, doing x solves the problem and you move on. But a remarkable percentage of the time, say even just 10%, it doesn’t. And then I would find myself almost immediately thinking, of course I need to do y. Even when 10 seconds ago I was convinced there was no other possibility.

Continue reading

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

Podcast Discussion on Management Matters

I continue to record podcasts as I promote my new book – Management Matters: Building Enterprise Capability. This the second part, of 2, of my podcast with Joe Dager, Business 901: Management Matters to a Curious Cat. The first part featured a discussion of 2 new deadly diseases facing companies.

image of the cover of Managmenet Matters by John Hunter

Management Matters by John Hunter

Download this podcast.

Links to more information on some of the topics I mention in the podcast:

More podcasts: Process Excellence Network Podcast with John HunterBusiness 901 Podcast with John Hunter: Deming’s Management Ideas Today (2012)Leanpub Podcast on Management Matters: Building Enterprise Capability

Joy in Work in the Quality Improvement Field

As I mentioned previously, I will be posting on a topics raised by Paul Borawski, CEO, ASQ as part of ASQ Influential Voices. This month Paul’s post, Are Quality Professionals Happy On the Job? looks at job happiness in the quality improvement field.

Paul stated he “wasn’t surprised that Forbes Magazine named software quality assurance engineer as the ‘happiest job’ in the U.S.” I was. Frankly looking at the results I question the methodology used – I just find their claims questionable. Whether any ranking could be sensible is also a reasonable question. I do believe certain careers make people happier than others, I question whether you can sensibly differentiate the top 20.

Still, looking at the happiness of those in the quality field is an interesting topic. My father created a challenge for me. He loved what he did: professor (statistics, chemical engineer, industrial engineer, business) and consultant (same things, with focus on quality and management improvement). Helping achieve better results was important to him. And helping create joy in work was also. It took me a while to see how much of an outlier he was – finding people who love what they do is much rarer than those that complain a great deal I have found.

That software development ranks toward the top doesn’t surprise me. Software programmers are some of the people happiest in their jobs in my experience. My experience is biased toward those given more freedom than those working in large bureaucracies (I can imagine those programmers are less happy overall). In addition to being happier with their jobs they also are demanding. They are not the least challenging of authority (some managers seem to equate docility with happiness, but that isn’t accurate, in my opinion).

To me the quality field allows for a great deal of joy in work. That doesn’t mean it is without frustration. I think the field does have a fairly high level of frustration as many are stuck in systems that are moving much to slowly to improve management practices. This is the biggest concern I find from most in the quality improvement field. So in order to be happy one has to learn to cope with some frustration while making good progress and finding happiness in all the achievements even while knowing more could be done.

Related: The Importance of Management ImprovementRespect People by Creating a Climate for Joy in WorkRespect for People: Optimize for Developer Happiness at EtsyCreate a System That Lets People Take Pride in Their WorkSigns You Have a Great Job … or Not

Continue reading

Respect for People: Optimize for Developer Happiness at Etsy

The webcast above discusses the culture of software engineering at Etsy (a very popular site providing a marketplace and community for small businesses – artisan focus). Some of the key points of the talk. Etsy trusts employees. Etsy’s strategy is to optimize for developer happiness. Etsy has lunches twice a week where employees build community.

Etsy sees code as craft. The echos Etsy’s value on authorship: “the people behind what we buy make commerce meaningful.” It re-inforces the belief that work has meaning and is valued and should have intrinsic value to those doing the work, people should have the opportunity to take pride in their work.

Chad Dickerson discussed the importance Peter Drucker placed on connecting people to the value provided to customer. Etsy takes steps to connect employees to the value provided to customers, including emphasizing the community of the company and the customers of Etsy.

Related: Respect People by Creating a Climate for Joy in WorkMistake Proofing Deployment of Software CodeBuild an Environment Where Intrinsic Motivation Flourishes

Continue reading

Management Improvement Blog Carnival #160

monkey at the Singapore Zoo

Monkey at the Singapore Zoo by John Hunter

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, innovation, lean manufacturing, customer focus, process improvement…).

  • Reflections on the 100th Birthday of Taiichi Ohno by Masaaki Imai – “Taiichi Ohno always placed respect for the worker first in his approach to kaizen. His focus was always on the customer, both external and internal”
  • A Lean Leader strengthens the business by developing people through coaching process improvement at the gemba by Jeff Liker – “Thinking of a leader as a teacher and coach, as managing from the gemba, believing deeply that people are the only appreciating assets of the company, believing in the value of intentionally creating a common culture and being a role model of that culture, and that the adaptiveness of the business to meet the challenges of the environment comes from how people are developed all the way down to the worker is quite different than the leader as the captain of the ship steering it cleverly through brilliant personal insights.”
  • Inspiration Stimulates Productivity and Engagement by Nicole Radziwill – “I’d also like to propose that engagement is a symptom – a consequence of feeling good and having a high quality consciousness! Let’s work on the root causes, and focus less on the symptoms.”
  • Kanban Networks Exerciseby Yuval Yeret – “The exercise brought to life the complexity of the organization’s network but highlighted how a Kanban system can simplify its operation as well as drive towards improvement. There were several A-Ha moments of understanding how Limited WIP would solve systemic problems currently haunting the organization.”
  • Continue reading

Learn to Code to Help Your Career

I believe there are big benefits to knowing how to code (programing, software development). What is possible for your organization is often significantly impacted by understanding how to properly use software (and create it, coding, when needed). The lack of understanding of software is a significant problem not just for those wanting a job coding (that are available for those with the right skills) but also for those making decisions about what the organization should do.

The profound ignorance (meant not in a pejorative way but in the descriptive way) of software is a significant problem for managers today. The critical role of software in our organizations is only growing. And the importance of understanding software (which coding provides in a way no other learning does) is only increasing. My guess is a decade or two or three from now a understanding of coding will not be nearly as critical for managers. I am just guessing the nature of coding will be significantly changed and not understanding the details needed to code will not be as critical as it is today. Maybe I am wrong about the importance of understanding coding fading over time (it is more a feeling than a chain of logic I can clearly explain easily).

There are many indirect benefits of learning to code. In the same way that those with an education in engineering do very well in their careers overall, even if they take a path where they are no longer engineers a background in coding prepares you well for your career. Actually, similar to engineering, part of this effect may well be those that can graduate with an engineering degree and those that can be employed for several years as a software developer have skills and abilities that would have made them successful even if they didn’t pass through those experiences (still I think, those experiences to add to their success).

Good programmers have a strong tendency to think in ways that those interested in management improvement need (and, sadly, often lack): systems thinking, customer focus, efficiency focused [good coders often hate wasting their time and naturally despise non-value added steps], a willingness to speak up about things that need to be improved, a desire to make a difference, passion for what they do… If you work along side good programmers these traits will be reinforced every day (this was my favorite part of my last job – working with great programmers that pursued these principles and re-enforced my doing so also). Yes there are also things you might have to temper in dealings with non-coders (being a bit kinder/less-direct about perceived failures, for example). Also some coders can be so engaged they expect an unsustainable commitment from peers (this is one of the great benefits of a good agile software development system – a focus on creating an environment for sustainable development [not expecting unreasonable effort/hours on the part of coders]).

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

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

Rethinking or Moving Beyond Deming Often Just Means Applying More of What Dr. Deming Actually Said

Don Reinertsen – Is It Time to Rethink Deming? from AGILEMinds on Vimeo.

I feel very strongly about the value of Deming’s ideas. I am glad people challenge those ideas and try to push forward management thinking. Helping us manage organizations better (to get better results and allow people to better enjoy their jobs and lives) is why I value Deming’s ideas. To the extent we find better ideas I am very happy. I understand I will disagree with others on the best ways to manage, and believe healthy debate can be productive.

What Don Reinertsen discusses in the video, about special and common cause is not the best way to look at those ideas, in my opinion (though I would imagine it is the most common view). For data points that are common cause (within the control limits and not a special cause pattern) it is most effective to use common cause tools/thinking to improve. For indications of special cause (points outside the control limits or patterns in the data, such as continually increasing results that indicate a special cause) it is most effective to use special cause tools to improve.

This does not mean that a point outside the control limits is caused by a special cause (also know as assignable cause). It is just best to use special cause tools and thinking to address those data points (and the reason this is true is because it is most likely there is an assignable cause). The control limits do not define the nature of the point, they define the type of improvement strategy that should be used.

Don also says repeatedly that you don’t “respond to random variation” in Deming’s view. That is accurate. But then he implies this means you don’t address system performance, which is not. You work on improving systems (that are in control) by improving the system, not by responding to individual common cause data points (random variation) as if it were assignable cause variation.

The purpose of the control chart (that Shewhart developed) was to help you most effectively take action (knowing if special cause thinking, or system improvement, was the best improvement strategy). The control chart shows if the results are in control and tells you that the system is preforming consistently (and identifies a special cause so special cause tools can be used immediately, this is important because special cause improvement strategies are time sensitive). It tells you nothing about if the results are acceptable.

Continual improvement was also central to Deming’s management philosophy (based on the business value of the many improvement options available in every organization). For Deming this meant working on improving the system, if the results are in control, instead of trying to deal with finding a specific assignable cause for one data point and acting on that. If the issue is one of the system performance (no indication it is a special cause) the most effective strategy to get better results is to improve the system, rather than approach it as a special cause issue (examining individual data points, to find special items in that event to be improved). You can use special cause thinking, even where system improvement thinking would be better. It will work. It is just not very effective (improvement will be much slower) compared to focusing on system improvement.

I agree with Don that the United States mentality, not only in nuclear plants but everywhere, is to apply special cause thinking as the strategy for process improvement. This is one the areas Deming was trying to change. Deming, and I, think that setting your improvement strategy based on a common cause (system improvement) or assignable/special cause (learn what is special about that one instance) is the most effective way to achieve the best results. We believe in continual improvement. We believe that the effective way to improve, when a system is in statistical control, is by focusing on the whole systems (all the data) not assignable cause (special cause) thinking where you look at what is special about that bad (or good) individual result.

The economic consideration of whether the costs of improvements are worth the benefit is sensible (and I do not see Dr. Deming arguing against that). That is separate from the best method to improve. For Deming the best method to improve means using special cause thinking for assignable cause issues and common cause thinking for systems issues.

The idea of where to focus improvement efforts is not something Dr. Deming made as clear as he could have, in my opinion. So I see the argument of Deming not prioritizing where improvement should occur voiced occasionally. This is a weakness in Deming’s content, I believe, more than his philosophy (but I can understand it causing some confusion).
Continue reading

You’ve Got to Find What You Love

Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.

- Steve Jobs

Watch this great commencement speech by Steve Jobs at Stanford in 2005.

We lost a great person today, when Steve Jobs died at the age of 56. His words are just as important today: you have got to find what you love to do. Keep looking until you find it. It won’t necessarily be easy to do. But life is too short to waste merely getting by.

My father found what he loved and pursued that throughout his life. He also died young. They both died young, but they both had great lives because they took charge to make the most of their lives. By doing what they loved they made the world a better place for many others, and themselves. Take that message to heart and make your life the best it can be.

Related: Quotes from Steve JobsPeter ScholtesPositivity and Joy in WorkBuild an Environment Where Intrinsic Motivation FlourishesRemembering Bill Hunter

Steve Jobs Discussing Customer Focus at NeXT

Video from 1991 when Steve Jobs was at NeXT. Even with the customer focus however, NeXT failed. But this does show the difficulty in how to truly apply customer focus. You have to be creative. You have examine data. You have to really understand how your customers use your products or services (go to the gemba). You have to speculate about the future. The video is also great evidence of providing insight to all employees of the current thinking of executives.

Related: Sometimes Micro-managing Works (Jobs)Delighting CustomersWhat Job Does Your Product Do?

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

Finding, and Keeping, Good IT People

Finding good IT people, wherever you located globally, is hard. Waiting for the good IT people to apply for positions, is not likely to gain enough good candidates.

To get really good IT people you need to actually manage your current IT staff properly. Then word will get out that your organization is not run by pointy haired bosses (phb) and good IT people will be open to joining. This obviously is not a quick fix. But this practice is the key. This is just respect for people with a eye on the special needs of creative IT people.

If you do this you will also reduce turnover. That doesn’t help in recruiting people, but it solves the underlying problem recruiting is meant to deal with – having staff to do the work. Making your environment tech employee friendly has the benefits mentioned above and will reduce turnover.

Like many issues when examined systemically the most important factors to deal with the recruiting problem are often not directly looking at the problem at hand. Now there are sensible actions to improve the recruiting process. Take a fundamental look at the hiring process and think about some real changes – how about trying people out first, not determining staffing primarily on judgments based on how well then interview. Don’t have silly prerequisites. Why do you need a college degree for an IT job? Or why require specific degrees, like a computer science degree, and exclude others, for example, an online IT degree. Might specific college experience be helpful? Yes. Might someone without it be a great employee? Yes.
Continue reading

Management Improvement Carnival #127

photo of Cliff Palace at Mesa Verde

Photo of Cliff Palace at Mesa Verde by John Hunter.

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, agile software development, systems thinking, lean manufacturing, customer focus…).

  • Jim Womack, lean blog podcast #116 – Great, as you would expect. Includes a great explanation of the problems that have made adopting lean ideas in medicine, which somewhat counter-intuitively includes the reluctance to use the scientific method/pdsa to examine results.
  • What Larry Page really needs to do to return Google to its startup roots – “If your company has to have ‘No meetings Thursday’ then you’re doing it wrong. How about ‘No meetings except for Thursday’… Having to launch a simple service in multiple datacenters around the world, and having to deal with near-weekly datacenter maintenance shutdowns is unacceptable for an agile startup. Startups need to focus on product, not process and infrastructure.”
  • Don’t forget what it’s like to be 10 by Richard G Russell – Your job isn’t telling them what to do. 80% of your job is understanding what your team does, and what they need to accomplish their job; then helping them do it.
  • Relationship between Process and Innovation by Jeffrey Phillips – “Let’s distinguish between effective processes that accelerate innovation and those failed processes that either weren’t meant to accelerate innovation or weren’t the right processes for innovative ideas to begin with.” [Curious cat 2007 post: Process Improvement and Innovation
  • Surfacing Problems Daily by Jamie Flinchbaugh – “When it comes to building a problem-solving culture, one of the most important traits is being able to surface problems quickly and face them honestly.”
  • How to start a movement in your company – by David Choe – “So, here I am to tell the tale and advocate for good leadership, clear vision, constancy of purpose, and true empowerment.”
  • 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

  • Recent Trackbacks

  • Comments