Category: Uncategorized

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.

For years almost all of the problems we’ve had at the restaurant have resulted from rumour and gossip.

We don’t have many strict rules, but one of them is that if you want to discuss another team member unless it is to say how well they are doing, you have to be willing to repeat what you are saying with that person present. If you are not, then we don’t want to hear it.

People discussing remuneration has been one of the recurring issues.

I’ve been toying with the idea of putting a list on the wall showing everyone’s remuneration with a note explaining why there is differentiation in the rates. each time I’ve discussed this with team members or professionals I was told this was a bad idea.

After researching what great Scrum companies do and listening to Jeff Sutherland and talking to Joe Justice, I’ve decided to take it a step further.

Here’s what I have decided to do:

My first list of making work visible

1. Share my vision openly with the world through this site and through a vision board which will be a series of epics written on post-it notes and put on the wall at the restaurant. This will be in a prominent place where customers and team members will be able to see it. I will write these in the form of a Product Backlog Story, “As a customer I want ………….. so that …………….”, If I can’t put it into the perspective of a) a customer or b) a team member, I probably won’t include it.
2. I will make our accounts public and encourage the team to read them and teach them how to understand what the numbers mean.
3. Publish all salaries so all can see.
4. I had a thought yesterday about creating an ascending remuneration package where every team member is trained to do every job in the restaurant. it will lead to an ultimate qualification called “Restaurant Owner” where the team member will have enough information to open and run a restaurant from scratch. when they reach that point they will be entitled to a full share of the profits and before that, they will be entitled to a scaled down amount dependant on how much knowledge they have of the various roles. There’s something great that comes out of knowing all of the jobs in your business, it enables you to make better decisions and it enables you to do any of the jobs you undertake better.