Connecting developers with the customer's problem

The holy grail may be that developers engage with their customers but there are plenty of situations where this can be difficult. Sometimes, it is also unclear who the customer is especially when the product is sold to public institutions - is the institution the customer or the members of the public that it serves?

I found many companies still have barriers between the developers and customers. Although they are often working to break these down, institutional change is usually slow. The more people in the way, the more chance the 'why' is lost and the problem is not addressed.

I wanted to come up with a way to connect the developers with the concerns of the customer irrespective of how removed they were. Collaborating with Dan Rushton, we started to think about conversations that would help make that connection.

All the way through this, I had Melissa Perri's excellent phrase 'Problems not features' ringing through my ears. I wanted to expose the problem we were trying to solve for the customer.

We eventually came up with a concept where we imagined the developer overhearing support calls in a call centre. We saw this as the primary interface for many customers with the companies that provided them with services. We also felt that this would be how a company would get most of it's feedback about it's service.

We thought that overhearing the customer explain the problem they were experiencing would provide excellent context for the developer to better understand why we were building something to solve that problem.

Our first thought was to simply role play a conversation but felt that this would not involve the whole team and could make people feel awkward. We wanted it to revolve around a conversation that was focused but also collaborative.

We then started to think of a storyboard that we could create to convey a conversation. Knowing people can be a bit funny about drawing in groups (unless you work with creative types of course who usually ask for more art materials), we came up with the a neat idea that we called a Situation Card.

The Situation Card is a bounded box and contains a single character in the form of a stick man. A simple conversation needs only 2 types of Situation card - one for the customer and one for the call centre member of staff. More complex conversations can use more types of cards - we created ones for people doing surveys, developers working at their workstation, people on their mobile phone etc.

The character is in one corner and has no face allowing the team to add speech bubbles, thought bubbles, facial expressions etc to convey the content of the conversation.

We found A5 was a nice size. Laminating them means you could re-use them. Here is an example of a Situation Card for a person on a mobile phone:

The conversation is told through a series of Situation cards laid out like in a line or columns like a comic book or story board. You can limit the amount of cards so that the conversation is short and concise - you can also refine or refactor pretty easily since cards can be removed and rewritten easily.

The idea is to tell a story and link the problem the customer has with the feature of your product that solves that problem. In telling the story you can use cues like 'If you could hold the line, I just need to check with my manager' to stimulate conversation in the team and check facts or confirm understanding before continuing the conversation.

The conversation can start off as a complaint and then be refactored to a support call, where there is a happy ending since we have the perfect feature to the solve the customers problem. The process of creating the conversation allows the team to better understand the role of the feature. We also think it could be a good way of exploring if a feature does what we think it does, although we have not tried that yet.

In the experiments we have had so far, we found this useful for connecting the problems of the customer with an unseen bit of infrastructure or service which has no interface as such but still has a part to play in the service being provided.

Still a work in progress, I will post up some examples as soon as I can.

Fear and Loathing on LinkedIn

Should you link with your boss on LinkedIn? Yes. It can be great fun.

We all know the signs of the LinkedIn shuffle.

You don't update your profile if everything is going OK.

You tend not to link with half a dozen recruiters in a week for 'fun'.

You don't suddenly get a load of recommendations for no reason.

A devious mind might want to strengthen their position leading up to a review by stacking the odds in their favour.

Update that profile. Accept that request. Have a chat with a few old colleagues about how wonderful you are. Maybe get the wife or girlfriend to call a few times a day for added paranoia.

Enjoy. You never heard it from me.

Reverse Interviews

Interviews are a cruel and unusual punishment. We prepare our knowledge ready for the inevitable questions that we will be asked but have little control over how the conversation will go. I find myself wishing I had said things in a different way or brought up more of my skills where I had the opportunity to.

Recently, I have been using technique which has helped me focus on selling myself and what I am capable of. Essentially, I use a mind map to record my ideal, imaginary interview ahead of the real thing and use that as tool within the interview.

I imagine and role play how the interview would go if everything were going my way. They ask me the right questions, in the right order and my answers are obviously elegant, free of swearing and technically correct. I am awesome in this world!

As I do this, I use a mind map to record what came up in my imaginary interview. I usually do this on the day so I am in the zone and the imaginary interview is in the same context as the real one. I start with the company name and expand out to incorporate areas of the company and finally questions or words that remind me of the thought process I was going through.

Obviously, in the interview things will be different. But I have my map of the things that sell me, so I use it to guide my responses. As we talk about things on my map, I cross them off since I know I repeat myself. I have also found I can guide the conversations to my stuff, which can sometimes help too.

