Improving the world with software

Essays from 2008, page 5

63 essays from 2008

1. 49

   Don’t blame, reward people that surface their own mistakes!

   In Lean thinking errors or mistakes are seen as opportunity for improvement and growth. But in lean, mistakes don’t come alone, they also provide an opportunity for the team to create a poka-yoke tool/device. Poka-yoke stands for “mistake proofing”, i.e. making sure the same mistake does not happen again. This can only be done by …

   11 April 20082 min readteams

2. 50

   The Proxy Product Owner, a pattern in Scrum adoption: version 1

   Below I try to describe a pattern that I’ve faced and have seen in other teams in the context of an Agile transition.See the explanation section for more details on each of the sections in the pattern.If you have faced similar situations let us know of your own story in the comments below. Proxy Product …

   10 April 20085 min readcode

3. 51

   Personal Scrum or Work 2.0

   So, I’ve been inflicting Scrum on myself. This is my “eat your own dog food” because I’m an Agile Coach at the company where I work, which in practice means that I try to work with teams and help them with Agile adoption, and in some cases with the Agile development. For me to preach …

   8 April 20083 min readteams

4. 52

   Proximity in the office is a sure way to increase communication (and the quality of it)

   I get this question often: “How should we organize our office?” or the variation: “How can I prove to the people in my team that we should work in the same room?” The reasons for working in the same room are many, but there’s also some trade-offs. First let’s look at some indications of proximity …

   25 March 20081 min read

5. 53

   Separation of design and requirements may have destroyed more software projects than waterfall…

   The people that convinced us to never mix design with requirements may have wrecked more software projects and destroyed more value in the software industry than anyone else! Just think what happens when you separate requirements from design: You don’t validate assumptions to more than a very superficial level (the “I don’t care about the …

   24 March 20083 min readcode

6. 54

   Admitting mistakes is the first step to learning, not just for you, but also for your team and company

   Here is an excellent piece from the blog Evolving excellence about how a worker at Toyota battled his fear of admitting a mistake and was rewarded by his pears and supervisor for not hiding, but rather disclosing the mistake he had done. Admitting you committed a mistake is a very important part of continuous improvement. …

   19 March 20081 min readteams

7. 55

   Busy vs. Productive, which one are you?

   Eye-opening piece about the biggest cliché in the work-world: Work smarter not harder (or longer). Do you see yourself in this? Busy-ness is impressive. It puts you in the heat of the action. It gives you an elevated sense of importance. You’re always late for social engagements, barely have enough time for family get-togethers, and …

   19 March 20081 min readteams

8. 56

   Testing to script is waste, creative testing is extremely valuable

   Testing is a hard job. Imagine this, you have to make sure an application of more than 2 million lines of code is ready to ship. It all depends on you, and your team of 2 testers. How do you do it? Well, one way to do it is to make sure you cover all …

   17 March 20082 min readcode

9. 57

   Adaptive Path discovers Apple’s Mojo, but Toyota got there first

   In a post called “Apple’s Design Process Through a Keyhole”, the blog over at Adaptive Path mentions one technique used at Apple when designing product. The basic idea is that in Apple, designers come up with 10 possible designs for a new feature (and I bet more than 10 for a new product). Then diligently …

   13 March 20081 min readcode

10. 58

    Communications of the ACM does not have proper review process for articles about Agile

    I was quite stunned (to say the least) when I read an article published in Communication of the ACM (October 2006 issue). The article has some fundamental misunderstandings about Agile Software Development and Methodologies in general. Here are some of the excerpts that caught my attention and then my comments on them: Here’s a few …

    7 March 20084 min read

11. 59

    On the subject of problem solving, and problem root causes

    Problem solving is key to the discipline of software development. What we do when we code/test/release a software product is essentially problem solving. We learn about a problem we analyze the root causes and then we come up with a solution. This post by Brett Schuchert reminds us that very often the apparent causes of …

    2 March 20081 min readcode

12. 60

    Why failing is learning, and learning is needed

    This week we had a couple of world-class trainers and speakers at our company, and boy did we learn! Dyson, the guy who re-invented the vacuum cleaner said that failure is the essential part of innovation and learning. In his company’s site he states that “15 years (…) and 5000 failed experiments” were required for …

    2 March 20081 min read

Nothing matches that yet.