What Does It take to be Agile?

There's a lot of discussion in many fora about the meaning of Agile, Agile Leadership and Agile Business, with some pundits even saying that "Agile is dead!" Inevitably many authors feel the need to go back to the Agile Manifesto and quote its principles. However, I feel that they get it wrong.

I have always had problems with the Agile Manifesto. Not because it was not a good thing or a great call to arms, but because, at its core, it just focused on 20% of any project or development activity. This really goes back to how it evolved as the shared set of principles that a dozen different groups found that they could agree upon and the fact that the lowest common denominator was the act of programming.

Just to illustrate the point, if you want to develop a mobile app and ask a man in a garret who specialises in these things, he will probably quote you somewhere around £20K for a simple app. By the time you have run through the whole project and costed all the effort which goes into the development, it will probably cost you around £100K to £120K in its entirety, because you need to go through the activities of planning, budgeting, researching, defining and agreeing requirements, workshops with users or customers, coding, demonstrations, testing, configuration management and publishing to get there, with some overhead for project management and development sourcing (even if this is internally developed).

The Agile Manifesto left out a lot of critical assumptions, such as some analysis is required to get to scope and a prioritised list of requirements. Standards and an architecture are mysteriously deemed to exist so that the developers can use them. Testing and implementation are miraculous things which just happen because working code has been delivered.

If you go into the real world, one of the biggest bottlenecks in delivering projects and products is Financial Approval. Often this has nothing to do with the business case, but more to do with internal organisational politics and the competition for investment funds. If governance is not well aligned to clear and explicit strategy, and the senior management of an organisation don't work well as a team in prioritising investments to deliver strategy and to preserve existing value, then this act can take longer than the actual project. So it was good to see Daniel Lambert's blog on strategy and architecture, discussing its need for success with Agile.

The Agile Business Manifesto is also an interesting document, although to my mind still a bit clunky and lacking focus on Quality, Value and Strict Scope Control (e.g. via MVP concepts). I also think that it is weak around Cultural orientation towards Innovation, Design Thinking and aligning Risk Appetite with Value. The principle around Strategy does not quite get the message across either. You need grand visions and hypotheses about how you will change the rules of your market, but then you need "proximate goals" or deliverable baby steps to address them with constant revalidation. Yet again there is the mistake of forgetting about data as well as informed decision making. Probably this is why awareness of the Manifesto is still low.

So we still need a better model and definition of Agile Businesses. Simply put, an Agile Business Focuses on Strategic Value and Quality, moving quickly and constantly to deliver ever increasing value. In doing this, it adopts an integrated team approach, encourages experimentation, prototypes and feed back, and analyses performance and perception data to fine tune delivery and plans. It never stands still, stops adapting or restlessly looking for new ways to improve value. It exercises a strong moral compass and attunes risk appetite to strategic delivery, innovation and optimal performance. It learns from experience, but also looks outwards for new ideas, inspiration and to understand trends.

Well that's my opinion anyway.

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.

DevOps 2018 Report

Puppet has published its 2018 State of DevOps Report. This year they have examined the premises on adoption and confirmed that most successful adoptions follow a project by project approach, with a single project pioneering the way and gradual cross poliantion of practice whilst it is matured.

The project focuses on 2 aspects of adoption:

• CAMS - Culture - Automation - Mearsurement & Sharing

• a 6 layer maturity model from 0 to 5, which broadly follows a simplify and Standardise Approach, Followed by Process Practices, then Automation and finally Self Service capabilities.

One of the themes of the report is the gap between teams practicing DevOps and Senior Management. It still appears that DevOps adopters continue to struggle with cultural aspects associated with empowerment and reporting.

Anyway, for anyone interested in the Lean Aspects of Digital Business Models, this is essential reading.

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).

IT and Digital's New World Order

A common theme in many IT departments or functions is the "Them and Us" relationship with the rest of "The Business". Miles of column print are given in IT publications and by analysts on emotional hand wringing about the lack of connection with colleagues in the business and multiple surveys examine the CIO's role and status in the business as well as his or her relationship with the CEO.