When the inevitable 'have you got any questions' question comes up, the answer is generally a 'you're darned tootin' I have some questions' and I look to cover any missed items on my map. I generally clue the interviewer into what's going on or simply leave them wondering with 'Do you mind if I refer to my notes?'.

This has served me well of late, I hope it helps you too.

Not a profession for old men

So, I am looking around at the moment and I notice something.

There are very few old developers. Lets say 45 - 55 is 'old' - it certainly seems to be for software development. It got me thinking - where do they all go? Assuming that we need to keep working to at least 55 (let's face it, it's going to be more like 70), that leaves a lot of time to do... er, what?

It is a little worrying if you ask me. This is still a young industry but we seem to have chopped a minimum of 10 years off the career path. I tried thinking of other industries that have a similar sort of cut off and not many sprung to mind.

Professional athletes have a physical cut off, although there are the odd few who carry on through to their 40s. Although, golfers seem to carry on into their 50's (my wife insists this does not count since golf is not a 'sport'). Call centre staff seem have a natural cut off in the amount of abuse they can take so they tend to be younger, which is just an observation.

I think a lot of this is down to presumptions. We presume that someone who is older cannot or will not change, but surely this is down to the individual? Some people respond to change and embrace it, others don't - might be more prevalent as you grow older but it is not unique to older people. I often find younger people stubborn to change - so maybe there is a sweet spot?

Work culture has a place too. Although we like to think that companies invest in their staff, it is more likely that they only invest in things they find valuable. So if you are using an old technology at work, you are going to be left far behind in the real world if you need to move on.

Again, this is down to the individual - the real geeks have a love for tech that is in-built. That's not something that just disappears at 40 (hopefully). Waiting to be taught something is a waste of your time. You need to do it yourself. Again, people of all ages fall into this trap, it is not something specific to being old.

Another big assumption is you cannot learn, which is clearly rubbish. This might not be as fast but I would take the incumbent experience over speed any day. When chaos erupts, I would bet the older developers are keeping calm and working through the problem without additional drama.

Maybe our minds just go. Or we can't take another flipping CRUD form, sell everything and live in the woods. Whatever happens you need to prepare for this now, as I cannot see it getting better. If you are entering the profession, think about how long you can keep doing it for. Here are my thoughts:

• Keep you skills up to date - check your CV every few months, if you have not added to it then you are doing something wrong (probably got too comfortable). 
• Keep up! Get interested in what is going on in the industry. Experiment with new languages, play with new systems, services and APIs. 
• Practice - find some way of experimenting that excites you and do that whenever you can. 
• Create and keep a childlike wonder of all things new and interesting. 
• Attend conferences, meetups etc and listen to stories, return the favour and tell a few of your own. 
• Seek to learn from others and don't be afraid to ask for help. 
• Read - everything you can, whenever you can. 
• Differentiate yourself by being awesome to work with. 
• Learn to communicate and collaborate and build this into your day, this is much harder to master than any code you will ever write.

And finally..... Code, Share, Discuss but Sleep, Laugh and Love in equal measure - there's more to life than just coding even if it doesn't feel like it.

Out and About: Agile on the Beach 2014 - Day 1

I spotted this last year and missed out on the early bird so made an extra special effort this year since this is one of the few Agile specific conferences in the UK.

Arriving on the Wednesday night meant a pasty and pint was foisted up on us in the bar, which was very welcome after a 5 hour drive. The subsequent pints chatting with the most excellent Jon Tilt from IBM might have been a slight mistake - but we only really discovered this at the breakfast retrospective. Jon showed us all up at breakfast after a run around Falmouth University campus looking fresh as a daisy.

The keynote this year was J. B. Rainsberger, who gave us a round trip of movements and the future of Agile with specific emphasis on XP. As with any good key note there were points I agreed with and some I didn't but the perspective was most welcome. Obviously a seasoned speaker it was a pleasure to listen to and the hour went fast.

Starting a conference about Agile with talking about the death of the brand i.e. Post Agile might have made some people feel uncomfortable but it embraced the idea that change is good as we learn from our experiences. Also, talking about "confident humility" resonated with me - the attitude we bring with us when we collaborate or pair is all important.

There was some fun too - the simplified planning cards were something I would adopt tomorrow! Can't seem to find a picture of them but there were just 3: Do it, Too F**king Big, No F**king Idea. J.B. wondered if there should be just one more, "I'll do that now"

Agile on the Beach has 4 tracks - Craftmanship, Team, Business and Product (which was a bonus track for this year). Curiously, I did not attend a single Craftmanship session which proved to me how my emphasis has changed over the last few years. People might create but teams deliver.

I started the day listening to Allan Kelly talking about "Does Agile work outside Software". This was more of a decomposition of what value we expect from Agile and if they apply to other types of business. There were some interesting points raised but the examples were the most compelling.

