The RHoK hackathon runs on the same weekend in over 30 countries around the world. Here in Melbourne, we had around 60 people involved and it was held at Swinburne University.

There were 5 problems to solve, and 5 teams. The crowd was quite diverse; one of the teams had members from 8 different countries, and the youngest participants were in Year 11 at school.

Overall, it was a really great experience. Awesome to see how the event works and to meet so many enthusiastic people, and to experience how quickly a new team can come together, make collective decisions and use the Lean Startup methodology to deliver something useful.

My learnings were many, but included:

• At a hackathon, just like in the corporate world, you need a variety of skillsets to ensure optimum results. For example, the business analyst on our team played a key role in helping define the problem and minimal viable product (MVP)
• Problem owners are also key throughout the event to get (and keep!) people enthused about the solution (problem owners are people from NGO’s and social enterprises, who define the problem that needs solving)
• The time goes extremely quickly! And when you take out the time to get the team started, and the presentation after lunch on the second day, you only really have one day to work developing it
• People don’t necessarily need to commit for the whole weekend – some people only came for the first few hours, some left early, etc.
• I have lots to learn!
• The beer tastes reeeally good afterwards :)

My team comprised 9 people (2 problem owners, 1 BA, 1 marketer, 1 designer, 4 devs) – and over the course of the weekend we managed to create a live, working website! The site hasn’t been officially launched yet so I can’t yet publish the URL, though I can give some details on the tech stack: Bootstrap, SASS, Yeoman, Facebook Connect, Ruby Sinatra, PostgreSQL and Heroku.

The RHoK event is in December – I highly recommend going along if you can make it!

Fear not, my friend: it can be automated, for both local and remote machines. I thought I might document how to do it because it took some time to get working.

The below script will:

1. Check whether the certificate (.pfx file) is already in the certificate store
2. If not already there, import the certificate
3. Find the key via its thumbprint, using Microsoft’s FindPrivateKey tool
4. Grant a user access to the key

NOTE: the below script is strictly illustrative – error handling and commenting are left as exercises for the reader ;)

@echo off
SETLOCAL ENABLEEXTENSIONS

:grantaccess
icacls.exe "%certpath%" /grant %user%:R

And that’s it.

If you cut and paste the above into a .bat file and name it something like install.bat, you can invoke it like this:
install.bat user_name footprint certificate_filename certificate_password
For example:
install.bat "IIS App Pool\AppPool1" bc4da1aa2b7116abe33277a44eaab2135210e23b certificate.pfx password

Some pre-requisites/gotchas:

1. You will need Microsoft’s FindPrivateKey tool which will locate the certificate in the store. You can obtain FindPrivateKey in the WCF samples: download
2. The script will locate the certificate by its footprint, which you will need to determine in advance by importing the certificate manually
3. You can also use FindPrivateKey to locate the certificate by subject name, but I found that locating it by footprint was more reliable for multi-line subjects
4. To grant access an IIS app pool access to the certificate, you need to specify the app pool name in the format
   "IIS App Pool\app_pool_name"

Installing the certificate on a remote machine

I used the SysInternals tool PSExec to run the script on remote machines, using the below parameters:
PSExec.exe /accepteula \\hostname -i -s -w remote_working_folder cmd /c "script_with_parameters"
Where:

• hostname: the hostname on which the script will run
• remote_working_folder: folder on the host which contains the certificate to import and the FindPrivateKey tool exe
• script_with_parameters: the batch file to run with all parameters specified

For example:
PSExec.exe /accepteula \\myhost -i -s -w c:\temp cmd /c install.bat "IIS App Pool\AppPool1" bc4da1aa2b7116abe33277a44eaab2135210e23b certificate.pfx password"

“I am a team leader of a small app dev team and I came across your blog articles on the use of wikis. I am very interested in setting up a wiki for my team for many of the reasons you have noted. Hoping you could give me a little advice.

I’m hoping to find something that’s very easy to use and …free!

What wiki engine do you use and how did you choose it.”

My preferred wiki is MediaWiki – it’s fast, easy to use & install… and free! It’s the same software used by Wikipedia and is well supported with extensions. I’ve used it at two workplaces before with great success.

Where I work now we use TWiki, which is also very good and has plenty of extensions available, but I find it a little slower and clunkier to use than MediaWiki. On the other hand, it has access control (which we currently don’t use).

If you can get budget for it (because it’s not free) I would also recommend Confluence, by Atlassian. A wonderful feature it is has is cutting and pasting of images into the WYSIWYG editor; otherwise, uploading images can be a little tedious with wikis.

But for something free, and depending on your specific requirements and whether you need access control, I’d recommend MediaWiki or TWiki.

