Agile Renaissance

TDD Coaches Should Not Pair with their Coachees

Norbert Winklareth — Sun, 25 Nov 2007 17:04:08 GMT

This summer I had the opportunity to work coaching some C++ developers in how to do Test-Driven Development (TDD). The workspace assigned to these developers made pair programming an almost impossibility. Rather than fight the physical limitations I decided to coach them without using the keyboard. To my surprise, coaching this way was both easier and more effective then I thought it would be. Coaching TDD is about form: is the coachee following the methodology; where are they having difficulties; how is their rhythm; are they partitioning the problem as fine grained as they need to; are they refactoring; and so. When you don't pair, when you don't have the ability to just grab the keyboard, you are free to focus entirely on the coachee's form.

I also notice that the coachee sets the pace of the work. The coachee is doing it all and so they learn it at their own pace. There is also no expert magic involved in the outcomes. Every person that I coached extensively - there were some who due to scheduling I only had one session with - reached a point of puzzle/amazement. During a review of their work, they would look at their code and their tests in a form of disbelief, coupled with knowing that they had written all of it and that the coach had not made the code magically appear. When this happened, they now knew the value of TDD.

I also discussed this coaching style with a number of the coachees and the majority stated that they preferred it and found it more effective then the pairing approach. So the next time you find yourself coaching someone in TDD consider not grabbing the keyboard and focus on the coachee's form and letting them learned TDD directly and at their own pace.

Links for 2007-07-11 Part 2

Norbert Winklareth — Wed, 11 Jul 2007 12:57:00 GMT

Agile PM in Several Different Domains
Glen Alleman is antidote to the cool-aid of what constitutes the limits of the development world.
Rails Code Review
Tell, Don't Ask
Applied to program development (I also have a weak spot for any post that talks about invariants.)
OO in One Sentence: Keep It DRY, Shy, and Tell the Other Guy
I have recently come to see how many people do not understand how to this when developing OO code.
11 Ways Agile Adoptions Fail
Confusing story telling with narrative
How To: Live and Learn with Retrospectives
Perception of Time & Priorities: Polychronic vs. Monochronic
Personally, I am schizochronic.
The capture-recapture code inspection
Uses probability to determine how many defects are undetected in your code - this is based on the work done to predict how many animals there are in the wild. Using this insight is so cool.
Leading and Creating Collaboration in Decentralized OrganizationsCaveat: research paper.
Putting Six Sigma back in its box ....
On the tension between improving how we do our knowledge work and stifling the knowledge work as presented by a critic of wide adoption/promotion of Six Stigmata.
More on balance ....
Complexity Creep
What developers can learn from ancient stadium builders
Wow! brings strong creditability to the old saying: that there is really is nothing new under this Sun.
Was Bill Gates Lucky? How about Einstein?
Well were they punk?

Links for 2007-07-11 Part 1

Norbert Winklareth — Wed, 11 Jul 2007 12:21:05 GMT

I let doing this on a regular basis slip, so here comes a little rush of links I liked or found interesting, enjoy!

