August 31, 2006 at 1:01 pm
· Filed under business, general, technology
I once received a powerpoint presentation from a colleague; in the business world, powerpoint presentations are often amourously called “powerpoint decks.” Well, this deck was a huge one — 80 pages long. And, no, I didn’t read it, not one single page of it.
I am a huge fan of Edward Tufte. In his book, The Cognitive Style of Powerpoint, he explains why the widespread use of powerpoint isn’t good for any of us. He argues the following:
Permalink
August 31, 2006 at 7:56 am
· Filed under business
All — today is the final day to join the Free Amazon.com Schwag Raffle. If you win the raffle, you’ll get [5] free authentic Amazon.com shirts. Details of the raffle can be found here.
Permalink
August 30, 2006 at 5:34 am
· Filed under business, general, technology
Forget what I said earlier. I’m back on Django; and Python is just the best language for what I want to do. My list of current personal projects include work in combinatorial auctions and something else. Django, Python, and MochiKit are what I’ll be using.
I experimented with Ruby on Rails, but didn’t get too far. I tried OpenLaszlo, but it was way too high level (too far away from the machine). I’m not a fan of PHP, really; so, anyway, yes, I’m back on Django for good.
Permalink
August 29, 2006 at 5:34 am
· Filed under business, general, technology
I’ve been a user of Linkedin for over a year now. I receive invitations from people for me to join their network and, until recently, I’ve unthoughtfully accepted any invitation that came my way. Well, I looked at my network today, and I honestly don’t know half of these people. Sure, there’s an argument that says that I need to keep a rolodex of folks handy for networking purposes, or whatever. But, it’s network of 35% strangers right now.
Permalink
August 28, 2006 at 5:00 am
· Filed under IT at Toyota, Lean Consumption Maps, agile/software, book reviews, business, drum-buffer-rope, featuritis, general, heijunka, ishikawa, kanban, lean, metrics, muda, obeya, operations, pareto principle, product development, quality, root cause analysis, six sigma, technology, variation, waste
Last week, I invited the readers of shmula to pose questions to Mary Poppendieck, the author of Lean Software Development: An Agile Toolkit for Software Development Managers (Paperback), which won the Software Development Productivity Award in 2004 and, the sequel Implementing Lean Software Development: From Concept to Cash (Paperback) which will be available in early September 2006. For this interview, 12 Questions were submitted and Mary was gracious enough to answer them — the reader’s Questions and Mary’s responses are below.
+++++
Permalink
August 26, 2006 at 9:11 pm
· Filed under agile/software, amazon, business, dynamic systems, general, lean, metrics, operations, six sigma, team size, technology
I’ve written about the importance of team size before, here, here, and here. Previously, this is what I said:
I’ve written about efficient teams before here and here. At Amazon, there is a concept of a 2-pizza team: no team should be larger than 2 pizzas can feed. It’s a great approach to team size. In my short career, I’ve learned how true that rule is. Here’s another thing I’ve learned –
- 2 people are smarter than one
- 3, 4, 5, 6, 7, 8 people are smarter than 2
Permalink
August 25, 2006 at 4:04 pm
· Filed under agile/software, amazon, business, dynamic systems, general, lean, metrics, operations, six sigma, team size, technology
I’ve written about efficient teams before here and here. At Amazon, there is a concept of a 2-pizza team: no team should be larger than 2 pizzas can feed. It’s a great approach to team size. In my short career, I’ve learned how true that rule is. Here’s another thing I’ve learned –
- 2 people are smarter than one
- 3, 4, 5, 6, 7, 8 people are smarter than 2
- a team larger than 9 people is just one big dumb blob
Permalink
August 24, 2006 at 7:41 am
· Filed under 5S, Lean Consumption Maps, agile/software, business, drum-buffer-rope, general, ishikawa, lean, metrics, operations, root cause analysis, six sigma, team size, theory of constraints, toyota, variation
5S is part of the Toyota Production System, anglicized in the US as Lean. 5S is a reference for standardized cleanup, order, or tidyness. Defined,
- Sort (Seiri): This refers to the practice of sorting through all the tools, materials, etc., in the work area and keeping only essential items. Everything else is stored or discarded. This leads to fewer hazards and less clutter to interfere with productive work.
- Straighten (Seiton): Focuses on the need for an orderly workplace. Tools, equipment, and materials must be systematically arranged for the easiest and most efficient access. There must be a place for everything, and everything must be in its place.
Permalink