Category Archives: IT

Robots for Health Care from Toyota

Japan has an extremely rapidly aging population. This increases the need for health care and for assistance with everyday tasks from the elderly. Japan is also among the leading countries for developing robots for health care and living assistance.

I have written about the efforts to have robots fill some needs in Japan previously, on this management blog and also my partner Curious Cat Engineering blog: Toyota Develops Thought-controlled Wheelchair (2012), Toyota’s Partner Robot (2007), Toyota Human Support Robot (2012) and Pepper, A Social Robot from Softbank (2017).

Most often innovation efforts take the form of understanding the jobs your customers are using your products and service for now and developing new solutions to delight those customers. This is difficult for companies to pull of successfully.

Occasionally innovation involves meeting completely new needs of customers. For example Toyota started as a loom company and is now known as a car company. Making such a radical change is not often successful.

Will Toyota be able to add robots to the products it produces successfully? I am believe they have a chance. But it won’t be easy. Obviously (as shown in posts on my blog for the last ten years) I respect Toyota’s management system. That gives them a chance to be successful. The product development system is going to be critical (ideas found in: Toyota Engineering Development Process and How to Develop Products like Toyota).

Toyota Sends Robots To The Hospital

Toyota demoed its Welwalk WW-1000 robot, a machine that can rehabilitate stroke victims some 60% faster than regular physiotherapy. The company also showed glimpses of other robotic technologies, for instance a Human Support Robot that picks up stuff, draws curtains, and performs other menial tasks a bedridden patient would normally need to call a nurse for.

Toshiyuki Isobe, chief of Toyota’s robotics lab, said that the company is not fixated on being a car company. “Toyota started as a maker of looms, and only got in to cars later,” Isobe said. “Our mission always was to make practical things that serve a purpose. If there is a need for mass produced robots, we’ll make them.”

image of the Toyota support system for rehabilitation of walking in stroke victims

image of the Toyota Welwalk system

Related: Innovation at ToyotaMore on Non-Auto ToyotaDelighting CustomersToyota Engineers a New Plant: the Living Kind (to fight pollution)

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 you 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

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

Good Startup Ideas from Startup Weekend JB (Malaysia)

I like all these startup ideas from Startup Weekend JB (Malaysia). I can’t figure out how to comment on their blog (I am guessing Tumbler just eliminates commenting?), so I started this post – and ended up adding much more than I planned on putting in a comment.

All of these ideas are not very technically challenging and pretty much versions of these businesses are already successful around the globe. But creating great user experiences (in apps or on web sites) is often neglected for doing something passable (and local conditions mean the business is a bit different here than it would be somewhere else).

To create a greatly successful startup focusing on great, not adequate, customer experiences is extremely useful. And you can leap ahead of competitors that don’t focus on customer delight.

One of the interesting things from my experience living in Johor Bahru, Malaysia the last few years is that Malaysia has way more entrepreneurial diversity than the USA (in my limited experience). Many of these businesses stay small. But you have entrepreneurs in all sorts of businesses at events in JB. In the USA the events I went to were all software focused (internet businesses etc.).

Here you have people setting up factories, printing companies, beauty entrepreneurs, construction companies, bakers, motel chain (less than a handful of motels so far) etc. going to HackerSpace meetings and Drinks Entrepreneurs, BarCamp etc.. Startup Weekend I do think was very IT focused, even in JB (it is setup to be that way so it isn’t surprising).

There are small business entrepreneurs in the USA, but they don’t go to entrepreneur/ LeanStartup etc. type meetings (in my experience). And they are more limited; so many businesses in the USA really can’t be done easily by some new college graduate. The capital and legal requirements are just so huge you need so much to start that it isn’t something considered in the cool-startup communities (in general – I’m sure there are some things like micro-brew startups etc.). In JB it seems to me fewer than 33% are IT dominated. Though I expect this will increase rapidly. I think there is a real benefit to including non-IT focused people in these communities.

The number of people outside of IT that decide to be entrepreneurs out of school is tiny (it seems to me). In Malaysia it seems much more common. But in general people don’t talk about it as being entrepreneurs they are trying to make a living and setting up their own business to do so is just a natural thing to do.

SmartDining – find local restaurants (mobile app) and order (for take out or dine in).

The app shouldn’t be too hard to do well. The challenges will be working with restaurants, marketing (so often the case) and maybe mapping (finding good suggestion). How to balance efforts well will also be a challenge – you could spend tons of time on many different valuable efforts related to this business. Vote.

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

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

Process Thinking: Process Email Addresses

This is just a simple tip. When providing email address think about what the purpose is. If it is to contact a specific person then an individual’s email address makes sense. But if you are really emailing the software testing manager then it may well make sense to provide people the email address software_testing_manager@

Essentially, I think it is often sensible to break out email addresses for specific functions or processes. Then the email address can just be routed to whoever is suppose to handle those emails. And as your responsibilities shift a bit, those you no longer do can be shifted to someone else and you start getting your new emails. Another nice (I think so anyway) side affect is your various roles are made more concrete. Often it seems who really is responsible is unclear, if you have 5 email address that Jane handled before she left it will be obvious if only 4 of them have been reassigned that 1 has not. Granted such a thing should be obvious without this email tip-off but given how many organizations really operate failing to assign all of someone’s responsibilities to someone when they leave is more common than you would hope.

It is also nice because, if their is a reason it is helpful, those emails can automatically go to as many people as desired. Also if the manager goes on vacation for 2 weeks, the emails can be sent also to the person filling in for them until they return.

