Categories
Agile Digital Transformation Insights Lean Startup Organisational Change

I Googled ‘Agile’ — and wish I hadn’t.

I Googled ‘Agile’ and discovered my worst fears. Confusion and mis-information about Agile software development, how it works, and how to make it effective as a method of digital solution delivery.

Following on from the short, rather poorly animated video, let me share a slightly more concise and coherent insight on how Agile should work and how it’s possible to make it a means of delivering exceptional outcomes. Spoiler alert: it’s probably not what you expect or want to hear, but please know I’m here to support you if you feel in the slightest bit unsure about what to do next.

The methods used to build solutions with software haven’t changed significantly for 30 years. And even though we’ve lived in the The Age of Agile for almost 20 of those years, the time it takes to deliver solutions, not to mention quality and efficacy, are still falling short of expectations.

Beyond Agile, examined why software development failed to meet the lofty aspirations of the Agile Manifesto founders. The book also explained how to avoid some of the classic mistakes of Agile software development.

A talk given by one of the creators of the Manifesto for Agile Software Development, Dave Thomas, underlines the dysfunction caused when the principles of the manifesto are misinterpreted or distorted to fit an enterprise IT agenda. He half-jokingly attributes the downfall as our tendency to turn adjectives into nouns; so instead of the title Manifesto for Agile Software Development, people turn it around a truncate it to — Agile Manifesto, thus losing its meaning and purpose.

Beyond Agile explores many of the noteworthy lightweight methodologies in use today, some of which pre-date Agile. This provides context and explains why software development often fails to meet expectations. Another founder of the Manifesto for Agile, Alistair Cockburn, puts it simply:

“The Agile Manifesto was the product of seventeen people from different schools and backgrounds. No one person is responsible for the words we came up with — it is clear that it was the product of all seventeen people. The addition or removal of any one person would have changed the outcome, something we recognised and discussed at the end of that meeting.

Whether you think ‘Agile’ saved the world or poisoned it, be sure always to recognise that it grew from a rich compost (joke intentional) of backgrounds. The next time you read a would-be history of the Agile movement, look for all those names. If you don’t see them, it is not a history; it is one person’s recounting of their journey, years after the event (as indeed, this one is).”

Cockburn’s statement gets to the heart of why Agile is such an enigma: few people bother to understand or respect it for what it is, choosing instead to follow second-hand interpretations of the manifesto or, worse still, adopt a consultant’s cheap imitation of it.

Agile often fails, not because it is inherently flawed or lacking in some respect, but how people interpret and apply the principles. The Agile Manifesto and its core principles are, in fact, quite logical and straightforward. The problem with Agile is it was released into the world and then distorted by people unwilling and unable to think about the true meaning and purpose of the method. Kent Beck, the creator of Extreme Programming and another of the creators of the Agile Manifesto, calls this the ‘staring dog problem.’

“If you try to point something out to a dog, it will look at your finger,” he explains. “If you explain an idea in terms of concrete practices — like test-driven development, pair programming, continuous integration — people will fixate on the practices and stop thinking.”

Kent is calling out that often we’re unable to make the cognitive leap between practice and application. Scrum and other so-called enablers of Agile fail precisely because they compensate for lack of intellectual integrity. They shroud important ideas like user-centricity and fast iteration in rituals and catchy names. The Agile manifesto left too much room for interpretation and not enough specific rules. It feels like we’re back where we started in the late twentieth century with powerful technology and tools but no idea how to make them relevant to the ever changing needs of our enterprise users and customers.

Beyond Agile, describes three outcomes Agile practised well delivers:

  1. Eliminates (or at least reduce) waste in software development;
  2. Creates software that people use; and
  3. Delivers projects on time and budget.

An analysis of fifty thousand software projects conducted by The Standish Group in 2015 found 29% of projects was successful (meaning they were delivered on time, on budget, and to a satisfactory standard). The remainder, 71% were either failures or failed to meet expectations. Just think about that for a moment: starting a large-scale technology project, there’s only a 1 in 3 chance of success. Not very good odds. The same report in 2018 showed the situation got worse, with only 23% of projects successful and 77% unsuccessful.

Other sources corroborate these stats. In a paper presented to the 7th International Conference on Knowledge Management in Organisations, Stanley and Uden proved that software projects typically overrun their budgets by two hundred per cent, and exceed their scheduled completion dates by fifty per cent.