Lonely Planet apparently use SCRUM throughout the organisation - a talk was given at Agile on the Beach 2013 about how their lawyers use it. Pair Programming? Try pair laywering (if that is a word) - a way of building peer review into the creation of legal documents. Same idea applied to different field. They also use stand ups, iterations and retrospectives.

There was more of this throughout the conference - "Agile = consistently identify and seize opportunities" is a concept that can be applied universally. Although some practices are specific to a field, the principles can be applied to many organisations. Interesting stuff.

Next I moved over to the Team track with a talk from Darci Dutcher about fostering collaboration with Designers. This talk resonated with me since I have had challenges getting developers to communicate. It seems that without IM or SMS as a buffer many of them have problems. Even bribes don't seem to work :(

She focused he talk around 3 ideas: Attitude, Skills and Facilitation. I really liked this talk - specifically the point that nobody 'teaches' collaboration. As she pointed out this is not the same as a compromise or what your bosses opinion is. It should be something new, created by the people in the room, each progressing ideas and being creative.

I did manage to ask her about what else we can do with people who just won't dive in. I have an article on some of these thoughts coming up but Jon Tilt had a some insight - "If you can't change the people, change the people" (not something I like to think about since I like the people I work with)

Talking about Jon... I have seen Jon before at Hursley talking about how IBM started to use Agile. The thing like about Jon's talks is that the challenges IBM face are way larger than pretty much anything anyone else is talking about.

Fancy getting about 30,000 developers across 20 countries and 80 locations on the same page? These developers also work on radically different products (through many acquisitions) and have completely different cultures. Where do you start? So, the title "Making the Elephant Dance" is apt.

Jon is also a great speaker, so this was fun too. My take away from this was their use of Confidence Maps to allow quick visual representations of a projects current status - even the attendees could pick out the project in trouble from the example.

So after a quick bit of lunch (nothing special, sadly - I was spoiled at Re:Develop!) I arrived a little late to see Melissa Perri from produxlabs.com talk about Lean Product Management. It was crammed - the Software track had the smallest room by far and this session proved most excellent, even though I was on the floor in the isle with half the room.

Melissa is an awesome speaker - fast but easy to understand. Her point about moving your focus to the problem is something I have long believed in too. I specifically liked the alternative structure to user stories that she suggested:

When <situation>
I want to <action>
So I can <outcome>

The shift of emphasis to make the problem the topic of conversation is similar to other alternative templates suggested for feature injection. I think I prefer this one however, especially when it is backed up with "Explore problems rather than gather requirements". I think that the phrase 'Problems not Features' could be a bumper sticker. Maybe a tattoo?

There was a nice comparison between a 'normal' Product Manager and Lean Product Manager - essentially that they work to a Goal. She put emphasis on experimenting not developing, proving you are moving the right direction and working with the whole team to produce results. She asked us "What does success look like?". It made me wonder if I was doing the wrong job.... this looked much like what I enjoy doing!

There was more (much more). Her take on an alternative to road maps is something I want to look into. She also wins the newly created conference award for most amount of amusing cat slides - well done you :)

Back on the business track was Frances Bonnington with a talk about the application of SCRUM is a non-engineering industry. Frances was a newly qualified ScrumMaster at this time and this was almost a trial of fire as she took us through a very honest look at what worked and did not work. It all had a happy ending, however when she took charge of some geeks as ScrumMaster. I like happy endings.

Having learned that Melissa's talks are usually rammed, I was early for her last session called "Beyond Pretty: Creating Measurable Designs". I even had a desk so I could write a bit more legibly, go me!

She kicked off with decomposing 'design' - being a mix of Visual Design (What it looks like), Information Architecture (How information is composed on the page), UI Design (How we interact with the design), UX Design (Can users achieve their goal?) and finally Marketing Design (Does it sell the message?).

She posed the question if any one person can achieve all these things, using the phrase 'the unicorn designer'..... makes me think of how I feel about the phrase 'Full Stack Developers' for exactly the same reason.

The talk was about measuring design, which started with a quote:

What cannot be defined, cannot be measured;
When cannot be measured cannot be managed.
- Paul Lillrank

The 'normal' linear approach (IDEA -> Research -> Wireframe -> Build -> Launch!) makes to many assumptions on what is a set of decision. Instead, treat the design as a hypothesis and treat this as a cycle allowing you to test the hypothesis. We only launch once we have solved the customers problem.

She explained there are 2 types of measurement: Quantitive and Qualitiative.

Quantitive is useful for spotting trends and we can measure them against KPIs but it won't tell you why. Lots of tools to do this for you!
Qualitative is about observing behaviour and finding meaning.

Measurable design calls on both of these to prove if your solution is working.

