Currently browsing the IT Category

Recommended posts: Toyota IT Overview - Innovation Example - Using Technology to Promote Management Improvement - Usability Failures - Dell, Reddit and Customer Focus - Experiment Quickly and Often
Other Categories: Google - Software Development


Agile Story Point Estimation

Posted on February 8, 2012  Comments (0)

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 Fixes – Mistake Proofing the Deployment of Software Code – Checklists 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

Posted on February 2, 2012  Comments (0)

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 timeline – John Hunter online – John Hunter LinkedIn profile – Top Leadership blogs – Top Management and Leadership blogs – Top Management blog

Steve Jobs Discussing Customer Focus at NeXT

Posted on September 8, 2011  Comments (0)

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 Customers – What Job Does Your Product Do?

Finding, and Keeping, Good IT People

Posted on April 6, 2011  Comments (3)

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

Posted on March 29, 2011  Comments (0)

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 Resources – John Hunter online (Reddit comments…) – Delighting Customers – Price Discrimination in the Internet Age

Customer Focus and Internet Travel Search

Posted on March 24, 2011  Comments (1)

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 Customers – Confusing Customer Focus – Joel Spolsky Webcast on Creating Social Web Resources – CEO Flight Attendant

Assigning Story Points to Bug Fixes

Posted on January 27, 2011  Comments (1)

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 Management – Mistake Proofing Deployment of Software Applications – Checklists in Software Development

The Achilles’ Heel of Agile

Posted on December 14, 2010  Comments (3)

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 Uniformity – management 3.0 – agile software development books – VW Phaeton assembly plant

Annual Performance Reviews Are Obsolete

Posted on November 15, 2010  Comments (0)

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 Appraisal – When Performance-related Pay Backfires – The Defect Black Market – articles, books, posts on performance appraisal

Involve IT Staff in Business Process Improvement

Posted on July 6, 2010  Comments (5)

I started out basically working on management improvement from the start of my career. My makeup (I am never satisfied and figure things should always be better) along with a few traits, experiences and probably even genes made this a natural fit for me. I tend to take the long view and find fire fighting a waste of time. Why fix some symptom, I want to fix the system so that problem doesn’t happen again. My father worked in statistics, engineering and business improvement and as I was growing up I had plenty of experience with process improvement, understanding variation, experimenting, measuring results…

I came into the IT world as I had needs and found the best solution was to write some software to help me accomplish what I wanted to. One thing that better software tools allowed is this type of thing when organizations failed to use technology well, individuals could just do so themselves. Without these tools people had to rely on the organization, but today atrophied IT organizations can often be circumvented. Though the IT organizations often try to avoid this largely by bans (instead of by providing the tools people need), which is not a good sign, in my opinion.

I then spent more and more of my time working with technology but I always retained my focus on improving the management of the organization, with technology playing a supporting role in that effort. That is true even as where I sat changed. And I have become more convinced organizations would be served well by using the information technology staff as business process experts.

At one point I sat in the Office of Secretary of Defense, Quality Management Office where I was able to focus on management improvement and using technology to aid that effort. Then I went to the White House Military Office, Customer Support and Organizational Development office and focused largely on how to using technology to meet the mission. Then I was moved into the White House Military Office, Office of Information Technology Management.

And now I work for the American Society for Engineering Education in the Information Technology department. My role started as partially program management and partially software development and as we have grown and hired more software developers I am now nearly completely a program manager.

I believe technology is a central component of understanding business processes today. But the truth is, many business people don’t have as complete an understanding as I feel they should. Now I believe, most anyone interested in planning their management career needs to develop a facility with technology and specifically how to use software applications to improve performance. You don’t need to be an expert programmer but you need to understand the strengths, weakness, limits of technical solutions. You need to understand how technology can be used (and the risks of options).