Two Good Rules
Five R's of Agile SCM Baselines
How to Get Your Time Back
Six Sigma, Lean, and Executive Satisfaction
I agree with Peter Abilla's conclusion about what Lean and Six Sigma practitioners needed to do in light of the results of this survey of Executives views on Management tools. I wish that a similar survey of attitudes towards Agile and its various methodologies would also be done.
Visualizing Software Systems as Cities
What is a Capability, Anyway?
Book Review: Refactoring Databases: Evolutionary Database Design
Good review from an experienced traditional database person.
How much does a Story Point cost?
The Pipelining Anti-Pattern
How SaaS changes the SI universe
Five things to remember when calculating the Cost of Delay
The Big DIP
By The Book 3: Throughput Accounting
How to innovate on time
Overcoming Fears with Collaboration
Adaptation and organisational change
Do SaaS ventures need VCs?
Henry Ford said that you should look to your manufacturing line for financing, seems the SaaS people are following this advice.
How To Share Lessons Learned
I like Mr. Meier, he always trying to come up with simple, small and effective ways to use the tools at hand.
The potential and peril of the postmortem
Sets the previous link into a larger context, failure to heed this advice will render feedback useless; as I so regrettably know.
50-Strand Template for Building a Word-of-Mouth-Worthy Business
Notes on "The Likeability Factor" (Tim Sanders at Austin Texchange)
A Kanban System for Sustaining Engineering
I am a huge fan of David Anderson and most recently his Kanban work at Corbis. This link is to a presentation he made on his work at Corbis and it is very enlightening.
Agile Suitability Filters
I am also a fan of Mike Griffiths and here he presents guidelines in determining which methodology to use on a project.
Humane Interface - Ask Aza Raskin Anything!
How Many Ways Can You Do Kaizen at Your Company?
Product Owner and business marksmanship
How Team Leaders Show Support or Not
Something I wish I had done more of.
Organizational Designs and Innovation Streams
Caveat: Research paper.
Nil nisi bonum
Love the title. Nice little riff on the benefits and challenges of speaking constructively.
Metrics in the Lean and Agile World
Softwarenaut: Cutting Edge Visualization in Software
When systems get big how do you see or know or come to understand what is there? Here is an interesting attempt at tackling this problem.
How to Get Things Done - Colin Powell Version
Interesting for the insights it gives into the man.

Links for 2007-05-27

Norbert Winklareth — Sun, 27 May 2007 15:20:00 GMT

Challenging why (not if) Scrum works
Alan Shalloway argues that the structure provided by Scrum, which is really just applying Little's Law, is sufficient to improve an organization's productivity. He does not argue that it will provide maximal benefits which you would get if you would also apply the humanistic aspects of Agile/Lean philosophy. I agree with him.
Design verification capability
7 faces of leadership
I like when people try to distill an open-end broad activity down to a few principles. It gives you a view of the person's biases and belief systems.
PMI Community Post
The title is misleading as it refers to what inspired the post. The post is about accounting for and handling variance in projects, which is in my opinion the least understood of the 4 fundamental underlying issues of product development or project development.

Links for 2007-05-25

Norbert Winklareth — Fri, 25 May 2007 08:44:00 GMT

Team Solving: The Under Utilized Power
From 2001 through 2006, my colleagues and I had on time delivery and this post explains one of the reason's why.
Why Do Deadlines Matter?
An amuse bouche on an important aspect of development -- although this aspect is more so from the larger organization perspective rather than development's desired point of view.
Balancing Perfection against Innovation

Links for 2007-05-23

Norbert Winklareth — Wed, 23 May 2007 16:36:00 GMT

Commitment, Delivery and Customer Expectations
Speed As A Competitive Advantage
Interview with Laurence Haughton one of the authors of It's Not The Big That Eat The Small...It's the Fast That Eat The Slow about his thoughts on this book 7 years later.
Pitching Agile to Senior Management

Links for 2007-05-22

Norbert Winklareth — Tue, 22 May 2007 13:47:45 GMT

Zero Equals Seven in the Kaizen Mind
This is a short post that is about hope or as Douglas Adam's so eloquently stated it, Don't Panic.
A History of Haskell: being lazy with class
You cannot call yourself a language geek and not know about Haskell, even if you are a lazy one!
Regenerative Build Tools
Testing is Not a Serviceand its follow up clarifying post, Services to the Organization
Agile or agile, Lean or lean?
Nice little riff on some of the noise going about what words to use when talking about Agile/Lean. I agree with Skip's conclusion, it is Agile and Lean for me as well.
Help me stir things up
A attempt to improve the success rate of the adoption of Agile Methodologies. I am in favour of what Mr Marick is trying to do.
Learning from "Positive Deviants": Pitfalls to Avoid
Do Kaizen Like Toyota
I really like points 1, 2 and 4.
The True Role of a PM on Agile Projects
Estimation: Time or Size?
Good judgment comes from experience. Experience comes from bad judgment
Software CM is Not a Process!
The idea that this post argues for bugs me and I cannot think of a valid counter example which bugs me as well. However, I do agree with Brad this area is important, in fact, poor execution in this area has sunk many a project and organization.

