Agile, Time and Material

Agile, Time and Material

Scrum and Agile Software Implementation is a relatively new methodology in the professional software design service industry.  Like many outsourced professional projects - whether in the field of construction or architecture - the way a vendor and a client arrive at an agreement on the billing method is the subject of intense debates and endless negotiations.

A Long, Painful - sometimes fun - Journey

As a custom software house, we have gone through tonnes of small, fixed budget projects and some time-based medium size projects before finally arriving at the point where we are now focused purely on large scale time-based professional services.  This was hardly a painless journey - which is why I often wonder why we went through the pain of setting up a professional services company in the very first place. 

Would it have been different if we have focused on building and marketing our own software products all along?  Would we have been as successful as some of the Web 2.0 start-ups we admire if we had just taken a bet and focus on our own software product start-up from Day 1?

Owning a Product versus Professional Services

So... what's the key difference between executing our own projects (being our own product owners) and executing a software implementation for a customer/product owner?

Product Owners are often subject domain experts in their specific field of knowledge - for example, in the specialist field of bioscience, in the field of financial markets, stocks and shares or even in the industry of consumer goods (FMCG) marketing.  Without their specific field of talent and know-how and their "user stories" ("user story" is a Scrum/Agile terminology), our technical expertise does not make much sense.

This implies that as hired guns, our job is to focus on understanding and translating our customer's vision into working software and usable interfaces.

The Problem

In theory, that sounds simple enough.  Communicate with and understand what the Product Owner wants and implement the code formally and express a user workflow, user interface for the end users of the software.

But here's the catch in real life - communication is subject to individual interpretations and understanding; and every individual (Software Guy, UI/UX Designer, Product Manager or Product Owner) has a different world view. Couple this fact with the challenge of fast evolving industry-business landscapes and you have a software implementation disaster in the making.

A project plan or a 40-page long RFP submission seldom survive the first contact with end users.  Software projects that are stewed too long for more than 3 months (based on initial plans and hypotheses) before its first release might be making too many erroneous assumptions about what its end users want and, as a result, be too "over-engineered" for its users.

Such projects with "fixed budget"and "pre-negotiated features" often run into the danger of poor user adoption upon initial roll-out.

Personally, I have heard and seen enough of such massive project failures by word-of-mouth from industry peers and from news reports to understand and know that projects fail not because of "lack of requirements analysis" or "bad project proposals".  They fail because of bad software development methodology and bad customer-software team communication structure.  

Introducing Agile and XP

Agile Software Development focuses on time-based implementation iterations.  This means that instead of waiting for 6 months to release the first version of a software, we focus on releasing a smallest possible unit of an eventually large-scale software in the shortest time possible (a good rule of thumb is between 2 days to maximum of 3 months, depending on what makes most sense to the end users of the software).

Product Owners and Customers work with us on an almost full-time basis, taking at least 30 minutes to 4 hours to communicate with us on a daily basis and provide immediate feedback to our Product Manager and Software Developers directly.  This builds a lot of trust and helps to reduce the misinterpretations and misunderstandings inherent in using the old school "single-point-of-contact" waterfall development which relies too heavily on large stacks of software requirements documentation.

By focusing on flat team hierarchy and clear communication between the Product Owner and the Software/Design Team and by focusing on releasing the software product in short cycles of iterations, we get rapid feedback from the Product Owner's target end users of the software product, tremendously increasing the chance of market and usability success.

Simple Billing, Powerful Collaboration

Without committing to a fixed budget, the Product Owner stays in full control of our quoted time-basis development rates and - being the Subject Matter Expert - retains the prerogative to prioritize exactly which UI/UX and Feature implementation makes sense at any given time.

The Agile Manifesto

To summarise simply, we value:

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

Agile vs Waterfall Project - Theological Tussle?

Is this long debate and discussion about what methodology to employ, which software development team to engage and what billing method to agree on really necessary? 

Product Owners simply just want their software done.  Without all the hassle; and yesterday if possible.

But in my opinion, here's a more interesting and relevant question I would ask:

Can you afford a Software Project Failure?

If you - like us - want to work with and associate yourself with fun, dynamic and intelligent people; if you want a software project success and a professional software team to rely on, drop us a note NOW!  Yesterday if possible! ;)

Share

Category: Communication