At the same time I just don’t think it is likely management everywhere will get a decent understanding of application software development. I also believe that in many cases organizations should do software development in house. This is a issue that certainly can be argued (but I won’t do it here). Basically I don’t think organizations should cram their processes into designs required by off the shelf software. Instead I believe they should design processes optimal for their organization and using off the shelf software often does the opposite (forces the process decisions around what software someone decided to buy). There is plenty of use for off the shelf software that doesn’t force you to make your processes fit into them (and sometimes even if it does that is the business decision that has to be made – I just think far too often organizations look at short term costs and not the overall best solutions for the system).
Continue reading →

Net Neutrality, Policy, Economics and Intelligent Engineering

Posted on April 13, 2010  Comments (3)

I believe net neutrality should be championed to prevent decay of the usability of the internet. It seems to me internet connectivity is a natural monopoly that economic theory says should be a regulated monopoly. Smart countries have invested in providing much better internet connectivity that the USA has at much lower prices. Now in the USA we have companies that seek to control internet connectivity and then use that monopolistic control to favor higher margin efforts. So force those that have resources available on the internet to pay or the ISP threatens to degrade the connectivity to their resources.

chart showing internet connectivity speed (USA 18th)

The investment in equipment and fiber that allows internet connectivity has to be paid for. If those regulated ISPs wanted to set bandwidth use pricing that is fine with me. If we decided it is best to have one low price say $30 a month for access at a similar perforance of 10 other countries (Japan, Germany, South Korea, Canada, United Kingdom…) and then charge extra for individuals those that use more than some amount fine. But I think it should not be tied to whether you use service that haven’t paid the ISP money to be favored. The USA is currently 18th and slowed down, while others continue to speed up.

The 2008 ITIF Broadband Rankings show the USA in 15th place, out of 30 OECD countries, for broadband adoption, speed and price. In 2001 the USA was in 4th place.

If ISPs don’t want to be in the business they should be in – providing internet connectivity. Fine, get out of that business and go into the business they want to be in. But don’t try to take control of a natural monopoly and then use that control to extort money from those that rely on the natural monopoly.

Google accused of YouTube ‘free ride’

Some of Europe’s leading telecoms groups are squaring up for a fight with Google over what they claim is the free ride enjoyed by the technology company’s YouTube video-sharing service. Telefónica, France Telecom and Deutsche Telekom all said Google should start paying them for carrying bandwidth-hungry content such as YouTube video over their networks.

I can understand why they would think that way. But isn’t it equally valid to say hey those that pay you for internet connectivity really want to use YouTube. If you need to make more investments in your infrastructure to support your customers use, then do so and raise the prices. I completely disagree with the ISP negotiating what content users can see. But if that were to happen why couldn’t Google instead of paying say, hey your customers really want YouTube – if you don’t pay us we won’t let you deliver it to your customers?

Net Neutrality: This is serious by Tim Berners-Lee

When I invented the Web, I didn’t have to ask anyone’s permission. Now, hundreds of millions of people are using it freely. I am worried that that is going end in the USA.
…
Yes, regulation to keep the Internet open is regulation. And mostly, the Internet thrives on lack of regulation. But some basic values have to be preserved. For example, the market system depends on the rule that you can’t photocopy money. Democracy depends on freedom of speech. Freedom of connection, with any application, to any party, is the fundamental social basis of the Internet, and, now, the society based on it.

Let’s see whether the United States is capable as acting according to its important values, or whether it is, as so many people are saying, run by the misguided short-term interested of large corporations.

I hope that Congress can protect net neutrality, so I can continue to innovate in the internet space. I want to see the explosion of innovations happening out there on the Web, so diverse and so exciting, continue unabated.

Google’s Traffic Is Giant, Which Is Why It Should be Your ISP
Continue reading →

Toyota’s Journey to Lean Software Development

Posted on March 18, 2010  Comments (0)

Toyota’s journey from Waterfall to Lean software development by Henrik Kniberg

Toyota builds cars (duh). In the past that didn’t involve much software, and the little software that was needed was mostly developed by suppliers and embedded in isolated components. Toyota assembled them and didn’t much care about the software inside. But “The importance of automatic electronic control system has been increasing dramatically year by year” said Ishii-san.