But it’s the cost of project failures that’s the real issue here. It’s nothing short of tragic:

– The cost of re-worked and abandoned systems costs the US economy an estimated $75 billion per year;

– In Australia, $5.4 billion is wasted each year on IT projects that don’t deliver value or are abandoned completely;

– One project alone — the infamously abandoned National Health Service patient record system in the United Kingdom — cost taxpayers £10 billion.

To put those numbers into perspective, the United Nations estimates that a yearly investment of $267 billion would end world hunger by 2030. A meagre $175 billion per year would eliminate extreme poverty globally.

It’s been almost two decades since the Agile Manifesto was written, and even longer since Winston Royce published Managing the Development of Large Software Systems. But little has changed and no single methodology has improved software development; it’s still a hugely expensive and wasteful endeavour that rarely meets expectations. And that’s hard to accept, in any era.

It shouldn’t be beyond humans to come up with a better, more reliable way of developing software solutions. Just as garment makers and car manufacturers in past centuries industrialised their domains, so too software coders need to do the same. Digitisation begets automation.

Methods like Beyond Agile address some of the shortfalls, but it’s by no means a silver bullet. The method requires skilled people, disciplined practices, full engagement with users and problem owners.

When I Googled ‘Agile’ I was hoping for the answer to some of the more taxing questions surrounding the method. What I came away with was this: to make Agile software development successful, there are four areas that align closely to the original manifesto principles:

  1. Start by defining the challenge or problem to be fixed
  2. Define the project outcome in terms of a quantifiable measure
  3. Describe the first 6–12 features or functions the solution must have
  4. Identify the first half a dozen users you’ll engage at the outset and throughout.

Rinse and repeat.

Digital Village is a community of IT professionals dedicated to providing flexible IT project team solutions in an authentic Agile way to enterprises in Australia and New Zealand.

Categories
Agile Customer Success Digital Transformation Insights Lean Startup System Engineering

What Dev Teams Are Missing.

UX designers, check. QA designers, check. Developers, check. The list goes on… but most highly-trained dev teams are missing a vital piece of the puzzle.

Software development is an inherently technical activity but without solving a real human need a project has no purpose. So why are those with the most immediate needs, the arbiters of purpose in this instance, missing from the team?

Standard processes for software development demonstrate the issue (sometimes jovially).

@johncutlefish

Customers and end users, the foremost experts on the business and its goals, are the critical missing piece from software development.

Aren’t they included already?

Well, yes… but not enough.

Towards Customer-Centric Software Development: A Multiple-Case Study found that, even in organisations with a high level of customer focus, that customers were only present at the beginning and end of the development process.

The authors found four key challenges with this approach:

  • Indirect access to end-users led to a lack of understanding of the reasons behind customer requirements.
  • Feature prioritisation is done based on employees’ opinions and is not continuously validated with customers.
  • Testing is seen as an opportunity to identify defects but not to validate mismatches between customer needs and product offerings.
  • A lack of systematic ways to collect, analyse and incorporate customer data into the product development process.

What’s the real problem?

By omitting the customer and end-users from the delivery team you are working on hypothesis (and to some extent guess work).

Even projects undertaken with extensive and painstaking research are based on what a potential solution could look like. This hypothesis isn’t tested until the end of the development phase when complete features are presented to the users and customers.

And now for the grand reveal… The software has been built to the customer’s specifications, or has it been built to the team’s interpretation of the customer’s initial specifications? Without fully understanding the customer’s situation there is a high chance of building the wrong software.

This of course has a huge impact on budget, schedule and, worst of all, the trust between the client and team.

So how does putting the customer and users into the project team help?

Shortening feedback cycles is a central principle of Agile delivery. By embedding key stakeholders within the team, feedback cycles are reduced from weeks to days.

Developers can demonstrate early prototypes and benefit from the unique expertise and feedback that only customers and end users possess. Rather than thinking, “what would the customer want?” at key decision points they can be asked directly.

No grand reveals, no surprises. A product is developed in collaboration with the customer and ultimately the people that will be using it.

Customers and users are busy people – do they have two jobs now?