Links for 2007-05-12

Norbert Winklareth — Sat, 12 May 2007 16:15:00 GMT

Unusual software bug
And how many of these different types of bugs have you been bitten by?
10 Attributes of Really Lazy People
I found this hilarious, until I realized that the writer was not living up to what he wrote and then I laughed even harder and then I went Catch-22 and fell off my chair laughing and crying.
Quantify the cost of the things you wouldn't have had to do, if only...
Shows you how to calculate the costs of not building quality in. If you want to help affect orgaizational change learn how and do similar types of calculations where you work.
Large Project Risks
Explores the physics of drag, my analogy, on large projects.
IT Managers Are Mediocre
Peter Drucker stated that the most important trait of a manager is courage and W. Edwards Deming is quoted as saying: "The problem is at the top; management is the problem".
Appirio’s eat-your-own-dogfood SaaS integration

On the Semantic Distance between Input & Output, Problem Partitioning & Complexity

Norbert Winklareth — Thu, 10 May 2007 16:56:00 GMT

I first used the term Semantic Distance as a way of discussing the distance between the execution capabilities of a programming language and the execution requirements of the solution. Reg Braithwaite took this concept and expanded on it in by looking at "how well programs are written for human consumption" — this is yet another in a long list of excellent posts from Reg (just call me fanboy). His observation linking comprehensibility of the program to "the form of the code matches the data the code generates" is the same as how my colleagues and I at OmniMark Technologies used to judge how good an OmniMark program was, by how much it's structure matched the structure of the solution. There is, however, more to Semantic Distance and in particular its relationship to input and output, problem partitioning and complexity. In this post, I want to explore this, by recounting how I first learned about Semantic Distance and how to overcome it and then briefly explore its implications on dealing with complexity.

Back in the fall of 1990, my friend Sam Wilmott used OmniMark to convert a document, an Intergraph document (if I remember correctly), to one based on a specific SGML DTD. It took him about 2 weeks to write the conversion program. Afterwards, he was unhappy with his solution so he decided to re-write it. This time as two programs coupled together using the OmniMark co-routine mechanism context-translate. I had naively thought that it would take him another 2 weeks, but he was done in 3 1/2 days. Boy were he and I surprised. A little while latter, I observed again this non-linear decrease in the amount of development time when writing a solution for a second time using the co-routining model. Then it happened again and again and it was also observed by some of my other colleagues and some of our customers. This phenomenon delighted me. It also bothered me, because I could not find an explanation for why it was happening. So I started trying to solve it myself.

My first attempt was to attribute this non-linear decrease in development time to the reduced learning curve when you solve a problem for a second time. However, at best, this explanation would only account for some percentage of the time difference and in some cases the programmers were already knowledgeable about the input and output formats which meant that the learning curve time difference between the two solutions was essentially zero. My first clue towards a better explanation was the observation that this decrease in development time happened independent of the source and target languages but that the amount of the decrease in development time did vary.

Specifically, I noticed a difference in time decreases between different translations into the same CALS DTD. In other words, the target language was the same but the source languages were different and the time taken to develop their respective solutions was also different. To capture this observation, I started drawing two points in space and labeled the left dot L1, the source language, and the other dot L2, the target language. I then drew a straight line between them and said that this was the syntactic distance between the lexical units of the two languages. This model was too simplistic. It could not explain the non-linear decrease in time caused by introducing an intermediate language, L1i, between L1 and L2. Another issue with it, was that I had observed in one case, that it took more time to write a program for two lexically similar languages then it took for a program between two lexically very dissimilar languages. This was clue number two.