A modern car is pretty much a computer on wheels! In a hybrid car about half of the development cost is software, it contains millions of lines of code as all the different subsystems have to integrate with each other. He mentioned that a Lexus contains 14 million lines of code, comparable to banking and airplane software systems. Ishi-san concluded that “Therefore Toyota needs to become an IT company”.
…
Most of Toyota’s ideas about how to do Lean software development resonated well with me. My feeling was that they are on the right track.

One thing bothered me though – the extreme focus on detailed metrics. I agree with the value of visualization, standardization, and data-driven process improvement – but only if used at a high level. My feeling was that Toyota was going to far. They say engineer motivation is critical, but how motivating is it to work in an organization that plans and measures everything you do – every line of code, every hour, every defect, how many minutes it takes to do an estimate, etc?

via: Justin Hunter

Related: Toyota IT Overview – Toyota Canada CIO on Genchi Genbutsu and Kaizen – Lean Software Development – My First Trip to Japan by Peter Scholtes – Toyota IT for Kaizen

Improving Software Development with Automated Tests

Posted on March 8, 2010  Comments (7)

Automated software testing is a mistake proofing (poka-yoke) solution for software development.

The way automated testing works is that software code is written that tests the software code of the application. This automated testing code test that business rules are correctly being followed by the code in the application.

So for example, a user should not be able to create a new account without entering password. Then you create code that does not allow an account to be created without a password. And you write a test that passes if this is true and fails if it is false.

The best implementation will then not allow deploying code to your production environment until the code has passed all the automated tests. So if a software developer changes the code, the automated tests are all run and if there is an error noted by the automated testing the code cannot be deployed to the production environment. So, in the example above, if somehow the changes made to the application code somehow now let an account be created without a password the test would fail, and the developer would know to fix the problem before putting the code into production.

Thus automated testing mistake proofs the process. Now the mistake proofing is only as good as the test that are added. Software development is complex and if the code has an error (based on the business rules) that is not tested then the code can be deployed to production and affect customers. But it is a huge help in preventing many errors from affecting customers.

It seems pretty obvious but until the widespread adoption of agile software development techniques and frameworks that make it easy to adopt automated testing (like Ruby on Rails) this sensible process improvement tool was used far less often than you would think.

Related: Combinatorial Testing for Software – Metrics and Software Development – Checklists in Software Development – Google testing blog – Hexawise software testing blog

Observations of a New Googler

Posted on February 6, 2010  Comments (2)

Some interesting thoughts from a new Google engineer, Things I’ve learned at Google so far

I would describe Google’s culture as “creative chaos”. There was some confusion about where I was supposed to be when I started. This resulted in the following phone call, “Hello?”, “Hello Ben, this is Conner (that’s my new manager), where are you?” “Mountain View.” “Why are you there?” “Because this is where the recruiter said to go.” “Good answer! Nice of them to tell me. Enjoy your week!” This caused me to ask an experienced Googler, “Is it always this chaotic?” The response I got was, “Yes! Isn’t it wonderful?” That response sums up a lot about Google’s culture. If you’re unable to enjoy that kind of environment, then Google isn’t the place for you.
…
Paul Buchheit was a software engineer at Google. He didn’t need permission to write something like gmail. Corporate culture says that if you need something like that, you just go ahead and do it. In fact this is enshrined as an official corporate policy – engineers get 20% of their time to do with pretty much as they please, and are judged in part on how they use that time. I found a speech claiming that over half of Google’s applications started as a 20% project. (I’m surprised that the figure is so low.) To get a sense of how much stuff people just do, visit Google Labs. No corporate decision. No central planning.
…
Sick day policy. Don’t show up when you’re sick and tell people why you’re not showing up. Note what’s missing. There is no limit to how much sick time you get if you need it.

I think he overestimates the lack of central planning, still it is another interesting view of Google.

Related: Eric Schmidt on Management at Google – Google: Ten Golden Rules – The Myth of the Genius Programmer

Managing to Test Result Instead of Customer Value

Posted on October 19, 2009  Comments (5)

Computer hardware and software creators use benchmarks as one tool to compare the performance of alternative products. At times this can be very useful. You can learn what software of hardware is faster and that may be a very valuable factor. However, any measure is determined by the operational definitions used in collecting the measure. And if people have incentives to improve the measured number they often will do just that (improving the measure) rather than improving the system (the measure is meant to serve as a proxy for some function of that system).

