ThoughtWorker Blogs

Before we start a small warning. This is a rant and as such contains certain properties common to rants such as emotionally overstating unimportant points, glossing over and confusing important ones, over decorative language and taking the odd innocent as victim.  Bearing this in mind please remember though serious my tongue is sometimes placed firmly in cheek for dramatic effect.

There has been a great debate happening over the airwaves of the blogosphere recently. Sparked of by James Shore's post The Decline and Fall of Agile it has gotten to some people declaring the death of agile and others calling for the rejection of the term altogether [link]. It's as if the Nazi party has just announced that the Third Reich was built on Scrum and suddenly everyone is trying to distance themselves: "no we never agreed with that agile stuff, what we were talking about is something completely different".

Around the same time another debate is picking up steam started by Roy Osherove's post Goodbye Mocks, Farewell Stubs. Apparently people find testing too difficult to grok so we need to reject terms like mocks and stubs ('cos though accurate they are apparently confusing) and replace it with another: Fakes. Oh the glaring irony as one side of the movement is rejecting marketing terms because too many people who use it don't know what it means while the other side try to introduce more marketing language to attract the people who don't know what it means.

Uncle Bob has dropped in like Batman at the Jokers party and delivered his direct, powerful blow: "the problem is you're all f*ing lazy". Although I feel that Uncle Bob is much closer to the truth than many other commentators he's not really offering a realistic solution out of the mess.

So what exactly is the problem we've got here? Both of these posts have something in common. James Shore's issue stems from teams picking up words like Scrum and Sprint and forgetting that they have to write decent code as well. Roy Osherove's post stems from the fact that getting teams to even write tests is met with constant failure. Both posts talk about a general lack of engineering skill in IT. In reaction different parties are offering up different solutions but they all fail to address the core issue.

