Value First,Timeliness Second and Cost Third - V1T2C3

We regularly see news items and posts on big government projects which have failed and Public Accounts Committee declarations which castigate Ministry of Defence for project cost overruns and late deliveries. We also have seen too many instances of banking system meltdowns in recent years, coupled with major failings in BA (British Airways) systems.

What do all these things have in common?

Broadly speeking it could be said that they all occur in environments where "Efficiency" or "Value for Money" is held at a premium over everything else. In these circumstances, Efficiency is actually another way of saying Cost Cutting and Investment Containment. In such environments, Quality, Value and Customer or User Experience are traded for keeping to budget. Timeframes get squeezed to meet the allowed spend profile and risk management is subordinated to keeping spend in check.

Over time, this results in a house of cards syndrome where multiple sub optimal solutions get patched together in ever more fragile comninations and governance is subordinated to budget conformance. The room for experimentation and evolution of the right solution is lost and cautious groupthink starts to destroy innovation and build catastrophy into strategy, planning and control of the business. Innevitably this leads to failure, finger pointing and further failure to rectify problems. So repeat failures start to happen.

What is the remedy?

Sack the CEO and The Finance Director! Appoint an empowered CIO. Pursue a culture change programme. Start Focussing on quality and value, which means reconnecting with both customers and the people who deliver the business. Adopt a philosophy where it is better to deliver a small amount of value incrementally and on time than to pursue an everything at once approach. Use design thinking. Understand your business architecture. Align your risk appetite to value (not budget). Experiment with Lean Delivery. But most of all remember that efficiency is not calculated as:

Efficiency = Q/t

(where Q = quantity produced, t = time period of production)

Instead, use the equation:

Efficiency = (Q-D(1+n))/t

(where D = the number of defects and n = the number of things produced needed to pay for the defects) 

So for example if profit margins are 10%, then 10 satisfactory units are needed to pay for the cost of the defective one and n = 10. If 100 units are produced per day, 1 unit is defective and n = 10, then Efficiency is (100 - (1 + 1 x 10))/1 = 89. If 99 units had been produced with no defects, then efficiency would have been 99. It is better to focus on quality and value, than time or cost. Time and cost have their place, but should be subordinated to outcomes.

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.

Another Week In AI & Machine Learning

Driveless

So the hot news this week is that people keep crashing into driverless cars. Wired magazine discusses the issue that the way in which the current generation of prototypes being driven on America's roads are experiencing a high level of accidents, apparently because they don't behave is the same way that ones driven by humans do. 86% of collisions in California this year have been due to being rearended or side wiped! Autonomous cars appear to be over cautious and annoy human drivers, not only by stopping unexpectedly but also because they are over compliant with the letter of the law in interpreting situations. So why don't they have signs on the car, just like a learner does to warn drivers that they need to keep clear? It's a pretty similar situation and people do tend to steer as clear as practicable from learners who they know to be unpredictable.

AWS Capability Continues to Grow

AWS also held its AWS Innovate Online Conference. In his "state of the nation" talk, Boaz Ziniman outline current capabilities available Off the Cloud (OTC) rather than Off the Shelf (OTS). Basically, AWS still provides impressive capabilities which allow a developer, data scientist or organisation to just start using AI and scale rapidly. Though they have been adding to this capability with impressively powerful capabilities around visual recognition and voice processing as well as bundled environments which are pretty much deploy and go. this is very liberating, because it provides a readily used Pay as You Go (PAYG) capability, which avoids much of the traditional issues of continuously having to research, select, implement, integrate and tune the suite of tools and infrastructure needed, as well as continuously returning to CAPEX approval and purchase processes for scaling to deal with increasing volumes of performance issues. 

There's a caveat though. Some of the capabilities, e.g. recognising a face in a crowd, which may be useful for security solutions, might also be used as the tools for enforcing a police state or merciless pursuit by paparazzi. Enabling such massive AI at scale, will to some extent be another nail in the coffin of personal privacy.

