Why Agile is important for Digital?
I know, Agile people have a very strong bias, they think agile everywhere.
On the other hand, how are digital people? Or even better, let’s look how digital is addressed by experts.
Most of the publications, presentations in conference or projects are only speaking about technology such Cloud, AWS, Blockchain, ERP systems and other robots and internet of things. Digital is an old topic and everyone is using it. But, what can we see as a digital nomad is just a huge mess.
When I travel to New York City, I have to buy Data Credit through a long procedure to use my Phone Navigation System. The ATM or any Public Transportation ticket machine ask me my ZIP Code and not my PIN number.
When you travel in Germany with your Lufthansa App, you have to log in twice, check a catalog of legal requirements (AGBs) to get access to the wrong informations.
Indeed, these are small examples and I’m quite sure you are knowing way more. Or maybe not if you are living in South East Asia and Japan, then you know way better.
I can speak for Western Europe. Here, compliance comes first and even the customer has to comply with regulation. It goes better since the last century. You have now Train tickets locating you and counting down to your location, adjust the price. You can buy a Bus ticket by SMS in France. It’s nice indeed but, I have to say, the customer experience is almost awkward. In a Pokemon Go era, we can do better as providing experience in low caps.
And what does Agile is that context?
Agile is putting the customer in the middle of the work. When I write Agile, I don’t mean the tools, the methods or anykind techniques (tecne). I don’t mean a catalogue that will be consumed by possible customers. I mean projects or development having customers engaged with the developers in fast experiments.
The genuine Agile roll-out process goes from Vision to Customer Experience and, from Customer Journey to User Stories. In Agile, Customer Experience and Journey are build with… customers and, User Stories with …Users.
And what’s about the MVP? The Minimal Viable Product is usually misunderstood as Minimal Set of Requirements instead of Customer Must-Have Needs First.
Very few companies are really doing it properly. I have to mention that one company has impressed me by doing it right, that is LaPresse in Montreal. I never had the opportunity to see it, but I attended J.M. DeJonghe’s presentation in Paris and I really liked what I heart. The concept was that the teams are working directly with the customer. Product Owner is translating the needs into a vision. Once the solution is delivered, then only then, the solution is documented and move up in the company structure. That’s not a revolution. That’s Agile at its simplest and how it should be.
The Agile Way of doing Digital
A couple of years ago, I designed a working model called Agile Digital Enterprise. I improved the name by calling it now “swarming”.
Swarming is a two weeks wave (release cycle) of two one week sprints starting in a Service Design manner.
Problem is a time-boxed workshop, facilitated by the Customer Journey (CJ) to ensure that we know what the customer want in terms of « DO-THINK-FEEL ».
Options is a « Service Jam » or « Hackathon » with a team of self organizing people gathering in a 2 days rush to create a working prototype including its business case. Like in Hackathons or ServiceJams, purpose is to produce as much as possible options for the customer. OPTIONS closes with a Review and the customer select the best option to work on it. Customer can be involved during this workshop as an agent in immersion. Outcomes of OPTIONS are working prototypes and cases in Lean Canvas format as example.
Prototype is a second run of a 2 days co-creation workshop with a team of self organizing people. In PROTOTYPE, all the attendees are working on the same CJ (outcome of OPTIONS). The first day is a build, the second day is a “destroy”. Destroy means to push away all the unnecessary features from the prototype to provide a Viable Solution (MVS). MVS is the minimal set responding to the CJ. Outcome of PROTOTYPE is the readiness to release.
Viable Solution is a one week iteration where the Development Team build the MVS ready to deploy. The MVS ends with the Review and a Retrospective.
1. Problem
Practices: facilitation, Service Design, co-creation.
Processes: explain the demand, generate first ideas, destroy first ideas (resilience), generate new idea, align the idea (resilience), refine the idea on robust story telling shape (obvious for all stakeholders).
Tools: visual management and facilitation tools only.
Infrastructure: safe facilitation room, ideally not in the day-to-day business facility.
2. Options
Practices: facilitation, Service Design, co-creation
Processes: start with the problem, have different teams working on that problem, make a cross-pollination review in the middle of the day, refine, pretotype and demo.
Tools: visual management and facilitation tools only.
Infrastructure: safe facilitation room, ideally not in the day-to-day business facility.
3. Prototype
Practices: facilitation, Service Design, co-creation, UX Design, Software Architecture, everything that matters to create a powerful solution.
Processes: improve the option, design a prototype, build the prototype, test the prototype, destroy to reach the Minimal Viable Solution with the customer.
Tools: visual management and facilitation tools, and all the necessary tool set that helps to get the prototype done.
Infrastructure: safe facilitation room, ideally not in the day-to-day business facility
4. Viable Solution
Practices: facilitation, Service Design, co-creation.
Processes: the Development Team helps their early involvement knows what and how to build the MVS.
Tools: visual management and facilitation tools only.
Infrastructure: safe facilitation room, ideally not in the day-to-day business facility.
This is how, my team and I are doing Digital Projects even SAP 4Hana.
Like Agile, it looks simple but application may be a bit challenging.
from Zürich with love
Pierre
