November 2017 – Insperitas

I am not a software developer but I do have project management experience. One of the problems for project managers is that developers want to work with Agile whilst customers often want a waterfall style report. This problem for me is fundamental. It’s the realization that there is a difference between Agile (a software development as a methodology, on which I am not an expert) and agile (small a) as a principle of a successful modern business. Coming back to the Manifesto of Agile helps us out here. These are simply good general principles. Even in their wording they recognize that asserting one way to be right and another to be wrong belongs to an older era where slow paced change was acceptable. In other words let’s be agile about Agile and not set in concrete.

These good principles need to start from the top. “Individuals and interactions over processes and tools” embodies the root of the question. Bosses should hire people they trust…and then trust them. This doesn’t just apply to developers. Once managers get this principle, Agile development follows smoothly. Until managers get it, we will face this continual, painful, seismic fault, with occasional earthquakes and aftershocks felt on both sides of the divide. (With PMs invariably caught in the middle!)

Bosses should hire people they trust…and then trust them

This reaches back to the recruitment processes which are not designed to select the right people but focus on certificates. It reaches even further back into the education system that directs children toward certificate attainment. (Excellent TED talks on this https://www.ted.com/talks/sugata_mitra_build_a_school_in_the_cloud and http://www.ted.com/talks/ken_robinson_says_schools_kill_creativity) We should, of course, 1^st teach children to care for other people and to respect them, and then teach them how to learn. Employees also need to do their part, being willing to be flexible with their role depending on what is needed at the time instead of sticking rigidly to an old job description.

So whilst I don’t disagree with teaching Agile (or Scrum, or any other agile development process) to development teams, I really believe that we need to start with teaching the philosophy and principles behind the Agile Manifesto.

The correct use of Cloud Services enables fast moving change.

A Brief History of Change

Companies used to be pretty static. Small changes were introduced over years. As a Global marketplace started to open up, companies realized the need to change in order to remain relevant and competitive. Small changes can be effected by the in house BAU team whereas large changes are renamed as projects and these are facilitated by project managers. (That’s why there are so many project managers now compared to 15 or 20 years ago.)

As changes in companies multiplied some problems developed. Changes sometimes broke things and running multiple projects concurrently required changes to be carefully co-ordinated. This led to change management becoming another drain on resources. Companies would create change boards or CABs and these have to be staffed by operationally responsible people.

CAB Meeting

Most people think of a CAB as Change Approvals Board. In fact ITIL refers to a CAB as a Change Advisory Board. There is a world of difference between the two! Changes are often reviewed in CABs by those who know the existing state of play well, but know little about the change being introduced. These people rely on getting the right information from the PM and the Project’s architect. This in turn reduces the CAB to a paper exercise. “Fill in this 8 page document and we will consider whether your change should be allowed to go ahead”. This is exacerbated by the CAB being staffed by people who have the responsibility to keep things working. So there is a general reticence to introduce change.

A CAB should of course be a forum to schedule changes that might interfere with each other not a hurdle to progression.

(Almost) Up-toDate

So now to Etsy and Amazon.

In 2011 Amazon explained that they introduce one change every 11.6 seconds. That’s a lot of changes to get through CAB… unless of course they have a better solution?

seconds

Etsy have a policy of asking their new developers to release change to live on DAY ONE of their employment. This allows them to get into the right mindset for introducing change. And the correct mindset is “Go for it!”

How can that work? Isn’t it dangerous? Well there are a number of tools and processes that can help. Perhaps the over-riding consideration is Fail-Fast (an Agile Teaching) but you need an infrastructure that can provide you with the security you need, one that can facilitate the Fail-Fast approach. This CAN be accomplished without reference to Cloud Services, but in reality Cloud will provide you with the easiest solution.

In terms of acronyms we can talk about DevOps, DevSecOps and WebOps. Also important are CI, CD and Agile. Each of these deserves its own paper. But the bottom line is that CABs ARE HISTORY. If your company has one.. you have a problem. You dont need it. Its slowing you down. Move on.

If you would like a FREE REVIEW to see how your business can benefit from Cloud Solutions then fill in your details on the contact page and I will get be delighted to help.