Early Adopters Surge Ahead

Finally, MIT Sloan and Boston Consulting Group released a report "Artificial Intelligence in Business Gets Real" which surveyed the application of AI in business across the globe. Whilst there were the usual scare stories about China being ahead of the West in adoption and that the gap between pioneers and laggards is growing larger there were some interesting points. The Chinese are deploying to meet efficiency and cost needs. Everyone else is deploying, because AI helps them do more and there was a message that AI will not replace jobs, but it will change the nature of work and the skills needed.

The second key message, was to experiment with something simple and demonstrate the benefits, because business leaders who had seen AI in practice, get it and are prepared to invest more, to the point that AI is almost addictive in the way in which it influences investment appetite once a business has tried it.

The final message was really around AI at scale. If you are planning on building your  future business model around AI, then you need to plan, prioritise long term investments and to get effective data governance in place. This does not just mean establishing once source of the truth, with valid, complete and coherent data. It also means having a good handle on version control. Since, if multiple applications of AI depend on the same data, it needs to be synchronised to avoid unintended problems. So Lean Data practices are fundamental to adopting AI at scale.

Finally, it was interesting to hear how paranoid Chinese companies, adopting AI, are about cyber security. Protecting their data from competitors and the continuing availability of data and AI based solutions becomes increasingly important once a company's business model has evolved to adopt AI. So the principle "Cherish your Data" (see The Way of DAU) is key to successful exploitation.

Conclusion

Human issues, ethics and common sense remain central to AI adoption, an Agile mindset encourages adoption and Data Governance is a key enabler.

Look Outwards Look Inwards - What Does it Take to Innovate?

The Leadership Crisis In Innovation

Today's Digitalised Business Environment has caused a crisis in leadership within most large global organisations. Many CxOs have come to realise that they and their colleagues in their Senior Management Teams are part of the problem. Though some remain incredibly blind to this fact.

Why is it that business leaders actually inhibit their organisations' efforts to transform, digitalise and innovate? There are many possible answers to this question, though for American and European companies, one of the answers may be that the background of the leaders dose not predispose them towards innovation. Too many organisations are dominated by people with Accounting or Legal backgrounds and unfortunately these professions tend to lean towards conservatism, compliance and enforcement of rules, rather than trying to break the mould or implement business and cultural change.

Another possible answer is that most management teams don't actually function as teams. They are too often populated by people who are locked into functional siloes and turf wars. So whilst it would be simplistic and cruel to accuse them of all conforming to the often quoted idea that only selfish monomaniacs reach these positions, the environments in which they work often pushes them to behave a like they are. This makes it difficult to build the collaborative, innovative and risk taking culture needed to survive and grow in the new digital market place. 

So various people have been researching what it takes to become an Innovative Leader. See HBR and the Conference Board.

A Model Of the Innovator as Leader

The diagram below summarises the findings of a couple of pieces of research and the author's own experience. So it may not be perfect, but it at least represents some contemporary thinking on the subject and, hopefully, is useful.

Whilst it may be too simplistic to state that an innovative mindset requires a leader to look both outwards and inwards, this does underpin a lot of what is needed. In the model, VALUE, CURIOSITY and CONSTRAINTS interact in an almost chicken or egg situation (which came first?). A lot depends upon context and situation as to which is the starting place but a sense of each is crucial to an Innovator. 

VALUE is key because understanding what is valuable to your organisation and its customers (or other stakeholders if it is a Not for Profit one). Almost everything that an organisation does, should be aligned to optimising value, i.e. growing, preserving or protecting it. This includes innovation. So it is fundamental to understand what value means to he organisation and to its customers. Of course if a leader is thinking about starting a new enterprise, then some opportunity identification may be required first.