There was a bit of cross over with her previous talk and that was a good thing. The ideas of iterative learning makes a lot of sense and she made a good point that you should only make small changes so you can monitor the outcome. If the change is too large, how do you know what delivered the impact you are looking for?

And there were more cats.

Finally, we ended the day with some flash talks. The highlight for me was a 5 minute talk on certifications and if they are good or bad. The suggestion was for a new certification, a CSSTWP:

Certified Stealing Sh*t That Works Practitioner

Awesome! The stickers were late apparently, which is a shame because I think I would prefer this one over anything else I have seen.

Also of interest was mutation testing. How do you know if your unit tests are working or any good? Well, how about injecting errors and running your unit tests again? Didn't sound like there was much in the way of tooling but I do like the idea.

A conference would not have been a conference without a bit of a party, hosted by IBM. At 6pm we all tottered off to the local beach for a few drinks and some food. They don't call it Agile on the Beach for nothing - by the way, organisers pay attention, it would be much easier to get corporate sponsorship if the name was different :)

No UX for you!

A few years ago, a designer friend said that we should load a different UI for older browsers. He wanted to make it look horrible and have the bare minimum functionality that we could get away with.

At the time, we basically ignored him and put it down to too much beer the night before. It turns out he might have been on to something, if this is anything to go by:

http://www.theregister.co.uk/2014/08/31/google_search_browser_support/

Guess this just goes to prove how important the user experience is. His notion that a terrible user experience would force people to move or upgrade might have been a stroke of genius. Lets face it, nothing else seems to have worked!

Not that disruptive, maybe

We have seen the rise of start ups in the last few years, challenging existing and much larger companies for a slice of their marketplace. 

The speed at which start ups can move is predominantly down to their size, which their larger competitors can rarely match. Other areas of difference are much more difficult to measure but culture and creativity would be in there too.

Given start ups are a threat, the obvious way to eliminate them would be to buy them. There will probably be a price point where this becomes attractive, especially to any investors in the start up. 

If the motivation of the investor is to make money then this seems to achieve the goal, as long as the price and timing is right.

It could even be a strategy of a start up to be bought out, essentially making a nuisance of itself and forcing a competitors hand. 

Maybe larger companies should see start ups as a form of R&D? Start ups innovate quickly, test the market and show a direction for the larger company to exploit. They even come with customers rather than just a bunch of patents.

So, I'm not sold on the word 'disruptive'. Start ups seem to stimulate rather than disrupt.

The 'Lean' Oven

A while ago, I started a project to build an outdoor kitchen complete with a wood fired oven. It has been a completely frivolous adventure which has kept me busy over the summer. The whole driver for this was the wood fired oven (and the need to build things, obviously).

When I came to the point where I wanted to fit the oven, I kinda stalled. You should know that these things are really expensive, the cheapest was around £500 the most expensive around £1000. I had planned to have a small one since I figured I would only use it a couple of times a year.

It was this thought that made me realise that I was not thinking clearly about the value, or perceived value it would bring me. I had bought into buying the oven because I wanted an oven and that is as far as it went.

So, I started to think how I could test if having an oven would be as valuable as I thought it would be?

So, I found some guides on building a clay oven. This made more sense - it was less money, I could fit it into the space I had created already and it looked fun to do.

Most of guides said how they had 'dug up some free clay' which obviously makes this sort of caper much more attractive. Not much of that around here, so it would be a cost. I found a local company selling clay, the cheapest was around £6 for 12 kgs. A rough calculation suggested I might need about 5-7 bags. This is mixed with sand which is easy to get hold of and relatively cheap so I ignored that for the time being.

It also had a hidden cost in the floor should probably be made using firebricks. It doesn't have to be but if normal bricks crack from the heat then I would loose my entire investment. I would need 15 for my base and they cost about £4 each locally. I can get them cheaper on the Internet but the postage offsets this so much that it probably is not worth it.

This would give me the option to keep it if it worked, which is a fair presumption since I would probably be following instructions from someone else rather than making it up as we go along. So, to test this idea with the option of keeping it would be around £100 - significantly cheaper than buying one that's for certain.

My thinking was a little clearer now. As great as this was sounding, it's still limiting my options and carries significant risk too. It was certainly a do or die operation - if it worked then awesome but if not I would only have a base and a whole load of clay to get rid of.

Then I saw this....

Yes, it's a fire back. I removed some from my house a while back and put them to one side since they are heavy.

I saw an oven however and with some bricks I had laying around I quickly bodged something that 'looks' like an oven:

But does it behave like an oven? The guides all have a ratio between the height of the oven and the height of the opening. You need enough to ensure a good airflow from the bottom to the stoke the fire. Let's test what we have and get some feedback to see if we need to tweak our design or if this is a non-starter.