– if anybody else has any questions, please feel free to email them to me!

It’s pretty easy to come up with many different answers to this question – defects, technical debt, project overruns, projects cancellations – even company failures. There is so much waste in software development it’s hard to know where to start!

According to Mary Poppendieck, thought leader in Lean Software Development, the answer is simple: the biggest waste in software development is building the wrong thing!

Similarly, when Steve Jobs returned to Apple in 1997, he famously said, “focusing is about saying no”. By ruthlessly cutting the product range, Apple’s talent was then free to work on products like the iPod, a device with a brilliantly simple user interface, with no wasted features.

I’d like to combine Mary and Steve’s ideas and say that we can help build the right thing by saying no. By cutting wasted time, effort, energy, and money, we can channel our resources to produce the best we are capable of.

Here are 5 ways it can be done:

1. Say No to New Feature Waste

New feature waste includes new features that don’t give enough value to justify their cost.

The Agile methodology helps us here. By breaking work down into stories, and by engaging product owners and prioritising stories, our team should be working on the most valuable thing possible at any point in time.

Every time we de-prioritise or de-scope a story, or a whole project for that matter, we make a conscious decision not to do something right now. This allows us to focus our immediate efforts on the work that add the most value.

2. Say No to Legacy Feature Waste

It’s not enough just to look at new features – we should also review products and features we already have.

According to Mary Poppendieck, 64% of software features are never or rarely used. Unused features add overhead to new development work via increased system complexity and additional testing.

I have a rule that if I haven’t used a piece of clothing in over a year, I donate it to charity; perhaps if a feature also hasn’t been used for a similar length of time, it too can be shown the door.

3. Say No to Frilled Waste

Frilled waste is waste due to developing more than was required, by adding bells and whistles, or over-engineering the solution.

We should only implement the minimum to satisfy the requirement.

This can be counter-intuitive. Naturally, we should aim to product quality solutions, and minimise technical debt. But if we go over-the-top in what we deliver, we are probably diverting our resources from higher priority stories, whilst possibly adding complexity.

4. Say No to Automated Test Waste

Automated tests can add huge value to the team and greatly enhance quality. But every test comes at a development and maintenance cost, so we need to be careful to ensure that each test adds value relative to its cost.

We should review our test suite continually to ensure the tests still add value, they are correct, and are free of duplication. Keeping redundant automated test code adds complexity, maintenance and execution time.

5. Say No to Fluffy Waste

The “just say no” concept can be extended to almost any part of the software development process. Think about your daily work, such as emails and meetings. Is that meeting or email completely necessary? What are the alternatives, or how could it be rationalised to provide the most “bang for buck”?

Our work should be a continual process of asking ourselves why are we doing this? Because it’s what we choose not to do that cuts through, simplifies and allows us to focus on what makes us and our software successful.

I began with my .NET 4 assembly and tried to install it via the usual approach, dragging and dropping it into the %windir%\assembly folder via the Explorer shell extension. Strange; nothing happened.

A quick search revealed that for .NET 4, Microsoft, for reasons which do not seem to be well documented, have created a new GAC location, in the %windir%\Microsoft.NET folder.

Well, that was annoying, I thought: but I could deal with it. I tried dropping the file into the new GAC folder… but there is no nice Explorer shell extension for the new GAC. Doh! (for the second time)

Ok, time to drop to the command line and fire up good ol’ gacutil.exe.

FAIL

I received this error message:
“Failure adding assembly to the cache: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.”

Sigh. Ok, I thought, I’ll just use the .NET 4 version of gacutil.exe. After a quick search of my PC I learned that it’s not installed with Version 4 of framework, nor with Visual Studio 10.

Yet another brick wall! But no worries – I would just download it. I found out via Matt Whetton’s Blog that I needed to download Microsoft Windows SDK for Windows 7 and .NET Framework 4 to get it, so I did (while wondering why I need to download that whole SDK to get gacutil??)

So then I found gacutil in the bin folder of the SDK and I ran it. Arrgh, it returned the same error message again!

Eventually I found the .NET 4 version of GACUtil in the SDK – it’s nestled in
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools.

Sigh. Could Microsoft really make things any more difficult? I just wanted to install an assembly into the GAC!

By the way, if you need to copy gacutil onto a server, you will need to copy the following files to it: gacutil.exe, gacutil.exe.config and gacutlrc.dll (the last one located in the 1033 sub folder containing gacutil).

Not written by you, of course. You wouldn’t write a mess like that, and you can hardly believe that somebody else did (or maybe you can…?)

