Category Archives: Software Development

Add Constraints to Processes Carefully

Take great care in adding constraints to processes to avoid doing so needlessly.

Online you will frequently find forms that have required fields that needn’t be. Certainly if you were designing with focus on what is best for customers those requirements rarely make sense. Occasionally a required field is a sensible constraint on an online form but so often they add unnecessary constraints.

I frequently find those forms even requiring a false answer since a response is required and none of the options are true. Often this is because the organization is thinking of the boxes they expect users to fit themselves into rather than thinking how to create the best user experience.

I wrote previously about a company representative that suggested a customer change their name because the computer system didn’t accept names with 2 characters. Constraints on creating a secure password are a frequent failure of web sites for the last 10 years.

Man without arms denied housing loan due to inability to provide fingerprints

because Wu Jianping has no arms, creditors claimed they could not give him a loan since he was unable to be fingerprinted.

After the case was publicized and there was a great deal of negative publicity on social media the banks modified their process and approved the loan. But your organization shouldn’t have as the mistake-proofing (obviously not mistake-proofing at all) that when the process doesn’t quite work well then rely on a massive social media outcry which is a signal to us to straighten out the issue.

Frequently I see unnecessary constraints creating the edge case excuse. By burdening your process with unnecessary constraints your create edge cases that fail and then use the excuse that each of the edge cases is rare and therefore you can’t justify the expense of fixing them.

But if you designed the process sensibly in the first place the edge case never would have failed and you wouldn’t need special work arounds for such “edge cases.” A simple example of this is unnecessarily complex web page code that fails if to submit a button without javascript. Yes, a small number of users won’t have enabled all javascript to run (today anyway) so it is an “edge case” to deal with if you don’t have the form work without javascript. But there is no decent reason to have it fail in most cases.

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

Software Testing and the Impact on Quality

My response to a question on Reddit.

“Software quality does not come from testing”
Does anybody have any thoughts on the validity of the above statement?

That statement is similar to the idea you can’t inspect in quality. Basically “Inspection is too late. The quality, good or bad, is already in the product.” W. Edwards Deming

I agree with those ideas. Software testing is a bit different (at least some of it is) from the inspection mentioned above. You are testing while the product is being developed and adjustments are being made before the product is released to customers. Also with internet based software you have the ability to update the software and now all users have that update. Where for physical devices they already have the product and the only option is a recall which is very expensive and often ignored.

Software testing however should pay attention to those points in the 2 links above (defects should be understood as evidence of a process that needs to be improved so defects are not built in the first place). What you want is not just to fix the bugs software testers catch but figure out the reasons those bugs were created and improve you process so you create fewer bugs in the future.

No matter what the software quality is based on the code that is written. At the best software testing can tell people about the bugs but unless the code is fixed the software quality didn’t change. But to say that software testing doesn’t have a big influence of software quality when testing is well done and the software development process is good (listens to feedback and improves) is not very accurate.

Related: Improving Software Development with Automated TestsCombinatorial Testing for SoftwareBuilding a Great Software Development TeamDeming and Software DevelopmentThe Defect Black Market

Functional Websites are Normally Far Superior to Apps

An email to I just sent to Uber

I understand the regular Uber app not having a functional website.

Uber Eats not having a functional website is super lame. It strikes me similar to Walmart 15 years ago telling people “we only have stores go to them, we just use the internet for advertising our stores.” Today for Uber: we only have apps, “we only use the web for advertising our apps.” Both you and Walmart want to use a limited function service that you both are comfortable with and want users to just put up with annoyance because neither of you want users using the connivence of the web.

When you bother to create a functional website maybe I’ll use it (I use several food delivery services now).

Using limited apps is rarely wise (unless you are crippled by the lack of a real computer and are stuck having to use just an app). Uber cars is a rare exception where the needs are so simple a limited app is ok. Picking restaurants and food on a tiny screen with a crippled app is just a lousy experience for anyone that uses real websites. The Ux for the app is horrible.