It lights and keeps going at a steady pace, it never roars but the wood is questionable and probably damp. I stick a BBQ thermometer and just leave it for a while, monitoring the temp every now and again.

The max temp the oven reached was about 150 deg C. Way short of the 600 you would expect from a 'real' oven but this was with dodgy wood and zero insulation, which is key to getting the temperature up and holding it. Whilst it was going, a lot of smoke come out of cracks and gaps. I solved this by simply packing them with some damp sand, which worked a treat and was nicely temporary as well.

What I also observed when I lit the fire was how the smoke came out of the front, which looked like it was causing a bottleneck. I also noted that the heat losses where significant since it got really hot, so insulation would certainly play a part in how well this works for actually cooking things.

So a further improvement would be to create a chimney just after the dip with a column to funnel the hot air up and out a little easier and hopefully improve draw. This is a one time shot since I would have to cut the fire back but I happen to have a spare so this is not as bad as it sounds. If I ruin it then I still have this one as a backup - so I still have options. If I break the first one I would need to be clear on my commitment since if I break the second one too, I have no more options with my current experiment.

Before I do that, however I could try to insulate it and make sure I can get higher temps. Just a covering of sand would probably help, maybe with an oven fire blanket too which has pretty good insulation value. Using some decent wood would be more representative and pretty low cost (or zero cost if my neighbour lends me some from his wood pile).

This is still a work in progress but it is the thought process that I thought was interesting. I was unsure what value my 'feature' would provide me so I wanted to test it and get feedback. I looked around to see what I had that could get me feedback as fast as possible. I then review what I now know and see if it fits with what I thought. I learn from it, tweak it and iterate to get more feedback.

I still have to prove that the oven will provide me with 'value' a.k.a yummy pizza - but a pile of wood and a few friends will answer that. So my BBQ 'showcase' will get me buy in to create a production version of my prototype.

CV.alt

I hate my CV. I know it contains what agents want to see but I don't think it represents 'me'.

So here is me playing around, maybe I should just send it and see what happens :)

Here is a link to a larger version

Christmas cards for your competition?

The Internet has thrown up some very counter intuitive business models in the last few years. In time, some of these could well be shown to be daft but for the time being they are on the cutting edge of business.

Conventional wisdom would suggest that having no competitors would be an advantage but in a market place as large as the Internet I think you need competition to ensure any sort of customer base.

Imagine a start up with an innovative idea. There is no established sector but there is potential to attract them, probably from other sectors that are related. Or maybe an established company with a niche product that needs to attract new customers to ensure growth or stability.

This is where competition comes in handy. Although you are all after the same customers, you are all marketing and drawing people to the same sector which advertises both you, your sector and potentially your competitors. So, you win some sales, you loose some sales - but you do stand a greater chance of getting them with competitors doing the same.

Different marketing strategies will target different people and conversions are not always obvious or guaranteed. So once the sector is discovered, customers will often look for competitors to secure the best service and/or price.

I would go as far as saying that entering a completely new sector would actually benefit from competition, so why not create some? You could open source your product and actively encourage people to provide a competing service to stimulate the sector.

Competition ultimately fosters innovation. Each company will be looking at their competition, assessing their products and comparing with their own. This basically creates a feedback loop, where we can reflect on what works and what doesn't work and plan what to do next. We get some new ideas from this new perspective, which starts the loop again from our customers perspective.

Our competitors also push us to iterate ideas faster, to forge better relationships and basically be better than them to ensure we get and retain our customers. All good things, if you ask me.

Complacency is too easy to fall into if we have no need to change. Competition forces us to look for value and act. Our competitors should be considered a mirror - what can we learn about ourselves by looking carefully at what they are doing?

After I wrote this thought process down, I found some other people with the similar points:

http://www.forbes.com/pictures/fgdi45eekll/5-reasons-why-competition-is-good-for-your-business-2/
http://www.shaunrosenberg.com/10-reasons-why-competition-is-a-good-thing

How nice to feel wanted

On returning from a conference, I was greeted by my daughter who flung her arms around me and said:

"I missed you Daddy!"

Aww. So, I asked her:

"What did you miss most? The hugs, the kisses or the cuddles?"

"Your password to the tablet" was her honest response.

Winner, Winner, Chicken Dinner: Azure Recommendation

In 2013 I won a competition to go to TechEd. I have since killed the blog it was on - here is the winning blog entry republished from http://thecodechimp.blogspot.co.uk/2013/03/teched-azure-recommendation.html Enjoy!

Yo Boss!

Sorry for the unproffessional start to this email but over the years I feel we have come closer.... the server crash of 2010, the staging server version snuaffu of 2011, the disk error nightmare of 2012 - good times! As a developer I feel I need to be frank with you - our relationship needs to change. Not mine and yours! The relationship with our hosting setup...

