The Agile Executive

With the successful release of Enterprise Profile Management 1.0, I asked Nick Beaugeard – Founder and Managing Director of HubOne – to capture and share with us his Agile development experience. Some of the threads he describes might have been mentioned in other posts in this blog. Others, like “Invest in your method and tools before you hire people, not after you hire people!”, appear for the first time. Whether mentioned here before or not, the ‘secret sauce’ is Nick’s ability to pull so many threads together. The power of so doing is nicely expressed in Nick’s guest post below. 

Nick’s been involved in Tech for 27 years (if you include the games he wrote for the Apple II aged 9) and has been involved with companies like Microsoft, CSC, JP Morgan and many others. He’s also ran a number of start-ups, from web 2.0 to services to solutions companies and has been successful with a number of those. Nick has a passion for all things Agile, but prefers to design the methodology to suit the purpose, rather than rely on a one size fits all method. Notwithstanding this, Nick has some notoriety within Dimension Data for passionately changing solution development from failing waterfall to a test based development approach, suiting solutions and services.
 
Nick lives on Sydney’s northern beaches with his wife, four kids, two mice and a framed copy of the fabled W.W. Royce “waterfall” speech to the IEEE.

Here is Nick:

I’ve ran start-ups before. I’ve even managed the development of products before, but this is the first time I’ve set up a start-up with the sole goal of developing a product and bringing it to market. Thinking back on the last 8 months, I’m not sure I’d have taken the challenge on in retrospect, but we did, and we succeeded and so in this post, I’d like to share with you how a micro-startup with a budget of $50,000 can design, develop, release and certify an Enterprise quality product without going both broke or mad….

 

During my career, which spans everything from support, through solutions and has a great deal of focus on Systems Management, I’ve been constantly frustrated by something which should be really simple, how to find people with specific skills or responsibility. Seeing that the problem still existed, I set out to build a solution which would attempt to solve such a problem.

 
The first step on the road was to meet with potential customers. At this stage, I had barely a germ of an idea. It could be written in 20pt type on a single piece of paper. Nevertheless, I met with over 20 different potential customers and attempted to pitch the “solution” to them. The feedback I got was extensive, but the main and core piece of information was that the solution had value and merit and if we could deliver then these customers might just buy the software. I even went as far as to ask them how much they’d pay for such a solution and got a fairly consistent figure of about $20 per year per user.

 
I realised at once that the problem I was trying to solve was not a database problem. In fact it was a directory problem so I set about investigating whether I could produce a solution using an LDAP directory.

 
Right at the beginning, though, I made an investment in tools. I implemented great source control, issue management, task management and a build platform, just like I was in a huge team.

 
I also made sure I adhered to issue and task management and made sure that I was forced to complete the criteria for each check-in. I know that sounds stupid, and it must have seemed so… The CEO of a start-up assigning himself issues only to resolve them on check-in.  However I believed it to be easier to implement the processes I wanted before I had a team on board, demonstrate me using them and it would be WAY easier to get the team to use them!

 
To test if my architectural hypotheses was correct, I wrote a very, very basic API. This small piece of code was able to perform some CRUD (Create, Retrieve, Update and Delete) operations on my own custom directory objects.

 
Let’s read the above again… See I had no spec, some interesting comments from customers and just went ahead and wrote a prototype API. Next I wrote some Unit tests which exercised the API and went back to my customers to see if I was on the right track.

 
That bit was tough. It takes a fair amount of imagination to see a simple set of unit tests and then extrapolate that to a completed product. However my friendly customer s were very patient as I explained that a response of “Passed” actually meant what I just explained had happened.

 
Once again that feedback helped and I felt confident enough to prototype most of the API and almost completely complete the schema. Once again I created a bunch of unit tests, but this time I focussed on the core scenarios as discussed with our customers.

 
Still at this stage, we had spent almost nothing, had a good, working and testable prototype API and a schema which worked.

 
It was then time to go and get a couple of developers. I knew a couple of my close colleagues had just resigned from another company so I asked them if they’d come and work for me, at a vastly reduced rate, for some stock in my new start-up. 

 
Just the stage for a spec, huh? We’ve now got more than one developer so obviously need to write down then entire goal of the solution…

 
I thought not. My API was just a prototype and needed to be secured, consolidated, better documented, globalized and tested for performance and the unit tests demonstrated exactly how things should work. My new, fresh team set to work on tidying up and completing the API, working on issues and tasks and performing check ins. They also got told whenever they broke a build.

 
We were then seriously thinking about building a web services layer. This had several advantages, not the least being that we could support clients on multiple platforms. However, I was still a little uncomfortable with my API hypotheses and really wanted to build a client that exercised the entire API before we invested in SOAP and web services.

 
Therefore we set the challenge and therefore the scope of version 1. Version 1.0 would deliver a server (LDAP with an Installer) and a client (Windows XP and above) which talked to the LDAP server using our API.

 
That made the next challenge was the UI. This is a problem for me as I’m not one for having any design skills at all. However I could have sat down and tediously wire framed every screen and interaction I and my customers wanted.

 
However I knew a better wireframing tool – the IDE we used to write code instead. I sat down and started to craft a UI, using a lot of trial and error. In 7 days, I had a UI which exercised the main aspects of the API and the code base…

 
And that’s how our development stayed, I’d prototype (wireframe with code) a feature and the devs would then go and finish it.

 
We found bugs in the API, sure, but never needed to write new API methods to make the client work.

 
In the final weeks, we just worked on testing and fixing bugs… The test plan you ask? – Well that was the user guide! A full test pass meant running through each page in the user guide and doing everything it said.

 
A recent code review showed there was none of my prototype code left in the platform, but it didn’t matter. We shipped the product and spent less than the $50,000.

 
In conclusion our method was:
·         Speak to your customers. Not lots, all the time!
·         Invest in your method and tools before you hire people, not after you hire people!
·         Make the software function, before you spend time making a UI function.
·         Continuously test, fix and test again and don’t be afraid to throw prototypes away.

 
Last Friday we released version 1.0, go download it, you be the judge of how we did!