Request a meeting agenda ahead of time, that outlines what the participants want to discuss and the best way of using the allocated time. Agendas need to have flexibility, and should act as a tool that force individuals to think about what they want to accomplish in meetings. The agenda helps all involved to focus on what they are trying to achieve and how best to reach that objective.
I'm a big believer in capturing an official set of notes, so inaccuracies and inconsistencies can be caught immediately. All those who attended, and those who missed the meetings receive a copy of the notes. When people are trying to remember what decisions were made, in what direction the team is going, and what actions need to be taken, they can simply review the notes.
This idea can and should apply to meetings in organizations in which people feel as though the boss will use favoritism for the individual instead of embracing the idea. Use the Six Thinking Hats, or at least talk on the raw information you have. Don't mix in feelings, without letting people know that it is just feelings.
To add a little pressure to keep meetings focused, get a timer on the wall, counting down the minutes left for a particular meeting or topic. Impose structure amidst creative chaos. The timer exerts a subtle pressure to keep meetings running on schedule.
A friend of mine once said that the entrepreneur is a person who, in order to avoid working eight hours a day, works sixteen hours a day.
Imagine yourself in a room, there's a meeting, 8 other people are there and the boss is speaking in monologue, talking about everything from hard facts to gut feelings, taking in points from one or two of the others in the room as he/she sees it fit. Most people sit there and take in whatever is being said, and hence is agreeing to whatever the decisions of that meeting are. Recognize it?
Edward de Bono introduced in 1985, Six Thinking Hats, as a framework of thinking about things. A framework that works in meetings as well as your own thinking. Lets look at the hats.
Questions The White Hat - considering purely what information is available, what are the facts?
Emotions The Red Hat - instinctive gut reaction or statements of emotional feeling (but not any justification)
Bad points judgement The Black Hat - logic applied to identifying flaws or barriers, seeking mismatch
Good points The Yellow Hat - logic applied to identifying benefits, seeking harmony
- Creativity The Green Hat - statements of provocation and investigation, seeing where a thought goes
- Thinking The Blue Hat - thinking about thinking
Using the Thinking Hats in a meeting, has proven itself well worth the time it took to understand and explain them. It allowed me and others to stop the Boss's inconsistent monologue, and say: "Now take on the White Hat" (Hard facts with no prejudice) or "Take on the Red Hat for a minute" and get the gut feeling about the subject from all the people around the table.
Sometimes having too much information can interfere with the accuracy of a judgment, commonly called "Analysis paralysis." The challenge is to sift through and focus on only the most critical information to make a decision. It is a lot easier to give input on a subject, when you are forced to think about it in a certain manner, which the thinking hats facilitates to nicely.
An intellectual says a simple thing in a hard way.
An artist says a hard thing in a simple way.
Five “discovery skills” separate true innovators from the rest of us.
The Innovator (1) talks with 10 people—including an engineer, a musician, a stay-at-home dad, and a designer—about the venture, (2) visits three innovative start-ups to observe what they do, (3) samples five “new to the market” products, (4) shows a prototype he’s built to five people, and (5) asks the questions “What if I tried this?” and “Why do you do that?” at least 10 times each day during these networking, observing, and experimenting activities.
Reference: Harvard Business Review
If I'd asked my customers what they wanted, they'd have said a faster horse.
You cannot only ask the right questions, you have to ask them the right way as well.
Reference: Wikiquote and somewhere in dialog.
If everyone is thinking alike, then somebody isn't thinking.
What's the least we could do, that would have all the necessary functionality to be shipped. In software/web industry you can change your product every day. Don't make the developing list be set for the next year or two.
Rest assure, the requirements for what's needed will change as you go along. Figure out what the necessary features are, and filter out the nice-to-have's, build quicker and deploy.
Text: Smidig 2008 [no] Picture: Modern Art
It’s the journey between pages or screens, not the pages and screens themselves, that can cause the most problems for users. Plus - problems with the journey are the most expensive problems to fix.
Design the journey between states first, before designing the states.
Reference: 101 things I learned in interaction design school
Design depends largely on constraints. … Here is one of the few effective keys to the design problem—the ability of the designer to recognize as many of the constraints as possible—his willingness and enthusiasm for working within these constraints….
—Charles Eames
Who goes to Google to search for Google? According to this, a lot of people.
I do not spend all day working on projects, so I estimate in hours of work, not days.
I cannot do a project, so I need to break it into tasks and estimate the tasks.
I find it that when I estimate a task, I usually see it as just doing the work. Take in consideration communication, waiting and ad-hoc changes in requirements.
Have I done more or less exactly these tasks before?
Yes: Hey I'm a better estimator.
No: There's a larger chance of failure.
In hindsight I find this rule amusing: Take the first estimation of number of hours, and multiply that with π (pi), and you get quite close to actual time.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The only thing I miss is:
Purpose and Outcomes over Solutions and Features
Reference: Manifesto for Agile Software Development and Dan North's "Outcomes over Features – the fifth agile value?"
Speed up your development with not adding options to your code, apply sensible defaults instead. Ask yourself: What will 80% of my users be happy with? If you find an answer - cut the option - only add the option, if most people would ask/asks for it.
Example: Adding a drop-down to choose number of results per page? Set the default to 25 items per page. Sensible defaults also helps for consistency in your code.
Reference: Getting Real: It Just Doesn't Matter by 37 Signals
 | Getting more posts... |