Obviously we can’t expect the customer to be turning in 40 hours a week, that would be slightly impractical (and rather unnecessary). Attending weekly team meetings and being able to respond to questions from the team is enough.

The point is to ensure the developer feels comfortable making a call to the customer or uses to clarify a requirement or gain feedback on an early version. Essentially, you remove the subjectivity and guesswork to ensure the right product is being built.

Sounds nice – does it really work?

Digital Village recently completed the first iteration of the Race Around Australia project and was rolled out for a successful pilot in NSW schools. Program manager Emily McLachlan was deeply involved in reviewing the work in progress and making critical feature decisions and prioritising application features.

Her involvement allowed the delivery team to frame technical decisions within the needs of the department, schools, teachers and students, which reduced uncertainty around the product to practically zero.

You can read about the project’s success here.

Next Steps

Convincing busy professionals to attend another meeting/ create time for the demands of a project team sounds, well, trick. In fact, the hardest part may be convincing people who feel somewhat out of their depth in a technical project to participate in delivering it.

With the right support, however, non-technical stakeholders like clients and end users can provide invaluable contributions to a project delivery team.

The first step, of course, is a conversation with project stakeholders. Luckily that conversation will be about how they can save money, reduce risk and enjoy the benefits of their new software as soon as possible. We have a suggestion…

Working closely with the customers means the team will share the customer’s disappointments and triumphs, and hopefully shifts the team’s mindset from focussing on feature delivery to customer success.

Categories
Agile Digital Transformation Insights Lean Startup

Time to pump up the tyres on Agile — without a budget blow-out

by Paul Scott, Director and Board Advisor at Digital Village

Photo by Henry Perks on Unsplash

The fall out from COVID-19 has yet to be fully understood, but one thing’s for sure; enterprises will be seeking fast, efficient and flexible ways to solve their problems with digital solutions. Projects have been backing up during the lockdown and now’s the time to begin clearing the backlog. It’s likely to lead to an uptick in demand for skilled resources, but will they be able to deliver fast enough and to quality?

The announcement this week of the budget blow out at the Australian Digital Transformation Agency’s son-of-Mygov project hows just how quickly things can get out of control without a laser focus on solving one problem one at a time.

The methods used to build solutions with software haven’t changed significantly for 30 years. And even though we’ve lived in the Agile Age for almost 20 of those years, the time it takes to deliver solutions, not to mention quality and efficacy are still falling short of expectations.

Beyond Agile, examined why software development failed to meet the lofty aspirations of the Agile Manifesto founders. The book also explained how to avoid some of the classic mistakes of Agile software development.

A recent talk given by one of the creators of the Manifesto for Agile Software Development, Dave Thomas, underlines the dysfunction caused when the principles of the manifesto are misinterpreted or distorted to fit a corporate IT agenda. He half-jokingly attributes the downfall as our tendency to turn adjectives into nouns; so instead of the title Manifesto for Agile Software Development, people turn it around a truncate it to — Agile Manifesto, thus losing its meaning and purpose.

Beyond Agile explored many of the noteworthy ‘lightweight’ methodologies in use today, some of which pre-date Agile. This provided context and explained why software development often fails to meet people’s expectation. One of the founders of the Manifesto for Agile Software Development, Alistair Cockburn puts it simply:

“The Agile Manifesto was the product of seventeen people from different schools and backgrounds. No one person is responsible for the words we came up with — it is clear that it was the product of all seventeen people. The addition or removal of any one person would have changed the outcome, something we recognised and discussed at the end of that meeting.

Whether you think ‘Agile’ saved the world or poisoned it, be sure always to recognise that it grew from a rich compost (joke intentional) of backgrounds. The next time you read a would-be history of the Agile movement, look for all those names. If you don’t see them, it is not a history, it is one person’s personal recounting of their own journey, years after the event (as indeed, this one is).”

Cockburn’s statement gets to the heart of why Agile is such an enigma: few people bother to understand or respect it for what it is, choosing instead to follow second-hand interpretations of the manifesto or, worse still, a consultant’s cheap imitation of it.

Agile failed not because it was inherently wrong or misguided. The Agile Manifesto was an irrefutable thing of beauty, and its core values are spot-on. The problem with Agile is it was released into the wild and then co-opted by people unwilling and unable to really think about it or understand what it meant. Kent Beck, the creator of extreme programming and one of the original signatories to the Agile Manifesto, calls this the ‘staring dog problem.’

