Battling Against Time

When developing software there are many pressures that play a role in the final outcome.

The biggest of these pressures by far is time, anyone who has ever been involved in a software project will recognise that initial inward drawing of breath when the release date is first vocalised.

I'm not about to attempt to argue that these deadlines shouldn't exist, that simply isn't the real world. Product needs to be delivered to end users and this cannot be after their need has passed or after someone else has already provided value.

What I am going to argue is that these deadlines need to be based on input from the whole team and be based on not just delivering software on time but delivering value.

Viable Product

A fundamental part of an Agile approach is Minimum Viable Product (MVP), unfortunately it is also greatly misunderstood.

MVP is not simply a measurement of scope for a release, it is instead a measure of value that will delivered to users.

Their are many factors that go into deciding what constitutes an MVP, time to implement is not one of these factors.

Viability is not a sliding scale, software can not be somewhat viable it either can deliver a use case or it can't, and that use case is either valuable to users or it isn't.

Of course we can iterate, we can improve and we can deliver more, but this brings us to the minimalist approach that should be taken to MVP.

Some think that MVP only ever serves to push out deadlines, the goal of MVP is actually to deliver earlier by not concentrating on polish but identifying how a core need of users can be addressed with the minimum amount of implementation. Refinement and improvement come at an equally optimised pace by defining the next MVP and the next.

Making Effort

Discussions about deadlines often take place from a very entrenched position, I need this and I need it by then.

As we have discussed proper application of MVP can often lead to a realisation that maybe you don't need all those things, but what if you can't reduce scope any further?

Fundamentally a project only has two variables, scope and time, to fix both means the only other levers to be pulled are effort and quality.

A lesson that continues to be a difficult pill to swallow is that its very difficult to create effort and that the majority of the effective ways that this can be achieved are related to a teams structure and not just to the number of members.

Software is a creative process not just a manufacturing process, would a novel be written faster by more authors and maintain its narrative? Would a symphony be composed faster with more maestros and hold its tune?

So we are left with varying quality, the sad thing about this approach is that it often does work in the short term by bank rolling the release on technical debt. But with equal certainty it will also be the downfall of future releases when the interest on that debt has to be paid.

Release Early, Release Often

So I said I wasn't going to argue against deadlines, some reading this may think thats exactly what I've done but actually what I'm proposing is that we introduce more deadlines.

Rather than viewing the Agile process as a brake on driving towards deadlines we should see it as providing the acceleration that means we knock them off earlier then we thought possible.

An Agile approach means we can chip away at a mountain of scope, we may not be able to see the summit but we can establish the base camps that will be the factor in a successful ascent.

Rather than concentrating on the final release that will be the fruition of our grand plan identify the layers of value that means we can deliver something to our users to get them on board and help them keep the faith.

This means breaking away from waterfall thinking and embracing the iterative nature of Agile. 

Letting go of the illusion of control that anything can be made to happen in any timeframe, instead making the most of what the teams is capable of by identifying whats the next best thing we could deliver to incrementally deliver value.

Arguments Against Agile

Whenever any philosophy or school of thought gains traction and reaches a critical mass of adopters a dissenting voice will start to develop against the new perceived wisdom.

This voice should never be ignored as while sometimes this can be simply a need to differentiate sometimes the points being made are genuine problems that need to be addressed.

Agile also has this opposition where some question its effectiveness.

I would never presume to say that Agile has all the answers but I do believe its as good a theory as we have yet devised. 

I also believe that most of the arguments put forward against are related to the flawed implementation of Scrum as opposed to criticism of an Agile mind set.

Too Many Meetings

A core principle of agile is face to face communication, this communication does not have to be regimented with an agenda, a duration or a fixed meeting place.

Simply put, the point Agile is making is that you'd be surprised how many problems get solved when those involved just talk to each other whether that be at their desks, at the coffee machine or over lunch.

A daily catch up with the team to ensure people are progressing and fortnightly opportunities to review progress and plan the next iteration do not seem onerous.

If you find yourself in an unending cycle of meetings, often about the same subjects, then you should question why there is so much uncertainty in the work your team are trying to get through or why there is so much disagreement on the way forward.

These problems are unlikely to be related to Agile, instead they are likely to indicate a lack of preparation, direction and vision.

No Commitment to Deadlines

A common frustration with Agile is an apparent inability to commit to a deadline.

Actually Agile teams commit to deadlines on a regular basis, every other week the team will commit to a certain amount of work being achieved in the next two weeks.

The team will also regularly discuss how they can improve there operating process so that they can commit to even more work in the next iteration.

Agile teams have a certain budget represented by their velocity, and this allows a certain scope of work to be completed in a certain time frame.

Agile is simply re-iterating the maths of this situation, that you cant fix time and scope because that involves you creating more effort. If you base your plan on the team creating more and more effort you will miss your deadline because thats not how teams or people can work sustainably.

Instead a deadline needs to be a compromise between timescale, scope and what the team think they can achieve, its possible for everyone to win.

Rigid Process

Some will say that they don't feel they can achieve as much with all the red tape and bureaucracy that Agile places on them.

Its critical in this situation to draw a distinction between Agile and the system we use to try and achieve.

Agile is not a system, a framework or a structure. Agile is a mind set and a philosophy.

Agile is nothing more than the principles laid out in the manifesto listing certain aspects of software development and team interaction that should be encouraged.

Scrum, and others like it, are attempts to organise teams to promote these principles. What they shouldn't become are rules and procedure that hang around the teams neck.