For those jumping the agile ship and getting onto the next coolest speedboat what exactly is that going to prove? Rather than improving the industry it leaves it helpless and sinking. This is a rotten attitude that resolves nothing: when every PHP and VB programmer converts to Ruby what you gonna do then? Oh it's OK Ola's writing Ioke and if that doesn't work we've always go Lisp (they'll never get that). Roy Osherove's solution of lowering barriers to entry is more commendable but will achieve just as little and is guilty of another great crime: dumbing down (though he's spot on about tool support). I don't think the solution to poor engineering skills are to withdraw important technical terms: can you imagine the Bar rebranding legal terms because, y'know Lawyers just find it too difficult to understand this stuff or Doctors calling for less names for the organs 'cos med students these days just can't get the point of having the terms stomach and intestine and they keep operating on the wrong one. Why can't we just call it the food processor? Jay Fields' novel idea is to ask them all to politely leave  (50% of them in fact). And if they don't? Well then I guess we'll all get together and go around with a big seal club and sort it out that way (it's what I refer to as "The Great Culling" - there's those Nazi's marching past again).

The real problem, the root cause to all this is simple (and on this most agree especially Uncle Bob and Jay): the gross under valuing of the skills which enable you to do your job. The thing is it's nothing new. It was there before agile and TDD had the impact they do today (they just laughed then). Remember those not so long ago days when people thought the solution to delivering software wasn't skills or focus on quality but getting some glorified secretary to type up several hundred pages of requirements and then handing them to some supposed genius to design everything for the monkeys to punch in? Well we're still there people: it's just they thought the solution to the mess that disaster caused was to do something called iterations, standing up and getting the monkeys to skip around the genius guy wrapping him in his own ribboned UML diagrams chanting "architect, architect, architect".

Nothing's changed, agile or not. The majority of the industry still doesn't value the basic, fundamental skills it takes to write software of acceptable quality. It didn't before and it still doesn't now. Instead it's obsessed with solving the problem by bringing in the right highly paid manager with the right powerpoint presented methodology. Until the industry gets that ain't the way it will drag every shining beacon of light (agile, Ruby whatever) down into Hades with it.

Writing software is about people People! That's what agile and Lean and all their friends tell you again and again. The fundamental principles are about people, not iterations, continuous integration and story boards. Go check out the Agile Manifesto and tell me where you see any of that stuff? This bastard form of agile which only talks about tools and processes is like someone got the manifesto and spun it round (People OVER Process read it Again). The practices and tools are there to actively encourage developers who are skilled, committed and know what they're doing and make them more empowered and productive and ultimately deliver MORE value and success, they are not there to replace them.

So what is the solution? The simple truth is that those of us who understand the problem have got to keep doing a great job, we've got to help those who want to do a great job but aren't sure how to do a great job and we've got help those who don't understand how to do a good job and may never will and may not even want to. Sure it's depressing sometimes, it's frustrating but we can't just give up on the industry and jump away on the next term or simply dumb the whole thing down so the next generation can get it a little more but ultimately still fail to get it.

Agile was never, is never going to be an quick, faultless success forever preserving an eternal purity. Our industry is sick, real sick. It's a beer guzzling, chain smoking, couch potato who's been told by his doctor to eat healthily, give up smoking and booze and get some exercise but instead just swallows the agile pill and hopes that's enough to save his sorry fat arse. And surprise surprise when the casualties start coming in their gonna blame those pills.

We have generation after generation bought up on bad practices and incorrect assumptions (smoking isn't bad for you, exercise gives you heart attacks) and what's worse most of them don't even know how bad things are: they think this is NORMAL (sadly because IT IS), they've adjusted to a certain degree of failure. IT projects are like lifts: sure your pissed off there broken down but your not surprised, you even kinda expected it.

The mess is big and it's gonna take years to sort it out and a lot of hard work. And yes, along the way people are going to buy the agile weight loss pill from some dodgy site on the Internet without seeking professional advice, get it wrong. And why? Because they're desperate!

It was totally delusional to think agile was going to result in everyone suddenly rejecting their bad habits and come crawling on their knees and go XP Kosher. And when that didn't work well there's always the prophesy of the True agile warriors standing in the post-apocolyptic world looking down on the dying as the last breath of those Tragic Lost sigh the now infamous regretful words "we wish we'd read our Domain Driven Designs". Well don't worry because to become agile all you have to do is close your eyes and say "please Kent forgive us our hacks and deliver us not into Waterfall" and mean it, really mean it, and wait, above the mountain there what's that? is it who I think it is? It is: the heavens are open and Martin Fowler is ascending into them.

Let's get real here: developers who have never come across TDD before, who've never experienced it's value first hand, who've spent years doing things a certain way are struggling to grasp the concept and oh sorry that's surprising why? I guess you were doing TDD from that first Hello World in Pascal? And those people who go in and try Scrum for the first time and find they are riddled with technical debt because gave into pressure and didn't invest in quality. Now stand up and be counted all you who never made that mistake.

I'm not saying that we should just let these things go, hold our noses, ignore the smells and step over the shit. Quite the opposite. But we've got to accept that we're not going to walk into a room of professionals and get them to convert overnight (or year or possibly even decade). How many years did it take before doctors accepted germ theory and started washing their hands?

Though there is hope: the most effective weapon we have is success. By being successful and then telling people about why and how we were successful. That's how this whole agile thing started, that's how it built up it's great reputation and that's how it's going to survive and get better. The more success the more people will start to realize that what they're doing now isn't as good as they think. Right now not testing, not caring about quality, high technical debt: that's the norm, that's expected. Keep being successful and people will start asking the others those awkward questions: why does this application crash when my last team were virtually bug free, why does it take a weekend to get a release out when my last team did it in a few minutes? Why does it take six months to implement a new feature when my last team took a week? What do you mean there are ramifications and complications? The more we deliver quality software the less room people will have to worm out of those questions and then the tipping point will come.

Let's not be mistaken, it's going to be hard work: but isn't that the whole point? Writing software is hard, agile doesn't change that and at first TDD certainly doesn't. Yes it's frustrating and somedays you really want to scream and kick in the can but what's the alternative IT ghettos sucking in grads and with no way out?

If, in the years to come, we want to work in a different industry then we've got to take some responsibility for helping create it.

One thing that really bothers me about testing is having various different assertion syntaxes. Take a look at the following JUnit examples. (don't worry, I'll be picking on Ruby and .net frameworks as well)@Test public void simpleAdd() { assertEquals(2, 1+1);}@Test(expected= IndexOutOfBoundsException.class) public void empty() { new ArrayList<Object>().get(0); }In both tests I want to verify something; however the two tests use different mechanisms for verification. This adds pain for anyone reading or maintaining the test. When determining what a test is verifying you need to look for assertions as well as expected exceptions in the annotation.When you start adding behavior based tests the situation gets even worse.Mockery context = new Mockery();@Test public void simpleAdd() { assertEquals(2, 1+1);}@Test(expected= IndexOutOfBoundsException.class) public void empty() { new ArrayList<Object>().get(0);}@Test public void forWorksCorrectly() { final List<Integer> list = context.mock(List.class); context.checking(new Expectations() {{ one(list).add(1); one(list).add(2); }}); for (int i=1; i < 3; i++) { list.add(i); }}Testing 1.03 different tests, 3 different ways to verify your code does what you expect it to. To make matters worse the mock expectations live in the body of the test, so there's no guarantee that when looking for assertions you only need to look at the last few lines of the test. Every time you encounter a test you must spend time looking at the test, top to bottom, and determine what is actually being tested.The tests above are simple, it's a much bigger problem when a test uses a few different forms of verification.Mockery context = new Mockery();@Test(expected= IndexOutOfBoundsException.class) public void terribleTest() { final List<Integer> original = new ArrayList<Integer>(asList(1, 2)); assertEquals(2, original.size()); final List<Integer> list = context.mock(List.class); context.checking(new Expectations() {{ one(list).add(1); one(list).add(2); }}); for (Integer anOriginal : original) { list.add(anOriginal); } original.clear(); original.get(0);}Okay, it would be terrible to run into a test that bad. You might work with people who are smart enough not to do such a thing, but it's very common to see tests that have both assertions and methods that are mocked. You may not consider mocked methods to be a form of verification, but if one of those methods isn't called as you specified it should be called, your test will fail. If it can cause your test to fail, it's a form of verification in my book.In Java, there are at least 3 ways to define expected behavior, and often a test mixes more than one. This is not a good situation for a test reader or maintainer.In the Ruby and .net worlds, the story isn't much better. The state based assertions are specified differently than the behavior based assertions; however, both Ruby and .net have a superior way of handling expected exceptions: assert_raises and Assert.Throws.Below are similar tests in test/unit with mocha (Ruby), with an example of assert_raises for handling the expected exception.def testState assert_equal 2, 1+1enddef testError assert_raises(NoMethodError) { [].not_a_method }enddef testBehavior array = [] array.expects(:<<).with(1) array.expects(:<<).with(2) [1, 2].each do |number| array << number endendAnd, for the .net crowd, here's the NUnit + NMock version of the 3 types of tests. As previously mentioned, NUnit provides an assertion for expecting exceptions, but there's still a mismatch between the state based and behavior based assertions. (full disclosure, I don't have Visual Studio running on my Mac, so if there's a typo, forgive me)private Mockery mocks = new Mockery();[Test]public void Add(){ Assert.AreEqual(2, 1+1);}[Test]public void Raise(){ Assert.Throws<ArgumentException>(delegate { throw new ArgumentException() } );}[Test]public void Behavior(){ IList list = mocks.NewMock<IList>(); Expect.Once.On(list).Method("Add").With(1); Expect.Once.On(list).Method("Add").With(2); for (int i=1; i < 3; i++) { list.Add(i); } mocks.VerifyAllExpectationsHaveBeenMet();}Testing 2.0In each language there have been steps forward. Both Java and C# have moved in the right direction regarding placement of behavior based expectations. Ruby still suffers from setup placement of mock expectations, but at least the behavior based expectations follow the same assertion syntax that the state based assertions use.In Java, the Mockito framework represents a step in the right direction, moving the mock expectations to the end of the test.@Test public void forRevisited() { List list = mock(List.class); for (int i=1; i < 3; i++) { list.add(i); } verify(list).add(1); verify(list).add(2);}Likewise, in .net, Rhino Mocks allows you to use "Arrange, Act, Assert Syntax (AAA)". The result of AAA is (hopefully) all of your tests put their assertions at the end.public void ForRevisited(){ var list = MockRepository.GenerateStub<List>(); for (int i=1; i < 3; i++) { list.Add(i); } list.AssertWasCalled( x => x.Add(1)); list.AssertWasCalled( x => x.Add(2));}These steps are good for the big two (Java & C#); however, I'd say they are still a bit too far away from ubiquitous assertion syntax for my taste.RSpec represents forward progress in the Ruby community.it "should test state" do 2.should == 1+1endit "should test an error" do lambda { [].not_a_method }.should raise_error(NoMethodError)endit "should test behavior" do array = [] array.should_receive(:<<).with(1) array.should_receive(:<<).with(2) [1, 2].each do |number| array << number endendRSpec does a good job of starting all their assertions with "should", (almost?) to a fault. It's not surprising that RSpec was able to somewhat unify the syntax, since the testing framework provides the ability to write both state based and behavior based tests. Looking at the tests you can focus on scanning for the word "should" when looking for what's being tested.Unfortunately the unified "should" syntax results in possibly the ugliest assertion ever: lambda {…}.should raise_error(Exception). And, as I previously stated RSpec still suffers from setup placement of the mock expectation "should" methods. Perhaps RSpec could benefit from AAA or some type of test spy (example implementation available on pastie.org).# this doesn't work, but maybe it should....it "should test behavior" do array = Spy.on [] [1, 2].each do |number| array << number end array.should have_received << 1 array.should have_received << 2endNext Generation Testing (Testing 3.0?)Eventually I expect all testing frameworks will follow RSpec's lead and include their own mocking support, though I'm not holding my breath since it's been two years since I originally suggested that this should happen. Today's landscape looks largely the same as it did 2 years ago. When testing frameworks take that next step, the syntax should naturally converge.In the Ruby world you do have another option, but one with serious risk. I've been looking for ubiquitous assertion syntax for so long that I rolled my own framework in Ruby: expectations.Expectations standardizes on both the location of your assertions (expectations) and how you express them. The following code shows how you can expect a state based result, an exception, and a behavior based result.expect 2 do 1 + 1endexpect NoMethodError do [].no_method_errorendexpect Object.new.to.receive(:ping).with(:pong) do |obj| obj.ping(:pong)endAs a result of expectations implementation you can always look at the first line of a test and know exactly what you are testing.Full disclosure: Before you go and install expectations and start using it for your production application, you need to know one big problem: there's no support for expectations. I'm no longer doing Ruby full-time and no one has stepped up to maintain the project. It's out there, it works, and it's all yours, but it comes with no guarantees.In the .net and Java worlds, the future of testing looks less... evolved. In the .net world, the ever focused on testing Jim Newkirk has teamed up with Brad Wilson to create xUnit.net. xUnit.net represents evolution in the .net space, but as far as I can tell they haven't done much in the way of addressing ubiquitous assertion syntax. In Java, I don't see any movement towards addressing the issue, but can it even happen without closures (anonymous methods, delegates, whatever)?I'm surprised that more people aren't bothered by the lack of ubiquitous assertion syntax. Perhaps we have become satisfied with disparity in syntax and the required full test scan.© Jay Fields - www.jayfields.com

generalist: a person competent in several different fields or activitiesIf you read my blog entry on Language Specialization you might have concluded that I prefer generalists. If, in our industry, generalists were what the definition describes, then I would prefer generalists. Unfortunately, business software developers seem to have created their own definition of generalist.business software developing generalist: I know how to do the simplest tasks with many different languages/tools, but I can not be considered competent with any of them.I blame Scott Ambler. To me anyway, it seems like the daft generalist movement started when Scott wrote Generalizing Specialists. Our industry has always been saturated by bad programmers. I'm on record stating that at least 50% of the people writing business software should find a new profession. The problem with bad developers is that they take good ideas and turn them in to monstrosities.I remember reading Generalizing Specialists and being inspired. I thought Scott gave fantastic and relevant advice. Unfortunately, many bad or junior developers heard: Don't bother to deeply understand anything, instead, you're agile if you know a little about everything. Suddenly, when I started interviewing developers I ran into situations like this.me: So, I see you have Erlang on your resume, how do you like the language?candidate: I like it's concurrency handling, but I'm a bit weary of it's syntax.me: (thinking - okay, do you have any original thoughts on Erlang?) I can understand those points of view, what problem were you trying to solve with Erlang and why did you think it was the right tool?candidate: Oh, I really only got through the 2 minute tutorial, you know, hello world basically. But if you guys have Erlang projects you want me to work on I'm happy to, I'm a generalist, I like all languages.me: Okay, so what language would you say you know the most about?candidate: I don't bother to specialize, I do a little bit with each language, you know, hello world or whatever, so I can use the right tool for the job. That's the best part of being a generalist.me: (thinking - this interview is already over) Okay, so tell me about the languages/tools you've had to use at your different jobs?Inevitably, the candidate doesn't even have a deep understanding of the tools they've used at work, because they are too busy doing hello world in every language invented. They also love to say that they take the Pragmatic Programmers advice to extreme and 'learn' several languages a year.The truth is, these generalists have little in the way of valuable knowledge. They provide their projects with little more knowledge than a Google search can bestow in 30 minutes. In short, they're worthless, if not destructive.I don't actually blame Scott Ambler. In my opinion he was right then, and he's right now. Become a Generalizing Specialist is still the advice that I currently give developers.Specializing in something makes you an asset to the team. If I'm building a Web 2.0 website, I want everyone to have an understanding of HTML, CSS, Javascript, Ruby, & SQL. However, I also want each team member to specialize in one of those areas. Knowing IE quirks is just as important as knowing how to optimize MySQL. And, I want to make sure I have team members that can get into the deep, dark corners of delivering highly effective software. That doesn't mean everyone needs to know what a straight join in MySQL does, but at least 1 person should. The rest of the team isn't entirely off the hook though, they better understand how to write basic SQL statements that are maintainable and at least semi-performant.Becoming a Generalizing Specialist takes time, but the first step is becoming a Specialist. Once you deeply understand one language/tool, you can move on to the next relevant language/tool. How do you know when it's time to move on? When you start having answers to questions that people aren't asking. If you're constantly looking up answers to common questions, you aren't a specialist. However, if you start providing more (relevant) detail in your answers than people are looking for, you're on your way to possessing the deep understanding that a Specialist should have. At that point, it's probably time to start looking deeply into something else.One painful mistake to look out for is specializing in something less relevant. If you work for a trading firm that writes only thick client applications, understanding why Chrome's Javascript VM is better than Firefox's Javascript VM is probably not the best use of your time. It's true that you may move on to a web application at some point, but by then your information will probably have become stale anyway. Stick to specializing in things that you work with day to day. Your language, your IDE, the Domain Specific Languages you use in your applications (regular expressions, SQL, LINQ, etc), or the frameworks you use (Spring, ASP.net, etc) are things you should specialize in to increase the value you provide to your team.Eventually, you become competent with several different tools and languages. You've become a Generalizing Specialist and as such you are significantly more valuable to your team.© Jay Fields - www.jayfields.com

Every so often, someone forgets to remove p() statements from their Ruby specs and then checks in. Figuring out where those p()s are afterward is a pain in the neck. Here's a simple solution: the whiny p.def p(*args) super *(args endDrop this little snippet into your spec_helper.rb or test_helper.rb and all your p() statements will also print the line number from which they are invoked. Pretty cool, what?

A Given is the context in which a feature is used When we write code, we want to know that it works. As developer, I want to know how to tell this before I even start coding, so that I can do as little work as possible. This isn’t laziness - it’s simplicity! It just happens that it also lets me head for the pub sooner (”Beer Driven Development”). In order to know whether my code is working or not, I’ll run the same kind of manual tests as the QAs will. I’ll also try to automate these. I start by thinking about how I’m going to use the feature I’m checking, and the outcomes that I’m expecting. That then leads me to think about the things I need to do first, before I can use my feature. For instance, I think about successfully paying a bill through my online banking system. That reminds me that I need to have sufficient credit with the bank, either a positive balance or perhaps an overdraft facility. We can use the application to set up a Given I could pretend to be an admin at the bank, and use the application to create a new account. I could then deposit some money in the account. That would allow me to try and pay a bill and check that the bill payment code worked. We can set up the state directly Let’s suppose that all bank account and balance details are stored in a database. I could set up the data in the database to make it look like an admin had created an account. That’s OK, because it’s not the account creation functionality we’re worried about - we probably have another scenario that covers that. We can use existing data Let’s say that we’ve copied a production database, or that we have some test data with which all environments are initialised. Maybe I have an account for a “Mr. Test”, with £2000 in. I could use this account for my scenario! But what happens if someone changes the data? Suppose that someone else writes a scenario that withdraws all the money, and it runs before mine? The first I will know about it is when my outcome - that I paid a bill successfully - fails. So, it’s useful for me to check that the state I need really does exist, either by checking the contents of the database, or by using the application to log in as Mr. Test and verify that my balance is sufficient. Either way, my Given contains assertions, just like my Then. It will fail if it can’t find the right data. This will help me differentiate between the wrong setup, and a genuine bug. We could use state if it does exist, and create it if it doesn’t If I wanted to, I could look to see if Mr. Test’s account existed, and if he had enough money, then create his account or add more money if he didn’t. This might be useful if, say, setting up an account was very expensive, but checking its existence and balance wasn’t. In that case, we’d have an assertion which performed the setup if it failed. I’ve never had reason to do this. Let me know if you do! Originally published at lizkeogh.com. Please leave any comments there.

Design is purely subjective only if design is solely about aesthetics.

Motrin, a US healthcare company put on their home page a large video advert with the basic premise that mothers who carry their babies are likely to get back ache and their pain killers are right for the job. Nothing wrong with that, however the message was ill-judged “Wearing your baby seems to be in fashion…” going on to “supposedly it’s a real bonding experience”. Oh dear. That ’s the sort of language that stokes the fire of mothers. There once was a time that they would have complained to each other at the NCT meeting (or whatever the US equivalent is), more recently a few might have blogged about it. But there is overhead in setting up a blog, and you need to think about what you write. Not so for Twitter. Twitter is low cost of entry, instant gossip.

Over the weekend Twitter has been buzzing with mums complaining about Motrin and their ad at #motrinmums. Look at the stats. From nothing to hundreds of negative sentiments in a matter of hours. Over a weekend.

(From Twitscoop)

It will be interesting to see how long before the ad is pulled. Will one person take responsibility, make the right decision (and do the right thing and apologize), or will it be a decision by committee and ultimately hurt the brand?

I started with the title “why you should care about Twitter”. Not so long ago I would talk to people about blogging and its importance to the enterprise and was told it was not relevant to that persons organisation. I’m surprised at how many CxOs I talk with today either don’t know what Twitter is or don’t seem to care. This is a good wake-up call. (Oh, and I picked this story up on Twitter via Jerimiah).

returned(){ //a method on Book
 setStatus(Book.AVAILABLE);
 title.setNumberOfCopiesAvailable(title.getNumberOfCopiesAvailable + 1);
 title.getUserInWait().notifyAvailability(title);
}

returned(){
 setStatus(Book.AVAILABLE);
 title.setNumberOfCopiesAvailable(title.getNumberOfCopiesAvailable + 1);
 title.notifyAvailability();
}

returned(){
 setStatus(Book.AVAILABLE);
 title.notifyReturn();
}

Kevin Meyer described his experiences with Gemba Research's Japan Kaikaku Experience so I figure I should do the same for Enna's Lean Journey Study Mission to Japan.  I'm a software person, not a manufacturing person so forgive any strangeness in what I observed and paid attention to.

----
On the Monday we visited two companies, the first being Aichi Sangyo, a welding technology company that has been operating for 71 years.

Some interesting points during the presentation by the Managing Director:

• small to medium-sized companies account for 99% of the companies in Japan and hire 71% of the workers
• Japan imports 99.9% of fossil fuel energy sources
  

The most interesting point was the idea that customers are looking for "Shohin", not product.  Shohin = Product + Following Service.  What this means is that you don't just list the features of the product, but show what that means graphically and make the specific customer benefits explicit instead of using vague statements.

Most of the study group didn't think that Aichi Sangyo was a good example of a Lean manufacturing company but I figured they were more of an engineering firm and they have managed to keep going for 71 years which is quite an accomplishment.

----
In the afternoon we continued to Toto Bath Create, the division of Toto that produces what are called unit bathrooms.  Toto reminded me more of what I've seen before from previous site visits organised by the Lean Network.  A lot of the emphasis is on 5S, kaizen, and training.  This was also the first place I encountered one-point lessons, though I'm sure it's nothing new for manufacturing types.

Most interesting point was Toto's distinction between two types of kaizen:

• C Kaizen - Change, Control, Communication, Challenge - refers to "improvement by ourselves in daily life"
• D Kaizen - Dynamic - refers to large company-scale improvements
  

I think this is equivalent to point kaizen vs process kaizen.

I've encountered a common perception, even amongst people in the Agile or Lean community, that positional authority is required in order to change anything. At the last Lean Summit Australia, John Shook corrected that perception. Now that he's started blogging, there's an entry I can reference the next time I'm told that "we can't succeed because we don't have enough authority":

Individuals in a lean management system take initiative to gain authorization to implement their ideas, manufacturing the authority they need when they need it: on-demand, just-in-time, “pull-based authority.” You will find no more appropriate occasion to exercise initiative, no better place to start than … right here and right now.