When I looked at the two sets of languages I observed that the two lexically dissimilar languages in fact had similar semantics and the two lexically similar languages had very different semantics. To capture this notion of semantic difference I drew a curve over top of the line connecting the two dots. I then reasoned that the area under the curve was where the semantics lay. Assume for now, that the curve is a 180 degree arc of a circle, the area under the curve is then

(PI * ((L2 - L1)/2)**2) / 2

When you introduce an intermediate language between L1 and L2 you end up with two smaller semi-circles whose combined area is less than the area of the initial semi-circle. This difference in area is due to the use of the power function, square, in the formula for the area of a circle. This model shows the non-linear decrease in time that was being observed. However, the magnitude of difference between the areas is not as large as what we were observing. So, on the suggestion of Mark Baker, I now use spheres when presenting this model today. The volume of sphere is calculated with the power function, cubed, which more approximates the observed decreases in time.

Implications

Semantic Distance is actually more "volumetric" than scalar in nature.
Breaking up the Semantic Distance between the Languages L1 and L2, into two smaller distances by introducing an intermediate language is problem partitioning. The effect of this partitioning is non-linear in nature.
The amount of complexity associated with translating between input and output is proportional to the Semantic Distance between input and output.

Problems with the Model

Here are the major issues with this model that I have identified:

This weakness is a variation of Zeno's Paradox about Achilles and a tortoise. The model predicts that if partitioning were recursively applied, then there should be no work to be done, which is equivalent to the argument that Achilles can never pass the tortoise. Clearly, this is not the case. In fact, there are aspects of the Semantic Distance that cannot be sub-divided, they are atomic in nature. These atomic "aspects" are sometimes completely orthogonal to any other aspects of the Semantic Distance between the input and output languages. This means that Semantic Distance is in fact n-dimensional in nature. And yes Reg, this means that there cannot be one language which has the shortest Semantic Distance between its capabilities and those needed to handle the n-dimensional nature of the Semantic Distance between any possible pair of input and output languages.
As my friend Jacques Legare, pointed out, the model does not show or prove that there is a relationship between Semantic Distance, complexity and implementation effort. To me there has to be, it is the only ting that makes sense to me, but showing it, proving it, is an open question. I am hoping that some reader will be able to provide assistance in answering this question, one way or the other?
As nice as I find the explanation, and while it seems correct to me, I wonder if there is a better or more correct and accurate explanation?

Two Bits of Advice on Writing Conversion Programs I Learned from Sam Wilmott

When translating from one input language to another, create the first intermediate language close to the input rather than the output language. Many times it is enough to just normalize the input. That is convert the raw and messy input into the format that a perfect author would created. This often times or with a little bit of design eliminates most of the corner cases and makes translating it into the output straight forward. The first output to create when using this technique should be a stylized human readable version, which captures as much information from the input as possible. This readable version provides you with three things: visibility or feedback, easily testable output and easier maintenance. Readability and testability helps to make sure that you are translating to the normalized form correctly and quickly and the same applies if maintenance is required. Once you have the conversion completed, you can convert the readable format into the required output format. If conversion to and from the readable output becomes a bottleneck, you just have to replace the output statement in the first program.

To eliminate problematic complexity between different Semantic Distance axes, introduce intermediate languages which only deal with changing one of the Semantic axis at a time.

Summary

To me, the neat things about this journey, was learning to use problem partitioning to reduce the complexity and time to overcome the Semantic Distance between input and output and coming to understanding just how powerful and wise the age old advice that you conqueror large problems/tasks by breaking them down into smaller ones.

Links for 2007-05-10

Norbert Winklareth — Thu, 10 May 2007 16:55:00 GMT

On the value of vagueness in organizational directives
Dale Emery recounts a story he heard about a CEO's response to a question about the company's primary value, which is to have fun.
A Lock-Free Hash Table
Perils and Pitfalls of Agile Adoption
Sucked back into the waterfall
This is a harrowing tale

Links for 2007-05-09

Norbert Winklareth — Wed, 09 May 2007 08:04:00 GMT