I know it will be difficult. Those new boxes we get every year are fun to open, aren’t they? I love the smell of new servers in the morning....  What I don’t love is the ensuing build, re-build, testing, fixing, patching and endless hours of investigation that go with each glorious box that we open. I’m not sure that men spending this much time together, alone, late into the night is a good thing.

I am a simple man, ask my wife - I just want to develop. Your specs are complicated enough, I really don’t need any extra challenges. I want to do this for you at lightspeed.... Speed Of Light Development, a fitting acronym given you have probably already SOLD whatever we are developing.

Jeff doesn’t work at light speed. Jeff? You know Jeff.... or “The Server  Guy” if you prefer. I know Jeff well.... I think he would be my Best Man, if I ever got married again. You see, whenever I need a new environment or virtual machine I need to talk to Jeff. This happens a lot - and Jeff is really Support. Yeah, I know multi roles are great but  honestly, I think Jeff is just looking everything up on the Internet.... I’m fall guy when everything goes wrong, which sucks.

It doesn’t have to be this way. You have already made one decision that will help enormously - we develop our products in Microsoft .NET. Yeah, I know you are a bit fuzzy on what that means but trust me, its a good thing. And guess what? It could be so much better. Seriously, all it takes is to embrace uncertainty.

Yup, uncertainty. We could be BFFs. You see, when you are coming up with a product you simply don’t know how popular that will be. It is difficult to design a web application that will work the same for 10 people as it will with 100,000 people. Its difficult to plan for something that is uncertain. You need to be able to react - to come up with a plan and know you can deliver it.

This is not something you need to worry about, that’s our job - all we ask is you give us the tools. Give us Microsoft Azure and keep the ideas  coming. Let’s ditch the hardware headaches and simply focus on delivering more product to more customers.

Microsoft Azure will change the way we conceive of products and they way we put them together. It will change the way we do business, if you embrace it. Our tools already integrate seamlessly with this new world, all we have to do is press the button. Literally.

Need a staging environment for your new super-important client? We can create a new environment on demand in minutes. We can deploy directly from our existing development environments and we can integrate our existing source control system to continuously deliver software, again all in minutes. We can take that staging platform and promote it to production, no fuss, no downtime, no problem. All this we can do without  writing a line of code or playing with a single config file. And we did not have to talk to Jeff, which is definitely a bonus.

Our development environment will have a new suite of tools and services ready and waiting for us to exploit on your behalf. We can scale up and out immediately but more importantly we can start to design applications  that are designed to scale from their inception and tune them accordingly. We can concentrate on delivering what you want to sell and fluidly adapt to your business requirements, growing organically without  the current drama.

I know you have different concerns. Security, trust, support, costs etc and rightly so. Microsoft Azure was built by the guys who designed the software we already run our business on. We might have a great relationship with our hosts but from a regulatory perspective, we don’t come close to what we should be doing. Would you prefer that security of  our customers data was managed by the company which actually designed the entire software stack or er, Jeff?

By using Microsoft Azure we are sitting on top of a secured, patched, certified platform which is universal across all our deployments - development, staging or production. The costs are based on what we use and we can scale in real time according to how our customers use our products. Once we know our requirements we can purchase upfront and realise double digit savings on the monthly costs (which I know will be more important to you than some of the other stuff)

Jeff will be happy too. We can purchase support direct from Microsoft - which can also scale - meaning he is backed up by certified professionals who know their own environment inside out. And I won’t be answering phone calls at midnight on a Friday, which is handy. Jeff will  have a array of diagnostics allow him to monitor your business and keep everyone happy as well as give us the information we need to refine our products further.

And this is just the beginning. When your finally decide how you want to  take our product worldwide, we can deploy to a number of worldwide locations and use content delivery services to ensure that our content travels the shortest distance possible to all your new customers. We can  develop applications for mobile or tablets all backed by services on Microsoft Azure. With the vast amounts of data we will accumulate we can  start to mine data with Azure’s Business Intelligence tools to give you all those pretty graphs you love to see.

The future looks great too. Microsoft are supporting development communities and encouraging us to join in. Many of the libraries we already use are backed and many contributed to by Microsoft. And they actually want to know what we think so they can make Azure even better.

Actually, moving to Microsoft Azure will ultimately affect our relationship. I will see you a lot less. Not only because I will be busy but because I really don’t need to be in the office anymore. Microsoft Azure allows us to manage our business when and where we want - I suggest we start with Tahiti. I’m mentally there already, are you going to join me?

The Dev Guy

Out and About: re:develop 2014, Bournemouth

