Category: Agile and scrum

In his book Kanban: Successful Evolutionary Change For Your Technology Business, David Anderson comes up with a a so-called recipe for success.

Basically, it is an ordered list of key steps for the starting technical function manager to follow in order to create positive change and make progress quickly in a volatile and chaotic environment.

The recipe for success looks like this:

• Focus on quality
• Reduce work-in-progress
• Deliver often
• Balance demand against throughput
• Prioritize
• Attack sources of variability to improve predictability

The recipe for success provides a guideline for managers trying to come in and make an existing team more agile. One needs quick win improvements which can only happen if there is low resistance from the team.

The six keys to success are:

• Focus on quality
• Reduce work in progress
• Deliver often
• Balance demand against throughput
• Prioritize
• Attack sources of variability to improve predictability

By following these guidelines as best as possible, you increase the chances of early success through newly inspired excellence.

Kanban by David J. Anderson

This is what I recently posted next to the front door for all of my team members to see whenever they walk in or out of the room. For me it is imperative that everyone realize what the true definition of done is. That way we can better refrain from cutting corners and releasing stuff too early. Basically it is a simple and straight forward checklist to help us do our work better by avoiding the most common pitfalls of software development.

Technical debt is a very bad thing for software development. As time passes, the more debt you collect and the worse things get. Before you realize it, you have accrued tons of interest. Your whole life starts getting bogged down. You find yourself in an impossible situation, slowly sinking deeper and deeper into the pool of quicksand. Your nose is barely above the surface, and you are taking your last desperate gasps of air. This is often a very cruel disease that sneaks up on you when you least expect it. A good example is trying to maintain legacy code. Or pushing new functionality atop a product that is not yet ripe for change. Focusing too deeply at the details in bug-fixing mode and not spending enough time looking at the whole picture will eventually cause much havoc and suffering.

More often than not, this is caused by doing too much too quickly and having to cut corners in order to achieve impossible deadlines. If you prefer it, you can just keep on sweeping the leftover dirt and dust under the carpet, as if nothing is happening. Sooner or later small bumps will appear and grow larger until they become impossible to hide. You reach a point in time when you cannot keep on ignoring these bumps. Even if everyone else seems to be ignoring them. Human nature blinds us when the so-called more important short-term goals are threatening our comfort zone, and we sacrifice the more important long-term survival for quick satisfaction. Our chances of surviving from one day to the next decrease pretty drastically.

Please, do not cut corners or you will be very sorry in the end. Step back, take a breather and do something before it is too late. Have the courage to speak up and make the world around you aware of it's folly. Unless of course you prefer to sink below the surface of quicksand at an early age, it's up to you really.

Times are changing and it's up to us to adapt quickly before it is too late. Decades of experience with traditional plan-driven software development has proven it beyond a doubt. We cannot ignore the hard facts that (after-care) software maintenance costs are at least twice as much as the initial development costs. That is, depending on the quality of the software. Lousy software could cause a tenfold increase in bug-fixing et cetera after the fact, maybe more. Very dissatisfied customers will turn away in a blink of the eye when the competitor introduces the next best replacement.

Much too often have hastily created products been pushed into the market prematurely. Because of fear of the competition, more often than not an exaggeration if not a complete illusion. This viscous circle has led to situations where maintenance costs have skyrocketed and even the supposedly leading technology companies have gone under.

Take a moment and think about it logically. Why continue like this? Why not use agile as a maintenance-compatible software development process? It would secure the complete product life-cycle from start to finish. Maintenance and development would become one, the continuous delivery pipeline would carry us forward, and we would be part of the current. It would avoid two separate teams of two conflicting and disparate mechanisms by combining them into a single cohesive unit working in tandem in the software development factory. Galloping in cadence, achieving higher efficiency, and best of all reducing unnecessary costs. Life would certainly be better.

Unfortunately, the obvious advantages can only be proven empirically rather than theoretically. We choose the wrong split in the road despite the warning signs that are so clearly in front of us. The human mind requires a more (so-called) structured plan which predicts the future better. A magical looking glass that will tell us that indeed we are the fairest of the land in the wonderful world of software development. Even if in the end it gives us a false sense of security, at least it makes us feel better. Even if it means joining the herd of lemmings for the sake of following, just in case. Until we reach the end wherever that might be.

DevOps Deep Dive Sessions:
Mastering the Four Pillars of DevOps
21 February, Amsterdam

16.00: Case Study 2: Walking the tightrope between Agile Product Development and IT Operations
by Kiffin Gish, Manager Development, Sdu Information Solutions, Amsterdam