Miranda's Technical Question
Jason Taylor's, The Good Life:
Incremental Environments for Performance Excellence
The Flow of Change
Excellent model on how to do branching and merging of code lines with a source code control system. I am a big fan of Perforce's SCM P4 and have been using it since 1995/6 -- the paper's model is agnostic to SCM tool you use.
Earthquake-proofing organisations [and projects]
A viable explanation of why some longer lived, 30+ years, companies have escaped the boom-bust cycle that affects most longer lived companies.
The Expression Problem Revisited: Four new solutions using generics
The expression problem (aka the extensibility problem) refers to a fundamental dilemma of programming: To which degree can your application be structured in such a way that both the data model and the set of virtual operations over it can be extended without the need to modify existing code, without the need for code repetition and without runtime type errors.

Links for 2007-05-04

Norbert Winklareth — Fri, 04 May 2007 09:21:00 GMT

The Agile Team's Dashboard
Using feedback to improve delivery of value. Not using available feedback mechanism is an important waste, it is unfortunate it does not have a unique name in English that I know of. Does someone out there?
Warusa Kagen is a Revolution of Awareness
The procrastinator in me hates phrases like "now things are the worst ever" and this is in spite of the my numerous painful lessons in the truth of need for eternal vigilance; I still need to read daily posts like this and take them to heart. Thanks Jon Miller, for reminding and encouraging us to not give in.
Standards, Abnormality and the Ideal
Jon continues on with exploring the implications of Warusa Kagen and lists three abnormalities to illustrate his exploration:
1. When work is performed in the absence of a standard, this is an abnormality
2. When standards exist but are not being followed, this is an abnormality
3. When standards exist and are being followed, this is an abnormality

Links for 2007-05-03

Norbert Winklareth — Thu, 03 May 2007 13:36:00 GMT

What Every Manager Should Know About Feedback
The problem with articles like this is to see just how many mistakes one has made in one's career and wishing you had received feedback sooner.
FRIM: Another Way to Gather Data
The title does not capture what this technique provides.
Letting Go of BDUF
A true story of just how hard this is to do.
No High Fives at Toyota
A nice commentary on how Toyota treats its latest milestone as just that another milestone on the road to perfection and the issues they are currently facing.
Risk Management
patterns & practices Security Engineering Explained
Ursala K. LeGuin on the power of Open Source Ideas
I second the recommendation of the book The Dispossessed.
They saw the Silverlight, and saw that it was good
Microsoft's latest chess move in the Internet business war.
Roll Your Own Window Manager: Part 1: Defining and Testing a Model
Neat model and accomplishment.
Per Brinch Hansen Archive
One of the most under appreciated pioneers of Computer Science, Operating Systems and Parallel Programming. He loved to develop elegant programs and one of the best summaries of his spirit is a graduate student, Anil Menon (1995):
Over the last ten years, I've studied under many teachers and taken many courses. Dr. Brinch Hansen's course was unlike no other. He was interested in solving problems in parallel. I had no idea, even after five earlier courses, that it was so difficult. He took seven to eight different problems and showed by means of a series of beautiful and elegant programs, how one would go about writing parallel programs. His insights were often remarkable, for example, his deep idea that process structures were the correct way to reason and work with parallel processing, just as data structures are the key to sequential processing. Or the time he told us about the importance of constraints in the design process.
Perhaps the conviction always evident in his presentation came from the fact that these programs were his own, and not copied out some standard book. Even now it mystifies me to some extent how he could reduce a really complex program to a series of subprograms each no more than a dozen lines, the whole piece elegantly connected.
What's a manager to do?

Lean Software Engineering Blog

Norbert Winklareth — Fri, 27 Apr 2007 16:35:00 GMT

This new blog, Lean Software Engineering contains some of the best thinking on how to improve software development. The two writers, Corey Ladas, who works with David Anderson at Corbis and Bernie Thompson practice what they preach.