“If you try to point something out to a dog, it will look at your finger,” he explains. “If you explain an idea in terms of concrete practices — like test driven development, pair programming, continuous integration — people will fixate on the practices and stop thinking.”

Scrum and other lightweight spawns of Agile are failures precisely for this reason. They shroud important ideas like user-centricity and fast iteration in practices, rituals, silly names and guiding principles. The Agile manifesto itself, despite its brevity, left too much room for interpretation. And now it feels like we’re back where we started in the late twentieth century with powerful technology and tools and no idea what to do with them.

Beyond Agile describes the three reasons why the method was created :

  1. To eliminate (or at least reduce) waste in software development;
  2. To create software that people actually use; and
  3. To deliver projects on time and on budget.

An analysis of fifty thousand software projects conducted by The Standish Group found that in 2015, an average of 29% of projects were successful (meaning they were delivered on time, on budget and to a satisfactory standard). The remainder, 71% were either failures or ‘challenged’ to meet expectations. Just think about that for a moment: starting a large scale technology project you only have a 1 in 3 chance of being able to celebrate success. Not very good odds. The same report in 2018 showed the situation had got worse with only 23% of projects successful and 77% wither challenged or failed.

Other sources corroborate these worrisome facts. In a paper presented to the 7th International Conference on Knowledge Management in Organisations, Stanley and Uden proved that software projects typically overrun their budgets by two hundred per cent, and exceed their schedules by fifty per cent.

But it’s the cost of the failures that’s the real issue here. The financial impact of project failure is nothing short of tragic:

  • The cost of re-worked and abandoned systems costs the US economy an estimated $75 billion per year;
  • In Australia, $5.4 billion is wasted each year on IT projects that don’t deliver value or are abandoned completely;
  • One project alone — the infamously abandoned National Health Service patient record system in the United Kingdom — cost taxpayers £10 billion.

To put those numbers into perspective, the United Nations estimates that a yearly investment of $267 billion would end world hunger by 2030. A meagre $175 billion per year would eliminate extreme poverty globally.

It’s been a long time since the Agile Manifesto was written, and even longer since Winston Royce published Managing the Development of Large Software Systems. But nothing has changed and no single methodology has really improved software development. Software development is still a hugely expensive, wasteful endeavour that rarely meets expectations. And that’s unacceptable, especially as we approach the end of lockdowns in the COVID era.

It shouldn’t be beyond humans to come up with a better, more reliable way of developing software solutions. Just as garment makers and car manufacturers in past centuries industrialised their domains, so too software coders need to do the same. Digitisation begets automation.

Methods like Beyond Agile address some of the shortfalls of alternative methods, but it’s by no means a silver bullet. It requires skilled people, disciplined practices and full engagement with users and the problem owners. Indeed its quite likely that many of the principles distilled in Beyond Agile can and should be applied to other development methods. This would go some way to fixing Agile.

In summary, to make Agile methods work there are four areas to consider which align closely to the original manifesto:

  1. Start by defining the challenge or problem to be fixed
  2. Define the outcome in terms of a quantifiable measure
  3. Describe the 6–12 features or functions the solution must have
  4. Identify the first half a dozen users you’ll engage at the outset and throughout.

Rinse and Repeat.

Digital Village is a community of IT professionals dedicated to providing flexible IT project team solutions to enterprise in Australia and New Zealand.

Categories
Insights Lean Startup

Turn Ideas Into Reality

The big product idea – where it all begins

I have come across several startup projects during this pandemic and thought it would be good to share some insights. We all have ideas and think we know how it should be executed. Whenever I catch up with a close family member and share a few beers, we talk about startup ideas and wonder how great it would be if we could pull it off. I must admit some of it is just pie in the sky. How do we then proceed with that idea and don’t just throw money down the drain?

Oops I spilled the beans

Time to spill the beans on making the perfect product

Here’s your three-step process for turning a dream into a real product:

  1. Everything is created twice, first in mind then in reality. Have a vision statement.
  2. You cannot manage what you cannot measure. Define success measures.
  3. Success is the progressive realization of a worthy goal or ideal. Validate continuously.

The product vision statement

