The 7 Deadly Sins of Agile

This week I went to an event organised by La Fosse and Intertechnica. This was a networking and discussion event with 2 speakers from Intertechnica (Rod Armstrong & a colleague) presenting 7 "sins" and opposing "virtues" followed by break out sessions to discuss them.

It certainly was a lively event, with some of the sins reflecting what happens when people adopt and perhaps bend the principles underlying underlying the "Agile Manifesto". Itwas great to hear that for most of the seasoned Agile Practitioners there, that the Agile Maifesto is not regarded as some holy dictat but more as a historical "call to arms" which, whilst useful at the time, is now rather dated and too restrictive to be regarded as the definitive bible for practising Agile.

Probably the best couplet of sin and virtue was Chaos vs Discipline. As this sparked some interesting discussion about how Chaos is in some circumstances useful for innovation and discipline for systemising value delivery, amongst other things.

Heidi Anderson of La Fosse has posted a review of the night here.

DevOps and AI means that Lean Data has another Principle

In an earlier post I expounded on the principles of Lean Data:

• Organisations know what data they hold and manage;
• Data is classified according to subject area and criticality;
• Only the minimum data necessary to Add Value to the business is held;
• Data replication is kept to the minimum level necessary to optimise business performance;
• Data Value is determined by its utility in Serving the Customer, Supporting Essential Capability, Protecting the Organisation, Providing Insight for Business Decision Making.

I also covered Data Portfolio Management. However, what I missed was the emerging issues around database management systems and Machine Learning. It appears that as people start to scale their Lean efforts (Strategic Alignment, Design Thinking, Agile & DevOps) they are beginning to realise that this includes data too.

What becomes increasingly important is having a handle on configuration management over data base design (i.e. schemas) and data sets themselves, ensuring that it is co-ordinated with code configuration management and integration across multiple deployments. This should have been implicit, but apparently it was not.

Therefore I suggest adding the principle that:

• Data configuration management of schemas, test data conditions and machine learning training data is co-ordinated with applications and code configuration management.

Culture Shows Up Again as the Thing Driving Agility

Forbes Insights and the Scrum Alliance have got together to publish a recent report on Organisational Agility, drawn from interviews with over 1,000 C-suite executives from around the globe.

A key theme which runs through the whole report is how important Culture is to Organisational Agility. (Something which I emphasised in "The Way of DAU"). Additionally, there are some compelling findings about the benefits of organisational agility. Over 50% of respondents identified benefits in the areas of:

• Time to Market
• Speed of Innovation
• Employee Morale
• Ability to Attract Talent
• Competitiveness
• Financial Results
• Ability to Manage Across Geographies

To re-inforce these findings, the report focuses on the performance of leading Agile Organisations and Laggard Organisations. Whilst they represent similar proportions of the overall survey population (16% and 19% respectively), twice as many Leader Organisations enjoy annual growth of over 20% as Laggards do.

In all probability, the CxO community that the authors consulted, probably included a pool of organisation most interested in Agility, as an earlier report by McKinsey suggested that only 4% of organisations have completed an organisation wide Agile transformation.

The report looked at a number of things, including whether organisational agility was End-to-End or siloed in functions. Based on the opinions of the respondents, it appears that Operations and Technical Functions tend to be the most Agile (79% and 75% respectively), followed by the usual suspects in Sales and Marketing. Interestingly enough, Finance achieved a credible 64% vote of confidence, but HR was amongst the laggards with only 56% of respondents considering it an agile function. Considering that HR is often thought of as the "Guardian of Culture" this is a worrying gulf and should be a wake up call to HR to re-vitalise its mission.

One area that I would have liked more analysis on, was whether Leading Agile organisations already had positive innovative and collaborative cultures before they embraced Agile or had to focus on it as part of Agile Adoption.

Anyway, the take away is that all CxOs, irrespective of function, need to work on fostering the right culture.

Aligning Digital Exploitation with Operational Capability

All Enterprises Are Not the Same

One of the tenets of Digital As Usual (DAU) is that most businesses are not pure play digital organisations. In almost all cases there are operations and activities which are essential to either fulfilling service or delivering a product which need to be managed as well. The Digital Adoption Framework assumes an Industry Categorisation Model as illustrated below.

