Stephen:

A thought provoking TED talk on the possible uses of git and GitHub to facilitate a new kind of ‘open participation’ working model into a range of knowledge domains. How could you apply this idea to your organization?

Originally posted on TED Blog:

The open-source programming world has a lot to teach democracy, says Clay Shirky.

In this fascinating talk from TEDGlobal 2012, Shirky harkens back to the early days of the printing press. At the time, a group of “natural philosophers” (who would later adopt the term “scientists”) called the Invisible College realized that the press could offer a new way to share and debate their work. However, because printing books would be far too slow for this purpose, they came up with a new invention — the scientific journal.

So what does this mean for us today?

Shirky explains, “If I had to pick a group that I think is our Invisible College — our generation’s collection of people trying to take new tools and press them into the service of, not more arguments, but better arguments — I’d pick the open-source programmers.”

Shirky explains a fact that any programmer…

View original 653 more words

It’s Predictability, Dummy

One of the frequent challenges I face when engaging with enterprise customers is the process of meeting their expectations.

If you’re selling software solutions to an enterprise, it’s quite likely that they are not experts in software, even though they may have a large IT department. However they may well be experts in planning and risk. For them, the software solution is a means to an end, to help them earn revenue from some other source.

Which is a long way of saying that in order for your customer to have a really good experience with your solution, one of the best ways to do that is to be predictable. This is a commonly overlooked characteristic.

Unless — and maybe even if — you’re under delivery pressure, you will do yourselves and the customer a favour by making your delivery milestones comfortably achievable, even if those milestones are not to the customer’s satisfaction. Sure they may argue long and hard with you about the milestones, but you’ll do no-one a favour if you agree to something that you’re just not sure of. Make sure you explain all the risks clearly and succinctly, and make sure you show them a sensible plan for achieving your milestone, one based on your assessment of risks and dependencies. In other words, push back if necessary. But sometimes the unimpeachable logic of your argument will be enough.

Why predictability? Because enterprises crave predictability and hate surprises. Any enterprise development programme requires the marshalling of a large number of resources by the enterprise, and quite often the cost of these resources will dwarf the cost of your software solution. So unexpected changes to the delivery plans due to missed milestones will create cost pressures within your customer’s organization. And because those costs have themselves been approved only after a long and tortuous review cycle, your lack of predictability suddenly has cost implications far greater than you can see. And your contacts within the enterprise will not want to have to go back and ask for more money because it reflects poorly on them. So now you have added a personal element to the problem as well. Always remember that your contacts have their own internal customers to please.

So: be boring, be predictable. Communicate excessively. Spend lots of time with your customer. Under promise and over deliver. That is the path to success with your enterprise customer.

Simultaneous Chess

I was trying to explain a rather challenging day at the office to my wife; a day where I felt like I had a thousand things happening at once.

I struggled for a few minutes and then stumbled to a description that “it is like playing simultaneous chess” where you must keep a number of game states in memory and constantly switch between them.

I think this is a rather apt description. I also see that the ability to play this kind of simultaneous chess is a really key attribute for many senior executives. That’s not to disparage a single-minded focus on one thing, since I believe this kind of attention is really the key to creativity. But not many us work on creative tasks all the time. Sometimes we must play chess, and if you can play multiple games simultaneously then that is also a valuable skill.

As a footnote to this post, I am not suggesting any adversarial element in my work. Of course we all strive for a win-win result in any deal. I am only commenting on the complexity aspect.

How long is your software release cycle?

Your organization’s software release cycle time is one of the primary indicators of the health of your entire software delivery operation. Ask yourself how long it takes your entire organization to make a software release from the time that a developer checks in that change – any change, even the simplest – until it goes into production.

No shortcuts, now! This release must be one that your enterprise will fully support, so testing and quality assurance is needed.

This is your release cycle time. Is your answer measured in minutes, hours, days, weeks, months or even years? Most organizations that I’ve seen measure their release cycle in days or weeks. But there are some organisations with release cycles at either end of the spectrum.

Why is this important? The reality is that your enterprise relies on software releases to fulfil some critical business need. It might be needed to generate business income, it might be needed to fix a defect that is affecting your customers. For these reasons, the shorter your release time, the quicker you can derive a business benefit. The smartest companies will create a competitive advantage from the speed of their software release cycle.

In a future post I’ll be writing about what your organisation can do to improve your release cycle.

Five signs your software deployment process doesn’t work

1. You create elaborate documentation about your software release process. Now you have two things to maintain: the documentation about your release process; and the actual release process itself. Documentation is a way for people to communicate in an unambiguous way about complex topics. But documentation maintained separately from the underlying activity creates yet another legacy.

2. Your production environments are not the same as your test or staging deployment environments. Machines are different, configurations are different, database settings are different, and the list goes on.

3. The software deployment is performed manually. You have different teams each taking ownership of different parts of the problem at a different stage of the process, and making a series of changes to a whole variety os systems in a highly manual activity.

4. Releases take hours or days rather than minutes. You have no reliable way to measure how long the release will take to complete. There are no measures or trial information available for you to make the assessment.

5. Releases leave you in a cold sweat, not knowing whether the release will succeed or fail. The dread of releases creates extreme stress throughout the entire organisation because of the fear of the unknown. Did you miss some minor detail that will cause everything to fail? Will your organisation suffer losses of perhaps millions of dollars as a result? Will furious customers jam the help desk with complaints, or the releases’ failure be  splashed across major media outlets? Will you have to explain the situation to executive management, or worse still, the board?