For: «target customer» Who: «needs» The: «product name» Is a: «product category» That: «product benefit. Reason to buy»

A simple, clear and concise vision statement helps you and others understand what the product idea is and whether it is going to stack up against other solutions out there. Follow the format given above and it will help you start off on the right foot.

How to define product success

Great! You are ready to hire some developers and start executing. Have you thought about how you will know whether the right functionality is being delivered? You need to define what your objective is and how you will know whether you have met that objective. Objective and Key Results format created by Andy Grove is a useful tool. Another way is to define a goal for a quarter and the metrics i.e. success criteria to determine if the goal has been met.

Product life cycle

Continuous product validation

In this digital age, product development i.e. Execution has become easy due to availability of cloud services i.e. Software as a Service, Infrastructure as a Service, Platform as a Service, Development as a Service?, * as a service.  This allows ideas to be tested and developed quickly. As you can imagine there might be others out there thinking of developing a similar product.

To test your idea, you need to launch quickly. Change is the only constant these days and the availability of the * as a Service allows us to pivot when needed without too much effort. Quite a few founders fall into the trap of spending too much effort on defining a solution without knowing whether there is a market for their product. It is OK not to have a “normalized” database or not to know exactly how the users will interact with the system.

Take an iterative approach and release early and often. Measure the response from your users and learn from them.

Did you just think of a product idea while reading through this blog? Create your vision statement and define success measures. Get in touch and let us turn your idea into reality through continuous deployment and validation.

Categories
Digital Transformation Insights Lean Startup library meetups Organisational Change Work Life Balance

Finding Balance- a transformation of work life for people and digital businesses

Consider this;

You wake up in the morning, you turn off your alarm, and as you lie there in bed, you check facebook, Instagram, WhatsApp,  Twitter, texts, emails and then the news. Then you go to the bathroom, you use the toilet, brush your teeth, take a shower, get dressed and then head for the kitchen. You drink some coffee and eat breakfast. Maybe you watch the news or check your emails again. It’s the same routine you follow everyday. 

Then you drive to work on the same old route, and when you get there you interact with the same coworkers you saw the day before. You spend your day performing pretty much the same duties you performed yesterday. You might even react to the same challenges at work with the same emotions; Then after work, you drive home; maybe you stop at the same grocery store and buy the food you like and always eat. You cook the same food for dinner and watch the same television show at the same time while sitting in the same place in your living room. Then you get ready for bed in the same way you always do-you brush your teeth (with your right hand starting from the upper right side of your mouth), you crawl into the same side of the bed, maybe you read a little, and then you go to sleep. 

:-/

THEN….

 All of that gets turned on its head.

Last week on the Digital Village Stream we held a panel discussion with:

Josephine Parker
(Leadership, Strategy Implementation, Transformation & Change | Yoga Teacher & Yoga Therapist)

Currently working with Allianz Insurance with their organisational transformation. Jo is a creative, driven Executive Coach, Facilitator and Organisational Development specialist, helping leaders and organisations transform and achieve more through their people.

Justin Rees
(Eighty20 Solutions)

Justin is the co-founder of ‘Eighty20 Solutions’ a modern workplace transformation company specialising in Microsoft systems integration. Justin has a background in running large scale transformation programs for enterprise organizations.

NIkki Thompson
(Coach & consultant – Inner Circle Work)

Nikki has a long history working in the health industry as a clinician and manager. She also brings business and life skills gained from raising a family and assisting her husband on their grain and grazing property. Nikki provides coaching and consulting to empower individuals and organisations to live and work more mindfully. This promotes health, wellbeing ,collaboration and creativity.

Dave Massage
(KPMG Australia)

With over 15 years in the ICT, Banking & Finance and Professional Services industries, Dave specialises in data analytics and strategy development and is passionate about growing and developing dynamic, high performing teams, delivering large scale strategic and transformational programs. Dave is currently the Director of data and analytics at KPMG.

Rachel Atkins
(This Thing of Ours)

With over 15 years in the ICT, Banking & Finance and Professional Services industries, Dave specialises in data analytics and strategy development and is passionate about growing and developing dynamic, high performing teams, delivering large scale strategic and transformational programs. Dave is currently the Director of data and analytics at KPMG.



