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.
Tuesday, 27 November 2018
Thursday, 1 November 2018
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.
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.
Subscribe to:
Posts (Atom)