Distributed Development : Avoiding The Fog

I've written about the challenges of distributed development as have many others, so I'm not going to bore you with another spin on the types of problems which crop up and new and improved ways of fixing them. What I am going to do is make a controversial statement and then try and pull a Houdini and explain myself out of it.

Communication can make for an opaque development process.

Ok, here I go.

Can User Stories be used in Waterfall Development?

If you work in the business of software development you most likely have come across User Stories. If you aren’t familiar with them, or are all of a sudden being asked to write them or deliver them and aren’t quite sure what they are, here is a brief background.

User Stories are born from Extreme Programming (XP) and Agile Development Methodologies. XP and Agile development is essentially a set of principles and practices which have emerged over the years (XP was first coined in 1999) to address with the challenges of software development and fulfill a goal of delivering working software as early as possible.

User Stories fit mainly into the requirements gathering and definition phase of software development. They are Agile’s answer to transforming what is often an onerous, expensive, confusing, obscure and inefficient process to one that is lightweight and effective, and drives the software development process towards delivering valuable software features early.

Like many other aspects of Agile Development, User Stories are becoming adopted as an industry standard way of describing software requirements.

The benefits behind writing requirements in this way include:

• Writing requirements as User Stories makes them easy to understand i.e. they eliminate technical or domain jargon 
• Writing requirements as User Stories helps validate their value to the users of the application 
• User Stories can be delivered independently and in short iterations, allowing the ROI from working software to be realised earlier 

However, because User Stories are being appropriated by different organisations who deliver software in less agile and more waterfall ways (wagile, scrumafall, etc) and don’t have all the other Agile practices in place, there is often confusion around what a User Story is and how they can be used to describe, specify and deliver a solution.

In my experience, this is often the case where an Agency or Software House (Delivery Partner) is tasked to define, cost and deliver a new build for a Client.

In this scenario, the following constraints often apply:

• The Client has a maximum budget to get the solution built 
• The Client has a massive wish list of requirements 
• The list of requirements exceed the budget
• The Client wants to know what they are going to get for their budget at the beginning of the project 

Given this starting position, the Delivery Partner has the challenge of defining and delivering a solution which has as many of the items from the wishlist within the budget constraint. So faced with this challenge, can User Stories be used to define and cost a fix priced build?

The short answer, I put forward, is yes with a caveat that User Stories go through the following steps to turn them into a scope of work that can be delivered within a budget.

The Devil of Distributed Development

There is gold in them thar hills!

Over the last six months, I have been working on a model for distributed, Agile Scrum development. This has been in response to on-going issues on software projects where development (front end, back-end and testing) is done in an offshore office. The issues have been around areas such as relationships, quality, communication, profitability and client satisfaction.

In addition to these common trouble hotspots, I work in a creative led Digital Agency which, due to the nature of the beast, presents even more challenges around establishing dedicated teams with the right skill-sets, consistent delivery methodologies, adhering to best practices and educating internal and external stakeholders into rationale behind them.  The last point around education is probably the biggest overarching challenge since if everyone knew what the right thing was to do, they would do it.

The best example of an education challenge is explaining the tax of distributed development. From a financial person's perspective distributed development is a no brainer.

"What? You mean one expensive onshore developer can fund almost five cheap offshore developers. These margins are massive! Well get on the phone to any country with a slightly f*cked economy and round up developers. Ideally it should be a country that has been oppressed by a communist regime guaranteeing optimal economic exploitation combined with a decent level of education. Yeehaaa! There is gold in them thar hills!" said fictitious Financial Person.

The most important part of Agile is education. Ongoing education.

Agile is a widely adopted methodology across the software devevlopment industry. The two main frameworks of Agile are Scrum and Kanban, both similar variants to each other but which both address the same set of problems with software traditional waterfall development, such as slower and more problematic delivery.

They address these problems through more collaboration across disciplines to ensure decisions are made with all relevant viewpoints taken into account, more frequent release cycles to ensure early exposure of the product to the client and the ability to adapt and change course where necessary, and a commercial structure that understands the reality of complex, software development with many integration points by agreeing to either fixed price or fixed scope, but not both.

A pragmatist’s view: What is Technical Architecture and how do you do it?

As a Technical Architect in a digital agency I am often am asked what the role actually means or does. This question comes from everyone including Technical Architects (TAs) and one that is actually quite difficult to answer. The reason for this is that the definition of Technical Architecture in the real world has a very broad scope and is different in different companies, projects and from person to person. It is often becomes a religious argument what being a TA means or what the best way of doing it is. Forgetting best practices, patterns, methodologies, techniques and opinions just for a minute, here a broad view ‘what’ a Technical Architect does and ‘how’ they do it. I'll even look at why in some cases. I'll leave where and who up to you.

Building a Cloud Platform: Weapons of War

I've just returned home from a big development build. For the last five months we've been in a secret room racing to get version 1.0 of a cumulonimbus size cloud project out. It wasn't easy. Getting to 1.0 was a real battle because... well, you don't know! Because you weren't there... man!

Now that I am back on civilian soil and fighting off night terrors from the horrors of war, I can reflect on what went well and what when badly. This could be a book in its own right; but for this post I'm going to cover The Weapons of War - or the essential tools needed when building any product or platoon... I mean platform.

What defines a successful project?

Single Fist Pump!

A colleague asked me over coffee, “What do you do?” I sipped my full fat cappuccino and reflected on the question. Sipping coffee and reflecting go well together so I may have milked the situation a bit more than was required. 

“Hello!” he interrupted. “Did you hear me?”

It was a good question erring on the side of existential and difficult to sum up in a tweet sized thought bite. 

For a bit of context, I have a technical leadership role which can mean many things to many people - including other people in technical leadership roles. I had to dig deep and try find an answer that came from my heart and wasn’t ripped off from the Steve Jobs Autobiography. 

“To make sure we deliver projects... successfully.” I said with the thousand yard stare of a visionary. 

“To deliver projects?” he smirked. “Truly inspirational.”

Avoiding the pitfalls of joint Web Site and Web Service development

How to turn a Balrog into a puppy dog.

Developing web and device applications these days is more often than not dependant on 3rd party web services. This integration is one of the biggest culprits behind projects being delivered late and costing more than expected. I’m not talking about fully developed and functioning web services, of course; but web services developed in tandem with the web site. There are a number of reasons why developing web sites and dependant web services together can cause severe delays in and over-spends in project.

Cherish the Small Stuff

Confucius say:

 You can stand with your back to the sea and shoot fish in a barrel, but you ignoring the giant shark which eat people and boats.

Okay, Confucius wasn't around at the time when Jaws graced the big screen. But if he was and he worked on technology projects then he would have said something like that. Probably.

What this pearl of wisdom means in real terms is this. If you are working on a big project and you need to reduce timescales, axing the simple stuff is not only ineffectual but will ultimately be to the detriment of whatever you produce.

The Yellow Brick Build: A project methodology

Thunder! Thunder! Thund! Thu.n.de.? 

In the world of project management methodologies there is a limited set of models we as a delivery team are asked to subscribe to. And once we do, often is the case where the project becomes a never ending battle between the theory and the reality. The best proposition for describing projects came from my old boss.

To quote:

"F*ck 'agile' and 'waterfall' - the new labels for project management are as follows: 'car crash' (small projects), 'train wreck' (medium sized projects), and 'airplane disaster' (large-scale projects)"