Understanding the CONSTRAINTS that an organisation operates under and what currently dictates market behaviour in its industry or sector is also fundamental, because this drives the Why questions? Why do we do things this way? why do customers behave like that? why do we not do this. Why are the constraints there and why don't we do things differently? (The why questions are sometimes called the 5 whys or 7 whys and basically, is a process of asking why enough times to get to the root of current behaviour) which then leads to What if questions such as What if this constraint did not exist? what would happen if we did this differently? etc. which lead to some theories about what works now and what would work in the future if the rules were changed, as well as some options for how to make these changes actually happen, which are postulates about how to disrupt the market place and are sometimes called BIG RULES.

CURIOSITY comes in from the other angle of observing what happens in the market place and asking why people do things. It also involves consciously looking outwards into different industries and disciplines through networking, attending industry events and carrying out research to see how they tackle different problems and then thinking about what lessons can be applied to your industry or even would spur new products or a startup business. It has been observed that many innovators are T shaped, as opposed to I shaped. I shaped people, only think about their discipline and nothing else. T shaped people, whilst having deep knowledge in their own area, also exhibit curiosity about understanding wider practices outside their specialism and applying them in a joined up manner. Curiosity identifies opportunities and asks why as well as what value can be derived from change.

These 3 themes of Understanding Value, Reviewing Constraints and Curiosity lead to the development of Vision. However, in most cases it requires an energised team to deliver a vision and successful innovative leaders involve the team in building a SHARED VISION of how things could be. This is an essential step in TEAM BUILDING as it helps motivate the team and encourages it to amplify any innovative efforts. Though a complementary aspect of Innovators is speed. Getting to market with an innovation, delivers most value if an enterprise is either first or second to market with a well targeted product. Hence VELOCITY of delivery is important, though it needs to be tempered with actually meeting a real customer need and being reliably and economically deliverable. This leads to the use of EXPERIMENTATION to test out the understanding of these needs as well as what actually works, and may involve exploration of OPTIONs to optimise the product. VELOCITY is also re-inforced by agreeing mutual stretch targets with the product delivery team. Note, the term mutual is important, as this is part of sharing and building trust. If the team buys into the targets, then trust and openness are more likely to be encouraged, leading to better team performance.

Other aspects of TEAM BUILDING and successful product development include DIVERSITY of the team and fostering an information based culture of decision making. Diversity in the actual structure of the team involves not only building a multi-functional team involving the internal disciplines needed to design, develop, deliver and market the product, but also where practicable a customer element. It also may include multi-cultural, multi-age aspects to encourage creative vitality by encouraging multi faceted view points within the product development process.

Adopting an Information based approach, means that the team must be INFORMATION RICH. Where it does not have information to support its decisions, experiments, trails, prototypes or other research should be conducted and the knowledge gained should be readily shared to support both effective and informed decision making, but also foster trust and understanding within the team. Though sometimes it has to be recognised that it may not be practicable to collect data before a product is launched. In this case, the team may have to either build features into the product which collect the data, supporting future product iterations, or use other means such as agile marketing to test hypotheses.

The last bricks in the model are SIMPLICITY and SYSTEMS THINKING. Taking an end-to-end view of how a product is delivered, enables the product team to anticipate likely problems as well as analyse operational performance and customer experience during delivery, so that continuous incremental improvements can be built into the product, refining its capabilities and delivery. SIMPLICITY, is a principle that should be applied as far as practicable. The product itself should be made as simple as practicable to deliver the value required by the customer. The delivery processes should be kept simple too, ensuring that activity is concerned with delivering value or experience. If complexity has to be increased to add value, e.g. by operating in multiple markets, then the team should look to see what else can be simplified. 

Conclusion

A leader needs his or her team to perform, because the leader can not do all the innovation him (her) self. The Team will only work if it is empowered, informed and enthused. so innovative leaders can set the context and the challenge, ensure that their teams are well informed, but also challenge them on value and pace. However, this does mean avoiding death marches, mountains of red tape and punishing the innocent, when things don't go as planned. The old ways have to die.

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.

Way of DAU Release 2

Release 2 of the Way of DAU has been released via Amazon and is available as a printed version here  and as an electronic version here. 