Your mind wanders to who to blame for this abomination before your eyes. You start complaining to the person sitting next to you. Then to your boss. Then you decide that it’s time for a coffee and then to browse for new jobs.

Sound familiar? I bet it does!

The difference between an average programmer and a good one is in what you do next.

Do you ignore it and try to forget you ever saw it, or do you attempt to improve it?

I have a simple rule that I like to follow: I always try to leave the code in a better state than I found it.

This might involve small improvements, like improving code formatting, renaming methods or variables, or adding useful comments. Tiny improvements add up over time, especially if the whole team is doing the same thing!

Or the improvement could be larger, like refactoring or adding test coverage.

Yes, this can take time, and yes you do have that deadline to consider. But it’s amazing how quickly small improvements can be done; certainly in much less time than it took to understand that grotesque code. Which means that your improvement might make it much quicker for the next person to understand – and that next person might be you, when you revisit it in a year’s time…

The important thing is to do it, and encourage your whole team to do it. Don’t be afraid to change things. Take responsibility for that code, even if you didn’t write it: embrace collective code ownership!

Jean has been consulting as an Agile coach for many years, so it was really thought-provoking to hear her top reasons of why the adoption of Agile might fail.

I thought I’d repeat the list on my blog for my readers because I think it’s a great compilation of potential pitfalls we should all work hard to avoid. Perhaps we could call them “Agile anti-patterns”!

The 12 Failure Modes of Agile (from Jean Tabaka)

1. “Checkbook commitment”

This refers to when people are saying they’re doing “Agile”, but without actually committing to it. They expect immediate results, and they use the same old organisational structure and metrics.

2. Culture that doesn’t support change

If the company culture is resistant to change, how can it adopt a methodology that embraces it? An example of this would be a culture where people are rewarded for not “rocking the boat”.

3. Ineffective use of retrospectives

Retrospectives must be done and handled effectively. The feedback gained via retrospectives must be learned from and acted upon. The whole team must be responsible for the actions from the retrospective, not just the scrum master.

4. Ignore needed infrastructure

For example, for a team to do Continuous Integration, it needs access to a build server!

5. Lack of full planning participation

The whole team needs to participate in planning and, as a team, commit to the work defined for the iteration.

6. Unavailable (or too many) product owners

Product owners are busy, but it is a warning sign when they say “we’re too busy for all this communicating”. Also, if there are too many product owners, it can be hard to get agreement.

Jean raised an intriguing question here: she asked how many people in the audience had done some form of Agile training. Many hands went up. Then she asked, how many people had worked with product owners who have been trained in Agile? I don’t think anybody raised their hand…

7. Bad scrum masters

The team needs to collaborate well within each iteration, and a poor scrum master can be harmful to the team’s morale and productivity. An example of a bad scrum master is one that plans all the work, puts it in a tool and then tells people to do it.

Jean made the point that if you take over the decisions for others you lower morale (and IQ’s!). Scrum masters should not control, they should empower.

8. Not having an onsite evangelist

This point is particularly important for distributed teams, or teams in branch offices. Without an Agile evangelist/coach onsite, the remote team can lose its way.

9. Team lacks authority/decision making ability

Agile is not about control, it is about empowerment.

10. Testing not pulled forward

Testing should be done up front, ideally, or else as soon as possible. Testing should also be automated.

11. Traditional performance appraisals

Traditionally, performance appraisals reward individual performance. In an Agile environment, the focus is on team performance, not individual heroics, and appraisals should reflect this.

Performance evaluations should also be regular, not once per year.

12. Change is hard, Agile is blamed

For example: an Agile methodology is introduced to solve a company’s problems. It fails, and Agile is blamed rather than the company’s own, deeper problems. It is often easier to look outwards and assign blame rather than to look inwards.

I must admit have a special interest in this idea: ever since I began using Agile for software development I have fantasised about its potential for non-development projects. I used it to partly plan my recent round the world trip. A former colleague of mine was using it to plan his wedding. If it works for a software team, it could work elsewhere… right?

But it’s never quite that easy, is it? It can be difficult to get buy-in for an Agile process in a development team, depending on the level of management support and developer engagement. Imagine how much harder it must be to get momentum in an environment or industry that may not have even heard of Agile!

Having these doubts in mind, the session was a real eye-opener for me. I was introduced to real people working in corporate teams using Agile for non-software projects.

Some examples I have discovered:

• The bank, Suncorp is using Agile for finance and procurement teams, with an Agile coach from software development background, and by mapping Agile onto standard processes
• The telecommunications company Telstra is applying Agile while providing external services to Suncorp, integrating with Suncorp’s preferred business service methodology
• Lonely Planet’s team of in-house lawyers is now using Agile to plan their work load and ensure priority items are done on time (Beverley Head in Agile Today, May 2011)
• AccuRev trained their whole sales team in Certified Scrum Training and adopted a quarterly iteration period, aligning with their sales cycle