There is no one Agile to rule them all, each team needs to find their own way the only things they need to believe in and follow are listed in the manifesto the rest is implementation detail that while important is not the aim of the game.

Feel free to find your own way, adopting an Agile mindset will ensure you take the right path, even if your path is different from others you'll still be on track to reach your destination. 

I've Got Something For That

Much like when someone disappears into a shed and emerges with the perfect tool for a particular job developers can often be heard saying "I've written something a bit like that before".

As I've said many times a good developer is a lazy developer, re-using what you've previously written should bring a smile to every developers face.

But how can we increase the chances that these opportunities will present themselves, what is it that makes code re-usable?

Simplicity Over Configuration

An easy trap to fall into is to take a piece of code thats fairly close to what you want and makes the bits that don't quite fit configurable.

While in a lot of cases this will yield a nice solution care must be taken to ensure that this won't run out of control. An object with a vast number of possible configurations can be difficult to get to grips with, what you need it to do might be in there somewhere but your eye isn't drawn to it.

This is more likely to happen when your trying to re-use code in a large block where the desired functionality is always going to be custom based on the context its being used in.

The answer to this is composition, by breaking this large code block down into small, simple, easy to understand building blocks you allow for different configurations of the functionality by allowing the developer to build the functionality that makes sense for them while taking advantage of the effort you've put in to taking care of the lower level details.

Layering the Pie

In a similar vain composition is easier to achieve when your code has a clear hierarchy taking us from low level detail all the way up to chunks of functionality that a user would recognise.

These functional blocks will very often be able to traced back to the same lower level detail.

By working out at what level certain pieces of code should exist you can avoid duplication and move towards a toolbox of code.

Obvious examples of this would be a data access layer or a networking layer, but even here recognising that there is a common pattern to how network requests are built, queries are constructed or results are interpreted can help the extract, abstract and re-use cycle that we are aiming for. 

Guarantee Included

Identifying that a piece of code might suit your needs is only the first step, it would be nice to also have some evidence that it does do what it claims.

This could come by reviewing the source code but it wouldn't it be better to have the code come with a guarantee of its effectiveness.

This evidence should come in the form of unit testing, those test results should not only demonstrate that the code works but also act as documentation for how the code is expected to be used.

This testing as documentation approach will help re-enforce that this is the piece of code that you've been looking for, this will solve your problem and enable you to move forward.

All this means that testability should be seen as synonymous with reusability, along with the guarantee and documentation elements the qualities of code that make it testability such as loose coupling will also make the possibility of reuse much higher.

While in many aspects of engineering becoming obsessed with a single element of the design may not be optimal striving to make something reusable will naturally lead to many other qualities.

Sometime code will be custom to a particular situation but a divide and conquer approach and thinking about how code will interact can help minimise these situations and help a developer be a a lazy developer. 

Tech Debt Accounting

Technical debt is incurred whenever a sub-optimal solution to a problem is chosen because of some other pressure aside from technical merit.

Technical debt is only technical debt if you knowingly choose that sub-optimal solution, anything else should come under the heading of mistake, poor judgement or idiocy.

So if we knowingly incur this debt why don't we just always do the right thing, I would love to tell you that its possible to do that but the reality of working in commercial software development makes it difficult to truly put technical concerns before all others.

We Need to Ship

The reason we write software is to ship it and there are many more inputs into the decision on when or if to do that aside from the purely technical.

I would like to be able to give you advice to never allow your code base to be affected by these outside pressures but it just wanted be realistic.

Shipping software is important, it reenforces our link with our users and reassures them that we are working on ways to improve the product.

Its a fine line between making sure software is properly implemented and meeting a schedule of releases and because of this we will occasionally stray either side of it.

We may occasionally ship late and we may sometimes ship something we aren't 100% happy with it, if we accept this is the reality then we need a strategy for dealing with the consequences. 

Auditing Your Finances

So if we assume that at any time we are carrying a certain amount of debt how can we ensure that it is effectively managed.

The first step is to record it, the chances are all developers working on a code base know the areas that need work or that cause problems when dealing with change.

But this isn't enough, too often when developers talk about this stuff it doesn't register with others and this is mainly because they can't see the impact.

Instead have a central register of tech debt that briefly explains the nature of the debt and the impact it has. The next time in a planning meeting eyebrows are raised as to timescales or complexity being able to point at an entry in the register and explain this is why is invaluable.

Secondly every time a bug or performance issue is encountered that is either directly caused by tech debt or exacerbated by it assigning the developer time taken up in finding a resolution and the users affected will highlight that everyone is suffering from the debt.

Visualising the impact of the technical debt like this helps highlight to non-techies that there is value in this kind of maintenance and continual improvement, stability and performance can be a feature.

Now or Later

The biggest piece of education you can conduct around technical debt is that its currency is time.

Time saved by choosing the sub-optimal solution is always paid back in either longer timescales for new features or more time spent on irritating bugs or failures further down the line.

This doesn't always mean we are doomed to either ship later or spend time fixing our code base, we instead need to understand that tech debt cannot be ignored. That it isn't related to people not doing their jobs properly, instead we can all work together to ensure we instigate a cycle of shipping and optimising and shipping.

Stability and performance are often overlooked features but users do not forgive lapses in either of those two things for sake of a shiny new feature. Its not always easy but it is possible to establish a balance between the technical merit and the need to ship everybody just needs to be aware of the nature of debt.