This takes into account feedback received for the MVP version and is now in a handier physical paper format.

I would like to thank everyone who took the time to provide comments and feedback.

The LinkedIn discussion forum can be found here if anyone has any constructive comments, suggestions or criticisms to help refine the next release of the book.

Group Technology For DevOps

One of the often overlooked concepts absorbed by the umbrella term of Lean is Group Technology. The concept originated in Russia, was refined in the UK and then seized upon by North America in the 1960-1980s period, especially when robot cells and flexible manufacturing were the fashion in Manufacturing Systems.

Basically the concep was simple. Old fashioned manufacturing factories used to be laid out in "functional" organisations. So, say, all the Lathes were in one corner, the drilling machines would be in another part of the factory and the milling machines in a different part or even a different building.

A component might require that: 

1. bar metal was cut to size - done by the sawing section;
2. it was turned to shape - done by the lathes section;
3. some holes were drilled - done by the drilling section;
4. a flat surface was milled on one side - done by the milling section;
5. one end was polished extra smoothly - done by the grinding section;
6. before final inspection, packing and shipping.

Each step would be conducted under the aegis of a different foreman. Each foreman had his own priorities and was tasked with running his section efficiently. At each step, the appropriate machine would have to be set up, perhaps with a special jig as well as, with its specific set of cutting tools.

So the process was a long series of queues and delays for set up, with only a small portion of time spent actually cutting metal. Efficiency was assure by having as much work as possible queued at each section, so the machinists never ran out of work.

Process times were long, delivery dates were never guaranteed to meet promised delivery dates, but it appeared efficient, even if  lots of money (working capital) was tied up in work-in-progress inventory. It was great for the foremen, because they were never individually to blame if something was late.

Group technology, was originally focused on reducing setup times. It involved using a classification system to identify parts which were similar to manufacture, e.g. small long thin round round parts or large short squarish parts, and batching them together for manufacture at the same time.

Then the idea of the group technology cell was introduced. All the machine required to make small round parts were organised into one part of the factory, in the normal sequence in which they might be used, creating a flow line. So similar parts were all sent to the same cell and put under the control of a single foreman who was also responsible for delivery performance. This allowed parts to be batched and pipelined along the natural flow line to meet both effectiveness and efficiency needs. It also meant that there was only one queue, the one going into the cell and work in progress could be reduced. Adding TQM techniques into the mix, so that the foreman was responsible for quality as well, turned him into a mini production manager and enabled quality to be improved. Then, where practicable, automation was introduced to raise overall performance further.

So what does this mean to IT operations. Well most organisations have normally organised so that the unix/linux administrators sit in one corner reporting to a senior administrator. The NT administrators sit in another corner with their senior administrator. PC administration sits under desktop support. DBAs sit in their own little getto, with a senior DBA. The network administration people might be in another building. If global outsourcers are involved, then corners become "Competency Centres" often geographically dispersed.

In traditional "on premise" or "in data centre" operations, a large part of the time of administrators is focused on the box shifting aspects of the role with manual administration of builds and maintenance tasks. No one team is responsible for the support of an application. So when things go wrong, different disciplines point the finger at each other, saying "our bit works it must be theirs which has gone wrong". This makes reacting to incidents slow and innefficient, and slows down releases of new features. So what appears efficient is an inhibitor on value by slowing change and reducing uptime..