Just like old school businesses were only comfortable with their old business models and didn’t create functional websites (instead using the web just to advertise that you should go to their store, or giving you forms to complete and fax back to them…) new businesses are often stuck on only using apps even though they often provide a lousy user experience compared to a functional website.

There are some apps that are very useful and not having a functional web app can make sense, but it is fairly limited. Getting a ride apps I can see as only apps. Driving instructions and live maps using GPS to locate you is another great app use. Boarding passes can make sense (though I do question some of that whole process conceptually this could be a good example of a app with no functional website).

But most cases not having a functional website is just lousy Ux.

Now there are some times when using technology to provide good service just isn’t worth the effort. Often though businesses just are stuck in their fax-thinking or physical-store-thinking or app-thinking and fail to use a technology that would provide great benefit to their users. I find it odd how often app vendors seem stuck in their app mindset. It wasn’t so surprising old businesses that were not based on technology didn’t take advantage of the incredible opportunities provided by the internet and the web. But it is less understandable when companies that are thought of as technology savvy are as blinded by their history (can’t see out of the app-mindset).

Continue reading

Use Urls – Don’t Use Click x, Then Click y, Then Click z Instructions

In the 1980s software applications had to use click x, then click y, then click z type instructions to get you to a specific location in a software application (or at least they had a decent excuse to do that). Too many web application development organizations forget that they now have urls to direct people exactly where to go: and that they shouldn’t rely on ancient “click here, then there, then in that other place” type instructions.

Here is an example I wrote up on my recent experience with iTunes and their failure to do this properly: Bad iTunes Ux and How to Submit a Podcast to iTunes. I see it all the time, that is just one example.

It is so sad that Google can’t even offer mildly decent help for their own software nearly a couple decades after they started out with the goal to organize the world’s information. And lots of other software companies also point you to clicking around various gui (graphical user interface) click paths instead of just

  1. showing the url (say in a help email) – instead of the gui click path text
  2. a clickable link to the url in web documents

On top of the waste inherent in click path instructions they often fail because the interface has changed and no one bothered to change the click path or the click path depends on other things being a certain way and they are not so the click path breaks.

I really can’t comprehend how this usability failure is something I run across all the time. Urls are not some secret idea only PhD computer scientists have heard of. This is super basic stuff – click path instructions should never have been acceptable for any web application. It is pitiful they are still common among companies that see themselves as advanced software development organizations.

Using the proper urls also will help make sure you are using human readable urls. Another super basic usability concept that is ignored far too often by some web application developers.

Related: Usability, Customer Focus and Internet Travel SearchMaking Life Difficult for CustomersPracticing Mistake-Promoting Instead of Mistake-Proofing at ApplePassword Gobbledygook Instruction (more bad usability)What I Would Include in a Redesigned Twitter Profile (2014)

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

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

Double Loop Learning Presentation by Benjamin Mitchell

Benjamin Mitchell – Using the Mutual Learning Model to achieve Double Loop Learning from Agileminds.

Benjamin Mitchell presents ideas using Chris Argyris thinking on double-loop learning. “Double-loop learning occurs when error is detected and corrected in ways that involve the modification of an organization’s underlying norms, policies and objectives.”

Single loop learning is basically to just try again using the same understanding, thinking and tactics. It is understood that the results were not what was desired so we will try again, but the supporting system is not seen as the reason results were not the desired results. Double loop learning is when the result leads to questioning the system and attempting to adjust the system and make changes and experiment to learn to be able to create systems that get better results.

Argyris: people will blame others and the system when their actions seem to differ from their espoused proper actions. (I see this as similar to the idea of revealed preference versus stated preference: revealed actions versus stated actions – John)

Related: People are Often IrrationalDouble Loop Learning in Organizations
by Chris Argyris
Theory of knowledgeRethinking or Moving Beyond Deming Often Just Means Applying More of What Dr. Deming Actually Said

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

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

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

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

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

Is Google Failing Too Often?

I think Google is extremely successful, but they do seem to consistently have problems adding to their portfolio. They did a great job with gmail. Android has been very successful. Google Maps is great. They did well building YouTube. Chrome is very nice. Automatic translation is very nice (as is the integration with Chrome).

