Many times I’ve heard colleagues say that ‘failure is not an option’, I’ve even said it humorously myself. But failure is an option and it might just be a good thing to experience sometimes.
Success is highly regarded in our society. It is extremely popular if the sheer number of blogs and websites devoted to it is any gauge. There seems to be an almost feverish chase after success, and it is success defined in fairly narrow terms – wealth, power, achievement, and high regard by other people.
None of these is a bad thing to have. But I do wonder if this chase after them is good for us human beings. I also wonder if the occasional failure might not teach us more about ourselves and the way things work than unbridled success. The knowledge of how to handle failure is critical to persistence and subsequent achievement.
Failure should be an acceptable option for human life. It builds knowledge and, handled properly, can make us more resilient. It is not possible to make progress without taking some level of risk, and the chance of failure is inherent in every risk taken. Of course, I am not advocating failure as a habit, but sometimes failure can be a good outcome.
So many of the great discoveries that benefit our world today are the result of people who knew how to handle failure. They are the result of persistence effort based upon revised knowledge. But if we have never experienced failure and do not know how to handle it then we might never persist until we achieve success.
This past quarter our household water consumption has been reduced by 25%. This effort has not made a negative impact on our quality of life, and it has inspired us to do more. Now trying to work out next steps to reduce usage even more.
Many times recently I’ve found myself in ‘meeting madness’. Someone somewhere has called a meeting, usually sending invitations via Outlook. The invitation usually has, at best, a one line summary of what the meeting is about. No agenda is set and nor are requests made explicit for necessary preparatory work to be completed prior to the meeting. Often nobody can track down the organiser of the meeting to seek clarity on what is expected or required.
The result: several busy people arrive in a room to find that they are not prepared for the actual meeting (since none of them actually knew what it was all about anyway). Often the first section of the meeting is concerned with setting the agenda to direct the discussions. Then the next section of the meeting is spent discovering that essential preparatory work is either not ready as yet or not done at all.
I know that I’m as guilty as the next person in this regard. So my new resolution is NOT to send out meeting requests to colleagues unless there is (a) a predefined agenda, (b) clearly set out requirements for any preparatory work by the attendees; and (c) a timeframe for the meeting.
The only exceptions to this are (a) where the meeting is a ‘catch up’ meeting with another person, where the agenda is simply to have an informal information sharing session together; or (b) scrum meetings that follow the scrum meeting model.
I feel like there are better ways to be spend my colleagues’ time and my employer’s money than on inefficient meetings. Clearly if we all continue the same way nothing will change. I cannot change what others do, but I can change my own meeting practice.
List of scrum rules from Control Chaos
Scrum : an iterative, incremental process for developing software in chaotic environments. Scrum consists of a series of 30 day sprints, each sprint producing an executable. Between sprints, all interested parties evaluate progress and reevaluate technical and business requirements. Work is reestablished and the team enters into another sprint.
The pulse of Scrum is the key to its success … management determines what should be done prior to every sprint, their determination influenced by prior deliverables and requirements. During the sprint, the team is left alone and produces the best software possible : let in chaos, keep out chaos, let in chaos, keep out chaos, let in chaos, keep out chaos … etc.
Backlog : a prioritized list of all work to be completed prior to releasing a product :
- Only one person maintains and prioritizes the backlog list.
- Any interested party can request that backlog be put on the list.
Between sprints, all involved parties and the engineering team meet to determine which work can be completed in the next sprint, and what the executable will be.
Sprint : a short burst of work lasting approximately 30 days during which an executable and other deliverables are built by an engineering team, as indicated by the assigned backlog.
- A sprint lasts no more than 30 days.
- A sprint is undertaken by a cross functional team consisting of no more than 9 members.
- Every sprint has a specific goal.
- An executable demonstrating the goal will be completed by the team during the sprint.
- The sprint team has final say in estimating and determining what they can accomplish during the sprint.
- Once the sprint is underway, new backlog cannot be added to the sprint except that, if the scrum master determines that a new backlog item will enhance the viability of the product, is in alignment with the sprint, builds on the sprint’s executable, and can be completed within the sprint’s time frame, the backlog item can be added. Examples are building a demonstration of the executable for a specific purpose, such as a trade show or prospect.
- If external forces determine that the sprint is working on the wrong thing, a sprint can be halted and restarted with new backlog and purpose.
Scrum Meeting : A short daily meeting where the team shares status.
- During the sprint, the team conducts daily scrum meetings.
- The meetings are held in the same place at the same time every work day.
- The meetings don’t last for more than 30 minutes.
- A scrum master is appointed.
- The scrum master is responsible for asking every team member the following three questions:
- What have you done since the last scrum meeting?
- What has impeded your work?
- What do you plan on doing between now and the next scrum meeting?
- Conversation is restricted to the team members answering the above questions.
- Meetings can be established for immediately after the scrum meeting based on answers to the above questions.
- The scrum master is responsible for making decisions immediately, if required to remove impediments to progress.
- The scrum master is responsible for noting impediments that must be resolved external to the meeting and causing them to be removed.
There is increasing comment out on the net that we are heading for another dot bomb disaster – but worse than last time. A good example is this on slashdot. The question is how resilient is the industry now, has it improved since last time? Perhaps the answer is the same as the answer last time – is the technology being developed and deployed building a saleable business advantage? Technology that does not offer this is doomed eventually as it cannot sustain itself financially.
In the business world any technology that does not have an understandable business purpose and serve a real business need is mere frivolity. Fun but unsustainable in the long run.