Modern "Everything as a Service" (XaaS) environments offer new opportunities. The job can be refocussed from box shifting and manual "oiling and adjusting" type tasks to a higher level of "End-to-End" application administration. This requires administrators to be re-organised into either application facing (if it's large like an ERP or core banking system) or business facing (if there are lots of linked smaller applications used by a business area) teams. They can then work with application and business facing development and test teams to meet the continuous delivery needs of modern digital products and applications. Tooling such as Splunk or Oracle's Management as a Service are good at pinpointing root causes of problems, ensuring that the team tracks down causes quickly and focuses on jointly fixing issues. 

That way, accountability lies with the team and incidents can be resolved quickly, whilst new releases are jointly planned to optimise value to the business. This is Group Technology for DevOps.

Update on the World of Agile

CollabNet has just published its 12 Annual Report on "The State of Agile". This makes interesting reading, although some filtering may be necessary as responses are dominated by North American participants in its survey. So for example SAFe tends to the prevalent approach taken to scaling Agile, which is more popular in the US than Europe.

To me, the most interesting bits are the high percentages of survey respondents reporting significant Business Value Oriented Benefits. Over 60% of respondents claimed:

• Better responsiveness to Changing Priorities;
• Improved Project Visibility;
• Enhanced Business/IT Alignment;
• Increased Speed to Delivery;
• Higher Productivity;
• Raised Team Morale.

The percentages far exceed the reasons for pursuing Agile. The other interesting metric is that only a fifth of respondents reported lower costs, which is in line with Agile philosophy, but still good to see confirmed.

The other key takeaway is that an increasingly high number of businesses have adopted both agile and DevOps as their mainstream approach.

Has Big Data Lost its Mojo?

A number of surveys were published during 2017 which suggested that Big Data has lost the CxO mind share that it had.

The overall impression gained was that business leaders are putting their emphasis on Artificial Intelligence (in particular Machine Learning) and IoT, whilst CIOs and Technical Leaders are worrying about Security and Lean (Agile and DevOps). 

At the same time the consumer and gadget end of things are focusing on wearables, voice and VR/AR based devices (implying other types of AI are getting important). 

Somewhere in the mix, people are worrying about culture, product management and marketing, and organisations designed around empowered product teams.

There almost appears to be an assumption that big data has been cracked and apps are easy. Also, data governance is not really getting the attention that it should do and vendors are pushing APIs for integration.

This suggests not just a gap between business vision and technical capability to deliver, but also that the consumer led boom in exploitation is going places which don't necessarily fit well with classical business environments. Open plan offices are not the place where people should all be talking to their digital assistants.

The lessons I draw from this are than business management teams need to start thinking holistically about what is needed to deliver their new business (i.e. digitally augmented) strategies and models, but also about what the future workplace looks like. Is the office finally dying?

They also need to get real about data. It needs to be managed using lean data principles. Integration and security are vital to get right. IoT and other exploitation approaches are going to emphasise Big Data's importance further. So it's vitally important to develop data specialists who understand your business and are networked with the right people. A recent article in the Harvard Business Review suggests that most organisations have focused on technicalities and need to look at a more immersive approach and organisational issues too.

IoT Adoption Drag

IoT Makes Slow Progress

Despite all the hype and general acceptance of its possibilities, IoT is making slow inroads into enterprises and can still be regarded as being in the early period of adoption in many businesses.

I have talked about CxO behaviour and culture in previous blogs as well as security and other issues, so what is holding IoT back?

Business Leader Perspective on IoT Adoption

A recent survey by the Economist Intelligence Unit (sponsored by IBM and ARM) involving over 800 executives around the world looked into the issue. This suggested that fewer than 10% had extensive IoT implementations, although many had dipped their toes in the water.

More positively, around 25% stated that IoT adoption was sparking innovation within their organisations with 22% indicating that IoT offered new opportunities, 20% saying it was changing business models and 16% believing that it was enabling entry into new markets and initiatives. So the overall picture is quite positive about its transformational potential.

Only 15% believed that IoT would significantly reduce costs, suggesting that IoT adoption is more about re-imagining their businesses than old fashioned cost cutting.

Interestingly enough, few executives saw technical issues as blockers to adoption. The key constraints cited were the Size of Investment needed (29%), Security and Privacy concerns  (26%) and lack of CxO Knowledge and Commitment (23%). 

This points to a smoking gun around Cost and Executive Behaviour / Team Buy In.

IT Leader Perspectives

Interestingly enough the British Computer Society's (BCS's) survey on Digital Leadership shows some mismatches.