The Industry Categorisation Model identifies 5 Categories along a continuum of Industry Product Nature. At one end of the continuum are “pure play” digital organisations, whose products are Information and Content based. These consist of Market Platforms like eBay and Compare the Markets.com who provide a platform, through which other organisations and people sell their goods and services, as well as Publishers and Providers of Content who provide videos, e-books, podcasts, news, music etc. At the other end are Extractor and Grower type businesses, such as coal mines and cocoa growers who provide natural unprocessed products. Off course not all businesses fall neatly into just one category. A major energy company such as Shell or Exon may straddle several categories along an Upstream (exploration, drilling and extraction) to Downstream (transport, refining and distribution) activities.

So why is this important when thinking about digital businesses? Well each different type of business operates in different ways, has a different level of dependency on capital assets and has different opportunities for exploiting digital technology to augment its business model. Additionally, the whole concept of Lean Delivery via Design Thinking, Agile Delivery and DevOps may have different opportunities and constraints as well as nature of delivery in each category.

Some Examples of Exploitation

The diagram below looks at the potential for exploiting Artificial Intelligence (AI) technologies according to Industry Category.

The “X”s in the table represent significant opportunity for exploitation against a generic type of Use Case. So for example AI technologies (machine learning, visual recognition, natural language etc.) can be used to provide insight and learning in every type of organisation, but there is very little opportunity for them to add to “customer experience” in say mining or farming. Again there is huge potential to build AI capabilities into consumer products, e.g. Alexa in Amazon’s Echo, but there is little opportunity to enhance a product such as iron ore or tree trunks produced from a Natural Product Extractor or a Grower. 

Alternatively for IoT, see diagram below, the opportunities are pretty limited for an Information publisher, but there are many areas where a farmer could use it to track livestock and monitor soil conditions and crop conditions, as well as control assets such as vehicles and trailer equipment.

This moves us onto exploiting iterative approaches within an organisation. The other night I was talking to someone from a major pharmaceutical company. Drugs take years of research to identify promising candidates for a problem and to test for efficacy and safety, as well as meet regulatory demands. There is little opportunity to exploit Iteration in this type of product development. But for the company overall, there are opportunities around internal processes and with Agile Marketing.

Agile Marketing is a growing area of adoption within industry and works well for consumer driven businesses. At its core is the use of small integrated product teams which focus on market research, product promotion, delivery of marketing and promotional materials, advertising and the information analysis systems used to support marketing data analysis. These teams tend to work in multiple sprints testing out marketing promotion hypotheses and rapidly identifying which approaches produce optimal results, to improve overall revenues. 

Iterative development also its quite different for delivering an oil tanker or a film, to the development used to support a consumer service. In the case of the former, iterative design, development and continuous testing techniques are used to deliver a single integrated complex product over a period spanning many months if not years. In the latter they are used not just to deliver the product, but to continuously keep it fresh, up to date and moving ahead of competition that is playing catch up.

So it's important not to adopt a one sized fits all approach, but to really get down to what can work for your organisation. This is part of what I talk about in my book.

Agile CIOs

The ever changing role of the CIO is often subject to much debate. Opnionons vary from the challenge of "why do we need a CIO?" to "CIOs should be driving our innovation and vision".

 A recent article by McKinsey - How to Become an Agile CIO - is a typical example. The authors,  Santiago Comella-Dorda, Quentin Jadoul and Swati Lohiya, set out 3 main aspects of An Agile CIO's role:

• Architect / Technology Visionary

• Driver of Knowledge and Talent

• Problem Solver

Whilst they are obviously part of the role, I think that they do miss the point in a number of areas. The first is that the CIO should be taking the llead in helping build a positive business culture which avoids blame, encourages collaboration and focusses risk appetite around continuous innovation. This requires a good focus on the soft aspects of Employee Engagement, as well as some on providing supporting tools.

The second is on uniting the Senior Management Team and their teams in building common understanding of each other's problems and shared opportunities, as the basic pre-requisite for developing an Integrated Product Team approach, in which each IPT addresses the requirements, design and enhancement of End-to-End product processes (whether there are internal or customer facing products).

The third issue is being the corporate consience on balanced performance and investment; Businesses which operate as teams tend to be the best at developing and exploiting digital business models and sustaining a Digital As Usual ethos. This does require balanced investment and commitment of resources so that the orgnisation can not only address new business opportunities, but also improve exisiting products, maintain capability and protect itself (and its customers).

Agile Is Not New, But It is Useful

Agile advocates are often quite quite siloed in their thinking, many having had little other experience of delivering projects than bespoke software development projects. Many of them are not even aware of the historical trends before the publication of the Agile Manifesto or that they are in fact just participating in an evolutionary trend, rather than a revolutionary approach. Agile owes much to Rapid Application Development or RAD (its immediate predecessor). Often, I have heard them musing about applying Agile to other technologies and industries and wandering whether it is possible. At the same time they miss the fact that DevOps, which extends Agile, is based on manufacturing theory (Total Quality Management, Just-In-Time and Flexible Automation).

