Business Savvy Software

I love developing software because its possible to create something of value from simply an idea in your head.  

Over the past few months, I’ve been talking to a number of people who are using agile or want to use it to build better software products. There are a lot of people using “agile” as a wild-card to implement rigid processes which often feel counter-intuitive to the goal.  

If I’ve learned two things about being Agile, its to focus on people over process and to take the agile toolset and apply these precepts over (not instead of) the existing precepts of building a good team with the right culture and leadership and using good software engineer principals.

My next four posts are a look at the bigger product lifecycle, within which sits the software development lifecycle.  The purpose isn’t to say this is the way or the best way, but to give an example of how Agile principals can be achieved in a design-led environment where the business wants a predictability. 

When you read this, keep in mind that its always about people over process so a lot of what I describe are just precepts upon which we discuss and plan the product development.  We are also trying new things all the time which keeps it interesting.  

Solving the Right Problems

Developing a product is as much about the bits that come before and after the software development.  Identifying problems, finding a solution that resonates with people, understanding the difference between buyers and users, then building it and finding the right messaging to get it into the hands of people who will spread the word.  Its so much fun and can have such a big impact on people when its done right.

Identifying the right solution to the right problem is often overlooked and when we do get this bit right (read Tuned In to learn about getting this right) – how do you build and deliver it better, faster, cheaper?  

I don’t care much for repeatable processes that get followed religously.  What’s more important is having the right people on your team, then equipping them to work to their strengths.  Process is important though because it gives us the framework for being creative.

So, lets have a look at the bit in the middle of ‘problem’ and ’solution’

To solve the problem, we kick off a project which will include some design, some development, some testing and some deployment.  This is where the debate on software methodology comes in – some people like to iterate the whole process, some like to iterate the development and testing, some like to iterate the design and some like to deliver the whole lot at once.

How you do it largely depends on the people in your team (which will hopefully be defined by the needs of your product).  If the developers are designing the app and talking to users then you can have very small iterations over the whole lot.  If you have highly structured requirements or your developers don’t have much domain knowledge, then you may iterate over the development and testing within a big project, or just deliver the lot within a small project. 

At Xero, we’re design-led, which means we iterate many times over the design (for a single project – not the whole app), then build and test in one hit.  While iterating over the design, it will be reviewed by developers, testers, users, customer care, sales people and generally anyone who has an interest.

With applications that are delivered online (which can include installed apps too), release cycles can be daily, weekly or monthly.  At Xero, we aim for about a month, but are flexible depending on what we’re working on.

Having regular releases is a great way of getting software in the hands of users and then using their  feedback to improve and extend the product.  This is also a main principal of agile to build-show-build-show and whether you iterate like this over the design or the software itself, the important thing is to involve users in the process.  At Xero, we iterate over both and I’ll discuss this more in part 2.

Life would be easy if we only had to think about one project at a time, but we usually have 10-20 projects in the works at any time and another 20-50 queued, so the prioritisation and dependencies between these is an important factor.  There are two things to look at here: the scope and the roadmap which are the topics of parts 2 and 3.

Read the whole series 
Product Lifecycle: Part 1 – solving problems
Product Lifecycle: Part 2 – scope
Product Lifecycle: Part 3 – the roadmap
Product Lifecycle: Part 4 – delivering