Over the last 4 years the principle concern of IT Leaders in the Digital Space has been Security (averaging 60% of responses, plus or minus 2% over this period). The second most important concern has been Cloud (at 50%). In the last 2 years, Governance has moved into third place at 35% followed by Agile and Big Data at around 25-30% each. IoT was only cited by respondents as a major interest by 18%. Although Cloud, Agile and to some extent Big Data are involved in IoT adoption.

This suggests 2 things. Business Executives are over confident about implementation issues and that IT Leaders have a mismatch in alignment and understanding with business aspirations.

IoT Success Factors

So it appears that CxOs need to get together and agree a common vision and set of priorities. IT Leaders need to build IoT into their plans and there is a need for education and collaboration to get a coherent approach in place.

Bitcoin - Last Years Most Successful Prototype

By now most of us are tired of hearing about Bitcoin and its outrageous valuations. We all know that it is a bubble, but still the juggernaut ploughs on.

If you step back however, this is just the latest and most public example of a prototype which accidentally became the operational product. The history of IT is littered with them and most techies have experienced the pain of replacing a decades old legacy system which was never intended to do the essential mission critical function which it now performs. Unfortunately Bitcoin is a lot like this.

This does not mean that Bitcoin is a failure, just that it is limited and, in a spirit of Agile / Lean adoption, the world and the Blockchain industry needs to learn from the experience and move on.

On the plus side:

Bitcoin is a great technology pilot of the original Blockchain Protocol Specification written by the mythical Satoshi Nakamoto (whoever (s)he/they happen to be).

Bitcoin has been widely and enthusiastically adopted outside the virtual world game space for which it was originally intended and is now often used in real world transactions.

Banks have started to trade in Bitcoin just like conventional currencies.

Other cryptocurrencies have become viable as a consequence, e.g. Ethereum.


Where we need to learn to do better:

Bitcoin and vanilla Blockchain don't have scaleable architectures. there is a limit to the number of coins which can be mined. Transactions and mining consume excessive amounts of power, so Blockchain now has the power consumption appetite of a small country. Transactions have now become as slow as traditional clearing system transactions.

Bitcoin never exploited the conditional contract features of Blockchain. This remains an area which is under exploited in many other Blockchain implementations outside the currency area.

Bitcoin has become an unregulated market. Some analysts refer to it more as a repository of value, than a currency. Its value has become extremely volatile due to over speculation. It definitely has attracted exploitation by criminal networks, leading to China's decision to ban it. The bulk of its coins are owned by a small number of people or organisations, offering the opportunity for extreme and pernicious manipulation.

There are multiple platforms and technologies, but no apparent standards body to facilitate evolution and interoperability.


So where next and what is the future? To me one of the big questions for future cryptocurrencies is around regulation. The thing which made bitcoin so interesting to many people was its global ubiquity, unshackled by government regulation. Governments have become interested and think that they should involved. At the same time, many consumers distrust governments and see this as just another way to extend the modern feudalistic grip of their taxation systems. Additionally, as all national currencies are now based on promises or monetary brownie points rather than any tradeable commodity such as gold (with its notional intrinsic value) there is no reason why a consortium of international banks or other businesses/stakeholder could not do this equally well and there is even an opportunity for the United Nations to flex its muscles and get involved to deliver a truly global and frictionless currency. This could have implications for current leading currencies such as the US$ which dominates world trade due to early 20th Century International Agreements to use it as the international currency for shipping.

Additionally, quantum computing offers both enablement and risk. The complex mathematical protocols involved in mining currency and validating transactions would easily be handled by quantum computing, lending capacity to deal with volume scalability. However this same risk, also could undermine some of the security built into Blockchain.

Whatever the future, I believe that 2017 is the year that Bitcoin peaked and it is now time to hand over the reins to other successor cryptocurrencies.

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.

2018 in Digital

Recently, the UK budget was set with a few old fashioned measures for increasing productivity, Investment in Infrastructure and More Money for Apprenticeships.

