Standard Agile Process

A few days ago a friend described to me how in their company they were introducing a new development process. To go with the flow they decided to introduce agile methodologies at the same time. To make sure that all worked on the same basis they are calling their new process “Standard Agile Process”.

I think that is a contradiction within itself. Either it is standard or it is agile but not both. Let me explain.

In my view at the very core of agile methodologies is the ability to adapt to the environment. Many factors can influence the decision including people, experience, customer base, technologies, product, target market, time zone differences. Since 1999 I haven’t found two teams who used the same agile approach not even within the same company.

Given sufficient autonomy and authority a team will adapt as well as they can. Is it reasonable to expect that any two teams (regardless of being in the same organization or not) start their journey at the same time, progress at the same speed, learn the same things at the same time, have the same set of experiences and end up making the same choices? Evolution is never the same if the factors influencing it are different or if the timeline is different.

It’s even more complicated - or easier depending on your viewpoint. One of the teams I’m working with is using multiple process all based on agile principles, no two are the same. Factors that have influenced their choices are type of work, product and customer. And each of the processes (at least three) is evolving at a different speed following a different set of changes. Changes are applied as the team identifies the need for them, if needed multiple times a day. Occasionally a process stays the same for a few weeks.

So when you see or hear the term “Standard Agile Process”: If you are impacted by it, keep the above in mind. Don’t switch off your brain. Think for yourself. Speak up.

Or just have a good laugh in particular if your leadership team allows you and your team to be truly agile. You may or may not believe in Darwinism. But history suggests that those who adapt faster and better not only have a better chance of survival. They also tend to have a better life, i.e. are more successful and have more fun.

Personality Tests

I just spoke to a friend who had applied a few weeks ago for a leadership role requiring experience with agile development methodologies. She submitted a resume and also spoke to the recruiter. In the next step she was then asked to do some online tests that would check for her personality and intelligence.

Based on the test results she was told that she was no longer considered included in the remaining candidates. The way I know her the results that she had delivered in her work have always been outstanding. Her experience with agile methodologies is fantastic.

After I heard this story I was wondering: If you want to fill a leadership role in software engineering which of the following criteria is a better indicator for a good fit:

1. Personality tests without even speaking to the candidate?
2. Concrete results over many years in various roles and various industries supported by data such as shipped product, improved quality, more features, shorter release cycles, increased customer base, lower development costs?

Of course, I am not an expert in personality tests, so I am probably completely ignorant of the value of such tests. In my own recruiting process I have never used personality tests other than talking to the candidate myself and having several of my team members talking to the candidate. This approach has always worked.

Lean Startups

Agile approaches are very much about adapting and using short increments when dealing with uncertainty. Starting a new company comes with a lot of uncertainty. Agile principles can help reducing risk and improving the odds of success.

Eric Ries is the inventor/initiator of the “Lean Startup” movement. His concept is to incrementally develop your customers and your business. By running experiments, some people also call them spikes, you learn a lot about the business idea you are working on. By using small increments you avoid spending months or years building a product or offering a service that in the end is fantastic but nobody is willing to spend money on. Eric Ries helps you de-risk your business idea.

A complementary technique is customer development a term coined by Steve Blank. While product development important (your product can also be a service) it is equally important to also develop your customer base. In his book “Four Steps to the Epiphany” he describes this process in details. His book is a work book, so be prepared that you will have to do homework.

Why am I mentioning these two? The work of both of them is based on agile principles. Therefore if you are considering to test one of your business idea then the work of these two authors should be part of your preparation. And both are not limited to new companies. If you are tasked to build that brand-new product in your company then you are basically running a start-up. The only difference is that you run it in the context of an existing company, which can be beneficial (e.g. financial backup) or a hindrance (e.g. bureaucracy).

Mass Customization

If you find yourself in a project where you need to deliver and maintain a large number of customized versions of an otherwise standard product you may want to consider designing your processes in support of mass customization.
There are a number of prerequisites that you’ll need to have in place. For one you need a base product that you want to customize. That base product needs a mechanism in place that allows customizing it. For example you could design it so it supports plug-ins.
Next you need a fully automated process for building the base product plus all plug-ins. Ideally you have a continuous integration solution and an extensive automated and virtualize test environment. The latter allows automatic instantiation of different target environments and testing of various product configurations in those environments.
One option for mass customization is then to create a custom package for each individual customer, e.g. by creating an installer containing the base product and plug-ins for just that customer. While the installer might be a good option for a shrink-wrapped product, continuous deployment in a hosted environment will typically benefit from a different approach. For example instead of packaging different installers, you might have a different deployment for each customer. Only the plug-ins for that particular customer would be included to be deployed in their environment.
You can drive this one step further, for example by providing a web site where your customers can select the base product and the plug-ins they want. If they are self-hosted they would receive the custom installer. If they are hosted their deployment in the hosting environment would be maintained accordingly. This web site could include integration with payments systems or with your internal accounting system, e.g. to check whether a maintenance payment was received.
Alternatively instead of having custom installers or custom deployments, the availability of plug-ins can also be controlled through the use of licensing in the deployed product. All plug-ins are installed but only the ones that were licensed are loaded and available.
Of course there are number of other factors that must be considered, e.g. how to design the process and the product so it can be upgraded without downtime. Once you have this in place, though, you will enjoy a scalable solution that allows mass customization.

Feature Branches and Release Management

In a few previous posts (here, here and here) I described how feature branches can be used to reduce project risk. As you move along there are further ways to simplify the use of feature branches.

For example I mentioned release management branches. Release management branches can be used for the final Quality Assurance (QA) work when preparing a release. Having a separate branch for this has the benefit that trunk (or master or main) doesn’t have to be locked down until the release day. The release management branch is controlled in that all changes that are accept to it, are carefully reviewed and specific to the preparation of the release. The rest of the team – that is everybody not involved immediately in the release management – can continue to commit new work into trunk.

That comes at a price, though. While working on the release management branch, trunk still requires work, e.g. merging new features. Alternatively you can neglect trunk while working on the release management branch. Even better is reducing or even eliminating the need for a release management branch altogether.

As a first step you could reduce the length of release management branches, e.g. from a week to a couple of days. Or you go all the way and just remove the release management branch altogether. This is feasible if you release out of trunk and have tight controls over what goes into trunk (“no junk in the trunk”). For example you could give your QA person the authority to decide when a branch is merged back into trunk. The equivalent in Git could be a pull request and the QA person decides which and when to accept a pull request into master. A review on the branch could be a prerequisite, for example QA could verify whether enough automated tests where written by trying to break the system.

By giving responsibility for trunk to QA and by minimizing the required release management tasks releases can easily be delivered out of trunk (or master). With tight controls trunk/master is no longer a “moving target”. Once you have eliminated the release management branch, the overall branch management and the release management has been simplified. A new release can be made from every single successful build out of trunk/master.