I am looking forward to watching this trend continue.

Perhaps it might become the silver bullet to unlock the next wave of productivity growth for teams of knowledge workers. Or maybe lots of story boards will just end up getting thrown off rooftops!

What do you think? Do you know of any other examples of Agile being used in non development environments?

Japanese garden (Randy Robertson)

With this thought in mind (perhaps I’m a little too enthusiastic about spring?), today I took the challenge of greatly simplifying my Inbox, based on one simple principle: does this item need my immediate attention?

To do this, I used the advanced features that Gmail offers to handle a lot of the ’email gardening’ for us!

I started with the low-hanging fruit: the Priority Inbox feature.

Turn on the Priority Inbox feature

The Priority Inbox feature is brilliant. It means that Gmail will automatically determine which items it thinks are important and which ones aren’t, and then shows you the priority ones at the top of the page. You can train it to teach it what you view as important and what isn’t.

You may ask, what about the items that the Priority Inbox feature doesn’t deem as “important”? I’m talking about dozens of emails every day: newsletters, notifications, bookings; as well anything important that Priority Inbox might have missed (it’s not perfect, after all!)

It would be helpful to be able to categorise all these emails, wouldn’t it? I did this by using Gmail labels.

Create labels

Labels are a very powerful Gmail feature: they allow you to classify and thereby group your emails. Think of it as an array of virtual flower boxes, organised by type of flower.

For example, I have a label called Newsletter, in which I like to group any subscriptions that I don’t need to read straight away. Later, I can read them by clicking on the Newsletter folder that Gmail creates for me the left-hand side of the Inbox.

Gmail Label

I created more labels, for example, one called Facebook, for Facebook notifications. Some people have said “just stop forwarding the notifications to your email account!“. But it’s often quicker to read them as email. It also means that I don’t need to log into Facebook, which as many of us might know, can be very distracting!

Create filters

I took the label idea one step further: I used Gmail filters to let it do the work for me. Filters are another powerful feature and are used to automatically process your emails for you as soon as they arrive. It’s like having a gardener to tend to your plants for you while you’re out shopping.

So I created the filter “all emails from Facebook should be removed from the Inbox and assigned a label of Facebook“. (Another example of a filter would be, “all emails from Brendan should automatically deleted.“)

Creating a filter in Gmail

I applied a similar process for labels and filters for notifications from Twitter, LinkedIn and so on.

Process remaining emails

At this stage the groundwork has been done for an automated email-management process. The flower boxes (labels) had been set up and the Gmail gardeners (filters) had been told what to do.

I then took my Everything Else folder and went through the remaining emails, the ones that were not classified as Priority. (At this stage I had around a thousand items in this folder!)

For each email, I applied a simple process:

1. Is this item spam?
   If yes, click on the Gmail Mark as Spam button. I find that with this feature I very rarely receive spam in my Gmail account.
2. Is this an email one that I DO NOT want to receive ever again?
   If yes, unsubscribe and/or create a filter to automatically delete items from that address in future. (For example, a mass marketing email.)
3. Is this an important item which needs to be read/processed?
   If so, click on the Mark as Important button to tell Gmail to mark emails like this one as important in future. Also click the Star icon to mark the item for later processing. (For example, an email from my Dad.)
4. Is this email one that could be archived automatically in future?
   If yes, create a filter such that any emails in the future from this address are removed from the inbox and assigned a label. (For example, all hostel booking notifications from HostelBooker can be archived and assigned the TravelBooking label.)
5. Anything else, either click on Archive or Delete as required.

The Result

INBOX ZERO!

What does that really mean? It means I have no emails in my Inbox that are unprocessed. Every email is in its logical place: either assigned a label for reference, or marked with star so I can deal with it later. I also have a large set of new filters to automatically process items in the future.

Is there more work to do?

Yes. I still have to go through and process the starred items. But now I know exactly how many of those there are, and as a constant reminder, I will see them every time I log in at the top of the page.

Was it worth it?

Overall, the process probably took me couple of hours to do. It was a profitable investment of my time: in future I will spend more time responding to important email and less time managing unimportant email.

In a slightly geeky way I also kind of like the feeling that my inbox is being constantly monitored by a robot that will filter the emails for me. That means less work for me.

On the other hand, I also know that I will need to be vigilant in applying this process regularly. I will need to keep creating new filters/labels to keep those pesky weeds under control.

Ok, enough about email. Now it’s time to go and have a cold drink in that garden!