Introducing and setting up an agile development team from scratch in a traditional plan-driven organization is hard. The real challenge starts while aligning efforts of this dynamic environment with the more structured and predictable world of IT Operations. What at first glance appears to be a collision of two totally different cultures is not so much a technical challenge as it is simply getting the opposing parties to understand and know each other better, sharing tools and knowledge. To better illustrate this, a case study will be presented about an advanced web-based e-government project, built using scrum, puppet and continuous deployment. deployment.

(The presentation went well, there was a big turnout and afterwards I met some people and had interesting discussions. I've also been invited to give a similar talk at the DevOps Summit in London this May.)

In practice integrated problem solving means that:

• Understanding the problem and solving the problem happen at the same time, not sequentially.
• Preliminary information is released early; information flow is not delayed until complete information is available.
• Information is transmitted frequently in small batches, not all at once in a large batch.
• Information flows in two directions not just one.
• The preferred media for transmitting information is face-to-face communication as opposed to documents.

Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck

Whatever you do just make sure that you focus on the tasks at hand and release software early and frequently, preferably in predictable iterations where defined deliverables are deployed.

The real killer is going for the big-bang release, shipping the product only after all of the functionality has been implemented.

This makes it difficult if not impossible to incorporate valuable feedback from the customers and end-users. The likelihood of creating a product that people love and want to buy is greatly reduced.

The worst drawback is that with a one off big-bang release, the team will be deploying the software for the very first time. They have not had time to practice this tedious process before. This means lots of last minute stress and an error prone release process where the launch date will more than likely be missed by a mile.

I really like the idea of focussing on the bare necessities when it comes to creating new products.

The best products are those which are simple and uncluttered, offering only the features that the customer really wants and actually ends up using.

An organization that embraces simplicity as a core element of the user experience will become a successful software product company.

Whenever there is discussion about whether or not to introduce a new feature or additional requirement, ask yourself first if this new functionality is absolutely critical to the success of the product.

If your answer is no, then discard this crazy idea and return your focus to what really matters.

Reference:
Agile Product Management with Scrum by Roman Pichler

There are a number of practical techniques to consider in order to run successful software projects, and one of my favorite principles from lean software development is the following:

"Decide as late as possible and keep your options open as long as practical, but no longer."

The trick here is to postpone a decision until it's still possible to make such a decision without it being forced upon you.

This is opposite to the traditional approach of project management. In this domain, everything has to be known with absolute certainy in advance. That way, the future deadlines remain fixed despite many risks and unknown factors which may get in the way. Risks have to be known in advance and tackled appropriately.

For especially high-risk projects, this traditional approach is not feasible at all. For these projects, delaying decisions is a must since decisions based on empirical observations is much more valuable than those based on theory and speculation.

Delaying commitments means that flexibility and capacity for change need to be designed into the system from the very beginning.

See the book Lean Software Development by Mary and Rom Poppendieck.

A natural tendency for software engineers nowadays is to divide large functional territories into digestible plots of land. Although blinded by their natural ideas of what technical activities are required to conquer the ever smaller acreage, one must avoid this urge of tasks splitting with all one's might.

Delivering a consistent and cohesive subset of all layers of a feature is better than delivering all of a single layer. By definition, a tracer bullet travels through all layers of a feature, taking with it a small piece of each layer.

For more information please have a look at Agile Estimating and Planning by Mike Cohen.

Although the agile project team knows when they will finish the next development iteration, they do not know exactly what they will deliver.

By having the courage and wisdom to admit that the result is kind of vague and unknowable in advance, good planning practices dictate a more straight-forward process of setting and revising goals that more importantly lead to a longer-term objective.

Embrace change, be flexible and go for it with everything you've got.

For an entertaining and well-written book covering this concept (and from which I paraphrased the words of wisdom above), please have a look at Agile Estimating and Planning by Mike Cohen.

Just call me Mr. Scrum Master from now on, please.

As of today, I completed the (grueling but fun) 2-day Certified Scrum Master training course given by the renowned founder and promoter Jeff Sutherland.

The highlight happened at the end of the day when Jeff Sutherland himself handed me my official certification and we did the secret handshake.

"At first, a theory better explains an event in the world, but then, as more details are calculated with it, it breaks because it can't account for some events or predicts results that are different from observed values. Eventually, as more and more 'defects' are found with an existing theory, these defects give rise to a crisis that is only resolved by a new theory which explains and accounts for the observed phenomena. Software development does not escape this historical evolution."

- Agile Software Development with Scrum, Ken Schwaber.