Information technology people actually understand this much better than most mangers (who also rely on measures for many things like return on equity, profit growth, productivity of various plants…) – so actually I find they are not nearly as fooled by measures compared to managers. On Reddit there is an interesting discussion on coding the product to provide good benchmark results [in this context benchmarking has to do with measured results on standard performance tests – not TQM style benchmarking). The technical details in this case don’t matter so much to my point, which is just that when people treat the measure as the true value instead of a proxy for the true value it is risky.

Technology companies compete fiercely and claiming the software or hardware is faster is one big area of competition. And the comment on Reddit is claiming one competitor changed some code only to get a better measure (that provides no benefit to customers). The problem with such actions, is they provide no actual value: all they do is make the measure less meaningful as a proxy.

Now it is also perfectly understandable why it would be done – when you are focused on improving the number, it might well be easier to distort the system to provide a better number (used by to measure performance) instead of actual improve the performance. It is easy to see why a company would do this if they want to have marketing claim their products are the fastest.
Continue reading →

Understanding How to Manage Geeks

Posted on September 12, 2009  Comments (3)

The unspoken truth about managing geeks by Jeff Ello

IT pros are sensitive to logic — that’s what you pay them for. When things don’t add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event. The more things that occur that make no sense, the more cynical IT pros will become… Presuming this is a trait that must be disciplined out of them is a huge management mistake. IT pros complain primarily about logic, and primarily to people they respect. If you are dismissive of complaints, fail to recognize an illogical event or behave in deceptive ways, IT pros will likely stop complaining to you. You might mistake this as a behavioral improvement, when it’s actually a show of disrespect. It means you are no longer worth talking to, which leads to insubordination.
…
Good IT pros are not anti-bureaucracy, as many observers think. They are anti-stupidity. The difference is both subjective and subtle.
…
The primary task of any IT group is to teach people how to work. That’s may sound authoritarian, but it’s not. IT’s job at the most fundamental level is to build, maintain and improve frameworks within which to accomplish tasks.
…
it’s all about respect. If you can identify and cultivate those individuals and processes that earn genuine respect from IT pros, you’ll have a great IT team. Taking an honest interest in helping your IT group help you is probably the smartest business move an organization can make. It also makes for happy, completely non-geek-like geeks.

The article makes very good points. As I have said before software developers expect more of management than most staff do. And I would say software developers are seen as more cynical than most staff because they accurately evaluate management’s failures (and are more willing to speak up about problems).

Pretending software bugs don’t exist doesn’t work. Pretending management bugs don’t exist doesn’t work either, but most are willing to pretend management bugs don’t exit. Programmers often figure bugs should be acknowledged and dealt with, rather than pretending they don’t exist. But they are called cynical when they mention management bugs – which only makes them less confident in the ability of management to preform their responsibilities.
Continue reading →

YouTube Uses Multivariate Experiment To Improve Sign-ups 15%

Posted on August 17, 2009  Comments (2)

Google does a great job of using statistical and engineering principles to improve. It is amazing how slow we are to adopt new ideas but because we are it provides big advantages to companies like Google that use concepts like design of experiments, experimenting quickly and often… while others don’t. Look Inside a 1,024 Recipe Multivariate Experiment

A few weeks ago, we ran one of the largest multivariate experiments ever: a 1,024 recipe experiment on 100% of our US-English homepage. Utilizing Google Website Optimizer, we made small changes to three sections on our homepage (see below), with the goal of increasing the number of people who signed up for an account. The results were impressive: the new page performed 15.7% better than the original, resulting in thousands more sign-ups and personalized views to the homepage every day.
…
While we could have hypothesized which elements result in greater conversions (for example, the color red is more eye-catching), multivariate testing reveals and proves the combinatorial impact of different configurations. Running tests like this also help guide our design process: instead of relying on our own ideas and intuition, you have a big part in steering us in the right direction. In fact, we plan on incorporating many of these elements in future evolutions of our homepage.