Another benefit is a manager, or whoever, can take a quick dip into the email traffic to get a sense of what is being requested. Another benefit (depending on the way it is implemented) can be to have all the software_testing_manager@ emails and responses associated with that email so if you are given that responsibility you can view historical response.

If our knowledge management (wikis, or whatever) solutions were great this would be less important (though still probably valuable) but often the email history may have the best record of our organization knowledge on a topic. When it is spread about in a bunch of individuals mail boxes it is often essentially lost.

It is a small think but this bit of process thinking I have found helpful.

Related: Management By IT Crowd BossesSoftware Supporting Processes Not the Other Way AroundEncourage Improvement Action by EveryoneDelighting Customers

Simple Customer Care: Communicate

Some management issues are hard. You are often balancing priorities. Sometimes though it is extremely simple: either you have concern for customers and take actions to back that up or you have some concern but don’t do anything about it.

Here are some examples that show you really just don’t care.

If you have invested millions in setting up computer systems to authorize, and reject, payments for say a credit card and you fail to notify customers when you reject a charge you just really don’t care. There might have been an excuse 10 years ago that it was too difficult to notify people. Today if your IT people can’t do that, hire a new CIO and have them create an IT support system that isn’t an embarrassment to any institution relying on it.

Another sign of an extremely weak IT and customer focus presence in an organization would be deleting records of your customers after 6 month or 1 year or ever. Again this is common among the too-big-to-fail financial institutions that seem much more able to design system to extract fees and justify ludicrous bonuses to executives than to provide the most basic services for customers.

Amazon, and most any non financial-too-big-too-fail institution, keeps your records available for you. The too-big-too-fail crowd though won’t keep records as well as the site you buy books from. They slap fees on customers if they want to get the paper statements they used to get for free. That is fine with me (the fees are far too high, but the concept is fine with me). The too-big-too-fail crowd wants to save money by not mailing you paper. Fine.

Then, deciding to delete your records after 6 months, or a year… is just a sign you have no interest in serving customers. Other than an organization that has no interest in customer service, suggesting such a thing would be a direct ticket to remedial training on providing value to customers.

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

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

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

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?

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

Innovation in Thinking and the Web

Investing time and effort to attract “the right kind” of contributors to a news site

He thought we needed to make the same shift with our users – instead of seeing having to engage with them digitally as a time-consuming and resource eating problem, we should be seeing our audience as an asset to the brand. Any online organisation that doesn’t include readers in the production chain is inherently inefficient.

I agree. And I think this is a good example of an organization needing to adapt to the changing environment. I thought about what I would do if I ran a news site and how I would try to take advantage of the possibilities to increase engagement using internet technology.

I do think if I was trying to increase engagement I would try to figure out how to highlight thoughtful commenters. I would probably try to look into something like the commenting system on Reddit (with Karma) and also the ability to follow commenters (like you can follow article contributers on Seeking Alpha). I would look at giving value back to good comments (maybe something like commentluv). I would definitely have a pages where you could view more comments by a commenter. I would try to set up categories and then list top commenters on local politics, local sports, health care… I would display in the order of popular comments (like Reddit) not just list in order made. There are lots of ideas I don’t see used (but I haven’t really thought about it until 5 minutes ago – maybe these are already widespread, or maybe I haven’t really though out why they wouldn’t work well).

I just remember a post here previously about a newspaper in Kansas that was taking some sensible actions, and seemed to get the value chain they were serving. I would also take a look at them if I were really going to do this for a news organization.

This blog has a failure miserable, engagement with readers. Hopefully I can work on improving that in the next year. My last post, Customer Focus and Internet Travel Search (is the effort of one of the 4 founders of Reddit).

Related: Joel Spolsky Webcast on Creating Social Web ResourcesJohn Hunter online (Reddit comments…)Delighting CustomersPrice Discrimination in the Internet Age

Customer Focus and Internet Travel Search

The internet should make finding airline flight information easy. Instead it is a huge pain. Hipmunk has taken on the challenge of doing this well, and I think they have done a great job. This video provides an excellent view of both web usability and customer focus. This is a great example of focusing on providing customer value and using technology to make things easy – which is done far to little at most companies.

Related: Innovation Example (Farecast – which seems to have been bought by Microsoft and broken)Making Life Difficult for CustomersConfusing Customer FocusJoel Spolsky Webcast on Creating Social Web ResourcesCEO Flight Attendant

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

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

Annual Performance Reviews Are Obsolete

Sam Goodner, the CEO of Catapult Systems, wrote about his decision to eliminate the annual performance appraisal.

the most critical flaw of our old process was that the feedback itself was too infrequent and too far removed from the actual behavior to have any measurable impact on employee performance.

I decided to completely eliminate of our annual performance review process and replace it with a real-time performance feedback dashboard.”

I think this is a good move in the right direction. I personally think it is a mistake to make the measures focused on the person. There should be performance dashboards (with in-process and outcome measures) that provide insight into the state of the processes in the company. Let those working in those processes see, in real time, the situation, weaknesses, strengths… and take action as appropriate (short term quick fixes, longer term focus on areas for significant improvement…). It could be the company is doing this, the quick blog post is hardly a comprehensive look at their strategies. It does provide some interesting ideas.

I also worry about making too much of the feedback without an understanding of variation (and the “performance” results attributed to people due merely to variation) and systems thinking. I applaud the leadership to make a change and the creative attempt, I just also worry a bit about how this would work in many organizations. But that is not really what matters. What matters is how it works for their organization, and I certainly believe this could work well in the right organization.

Related: Righter Performance AppraisalWhen Performance-related Pay BackfiresThe Defect Black Marketarticles, books, posts on performance appraisal