The Good Lazy Developer

I've said several times that a good developer is a lazy developer, this is not to suggest that they should be lazy in their attention to detail or their willingness to apply their skill to solving problems.

It is more about proper application of that skill and maximising the benefits that it can bring.

Engineering effort is not a commoditised product, it doesn't simply scale with the number of engineers in a team or with the number of hours each engineer works.

Its a finite resource that needs to be deployed with some calculation and forethought to ensure value is delivered.

Solve the Right Problems

Developers are very often compulsive slightly obsessive people who sometimes focus their effort on the minutiae of a problem or a piece of work.

While this attention to detail is partly what makes them good developers it is a beam that needs to be carefully focused to eradicate the most important problems.

A good example of when this is not done is when an inordinate amount of time is spent perfecting the UI for a customer journey that actually under the hood doesn't work.

Another example would be expending large amounts of effort on an edge case that is unlikely to happen or can be managed in a different non-technical way.

Whilst you always want developers to see the whole picture of a piece of software you do want them to adjust their attitude to when they are happy to say something is done, or at least done for now.

Customer journeys delivering the intended outcome should be such a staging post, a good lazy developer just wants to get to the point where things work and save polish and refinement for another day.

It may be that we don't want to ship until this polish is applied but we still need to approach the problems in the right order and ensure effort is concentrated in the right areas.

Automating the Housework

Developers time needs to be maximised on the furtherment of the product or system they are working on, the implementing of the pipeline to produce this shouldn't be a task that requires continuing application of effort.

When properly implemented the DevOps movement is an answer to this dilemma.

A scrum team contains a technical resource that can be equally adept at using technology to implement an autonomous and continuous pipeline of delivery as it can be at implementing the desired business outcomes.

Whenever a task becomes repetitive or onerous the good lazy developer wants to develop a way to avoid having to undertake that task again and instead concentrate on the production of new features or improvements to the code base.

The nature of these tasks is likely to be different in different teams but the fundamentals of building, testing and deploying code are common to all teams and the slicker these things can be made the more time and effort is conserved for solving the right problems.

Avoiding the Maintenance Headache

The majority of developers prefer to be creating code rather than maintaining it but none the less keeping an existing code base going is an unavoidable task.

The good lazy developer wants to reduce the impact of bugs or requested changes for a pre-existing code base. To do this they anticipate this requirement for change or modification coming and deploy the tools of loose coupling and strong cohesion that they have at their disposal.

This makes the code testable and composable, not only does this make the impact of change easier and more predictable, when combined with an automated pipeline it can prevent problems before they are shipped and reduce the impact even further.

Well structured thought through engineered code helps a team develop lazy habits by allowing them to keep to a minimum the amount of effort involved on change activities and avoid the cycle of tearing things down to build them back up again.

The majority of the time when we are referring to good lazy developers we are referring to an active dislike of repetition of the mundane and a preference to expel effort on the new and exciting. 

We are also referring to an understanding that developing software is a long term aspiration more than it is a short term activity. You'll never solve all the problems so make sure your plan of work address the most important ones first rather then being side tracked on the areas that potentially technically fascinating but ultimately of secondary or tertiary importance.

  

What Do Points Make?

When working in or with a scrum team talking about, debating about and on occasion arguing about points is common place.

Ultimately the ability to deliver points is a strong indictor for a team in terms of a velocity but its important to appreciate what this measure should represent and also importantly what it doesn't represent it.

Effort or Complexity?

An often debated aspect of pointing is whether they should represent complexity or effort.

I believe ultimately its difficult for team members to remain focused on one particular criteria when giving a points estimate, they are likely to consciously or sub-consciously be taking many factors into account complexity, effort and time to name a few.

For this reason we should see points as simply representing the currency of the work a team can get through in a sprint, each point representing a unit of work to be achieved.

Relativity and consistency are the most important aspects of pointing, points are unit-less, providing a 13 point story is more work for the team then an 8 or 5 point story and providing two 13 point stories represent roughly equivalent pieces of work then pointing is serving its purpose.

The exact reasons the team are choosing a points value is not necessarily relevant providing they are consistent in the application of those reasons.

Everything is Work

If we are going to have an accurate measure of the work a team can achieve we need to ensure all tasks that require more than a trivial amount of work carry a points value.

Sometimes we are tempted into indulging in creative accounting because we feel we want to ensure some piece of work is put into a sprint whether this be a bug fix, sorting out some technical debt or doing some refactoring.

But we can't achieve work with zero effort and ultimately in our attempt to fix or improve our code base we may very well have the opposite effect when more stories are added to an apparently under filled sprint even though we already have a lot of work on our plate.

If we generate a lot of technical debt or bugs the points value this work carries is a direct measure of the price we must pay to fix these things and should act as encouragement to not incur these charges.

Points Aren't Prizes

The purpose of a scrum team isn't simply to score points, it is to achieve business outcomes. At the start of every sprint the teams velocity represents a budget that can be spent to achieve these outcomes.

All members of the team can and should play a role in deciding how best to spend that budget in order to achieve value for money, in the form of a well defined MVP, and to create some investment opportunities for future sprint delivery.

It is all too easy to construct a sprint that achieves a lot of points but has very little tangible benefit, its not the case that at the end of every sprint we have to have a new feature or widget but we do need to understand how we have moved forward and how this will flow into the next sprint.

Points are a mechanism to use in planning to provide estimates and judge how much work to commit to in an iteration, they are not the only measure by which a team should be judged.