In the latest entry, More than one solution to the Project Triangle, Cory takes on the infamous Iron Triangle of project management. He starts by arguing against those who want to make it more complicated by adding a quality dimension, as Joe Marasco does in this article, The project pyramid -- there is a lot of good information in this article.

The main point of Cory's entry is that prioritizing the tradeoffs is the central task of leading/managing development. He concludes with a nice intro to Set Based Design as an effective way of handling the scope vs cost tradeoff.

My favorite post is Schedule is orthogonal to workflow. This concept was a revelation. It provides a deeper principle in explaining the success behind Kanban in Action and it shows the power of Axiomatic Design.

Links for 2007-04-27

Norbert Winklareth — Fri, 27 Apr 2007 16:33:00 GMT

IQ and Muda: Information Quality Eliminates Waste
Ah, I love of sound waste being rooted out in the morning.
Streaming & Streaming programming languages, you can't keep a good idea down.
Faster laziness using dynamic pointer tagging
Making higher level languages run faster, warms my soul.
Combining Events And Threads For Scalable Network Services
This paradigm blending was done in Haskel. Programs that use it have comparable performance to C programs for Disk and TCP/IP throughput and similar performance to Apache WebServer for static page delivery. As well, they were able to launch 10 Million threads in 480 MBytes of memory -- yes that is 48 bytes overhead per thread, they were only able to launch 16 K with the C Native POSIX Thread Library.
Creative Think
Andy Hertzfeld account of talk Alan Kay gave in July of 1982. Wow!
Resistance fades as SaaS goes mainstream
Software as a service (SaaS) looks like it will be one of the major tectonic shifts in the use of software. Phil Wainewright is one of the best analysis of this movement.
Quasi-Lean at a Call Center
How to Use a Kaizen Newspaper
I now recommend that people start with learning to see waste and record it. Jon Miller shows how to take this to the next level.

Links for 2007-04-26

Norbert Winklareth — Thu, 26 Apr 2007 08:33:00 GMT

BAKER'S DOZEN: Statements from an Agile subculture
Excellent advice on how to improve delivering value.
Where does QA fit within Agile?
How one company has integrated QA into their Agile strategy.
The Ladder of Inference and Ladder of Inference
A short introduction to this concept developed by Chris Argyris. Thanks to Mishkin Berteig for the references.
6 things I’ve learned about software development
I thought of something snarky to say when I read the title, but the body made me bite my tongue.

On Semantic Distance and Computer Languages

Norbert Winklareth — Wed, 25 Apr 2007 17:54:19 GMT

One of the recurring themes that programming oriented bloggers post about is the suitability or lack of some programming language for solving problems. Two excellent examples ( and extremely informative posts in their own right) of this are: Why Why Functional Programming Matters Matters and a commentary on it, Measuring the power of programming languages. What is interesting to me is that none of the posts that I have read have every framed the discussion around the semantic distance between the solution and the capabilities of the language used to implement the solution. Bridging this distance is where most of the effort of development occurs. The closer the execution semantics of the implementation language are to the execution semantics of the solution the less implementation work is required. Reg Braithwaite, the author of the first example, has a number of wonderful examples of this, spread throughout his posts, in fact one could argue that semantic distance is one of the central issues of his intellectual life.

One of the clearest examples of semantic distance is in a wonderful paper, written by Paul Hudak, called Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity (beware the paper is only available in PostScript). This paper describes the results of an experiment comparing the suitability of different languages for creating prototypes of systems. One of the most interesting insights for me was the solution developed for the test prototype that needed to be built. The solution was based on a brilliant abstract and I realized that I could use it to solve a similar type problem I had and that I was not able to use Haskell in my solution. I could however imagine that I was able to use Haskell and so I did and developed a solution using Haskell. Now all I needed to do was translate this solution into the language I was using. To do this did not require that I write a badly implemented version of Haskell, rather I was able to quickly implemented a set of abstractions that matched those of my solution and that solved the problem. I used this technique because of my understanding of the concept of semantic distance and how I needed to overcome it to solve the problem. What I have since discovered is that many others use this technique as well.