via: @hexawise – My brother has created a software application to provide much better test coverage with far fewer tests using the same factorial designed experiments ideas my father worked with decades ago (and yet still far to few people use).

Related: Combinatorial Testing for Software – Statistics for Experimenters – Google’s Website Optimizer allows for multivariate testing of your website. – Using Design of Experiments

Baking in Quality to Software Development

Posted on August 15, 2009  Comments (2)

One of the reasons my organizations switched to Ruby on Rails for software development was the great integration with automated testing. We always wanted to have good test coverage on our software applications (which are web applications – some used only inside our organization) but didn’t actually find the time to do so. Since we adopted Ruby we have been doing much better in this regard. It isn’t just the switch to Ruby, of course, but the switch to Ruby coincided with the beginning of many improvements to our software development practices that have continually improved over the last couple of years.

Here is a post on How to build quality software by an agile, Ruby, lean software developer

I’ve mentioned previously about baking-in quality and not having developers throw code over a wall to testers.
…
Everyone on the team is concerned with not only assuring quality in what we deliver, but making it visible to ourselves and the business.

We work in an agile manner, iterating through development with extreme programming practices and Behaviour Driven Development. Facilitating our relationship with the business is Scrum and we utilise kanban principles and systems thinking to maintain a speedy throughput of high-quality work. This mixture allows us to communicate effectively, develop the correct features properly and continuously deploy our work when it is complete, thus maximising business value. I should also mention that we are fortunate enough to have our business people/customer sat across from us.
…
Without testers or a QA team there is no wall over which work can be thrown and the responsibility for quality absolved.
…
The inspection typically carried out end-of-cycle only yields bugs that were low severity and of no real impact to the end user.
…
An agile testing must-have, we use TeamCity to continuously run our unit tests on each check-in. We also execute our Cucumber acceptance tests on scheduled runs. The status of the builds are visible on dedicated monitors around the office as well as a nice 6′ projected screen.

via: @benjaminm

Related: Combinatorial Testing for Software – Checklists in Software Development – Software Supporting Processes Not the Other Way Around – Software Development and Business Process Support – Top Blogs for Software Development – Hexawise: more coverage, fewer tests (my brother’s company)

Don’t Hide Problems in Computers

Posted on August 11, 2009  Comments (3)

Making things visible is a key to effective management. And data in computers can be easy to ignore. Don’t forget to make data visible. Paul Levy, CEO of Beth Israel Deaconess Medical Center in Boston recently hosted Hideshi Yokoi, president of the Toyota Production System Support Center and wrote this blog post:

Together, we visited gemba and observed several hospital processes in action, looking for ways to reduce waste and reorganize work. It was fascinating to have such experts here and see things through their eyes. Mr. Yokoi’s thoughts and observations are very, very clear, notwithstanding a command of English that is still a work in progress.

The highlight? At one point, we pointed out a new information system that we were thinking of putting into place to monitor and control the flow of certain inventory. Mr. Yokoi’s wise response, suggesting otherwise, was:

“When you put problem in computer, box hide answer. Problem must be visible!”

The mission of the Toyota Production System Support Center to share Toyota Production System know-how with North American organizations that have a true desire to learn and adopt TPS.

Related: The Importance of Making Problems Visible – Great Visual Instruction Example – Health Care the Toyota Way

Three Years of Real-World IT Projects In Ruby

Posted on July 16, 2009  Comments (0)

Nice webcast by Martin Fowler, Three Years of Real-World Ruby. This talk is probably only of interest to those of you in software development, but for them I think it is an excellent presentation.

At work we have been use Ruby for the last 3 years and have found it to be a powerful language that helps make writing software applications fun. And that is important. By providing a powerful language and a rails framework that takes away much of the drudgery of writing code you can create an environment where develops are happy and productive. We are hiring, by the way.

The talk provides a good background on their experience using ruby to manage projects; and how they manage ruby application development projects.

Related: Combinatorial Testing for Software – Checklists in Software Development – Future Directions for Agile Management

  • Recent Trackbacks

  • Comments