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.

Cloud Expo 2019 Shows The Way

This week we had the annual Cloud Expo Exhibition in Excel (London), combining multiple tracks for IoT, Cyber Security, Big Data, Blockchain, AI, Data Centres and Big Data.

As usual the show was massive and noisy, though this year definitely there was more buzz and energy than last year and there appeared to be more exhibitors including a new batch of database and big data tool providers as well as old school adaptors such as Oracle and IBM.

Cloud Expo has a continuous stream of presentations, but to be honest they are difficult to extract much value from, as they are short and the venue is extremely noisy. The couple that I attended just served to reinforce what I thought that I knew already.

One of my personal favourites, Dark Trace, was there with its machine learning enhanced security technology (see past blogs), but I got more excited to see that Check Point had launched CloudGuard. Whilst Dark Trace will help dig you out of problems, Checkpoint is there to stop you getting into them in the first place. On a first inspection of claims and taking Checkpoint's pedigree into account, CloudGuard provides essential and robust means for securing SaaS and IaaS solutions and provides a platform for securing heterogeneous services such as Azure, AWS and Google Cloud Platform as well as many major SaaS applications such as G-suite, Salesforce, DropBox and 0365.

The other great thing which leapt out at me was Aptio's extended offering around cloud. Aptio, if you are not familiar with it, provides ABC (Activity Based Costing) software for IT operations. This assists greatly in understanding the unit costs of your key services at both an infrastructure tower level and an application level. So for example you can calculate how much it costs to support a user of an ERP system, or to digitally support a retail client, as well as understanding basic things such as what does it cost to run a server or support our business continuity plan. As the Aptio software plugs directly into the Finance Module of most ERPs, it uses real financial data and adapts to changes in pricing as they are incurred. So what's new? Aptio has added the capability to deal flexibly with cloud service providers. This makes it much easier to model the costs of say a cloud migration and compare different service providers, For existing users of cloud services it provides the means to model costs of hosting on different platforms on a day-to-day basis and adapt to changing pries and cost models of vendors to identify re-hosting opportunities for cost optimisation. Given the sheer volume of data and relationships to be addressed, this is an almost impossible task to keep up with if performed manually with a spreadsheet, so is obviously a great tool to assist in managing an enterprise estate.

Black Friday Comes Again

So it's that time of year where we all go collectively mad in the herd stampeded for bargains in the run up to christmas.

It's time to reflect that this sort of consumer fever is driven by mobile users and that the statistics are quite incredible for sales and year on year growth.

I know that not every business is involved in direct sales to consumers or that every market in the world is dominated by Christmas. However, many businesses have spikes in activity driven by certain times of the year. Local religious holidays are only one example. In the UK, the number plate registration scheme changes the primay letter on the number plate at fixed times in the year. This triggers not only discounts on cars with the previous period's plates, but also car loans and insurance renewals. Summer time often drives spikes in behaviour around drinks and ice cream sales, and school holidays drives resort bookings for travel in many parts of the world.

The important issue is that sales are increasingly being forced down the mobile access route and businesses need to plan for capacity spikes. This is great news if they are running on cloud platforms, but they should still be running planning sessions and exercises to ensure that they can scale. also they need to look at the back office and operational processes of their businesses to ensure that they can fulfil sales quickly, accurately and efficiently with minimal errors. As many digital businesses only work if they have rock solid operations in the "bricks and mortar" world.

Fundamental to this is the customer experience on digital platforms, IoT type instrumentation throughout the fulfilment process (with real time BI to monitor the situation for load, capacity and bottlenecks) and proven scalability, as there often are little niggles in scaling up cloud infrastructure in a responsive manner.

In the end, there needs to be a contingency plan to deal with SNAFUs such as problems with cloud platforms, which occassionally occur and some planning to deal with the types of security vulnerability which can occur when people, processes and systems are stressed by volume.

So balck Friday (or its equivalent) should be included as a major scenario for evaluation in any business's contingency planning.

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.