Month: November 2017

Manifesto for Agile Software Development	Comments
Individuals and interactions over processes and tools	Yes, self-explanatory
Working software over comprehensive documentation	If we define “working software” as something that is of real use to the customer, something that has value, that the customer is happy to pay for, we are getting closer to being able to find a definition that would translate to a restaurant – so we could say “food, drink, ambiance, and service that they need and want, once they experience it” I add the last part because of ‘Humphrey’s Law’ which says in software dev. that users do not know what they want until they see working software. Often end users say, “I’ll Know It When I See It” (IKIWISI). I think the same is with most things so the importance of testing on the customer as often as possible, the “inspect and adapt cycle” where we have iterations or evolutions of products all based on testing and feedback direct with the end users.
Customer collaboration over contract negotiation	OK, I covered that above, but how does the contract negotiation part relate to a restaurant? Well, it would apply if we were arranging a wedding lunch for a client, rather than trying to lock them into an agreement, to be constantly evolving the event so as to maximize the client’s satisfaction. In a single service, it’s about getting constant feedback from the customer and adjusting the service based on their needs in the moment. Also allowing and encouraging customers to ask for changes to regular menu items. “I’d like the salad with the dressing on the side”  or “I’d like extra green vegetables instead of the potatoes” etc.
Responding to change over following a plan	This is such a fundamental part of working in the hospitality industry, we have a plan at the start of a service or party, but needs change constantly, so we have to respond to what is happening at the moment, as  Eisenhower said, “In preparing for battle, I have always found that plans are useless but planning is indispensable.” and “Plans are worthless, but planning is everything”
12     Principles behind the Agile Manifesto
1)      Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.	OK, in a lunch or dinner service, this means to serve quickly and respond to what the customer wants, to anticipate in each moment and get things moving quickly.   On a longer-term perspective, we can think about product development. Things like a) seasonal changes b) health trends c) product improvements whether to do with food, drink, service, ambiance.   As an ‘agile’ company we are attempting “Kaizen” – constant and never-ending improvement in every aspect of what we do. These improvements should happen often and be in line with what the customers need and want and be developed by the team by pulling from a prioritized backlog.
2)       Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.	Self-explanatory
3)       Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	See point 1) above
4)       Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.	Self-explanatory
5)       Business people and developers must work together daily throughout the project.	Self-explanatory – in our business ‘developers’ are chefs and front of house team members including receptionists and home-delivery operators – cross-functional teams, and ‘business people’ are the shareholders, suppliers, legal professionals, the executive board and any management.
6)       The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.	Yes. Pre-shift meetings and hands-on training etc. Pairing, and Scrum of Scrums (sharing impediments) and Meta Scrum (sharing and dividing up the vision).
7)       Working software is the primary measure of progress.	What is our version of ‘working software’? I suppose it’s great quality products we can sell to customers.
8)       Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.	Self-explanatory – let’s make sure our team members have enough time off to enjoy life!
9)       Continuous attention to technical excellence and good design enhances agility.	Self-explanatory
10)       Simplicity–the art of maximizing the amount of work not done–is essential.	Self-explanatory – KISS – keep it super simple, but as Einstein said, “everything must be made as simple as possible, not simpler”
11)    The best architectures, requirements, and designs emerge from self-organizing teams.	Self-explanatory – the people doing the work know best how to do it and let the teams self-organize to create harmonious teams – some combinations of team members are better than others
12)    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.	Self-explanatory – This is the key – the Kaizen, the way we become great.

 

Keith Cunningham said, “what would your business look like if you never lost a customer”.

For the last few years, I’ve thought about it a lot, I thought about what the business would look like, but comparing it to now, how it is.

I think I missed the point of the question. It came to me this morning what would my business look like if we had never lost a customer, what type of business would it have to have been and what would it look like now? What would the business have had to look like in order to have made that happen?

What would the business have had to look like in order to have made that happen (that we had never lost a customer)?

This is such a great question and it forces us to do two things:

1. Imagine the perfect business from the customer’perspective.
2. Imagine what things would have to have looked like at those moments when things have gone wrong in the past for them a) not to have gone wrong in the first place or b) if things had gone wrong, for the situation to have been resolved so well after they went wrong that we turned it around and showed how much we cared and won a raving fan?

This is where we can start building a list of potential things to work on, it’s what is called the Product Backlog (PB) in Scrum.