Actually, project managers who subscribe to the AgilePM approach, will often use the organisational aspects of agile to run their projects and the approaches used in RAD were not new either. Prototyping was a feature enabled in manufacturing by the use of CADCAM to rapidly design and produce prototypes and Engineers have always been taught that Design is an iterative process. The concepts of Design Thinking originate from academic papers produced in the 1960s, and address many of the technique aspects of Agile including multi functional product teams and evolutionary prototyping and development of innovative products.

But if you want to see Agile organisational constructs such as sprints in action, go to a shipyard. almost all modern shipyards practice modular shipbuilding approaches. They split the overall design into modeles which are constructed and outfitted. These are combined to form blocks, which are then further outfitted. The blocks are then moved to the construction berth, combined and integrated. Work is usually organised around 1 to 2 week production units (although sometimes 4 week ones are used). Testing is continuous and progressive as systems and compartments are completed. Test conditions are part of design. (Does this sound Familiar?). 

Although this practice evolved in the late 60s in Japan and gradually spread, it was in fact learnt from high rise building construction, with each floor of office or hotel blocks treated as a sprint.

Likewise, filming has a similar approach. Up front sketches are used to design each scene. Some work is done with cameras, lighting and film to workout the best combinations to achieve the cinematic affects required (a little similar to preliminary UI design). Scenes become the sprints and are filmed iterativelly to produce what can be afforded and so on. UAT is done with test audiences.

So Agile is not new, it's just slightly tailored to software development, and just like some of the other approaches used elsewhere, it's based on producing a right quality product with the minimum of fuss.

The Way of DAU - The best a business can be

Just to let you know, The Way of DAU is now available from Amazon as a paperback. (click on Amazon to see) and the e-version should be available soon. 

This is a deliberately simple book on the quite complex subject of how to adopt a sustainable digital business model. It was inspired by my personal frustration with incomplete models and advice available for Digital Business.

Digital operations have now replaced traditional Business As Usual business models. The Way of DAU promotes 10 basic principles, an iterative Framework (the DAF or Digital Adoption Framework), and positive cultural values to achieve the behaviours needed in successful digital businesses.

The book is based on a mixture of personal experience (in an organisation struggling to reinvent itself) as well as collected best practices. The current edition represents an MVP version. I hope to collect constructive feedback via a LinkedIn Group to drive future releases of the book. (see: The Way of DAU Group ).

Integrated Product Teams - Digital Organisation

IPTs Are Not as New As You Think

I first came across the Integrated Product Team concept in the most traditional of environments, the Defence Industry. Their adoption was one of the major hallmarks of an attempt to revolutionise UK MoD procurement in recent times.

Benefits of IPTs

The best aspect of the IPTs, was not just that they were multi-disciplinary and therefore great at surfacing all the dimensions of a problem, but they also helped break down the barriers of distrust that exist in the Defence Industry. This is highly significant because, the industry has traditionally had a huge gulf separating the MoD and its contractors, due to the insecurity that is encouraged by the Treasury in its pursuit for what it thinks is Value For Money. The Treasury usually takes the stance that the costs are too high and the public sector is being ripped off by rapacious private sector companies, encouraging a general sense of insecurity in the public servants (in the MoD) who are dealing with them. This then leads to relationship problems and behaviours which inevitably stretch out acquisition projects, impact the quality of what is acquired and often results in increased costs. It is a situation which Demming (one of the grandfathers of the Total Quality Movement) would have predicted. As he advocated focusing on quality (driven by customer needs) and continuous improvement, with the philosophy that improved costs and value would follow.

Design Thinking And Agile

The concept of Design Thinking (see for example the UK Design Council's Double Diamond Model for product development) also relies on a similar multi-functional teams to get at what is the real customer problem to address, and then what is the most appropriate product design option for delivering it, supported by iterative design and prototyping to develop a right quality product.

So it is no surprise that the Agile Movement, building on traditional Rapid Application Development techniques of user-centric prototyping, has gradually moved to a Product Team based approach, particularly when the market driven influences of digital companies such as Amazon and Google are taken into account.

IPT Case Study

So I was really interested when SLOAN research into the adoption of an IPT based approach at a major bank was published recently. See: What to Expect From Agile. It has some great practical insights into some of the considerations to take into account if your organisation is thinking of adopting an agile or digital business model.