Recently, however, the press has been distracted by the idea of automation and everyone being replaced by AI based automation and the supposed death of many jobs, without actually bothering to analyse the capability of AI tools. the fact is that they are both powerful and limited at the same time and it takes an aweful lot of training to get some quite basic capability out of a machine learning application. Anyone who has used Alexa (Amazon's voice based AI agent for automating your home, answering general knowledge questions and playing music) knows that you can be both delighted and frustrated by her abilities to do what you want or to get it so completely wrong that you wring your hands in despair.

In reality the things having the most impact in the UK are Brexit (because it is used as a general excuse for not making decisions and refusing to hire new staff) and the impact of XaaS and Lean. These are gradually evolving the way in which products are developed and IT works both within itself and with other people in the wider business. It's no longer appropriate to organise IT around functional siloes and gatekeeper roles, which slow down progress and frustrate our business colleagues. The move to end-to-end product teams and more integrative roles means that IT needs to shift its mentality from reclusive castle dwellers to engaged collaborators, as IT becomes a fundamental part of business operations. The rest of the business has to do this too. Because, when you look at it, most other functions suffer similar problems of angst and feelings of under appreciation.

The most difficult part of the evolving role, is how does IT relate to Business Operations once this transition has been made and IT is properly organised to align and integrate with Operations. This means that many traditional assumptions around how to implement ITIL, organise testing or approach enterprise architecture (for example) need to be revisited. People in IT need to move towards taking more interest in the business and its customers, as well as what a collaborative culture looks like. It also means that CIOs need to become more assertive (not aggressive) in engaging with their peers to understand and agree business priorities, as well as partnering internally and externally to move quicker to address urgent needs. Old ideas like "boiling the ocean" with monolithic technology change initiatives need to go. Smaller, quicker steps and daring to experiment is now the order of the day. Whilst, rigorously pursuing simplification, security hardening and IT automation in localised areas as these steps are taken is the path to earlier value delivery. This means that 2 speed IT is a misnomer, its more like 6 gear 4 wheel drive IT, which adapts to different terrain and problems.  

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.

The Value of Data

Today I realised that the evidence for Digital being the New Normal was compelling when I read about the way that the agricultural industry is embracing IoT, Big Data and Machine Learning (see: FoodIT: Fork to Farm ) which provides comprehensive overview of the 4th annual conference examining how to join the ecosystem from consumer to farmer up, so that farms respond to consumer tastes, improve yields, avoid waste and provide the provenance etc. that consumers now want. There are great opportunities to provide the next Deliveroo for farm products and by-pass the super markets entirely. This would greatly improve profitability for farmers and the experience for customers as they get fresh, seasonal, sustainable, quality products directly. It could also bypass the scandal of the modern monopoly of slaughter houses, if the right investments were made.

I especially enjoyed the redefining IoT by the conference as the Internet of Tomatoes, spelling out how much the industry has got into it.

There were also some interesting predictions for Data in another couple of articles on the data makes possible  site by Kirk Borne of Booz Allen Hamilton about trends for this year. Personally I found his comments on graph analytics the most compelling as this is an area of growing maturity in which it is now possible to easily uncover insights into linkages of cause and affect and networks of people and activity. He also had interesting things to say about hyper personalisation and realigning AI with a people centric model of mutual assistance to do more (similar to some of my previous observations). Finally he coined a new phrase DataOps to describe lean development approaches as applied to big data.

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.

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 ).

The Way of DAU - The New Digital Philosophy

For those of you who have come to accept that Digital has become the new normal, it it is not surprising to know that there is a new acronym DAU or Digital as Usual. This replaces the old one BAU or Business as Usual.

There is even a philosophy known as The Way of DAU (pronounced Dow). This is built around 10 guiding principles which encapsulate current best practice in the Digital world.

For those getting started, the principles are useful for driving adoption and practice of Digital. They are:

1.       Understand the Market;

2.       Identify what Changes Rewrite the Rules;

3.    Select High Priority Opportunities;

4.       Build Product Focused Culture and Teams ;

5.       Walk in your Customers’ Shoes;

6.       Embrace Opex;

7.       Go Lean;

8.       Cherish Information;

9.       Nurture Partnerships;

                    10.     Harness Fear of Obsolescence.

Although there is an assumption of a continuous iterative loop to be followed when applying them.

That's all for the weekend.

At The Edge of The Enterprise and the New Lean

One of the Truisms for anyone practising IT Strategy and Architecture, is that All the Competitive Opportunities Arise at the Edge of the Enterprise. Everything else is about making business more fit to exploit them through improving the agility, effectiveness, efficiency and protection of  business capabilities.

This is why Digital has been so important. Digital blurs the edge of the enterprise so that a business may operate globally to reach more customers or provide a more comprehensive service to existing customers. Digital also make it easier to partner with other organisation to deliver new products and services or a better sales and delivery experience. 

Digital also makes it easier to reach out and find out what is going on in the market place and find out what is going on and to affect delivery of service in customers homes, premises and assets through combinations of IoT and Big Data.

However, as companies all adopt digital models and Digital becomes the new normal other things are starting to happen. Customer expectations have risen and improving the "Customer Journey" or the life cycle of customer experience has now become essential. This is now encouraging greater examination of internal processes and capabilities.

Whereas before, internal capabilities were improved for scalability, predictability and efficiency. Now, internal capability has to be optimised to address everything that is essential for delivering service to customers. Digital has become part of the New Lean Organisation. Not only does this change the nature of investment, it requires continuous discipline, development of Enterprise Architecture capability, partnering with Product Managers (especially in Marketing) and investment in flexible productivity technologies such as BPM and Machine Learning to reduce lead times for customer fulfilment, improve consistency and enable employees to spend their time doing meaningful work (as opposed to the drudgery of many repetitive clerical tasks).

This will not only make employees more productive, but it should enable organisations to deliver a wider range of products and services, tailored more specifically to individual customer needs and with enhanced economies. For some people this means more fulfilling jobs. For others this represents a threat to low skill jobs. The biggest challenge now is going to be the (re)training of low skill employees.