The problems with larger and/or physically separate groups are not so much problems about communication as they are problems about connection.
Having a suggestion box doesn't mean people are involved (and therefore committed).
Telling people to call you if any problems comes up doesn't mean you've made yourself available.
If you were really interested in what people think, you'd go to them. You wouldn't just be asking them to come to you.
From Mark Edmondsen at The Lean Executive, How to Begin and Lead an Enterprise-wide Lean Transformation:
Even if you design for the current context only, you don't want to create designs that are excessively fragile. You shouldn't assume excessive precision and accuracy in requirements otherwise minor corrections will cause your design to collapse.
Of course, it always depends on the cost of just changing and fixing things later.
An old (1996) Fast Company article by Mort Meyerson, former Chairman and CEO of Perot Systems:
One hundred years from now, we'll know we were on the right track if there are more organizations where people are doing great work for their customers and creating value for their shareholders. And raising their children, nurturing their families, and taking an interest in their communities. And feeling proud of the contributions they make. These are things you can't measure when winning and losing are only financial metrics.He also has three jobs for a leader:
From Simon Baker,
VALUE
IF you don't repeatedly release software
into a production environment
at least once every month
that realises business value
for a real customer...
TECH
IF you're not paying constant attention to technical excellence
with simple, effective, incremental design
driven by continuous, repeatable automated testing
with at least 95% coverage...
LEARN
IF you're not learning
through inspection of every iteration
and adapting and improving
all of the time...
TEAM
IF your team is not empowered to self-organise,
does not sit together and engage in face-to-face communication,
does not include your customer
and all the necessary skills to make its own decisions and take immediate action...
THEN YOU HAVE COMPROMISED YOUR AGILITY
Seth Godin's Unforgiveable Manifesto at gapingvoid:
Does it take 500 words to change things?
Probably not. It probably takes less than a hundred, plus a secret ingredient.
An old Fast company article on Dr. Govindappa Venkataswamy and Aravind Eye Hospital:
Since opening day in 1976, Aravind has given sight to more than 1 million people in India. Dr. V. may not run a business, but it's important to note that Aravind's surgeons are so productive that the hospital has a gross margin of 40%, despite the fact that 70% of the patients pay nothing or close to nothing, and that the hospital does not depend on donations. Dr. V. has done it by constantly cutting costs, increasing efficiency, and building his market.
It doesn't matter that it should have been done before. That's a process improvement issue. It still needs to be done now, so add it to the backlog.
Via Mark Graban at the Lean Blog,
A Fast Company article about Toyota's Georgetown factory.
In the larger arena, when the strategy isn't to build cars but to build cars better, you create perpetual competitive advantage. By the time you best your competitors, they aren't just a bit behind you, in need of a reorganization and a sales surge to regain the lead. They are a decade behind. They just don't realize it.
...
At Toyota, there is a presumption of imperfection. Perfection is a fine goal, but improvement is much more realistic, much more human. Not a 15% improvement by the end of the quarter, a 1% improvement by the end of the month.
...
What happens every day at Georgetown, and throughout Toyota, is teachable and learnable. But it's not a set of goals, because goals mean there's a finish line, and there is no finish line. It's not something you can implement, because it's not a checklist of improvements. It's a way of looking at the world. You simply can't lose interest in it, shrug, and give up--any more than you can lose interest in your own future.
...
"Once you realize that it's the process itself--that you're not seeking a plateau--you can relax. Doing the task and doing the task better become one and the same thing," Shook says. "This is what it means to come to work."
I've been using Selenium RC and some observations made me think about what's going to happen in the world of web application automated testing frameworks.
The need for another process to run a SeleniumServer seems to me to highlight a failure in the approach... but if cross-platform support is easier with Selenium then I believe it will still win.
However, I suspect the COM driver testing tools will eventually catch up (cross-browser is not entirely seamless with Selenium RC) and their technical architecture seems simpler to me.
If none of the tools existed and I was selecting an approach from scratch, I'd probably end up with something more like Floyd fronted by FIT if being used for business facing tests.
As it stands now, I'm not really sure where things will go.
The User Story isn't complete until it's at a state that a user will actually use it.
It doesn't matter that all the specified aspects were done and all the tests pass. It doesn't matter that it was successfully deployed to production. If no one uses the feature, it's equivalent to have never been built in the first place. Actually worse, since not building it would have been cheaper.
Don't focus on delivery to production. Focus on the end goal of someone actually exploiting the feature that you build.
You group things together because they are related... that makes perfect sense doesn't it?
Well that has nothing to do with how I actually use the system. My groupings are based on the activities I need to do. My groupings are based on how I think through my problem and that has little to do with how your novice domain mind thinks.
A great talk by Iqbal Quadir, co-founder of GrameenPhone at TEDTalks:
The key message I got out of this was that foreign aid empowers authorities and marginalises citizens. This is the World Bank model and it doesn't work. Instead, the Grameen model is to empower citizens by enabling their economic development.
In other words, you can give people money to make yourself feel good. But if you actually want to help, you need to empower people to make their own money.
Another aspect I like about this model is that it doesn't rely on charitable sentiment for the process to continue. Grameen makes money. They don't need to ask anyone else for money to do good because they have a business model that incorporates doing good.
We are 13.7 billion light years from the edge of the observable universe.
That's a good estimate with well-defined error bars.
And with the available information, I predict that I will always be with you.
----
Michael Shermer, founder of Skeptic Magazine at TEDTalks:
Simon Baker blogs about Kent Beck's talk at Agile Business Conference 2006:
The weasel is agile and fast. But Kent asks "would you trust one? Other than agility what else do individuals, teams and organisations need?"
Fixed layouts (that dynamically change with browser width) versus liquid layouts?
Controlled font sizes (i.e., disable user control of font sizes) versus not?
No underlines to indicate links versus sticking with the "blue underline = link" convention? (I know browsers can override)
Except for the first one, these seem pretty obvious to me if I'm more concerned about user performance over aesthetics but perhaps I'm missing something.
You will never get an optimal result with a "perfect" specification because there is no conversation.
Interaction between people is the most important part of the Agile process. If you are trying to adapt your requirements process by forcing more detail to get more concrete specifications that don't change as often, you're going the wrong way and there will be negative consequences.
You write things down so that you can help yourself think, you write things down so that you can remember, you collect things so that it's easy to refer to... but the conversation is still primary.
We're not done when the code passes all the concretely specified story tests. We're done when we all agree that it's best to stop working on this particular feature for now and move on to another one. The tests are just a tool to help us have that conversation.
Via Bill Wake,
Alistair Cockburn wrote a paper on five strategies for what people should do if they're not part of the constraint:
When these strategies are added to the more commonly known ones of having the non-bottleneck people sit idle or do the work of the bottleneck people, we get five strategies to choose from for how to make use of the "excess efficiency" available at non-bottleneck stations:
- 1. Have them sit idle.
- 2. Have them do the work of the bottleneck station.
- 3. Have them simplify the work at the bottleneck station.
- 4. Have them rework material to reduce future rework required at the bottleneck station.
- 5. Have them create multiple alternatives for the bottleneck station to choose from.
In each of these the efficiency of the non-bottleneck station is strategically lowered, that is, the efficiency is deliberately "spent" in a particular way to gain an overall advantage in system throughput. The ways in which efficiency should be spent differs according to situation.
Via Making Life Easy,
This is not really something I'd use myself since I don't actually care to have a watch like Brad Pitt's... and I'm not sure how effective it actually is... but the celebrity search feature at like.com is such a cool idea.
Well, folk medicine dies hard, in programming as at home, so it is going to be difficult to sell the idea that documentation, as such, has no intrinsic value. The value of the documentation is only to be realized if documentation is well done. If it is poorly done, it will be worse than no documentation at all.If I might reformulate this to be more similar to Gilb's Law and my corollary...
-- Jerry Weinberg, The Psychology of Computer Programming
Anything can be documented in a way that is superior to not documenting it at all.
Anything can be documented in a way that is inferior to not documenting it at all.
As a matter of good practice, the test program should be constructed before the "fix" is made to the production program. In the first place, there will be an all too human tendency to forget about the problem once the production program is working correctly, so we must impose a little discipline on ourselves. Possibly more important, however, is the chance that by the mere act of constructing the test case we shall discover the problem.Note also the use of "good practice" over "best practice". When was that nonsensical phrase, "best practice", introduced to the common vocabulary anyway?
-- Jerry Weinberg, The Psychology of Computer Programming, first published in 1971
Could we not say, then, that the first rule of problem solving is "don't make assumptions"?So the next time I hear "Assumptions make an ass out of you and me", I can say "Well, actually..."
We could say that, but we would be precisely wrong. If we are to be successful at solving problems, we must make assumptions. If we really faced each problem as entirely new, it would be impossible to improve our problem-solving performance.
...
Intelligent behavior, then, does not consist in eschewing assumptions, but in being sufficiently flexible to manipulate assumptions as the occasion demands.
-- Jerry Weinberg, The Psychology of Computer Programming
Via The Psychology of Computer Programming,
I have in mind the only liberty worthy of that name, liberty consisting in the full development of all the material, intellectual, and moral powers latent in every man; a liberty which does not recognize any other restrictions but those which are traced by the laws of our own nature, which, properly speaking, is tantamount to saying that there is no restriction at all...You can probably find a free version at the Anarchy Archives.
-- Mikhail Bakunin, The Political Philosophy of Bakunin
In certain types of groups, and often in programming teams, the group tends to choose two complementary leaders - a task-specialist who sets, allocates, and coordinates the work; and a maintenance-specialist, who irons out conflicts among group members or between individual goals and group goals.I'd say that I'm more of a maintenance specialist than a task specialist. I'm the person you bring in if you want a "calming influence". If you need someone to "kick ass and take names", look for someone else. And while you're at it, prepare yourself for project failure.
-- Jerry Weinberg, The Psychology of Computer Programming
Via The Psychology of Computer Programming,
But when, at an early stage, I had to manage serious enterprises and to deal with men, and when each mistake would lead at once to heavy consequences, I began to appreciate the difference between acting on the principle of command and discipline and acting on the principle of common understanding. The former works admirably in a military parade, but it is worth nothing where real life is concerned, and the aim can be achieved only through the severe effort of many converging wills.
-- Peter Kropotkin, Memoirs of a Revolutionist
Via Dare Obasanjo,
Greg Linden blogs about Marissa Mayer speaking about some user tests at Google:
Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.And that's for 100s of milliseconds, never mind 30 seconds.
This conclusion may be surprising -- people notice a half second delay? -- but we had a similar experience at Amazon.com. In A/B tests, we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.
I just noticed that gapingvoid has card designs at Street Cards.
I think moo Flickr cards work better for cool business cards but gapingvoid cards might be interesting to hand out in non-business situations.
Jim Womack on mura (unevenness in operations) creating muri (overburdening people and equipment) and thus undercutting previous efforts to reduce muda (waste):
And in most companies we still see the mura of trying to “make the numbers” at the end of reporting periods. (Which are themselves completely arbitrary batches of time.) This causes sales to write too many orders toward the end of the period and production mangers to go too fast in trying to fill them, leaving undone the routine tasks necessary to sustain long-term performance. This wave of orders -- causing equipment and employees to work too hard as the finish line approaches -- creates the “overburden” of muri. This in turn leads to downtime, mistakes, and backflows – the muda of waiting, correction, and conveyance. The inevitable result is that mura creates muri that undercuts previous efforts to eliminate muda.
Mark Graban at the Lean Blog talks about how GM has recently raised prices in response to increased materials costs and how this mindset is just wrong.
...the Lean/Toyota mindset says that prices are set by the MARKET. Prices have nothing to do with your costs: labor costs, commodity costs, etc. If GM is arbitrarily raising prices and the market doesn't value their cars accordingly, sales will drop, or GM will end up having to offer more incentives to get prices back down. But, if the market is really allowing GM to raise prices, why should GM have to use the "excuse" that raw material prices went up?Buyers don't care what it cost you to build something. They only care about how much they value what was built.
Back in the day, Extreme Programming emphasised an Onsite Customer as role distinct from the development team. These days, it's generally agreed that this kind of explicit division is not as useful as seeing everyone as being part of the Whole Team, the same Project Community, etc.
Some times though, I think that understanding the division helps reminds us that if we're not the designated Customer or Product Manager, on matters of feature prioritisation and selection, we are still providing advice and we are not supposed to be taking control.
Stephen J. Dubner at the Freakonomics Blog offers some options that would create incentives for people to vote.
I like the one about banning pre-election polls. The lottery ticket idea is also good. Mandatory voting on the other hand just feels undemocratic somehow.
When I first encountered the table and column completion in Squirrel SQL, I immediately thought that it would be cool to enhance Squirrel to support full-fledged database refactorings.
Now it seems this technology now exists.
Via David Hayden through Roy Osherove.
My typical project build uses Ant and a tool like JDepend to enforce package dependencies. I've always had a strained relationship with JDepend because I always thought "package dependencies" were more about relationships between separately deployed components over Java packages. And of course, JDepend was (is?) a bit opaque about what class was violating a defined dependency constraint.
I've now experienced an approach where separate components are created and dependencies are enforced by the build process. This means that we don't need a package dependency tool but I'm not sure I like this better.
The tool and build file setup is definitely more complex. It seems that things like Maven and the project features of Eclipse were designed to accommodate this complexity. Perhaps this is why I've never really bothered with Maven or those Eclipse features.
Setup complexity is also not my only source of unease.
I don't think this approach reflects the make-up of a small co-located team that practices collective code ownership, encourages pairing, etc. In fact, I think the approach instead reflects the opposite (i.e., isolation, specialisation, etc.). So it's a Conway's Law thing.
I received an advanced copy of The No Asshole Rule by Bob Sutton, and given that it seems the other bloggers are starting to write about it, I figure I should make my own initial comments.
This is one of those books that I just start assuming everyone I meet has read. If I'm talking to people about recruiting, about organisational culture, about how we want to work, I've already just assumed that people know The No Asshole Rule. Probably not that reasonable an assumption since the book hasn't been published yet...
So via Brand Autopsy, check out the video at Fifty Lessons, and get the book when it comes out. It'll make our conversations go faster.