I was a co-creator/developer of the streaming programming language OmniMark. On a number of occasions I have met former OmniMark programmers and a number of them had said that sometimes when they are faced with tough problems they work out a solution by pretending that they still had OmniMark. Once they have solved the problem using OmniMark they then implement a solution in the language they are using.

If you survey the over 5000 different languages and dialects that humans speak, you find that there is no universal set of equivalent semantics between them. This fact implies that there can never be a computer language which will always have the shortest semantic distance between itself and any solution. Therefore there never will be a universally best programming language. On the other hand, if you cannot use the best language for a solution you can always pretend you can. Once you have a solution then you can implement the solution in the language you have. Two follow on points to this: I hope you now see the value in learning other languages/semantics and that the downside is never being able to use the best language available for the problems you have to solve and always having to use this technique to bridge the semantic distances.

Links for 2007-04-25

Norbert Winklareth — Wed, 25 Apr 2007 17:46:00 GMT

Coprolitic Programming
New word for today, coprolite and a "scary secret of our industry". My thanks to Reg Braithwaite for the reference.
Toyota ranks #1 globally in sales
Toyota the Father of Lean has for years been the most profitable car maker in the world and in fact is just about #1 in every other measure, except for most vehicles sold, which GM has held forever. By the way Toyota past GM sooner then they had planned.
Building Quality Into the Teaching of Medicine

Links for 2007-04-23

Norbert Winklareth — Mon, 23 Apr 2007 14:08:00 GMT

Schedule is orthogonal to workflow
Insightful post on how to evaluate the quality of your requirements, designs and your scheduling.
Are Great Teams Less Productive?
Short interview with Amy Edmondson on her research findings about learning in organizations. The paper, When Learning and Performance are at Odds: Confronting the Tension, which triggered the interview is also worth reading, bit dry though.
Cory Ladis, the author of the first item above, recommends reading J.D. Meier's Blog. I did and here are my favorites from his blog:
- Catalysts and Drains
- Be the Software
  Love the title. Excellent advice how to improve feedback and learning for the "customer" about a product.
- Scenario Evaluations for Product Design and Feedback
- Scenario and Feature Matrixes
- Input Validation Principles and Practices
- Time-boxes, Rhythm, and Incremental Value
- World Class Testing
- 2 Key Process Pitfalls
- Avoiding Do Overs - Testing Your Key Engineering Decisions
  Advice on how to do spikes of engineering design decisions for large applications.
- Task-Analysis Grid for Communicating Product Design
- Scenario Frames for Guidance
- Influencing Without Authority
- Requirements Perspectives
- Roles and Goals
  A nice little post on how easy it is to have lots of excellent user-centered motion but no progress.
- Driver's Guide vs. Owner's Manual
- MUST vs. SHOULD vs. COULD
- Perspectives Frame
- Worst Things First
  Given a choice, I always want to hear the bad news first!
- The Secret of Time Management
  Take the time to read the big rock story.
A Burn-Rate Based Estimation Tool

Creativity and Resource Constraints

Norbert Winklareth — Sat, 21 Apr 2007 11:12:00 GMT

At the end of this article, In Praise of Resource Constraints the author quotes an old Finnish army adage:

(derived from Finland's battles against much bigger adversaries throughout the course of its history):
"If the heavy armor does not move with four people pushing it, take one man away and let us see if three can do it!"

This made me laugh and remember a quote from a blog post, What Would You Do If You Had No __? attributed to Taiichi Ohno:

"Your wits don't work until you feel the squeeze."

This matches my experience as well. But why? My theory is that unlimited resources makes it is too easy to stop asking assumption challenging questions. Without these type of questions we are not broadening our learning, we are just deepening specific knowledge or continually reaffirming what we already know or worst believe to be the case. At the beginning of one of Howard Gardner's book he relates a story about being asked if he, a professor, feared not being able to answer someone's question. No he replied, "I fear not being able to think of questions to ask".

So what are you removing to help yourself think more creatively?