This was a new 1 day conference this year that I heard about through a Microsoft mailer. I was late to the party so missed the very reasonable early bird pricing but was treated to a ticket by my wife for my birthday.

I like conferences. I won an all expenses paid ticket to TechEd 2013 and have decided to get to at least 2 a year since that experience, which was awesome. This is my second this year, being followed up with Agile on the Beach in Plymouth in September.

Personally, conferences can show you what you should be looking at next. They are usually a mix of stuff that you want to know more about and stuff that you should be paying attention to.

Re:develop 2014 was a nice mix and was pretty slick - they guys from Base did a really good job of keeping everything running and looking after everyone. The food was excellent and they made sure there were snacks and refreshments galore - it might seem like a weird thing to say first but the quality of catering goes a long way and seems to stick in peoples minds for some reason.

This is the first year, so I expect it will be even better next year (and hopefully the same price).

The day kicked off with a session from Tom Byers, who is a Lead Front end developer for GOV.UK. He basically went through 10 things he has learnt from his experience on the GOV.UK projects. Of specific interest was how design is a Tool, talking us through what they have learnt about how people read content using eye tracking and how different layouts affected how people accessed the info they needed.

Tom also explained how much effort they put into the actual content. There was also some great material on making forms easy to use, which was really interesting (including a very painful video showing how it can all go wrong!).

What you should be interested in is what GOV.UK have open sourced and written about various aspects of UX, here are a few that I jotted down:
https://github.com/alphagov
https://www.gov.uk/service-manual/user-centred-design/how-users-read.html
https://www.gov.uk/design-principles

Paul Davis from the Ghost Foundation followed up with a off the wall look at what it is like to work at Ghost. This was a great insight and maybe hinted at a trend that we will see more of in the future. Ghost work 100% remote - their way of putting it is "Our headquarters is the internet. If you have a wifi connection, we have an office near you.".

Paul revealed the pro's and con's of this style of working with flair and humour. Rather than a polished sales pitch, we got a guy who explained why he loved what he did and who he worked with - should we all be so lucky. Very cool and definitely the subject of most my thoughts on the way home. Check out Ghost for all your blogging needs:
https://ghost.org/

Ben Howdle was a web developer but has since turned to the dark arts and become an iOS developer. This was a pretty code heavy intro into what is similar, what is kind of the same and what is just plain old odd about iOS development. I was really happy to see someone doing this as Objective-C has never been something that made much sense from all the articles, quick starts and blogs that I have read.You can read about his experience in this shift writing an iOS app:
http://benhowdle.im/2014/04/24/ios-for-web-developers-building-permeate/

Secretly, Liz Keogh was the reason why I had to go to redevelop, being a long time fan of her thoughts on BDD. It seemed effortless - taking us through BDD and Cynefin in under an hour. It was definitely too short, I could have listened to her all day. It was the little details that resonated with me. I am no stranger to BDD or Agile but sometimes a specific sentence makes you sit back and reflect on your own experiences. Liz provided me with several of these. Maybe I should start some sort of fan club? Does she sign things? A photo for my desk would be nice.... more awesomeness here:
http://lizkeogh.com/

The boys from the Guardian where not what I expected. Between Kaelig taking us through breaking down the boundaries between developers and designers and Patrick Hamann taking us through how they use continuous deployment there was a load of information to digest. To be honest, I'm still going through the things they raised and will be for a while.

For me the take away thought was about how short cycles mean faster feedback. 2 weeks is too long for these guys, who like to think in terms of what can be put into production today. Some numbers that blew my mind were 10,000 production deployments a year, 7,000 unique types of device using their service and 8 minutes to deploy. I wish I had counted but the amount of monitoring these guys use is amazing - there must have been about 7 different dashboards in use.

They have open sourced a load of stuff along with their deployment tool, Riff-Raff:
https://github.com/guardian

Phil Bennett from the Carswell Gould agency gave us a comic walk through of a project through to deadline, which he described as Panic Driven Development. He emphasised how no one tool or technique will help absolutely, you need to be flexible to deal with the different types of customers and projects you are dealing with. Interesting perspective and certainly explains the differences I have noticed in ex-agency staff once they leave agencies....

Richard Evans works for a company called WDS, where he works on AI within their R&D team. This was a really interesting intro to AI and it's increasing prevalence. His demo's show AI actors responding to social situations, which you could alter and effect by being an actor along side the other AI actors. He explained how the AI engine worked and how each actor is described in a language designed by Richard for this explicit task. Richard made this funny and easy to grasp, which was really good. This sort of AI is being used in customer service to help people find the content or department that will help them.