We spoke about working from home (WFH) and what this might mean for us as people in terms of work and life balance. We also explored the impact on business and how organisations are navigating this change and how they will need to adapt to remain relevant into the unknown future.

 

How are we dealing with the change?

Around the 29 minute mark on the video Rachel describes a change curve model. The Change Curve is a popular and powerful model used to understand the stages of personal transition and organisational change.

Ref: https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model

 

Rachel’s observation was that companies went from being in denial or panic mode to then jumping to focusing on what is going to happen in the future. Possibly avoiding the reality of now. 

Jo suggests that this coping mechanism is where employers need to be focusing on to support their people. Being a crucial point in this journey of change. It is an especially important point in time where there is a need for authentic care and support for people before business implications are considered. 

 

Adapting to change means being flexible. 

In the ‘old-normal’ world there was often a clear distinction between work life and home life. Now that everyone is working from home, co-workers are seeing a new side of their co-workers that is more real as they get to meet their kids in the background trashing the house or the pet dog joining the conference call. Or as a listener shared on Youtube chat on the call, her friend sharing more than expected with her husband’s company. 

But what this ‘rawness’ or ‘exposure’ of vulnerability is doing for people and companies, is bringing them closer together in a more personal and meaningful way. There is empathy between co-workers and also client relations because we are now no-longer displaying a different version of ourselves. The benefits of this authenticity is trust, better communication, culture, camaraderie and togetherness. 

Parents having to cope with a very hectic home life are obviously finding it very difficult, but at the same time coworkers are aware of their challenges because they have a window view into the lives of their co-workers. The team now has a greater appreciation and understanding of the lives of the coworkers and the blend between life and work is more balanced. Dave shared his experiences of this and Rachel suggests how organisations should be supporting their staff at about the 47min mark (here).

 

Will companies want to go back to the ‘old-normal’?

Justin raised a good point about why WFH is working now and what the challenge might be when the lockdown is lifted. Suggesting that WFH is working for many organisations now because everyone is in the same circumstances. The real challenge comes when we go back to the office and there are say 80% of people working from the office and the other 20% remotely. Do those people who are working from home feel that they can contribute and are being heard by the rest of the team? Taking into account non verbal communications such as body language and the effects of physical presence. 

Some people thrive in the office environment and feel a need to be around other people. While others enjoy the solace of their own space and actually would prefer to WFH from now on. We might see a more equal split between those working from home and those from the office. If that is the case, workplace environments and communication technology will need to be re-imagined. (if you are a large organisation interested in exploring what that might look like, I recommend speaking with Justin or someone from Eighty20 Solutions about that). 

 

Jo described a very interesting scenario; now that people are not needing to go into the office anymore, but they will still be wanting the connection and community that comes with the workplace. So the office environment we are accustomed to, could be more about social hubs for people to congregate and work. Which opens up a range of working environment designs that are more functional, enjoyable, productive and innovative.

 

Reliance and Adoption of Digital

The Industrial Revolution accelerated growth through mass production and huge efficiencies. It was throughout this period that organisational structures were formed and systems and processes were prescribed to form the blueprint of business, employment and trade that we still live our lives by today (including school systems). 

This attachment to a Marxist view that value is determined by time of labor input, has developed an expectation overtime that employees need to be in the office, at their desk and sitting there from 9-5. And this is how a company can be sure that things are getting done. This is of course an extreme example of ‘command and control’, but it highlights where we have come from and how things can change. 

When asked about the impacts on business, Dave shared that one of the lasting legacies of this scenario will be a faster and more extensive digitisation of Australian businesses. He expressed the general resistance that organisations have to digitisation and some examples of how much more effective teams can be when truly adopting digital into their organisation. (Thanks Dave for the reference to this great article about such adoption of digitisation in the Australian business community.) 

Digital technology provides an opportunity for businesses to quickly create new customer value propositions. By better understanding the customer, creating more meaningful services and products, and providing an enhanced customer experience through new digital offerings. As more people are online now, there are new opportunities everywhere for organisations to try new things and remain relevant into the new world. 

 

Digital Business Design – Digital transformation challenges and what solutions researchers have learned

Digital business design: ‘The holistic organisational configuration of people (roles, accountabilities, structures, skills), processes (workflows, routines, procedures), and technology (infrastructure, applications) to define value propositions and deliver offerings made possible by the capabilities of digital technologies. 