But so many things just don’t go anywhere. I can’t understand why they can’t take something like Google checkout and make it much more successful (there is money even Google cares about waiting for success in this area). Grand Central was great – Google Voice has not built that the way I would hope. Google has an endless stream of very small companies they buy and then the service dies.

It has been long enough now that I am starting to feel more comfortable saying Google is not doing a good job of creating and building new products. There are a few successes. And having failures isn’t a huge deal – taking risks is wise. But they just seem to be succeeding far to little, especially when you look at the talent and resources they have. Of course, some will say the resources they have is a problem. I really think it is more along the lines I see you mentioning above – they have become too rigid in development. I actually support more standardization than maybe people want (there can be big benefits) but I believe you need to then allow for exceptions. It seems to me Google doesn’t allow enough. It is tempting for managers to want to duplicate the same style that has made adwords and search successful. That might not be the answer for every project though.

They also seem to be driving away to many people with a rigid adherence to proving every little thing. Now I think some of this is a significant part of Google’s success. The trick is not to throw out all such efforts, but to find ways to gain the benefits without crushing innovative people’s will to continue.

I continue to own stock in Google and believe the future is very promising. Google does far more right than they do wrong, but they have room to improve.

Related: Why Google can’t build InstagramObservations of a New GooglerGreat Marissa Mayer Webcast on Google InnovationGoogle: Ten Golden RulesEric Schmidt on Management at Google
Continue reading

Annual Management Blog Review: Software, Manufacturing and Leadership

In my contribution to the 3rd annual management blog roundup I will take a look at 3 blogs: Dennis Stevens, How to implement “Lean Thinking” in a Business and the Three Star Leadership Blog. This year 14 management bloggers contributed to highlight over 40 blogs, be sure to check out all the posts.

photo of Dennis Stevens

Dennis Stevens


Dennis Stevens writes a blog of the same name focused on agile software development principles with a strong focus on Dr. Deming’s ideas and lean thinking.

  • What’s Deming got to do with Agile – “Deming is not about manufacturing. He is about showing management how to create an environment for success. Deming is about culture – and his System of Profound Knowledge creates an environment that is especially effective for knowledge work… In knowledge work, where products are invisible, impact can be difficult to demonstrate. Kanban clearly shows progress and demonstrates the contribution of each person to the delivery of value. Additionally, PDSA provides opportunities for everyone to contribute to improving the quality of the organization’s capabilities.”
  • Kanban Mental Models and Double Loop Learning – “the Kanban cycle supports continuous learning that the team internalizes. Argyris’s model gives us some insight into why Kanban teams are consistently achieving double-loop learning and rapid maturity.”
  • We are Doing QQ All Wrong– “Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests… Test driven development or test just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation.”
  • Shorten and Reduce Variability in Lead Times Using Kanban – ” identify and leverage strategies like reducing waiting, reducing rework, making work ready, defining small size work, and swarming, to improve lead time. Tracking causes of defects and blockages can help make decisions to focus these strategies appropriately. Reducing lead time duration and variability will result in increased predictability, faster feedback, improved flexibility and responsiveness.”
photo of Tracey Richardson

Tracey Richardson

Tracey Richardson writes the How to implement “Lean Thinking” in a Business blog focused on the lean manufacturing and the Toyota Production System.

  • Common Mistakes when we are Problem Solving – “Not utilizing the ‘Power of the gemba’,–or often referred to as “Go see the work/process“.!! I often see teams working together in a room trying to solve the problem by using their experiences, hypothetical guesses, and what their opinion is. I quickly disperse the huddle to “go-see” with their own eyes the current situation.”
  • How many different types of A3’s are there? – “I will briefly describe the 4 different types of A3’s and when to use them based on my experience: Problem Solving A3, Proposal A3, Status Report A3, Strategic Planning A3. All A3’s should follow the PDCA thinking regardless of which type you are working on.”
  • Why is asking “Why” so important? – “It is important to ask why repeatedly when visiting the gemba to determine what is current happening versus what should be happening. In many cases we stop at a symptom to the problem because we are often pressured for results and quickly solving the problem without going past the symptom seems to be the best answer.” [this one is actually from 2009 but I included it anyway – John]