Ross Tuck was fantastic. This was a non-technical talk on advice - essentially advice on advice called "Things I believe now I'm old". Ross might have a funny accent but don't let that put you off, his delivery was slick, thought provoking and funny. This is one of those talks that you have to see - he is based in Netherlands so I consider myself very lucky! Check out his whereabouts here:
http://rosstuck.com/

Throughout the day several themes re-occurred - these would be my takeaways:

Conversation - this was a theme that was revisited by several of the speakers. Liz hammered home the use of conversation in BDD above and before documentation and tooling and the boys from Guardian talked about the use of common language between their developers and designers. The AI examples we were shown revolved around conversation too, although the focus was on the social interactions within the conversations.

Feedback - "Assume you are wrong" (Liz), get feedback and iterate - do this as fast as you can. "Don't be afraid to break things" (Patrick), monitor, isolate, fix and repeat. We should be used to iterations - how often are we breaking down work based on the technicalities rather than the need to validate what we are doing?

Openness and Trust  - lots of speakers showed how they had benefited from open sourcing their tools and designs. Both Ghost and The Guardian thrive on trusting their teams which helps them buy into what they are delivering. The guys at Ghost seem to do everything, all the time 24 hours a day and are trusted to just get on with it. The Guardian have developed a culture where their developers are also DevOps and put things directly into production many times a day. Ghost also open their business to their employees - do you know how much your employer has in the bank? How about what they are spending each month? Food for thought.

Definately one I would go to again - any chance of a mailing list so I don't forget? It was the only thing missing :)

What do your customers know anyway?

Agile undoubtedly changes how we engage with our customer. The customer is centre stage to all our efforts.

For any organisation that has kept their customers at arms length, this is a scary prospect. It is highly likely that customers are more hostile than helpful in this scenario.

Involving customers in the development process is not an easy thing to achieve. I have even heard it said that it cannot be done for various reasons. This typically reduces customer involvement to demands made during sale or contract renewal - which are both driven by sales people.

At this point, we are clearly in panic mode as our number one concern is to protect revenue. This is typically where good product design is the last consideration and the product is polluted with some pretty badly designed features.

This is not the customer engagement we need. If it were left to the customer they would have the 'Do It' button that basically performs their specific function. The customer does not know best when it comes to product design - you do. That is what you bring to the party.

Just because your existing customers will put up with a naff experience don't forget that new customers might not be so forgiving. A poor user experience will ultimately affect your ability to attract new customers - they have zero investment in you and will simply move on.

Getting involvement with your customer as a standard part of your development process will radically shake up how you work as a business. Listening to your customer is where the agility that you are looking for will come from.

Our engagement with the customer should focus on one thing - what is the problem we are trying to solve for them. By concentrating on the high level behaviours they are looking for, we get to solve that problem for them. That uses our formidable skills as software developers to their full extent.

The customer does not know what they want. They know what problem they need solving. Once we know that, we can create software that is truly useful.

Just like you would not trust anyone to pass on a really important message, getting the customer to explain the problem to the people who will do the work is the holy grail. The more people you have in the way, the less likely we will solve the customers problem. Diluting their message through a chain of dialogues that are each biased is a waste of everyone's time.

If you can do all this, then you only need a team who can guide conversations with your customer to fully appreciate what problem the customer wants to solve.... and we all have one of those, right?

What does that mean?!!!

I hate three letter acronymns.

I think they represent a past that we have hopefully left far behind. They obscure conversation and serve only to make people think they sound intelligent. Unless you are a part of the club, their meaning can often be shrouded in mystery.

Over the years I have witnessed a massive change in the type of person who has ended up being involved in IT. I can still remember when it was unthinkable that anyone without a degree in comp sci could write software.

As the Internet gave everyone a new platform to write software for, the tools became more approachable and now everyone is invited to the party. This has been the single greatest change in IT and has brought about a new generation of conversable developers.

I will credit Dan Rushton with this phrase, it's a good one. He also bagged the domain where you can check out his ramblings.

I like to think that we can solve all the technical problems that are thrown at us. The bit we are missing is understanding what it is we are actually developing. It should be easy, right?

The idea that a specification can detail everything is frankly insane. If it could, it would likely be unreadable. The future is through the oldest of all forms of communication - conversation.

Conversations are the corner stone of agile software development. Nothing allows a team to convey ideas and gain understanding faster than conversation. If there is a problem, you can guarantee that a conversation will enable people to get to the bottom of it. If it's important, you pick up the phone and talk about it. Conversation is a natural instinct.

Although business value is pinned as what we are trying to uncover, I cannot see how this happens without good communication. Good conversations enable us to uncover value at all levels of the organisation. It is the unseen foundation for all agile principles.

As a developer, communication transcends all other issues. It is key to the success of my code and the organisation I work for. So, I write about my adventures whenever I can. Enjoy :)