(Ross et al., 2019) 

 

For mid-large businesses, becoming digital is a competitive necessity. Ubiquitous data, unlimited connectivity and massive automation provides organisations with an opportunity to reinvent themselves, adapt to new markets and evolve for the future of business and the way people work. Reinventing themselves for the future requires stepping into the unknown, and I have great respect for the leaders of these companies who are steering these highly challenging transformations. There is no right way up the mountain and there is no pre-existing cut path guiding the way. 

 

Experimentation and flexibility are characteristics that typically are not associated with large organisations, but ironically this is what it is going to take to navigate the digital mountain.

 

In September 2019, the MIT Sloan Center for Information Systems Research Press published the findings of 4 years of research into a book; Designed for Digital. How to Architect Your Business for Sustained Success. Within it, defining 5 organisational capabilities that companies must develop to succeed at digital. These 5 building blocks of an organisation are:

 

      1. Shared Insights about what digital solutions the company can develop that customers will pay for. (building the intersection between what the business can do and what customers desire.)
      2. An Operational Backbone that captures the company’s requirements for integration and standardisation of core operational processes. (This building block enforces reliability in the execution of foundational processes and integrity of company data).
      3. A digital platform of reusable digital components making up digital offerings (this building block provides access to repositories of business, data, and infrastructure components.
      4. An accountability framework that allocates decision making rights to ensure both autonomy and alignment (this building block defines roles, decision rights, and processes to support speed and alignment in development and use of the digital platform.
      5. An external developer platform that exposes digital components of external partners (this building block provides the technology, processes and roles enabling digital partner relationships. 

(from “Designed for Digital: How to Architect Your Business for Sustained Success (Management on the Cutting Edge)” by Jeanne W. Ross, Cynthia M. Beath, Martin Mocker)

 

What got me into tech, was the fascination with the fact that with technology, almost anything is possible, you are only limited by your imagination. What I love about innovation, is that there are no ‘right’ or ‘wrong’ ideas. There’s only things that work and things that do not. 

So what new designs of businesses are we going to see in the future? What innovative configurations of people, processes and technology will form throughout the evolution of the digital age? What new services, products and offerings are we going to see? And what could this mean for employees and their livelihoods?  

 

Finding Balance: Giving power to the people

Centralised organisational structures have most of the decisions and responsibility at the top of the organisation, while decentralised organisations allow decision-making and authority at lower levels of the organisation. 

Source: referenceforbusiness.com

 

By breaking down silos and verticals into small cross-functioning teams, it can provide the business with greater and faster innovation because of the diverse knowledge and expertise within the one team. There is no skill or knowledge waste and people are learning from one another. Ultimately each team has their own culture. A team culture created by empowering individuals and teams to take ownership and responsibility for what they are working on. Where it is a choice to work, not a requirement.  

 

Funnily enough, the flexibility that companies need is the flexibility that people now need for a healthy WFH and work:life balance. Companies that are adopting ways of engaging people that provide a flexible balance between work and personal life will no doubt attract and retain the talent they want and need. 

 

An example of this is a small team of people dedicated to a specific digital product where they are responsible for its design, delivery and success like a startup within an organisation. The cross functioning team can quickly innovate, test and make decisions without getting approval from further up the org chart. There is ownership and purpose in this way of working that is empowering and enjoyable. And it gets results. (learn more about DV teams here)

 

Transformation of work life

In Nikki’s words; 

COVID to me is giving us a beautiful global tap on the back to say change how you do business, because if you don’t your grandkids are not going to be impressed.’ 

 

We are being forced to look at the world in a different way. The way we work, the way we live, the way organisations operate, serve their customers and engage their people in employment. 

Like the movie Finding Joe, we are all on a journey of transformation where if we break from the shackles of the past, we are sure to come out better than how we went in. But we need to make choices and take risks and be willing to let go of the way things were. 

Whether that be the shackles of legacy organisational structures or personal baggage we hold onto, we have the choice for a more balanced work life.  

 

Finally, 

Consider this;

You wake up in the morning, you turn off your alarm, and as you lie there in bed, you have a choice. How will you choose to live your life?   




Join the mailing list & stay connected

Categories
Insights Lean Startup library meetups

User Story Mapping

You have an idea for an app. But how do you explain what you want to a development team?

User Story Mapping is a tool to visualise an end-to-end flow of the user experience of a service off a product.

This is useful if you’re a startup or business wanting to build a piece of technology. It helps you communicate what you need in a way that allows both technical and non-technical people to come together and speak the same language.

 

8 simple Steps of User Story Mapping

how do you  translate your vision of a digital product into a collection of user stories to populate a product backlog?

Creating a Story Map: Start with the Backbone

Step 1: Individually describe tasks needed to complete an activity.

Specify individual tasks on each Post-it note.

As a group, write these down individually in silence.

Think about the entire user journey from start to end and what actions the user is taking , what decisions their making and what they need to do for them to reach their goal.

Step 2: Combine common tasks and remove duplicates.

Come together as a group now and combine the common tasks. So there is unique tasks for each step in the user journey process.

Working in groups reduces the chance of missing things. Coming together to collaborate is like a giant bran of collective intelligence. The benefits of collective thinking.

Step 3: Order tasks from left to right in a narrative flow.

Order the tasks from left to right in a sequence from start to finish.

Step 4: Identify group and define activities.

Once you have your story line you can look at the relation of each step and group them into categories so you can see the fully functioning process at a high-level.

Step 5: Test for gaps and update flow if needed.

Review the process to see if there is any gaps. Is there anything missing from a business case or user perspective.

Creating a Story Map: Build Out Map with Prioritised Stories

Step 6: Map stories to expand out each user task.

Now that you have your high level user journey, you can start digging into what the user needed to do within each of those steps. Now, create user stories for each of these steps.

As a…. I want to…. So I can……

Each User story should meet. Criteria using the INVEST principle.

Independant: stand lone

Negotiable.

Valuable

Estimable

Small, enough to be developed in 1 iteration (20 day sprint)

Testable; can it be measured, is there an acceptance criteria.

Now, everyone generates as many user stories as the can, against the move INVEST. And places them under their most suitable task lists and activities.

There is no limit to the number of user stories.

Creating a Story Map: Build Out Map with Prioritised Stories

Step 7: Prioritise the stories under a task.

Now, you need to go through each user story and start to categories each one against a MOSCOW rule so you end up with a prioritised list of user stories.

Must have

Should have

Could have

Won’t have

The result of this will be a list of Must have user stories that will make up the backlog of the next development sprint.

Creating a Story Map: Create Outcome-based Release Slices

Step 8: Create Outcome-Based Release Slices.

You now have a clear backlog of user stories that can be handed to the dev team for the first sprint. 

Categories
Insights Lean Startup library meetups

How to apply the Business Model Canvas

What is the Business Model Canvas for & how do I use it?

Who are your customers? How do you create value for them and how do you make money?

The business model canvas is a framework to compartmentalise the various aspects that bring a business together to create value for its customers. 

The BMC is a incredibly useful tool that provides a visual representation of your business. It lays out how the different operations within your business function in relation to each other and quickly highlights the areas that have not been getting the attention they require. 

In this Meetup session we walk through each of the 9 segments discuss what they are and give some examples and then we applied them to some of our members businesses right then and there!

Some Snapshots of the evening

Some Next Steps

  1. Download your own BCM
  2. If you would like help with your business model canvas email Jason
  3. If you would like help with your business technology go here to create an account and submit a brief.  Sign Up
  4. See upcoming events
Categories
Lean Startup library

Innovation Accounting

A way of evaluating progress when all the metrics typically used in an established company (revenue, customers, ROI, market share) are effectively zero

Eric Ries (author, The Lean Startup)

 

 

 

Measuring Success

Satisfaction

  • Is there anything more important that User satisfaction?

 

  • Our hypothesis is that if everyone on all sides of the 3-sided marketplace are satisfied, then this will result in positive financial outputs.

Our metrics are advanced rating systems where we measure true satisfaction of all users.

 

How does satisfaction correlate to cash?

Digital Village runs project

 

We are developing a matrix that is again derived from Lean Startup (page number) that measures a users wants and needs is relation to the different experiences the business offers.

 

Client Producer Specialist
Personal Needs

(internal)

90/100 50/100 20/100
Interactions with others

(External)

50/100 70/100 70/100
Interaction with DV (platform tech etc) 30/100 85/100 50/100