I then read someone's blog which suggested that this had missed the mark. His premise was that investment in technology usually fails and there is a need to continue to emphasise other traditional business change and simplicity measures such as clear strategic leadership, process design and email de-cluttering. He produced statistics to show that e-mail costs more than the UK's contributions to the EU's budget. Although I thought that this particular commentary missed the disasters caused by poor collaboration by business leaders and the failure to work together as a unified team.

At the same time, a commentary in Forbes suggested that 2018 will be the year of software automation with a sudden increase in the trading of enterprise data sets and a huge increase in the number of data scientists. Although the breaks to this are whether data sets are considered valuable IPR and the need to train up a lot more people in aspects of data science.

Contino and Gartner have identified 2018 as the year of DevOps with DevOps driving Agile (Gartner) and increasing competition between Platform Vendor services between AWS, GCS and Azure as well as the new wild card entry AliBaba. Interestingly, growth rates for all of these services are in the 50-90% p.a. area. Contino also mentioned that there are many new developments not just in the area of containerisation and serverless computing, but also in improved cloud security via projects such as Calico.

Surprisingly, given the recent frenzies, most commentators were muted on the impact of AI and Machine learning. Likewise, no one bothered to mention the rapidly maturing area of wearable technology or the new promises that quantum computing may at last start to deliver.

Overall, the impression is of Lean Digital becoming mainstream whilst other post digital technologies gradually insinuate themselves into leading edge enterprises.

Agile Portfolio Management

The Agile Business Consortium recently published its book on Agile Portfolio Management. See a recent article here AgilePfM .

Key things about it that are complementary with the The Way of DAU are the insistence of alignment with strategy and value, the emphasis on innovation and collaboration and the highly iterative nature of the activity.

It fits nicely into Layer 2 of the DAF framework.

Digital Patterns

Most software developers are familiar with the concept of a pattern. They use them to describe types of programming problems which can be solved in the same generic manner.

This was originally developed to support the indexing of re-usable code and trading in 3rd party off the shelf code components, with the idea of improving overall development productivity and quality. The quality aspect arising from the assumption that such code would be designed to be flexible and robust in many scenarios.

The idea was not actually that novel as it replicated the concept of group technology in manufacturing, where a group technology code defines the shape, size and manufacturing characteristics of 3D parts or components. The idea being that groups of machines could be set up to manufacture families of parts more quickly than traditional methods where machines were grouped functionally and work meandered all over a factory between the functional groups of machines. 

Anyway, patterns have become such a useful metaphor that developers will often describe what they are doing in terms of what the pattern is and therefore what tools and approach they are using. Consequently, the concept of patterns has also been adopted to describe aspects of solution architecture and encourage design re-use within enterprises.

So I have been struck recently by the fact that going digital or adopting a Digital As Usual model might be facilitated by certain organisational patterns.

For example, Lean and Agile solution development is usually product and product team based. The product team integrates the viewpoints of several functions involved in developing and exploiting the product typically including users, product owners, analysts, developers, testers and DevOps engineers. This might be called the Product Team Pattern.

Some approaches to delivering digital products also look at mass customisation via standard features. The principle being that a product is constructed from a number of features for which there may be a number of standard options. The product is then tailored to a customer's needs by selecting which features and which options the customer wants. This then gives a tailored product experience with most of the benefits of a bespoke product, but better economics and more consistent quality because each feature and each option is standardised. This might be called the Adaptive Product Pattern.

A recent article in the SLOAN MIT Management Review, Is Your Company Ready for a Digital Future? described a "Future Ready" pattern, in which it identifies a combination of Customer Experience and Process Efficiency capabilities as delivering this type of pattern resulting in low cost innovation, superlative customer experience, modular agility and the ability to exploit data as a future asset. Whilst this complements the thinking in "The Way of DAU", it struck me that perhaps there are other patterns out there which need to be identified. 

Any thoughts anyone?