The Achilles’ Heel of Agile

Guest post by Jurgen Appelo

When I wrote this, I was working in a big open office space in the Van Nelle Factory in Rotterdam (see photo). About 100 people work in an office that was the first of its kind in Europe, when it was built in 1929. And more than 80 years later, architecture lovers from all over the world still come to admire it, take pictures, and make drawings. I sometimes waved at them.

photo of open office style at Van Nelle Office
Van Nelle office, reprinted by permission of Stephan Meijer

A big open office space has advantages and disadvantages. Advantages are flexibility and easy communication. The main disadvantage is that it is a shared resource for all who work there. Climate, sound, and light are hard to manage in a space like that, and the optimal configuration for the whole is never optimal for all. But our office manager did the best she could in trying to maximize pleasant working conditions, while maintaining tight rules to keep things under control. A shared open office is not the ideal environment to give people full responsibility over their own working space.

Self-organization is usually promoted in agile software development. But when shared resources are not managed by a central authority, self-organization often results in the Tragedy of the Commons. The name refers to a situation in which multiple self-organizing systems, all acting in their own self-interest, overexploit a shared limited resource, even when they all know it is not in anyone’s interest for this to happen. The impact that humanity has on CO2 levels in the air, trees in the forests, and fish in the sea, is right now the most debated and intensively researched case of the Tragedy of the Commons. Organizations also have shared resources, like budgets, office space, and system administrators. We could see them as the business-equivalent of the air we breathe, the landscape we change, and the fish we eat.

Research indicates that four ingredients (called the four I’s) are needed for sustainability of shared resources [Van Vugt 2009:42]:

  • Institutions [managers] who work on building trusting relationships between competing systems [teams] in order to increase acceptance of common rules;
  • Information that increases understanding of the physical and social environment, in order to reduce uncertainty (because uncertainty results in bias towards self-interest);
  • Identity, or a need for a social “belonging” that encompasses all participants, to improve and broaden one’s sense of community and reduce competition between teams;
  • Incentives that address the need to improve oneself, while punishing overuse and rewarding responsible use.

Research shows that it is imperative that there is some form of management (or governance) to protect these shared resources by working on these four I’s. (I realize that most modern day governments are not setting a good example of how to do that.) In the case of shared resources, whether it concerns money, space, or system administrators, someone outside of the development teams must keep an eye on long-term sustainability instead of short-term gains by individual teams.

The Tragedy of the Commons is the Achilles’ heel of Agile. It takes management to protect that heel, in order to prevent teams from depleting resources, and crippling the organization.

This article is an adaptation from Management 3.0: Leading Agile Developers, Developing Agile Leaders, by Jurgen Appelo. The book will be published by Addison-Wesley, in Mike Cohn’s Signature Series.

Related: Embrace Diversity, Erase Uniformitymanagement 3.0agile software development booksVW Phaeton assembly plant

Jason Fried: Why work doesn’t happen at work

In this TED talk, Jason Fried, founder of 37 signals, discusses how people get work done. When asked where do you go when you really need to get something done, almost no-one says: the office (unless it is early in the morning or late at night)? This is especially for creative people and knowledge workers. They need long stretches of uninterrupted time to concentrate. “The real problems in the office are the managers and the meetings.”

The main theme is that interruptions can severely damage performance, especially for what Peter Drucker called knowledge workers.

He offers 3 suggestions to make the office a place people can get work done. No talk Thursdays. And if that is too much how starting with 1/2 a day Thursday once a month. Second, replace active distraction (meeting, going and talking to a person) with passive distraction (email and IM) that a person can turn off when they need to focus. I have found this very useful myself. And third, cancel meetings. He closes with: I hope I have given managers reasons “to think about about laying off a little bit and giving people some time to get work done.”

Related: Understanding How to Manage GeeksBetter MeetingsWorkers Allowed Recreational Use of the Internet are More ProductiveManagement By IT Crowd Bosses