Mary and Tom Poppendieck wrote in their new lean book "Leading Lean Software Development: The Results Are Not The Point " that if you have too a long list of user requests, limit it to the length that fits to your thoughput. And in their talk I heard one episode of their client where they accutally saw a list you would have to spend *years* to catch up, so they said to them "Discard the older part. you cannnot do with them anyway."

Discard the older part ? They are waiting for loooong time. I thought this idea was counter-intuitive. But I recalled Jim Coplien's pattern for telecommunication "call half queueing".(I don't remember the correct name of the pattern, but should be a reference somewhere) It says, if the waiting call list is very long, the next call to be connected is the newest call(the last arrived call), not the oldest call(first arrived call). This is the real-world implementation, and supported by psychology... a long waiting call can possibly be giving up.

More generally, the older part of the long request list has a good chance of being "stale".

If you think this is wrong, imagine you have a pile of unread newspaper. Do you read from the bottom of the pile or from the top ?
Or to be more upto-date, think about a long unread timeline of your twitter. Do you like to read the older part first ? I would start reading backward from the fresher tweets.

Any thoughts or comments ?

P.S.
As a product owner of Astah* UML and mindmapping editor, I'm thinking I should think more about priorities and how to notify the source of requests.... and else.

After Agile has been adopted so widely, scaling agility across the enterprise is now a topic for these years.

In this blog, I ponder two ways to scale Agile -- a "Tree" and a "River" as metaphores in the mother nature.

"Tree" type, or "Scrum of Scrums" type scaling.

This is a natural extension of Scrum from a team to a project of scrum teams or a progam of scrum projects, and maybe to a company with a product portofolio.

In this model, typically each scrum team has standups everyday and retrospectives after each sprint, while scrum masters form an upper level scrum and have standups and retrospectives after the ones of the sub-teams. Even a company board meeting can be seen as a top level scrum. In this way, tree type scaling shares (and needs) strong synchronization of the teams though out the organization. I assume Jeff Sutherland's Patient Keeper and its Type C Scrum is a good example of this strong "scrum" company.

A tree shares a rhythm, location, climate, mood and so on as a living thing. It scales strongly but within a size of tree.

"River" type, or "Lean" type scaling

The other scaling strategy is to connect different teams such as a marketing team, development team, and QA teams with queues between them.

I would call this a "River" or lean type scaling, where multiple teams
work asynchronously in their own rhythm and culture using buffers inbetween. Lean is an attitude to make value flow seeing the whole.

In this "river" type, even the concept of iteration is not necessary. Using kanban or other information-sharing and buffer-management tool, the work flows from upstream to downstream through the whole value stream across the enterprise.

A river runs through countries sharing a flow, but each country has its own climate, rhythm and culture.

My hypothesis

When scaling Agile, a company with less than 100 employees, like an energetic startup, can and should use tree type scaling to get a whole company agility and to create value from its teams. It is like a growing tree pumping water and nutrients from the soil, sharing one strong culture and sense of timing in possibly a collocated workplace.

On the other hand, a big company with different division cultures or a big project with multiple companies, can use river type scaling
more effectively because each sub-team naturally has different rhythms and wants to move independently from the other teams. It is like a river runs across a continent making a value flow to the ocean connecting different regions.

Tree scales with a stronger synergy, while a river scales a lot broader.



...read more

I attended Agile09 confernece in Copenhagen, where I met great thinkers and a lot of nice people.

Tom Gilb is my hero. I was told by Craig Larman that he was the FIRST agile methodologist who had articulated "Evo" with a PDSA feedback cycle in the late 70's. I long wanted to meet him in person. And finally I met him and found he was a passionate gentleman with deep thoughts.

Kai Gilb extends "Evo" to more business directions to include stakeholders and their value in the loop. He says that Agile is too a narrow developer-centric view of the world. There is a much bigger world in the business side, which is, in Scrum, addressed as just one ringable neck(Product Owner). It is vital to focus on "value" not "feature" and feedback in the measurement of the value, not just working software. I agree!

Roger Leaton from BT shared his experience in rolling out Agile in a large company. He made 70% of the project be Agile, which was 30% in 2003. He sees Agile transition as a cultural change, and I share a lot in common with him. The slide on the left is showing the difficulty of cultural changes as a iceberg. Even though the surface of it looks to be changed(adoption of practices), if the hidden part(understanding of value, culture of the organization) is not, the change won't last.

Staffan Nöteberg is the author of "Pomodoro technique illustrated". he expained the technique in a unique style using puppet plays and hand-written illustrations. I'm thinking of emulating him sometime.

I met Nicolai Dragsted from a lawfirm. He is a lawyer trying to create a type of contracts suitable for publich sectors to outsource Agile development. His material includes concepts of waterfall and Agile, issues to be addressed in the contracts, and templates of the contracts. I will take this back to Japan and introduce it to Japan government.

OK, me. I talked "Learning Kaizen from TOYOTA". I showed the audience a video and together with them extracted lean ideas and commonalities with Agile in it. I recently read John Shook's(The first American manager at TOYOTA who transported TPS concepts to NUMMI) article on Starbucks Lean adoption, and am really convinced. So added "Lean is scientific management where the scientists are the fron line workers" as a message.

(thanks for the picture, Troels Hansen)

Here's the mind map.

I have a lot other topics to say, but I should go sleep now to get out of the jetlag. Thank you Dan and Anja from DANSK IT and Bent, Sune, Jesper, Thomas and other BestBrains wild guys. They organize a study tour to Japan every year called "roots of lean", so Norse who want to visit Japan, contact them!

astah* Basic Operation Guide has been added astah* website.

- astah* Basic Operation Guide

This guide shows you the basic operations in astah*, starting with the screen layout of astah*, Model and View Element, and how to create a diagram/model and so on. It is helpful for those using astah* at the first time.

I have attended three days of UK Lean Conference held in London. To Agile practitioners like me, it was an eye-opener to a whole wider view of software development. Here's a thought I got.

What was Agile to me:

Agile was something important missing from "Software Engineering" in the real world software development. Agile found that the bottle neck of software development was not in software engineering part any more(did you read the Demarco's Software Engineering: An Idea Whose Time Has Come and Gone?), and it was in social activities that connect software development with business. For example, Scrum can be seen as a set of role definitions and communication patterns between business and development. And the important thing was that the value was not in the software itself but in the business. Agile kind of extended the engineering thinking to the social part of development, which may be called "social engineering"(Ivar Jacobson used this saying).

So let's say Agile is a connector between business and software engineering.



What is Lean to me:

But the world of business was not only software, of course. From the business perspective, IT or software development is just one activity in the value stream of a company. It adds values together with other parts of the business in the stream such as markeing, accounting, and etc.

So, I find Lean is more a company wide initiative that makes the value flow from concept through development(where I live in) to c ash(or customer needs).

I drew a "T-shape" model that expresses my thought.



Chris Matts model:
Chirs Matts

told me (on the dinner party table, BTW) a completely different view of Agile and Lean. His model is a matrix of consciousness and competence.

While Agile focuses on solving conscious issues to make an incompetent organization competent, Lean makes the conscious competent organization to unconscious competent mode, which can be done by knowledge translation. Yes, Lean companies do competent operations unconscously.

Chris has more to say to this diagram, but I'll leave it to him.

I had one whole day free today after the UK Lean Conference, so I wandered around London city this morning.

In front of the National History Musium, I met a couple sitting separately on a bench and squabbling with each other badly... The boy seems to be British and the girl seems to be American.

Girl: You British always think you are the best in the world !
Boy: You Americans always want to rule the world !

I just happend to pass by. As an Agilista, I suggested to do a "Retrospective" of their history to find that they always have "Options" on what to do with this relationship today. And I gave them Japanese yellow scarves which I had with me for souvenirs. In Japan, yellow scarves or handkerchieves are a simbol of reconcilation. When a couple fight badly and one gets out of the house, the other put a yellow scarf at the entrance of the house to express "sorry, I'm waiting for you".

After I told them the story, they seemed to be reconciled. I was happy as a Japanese to see a British boy and an American girl wearing yellow scarves and setting closely together, again.

P.S.
Sorry, Chris and Esther. While I was looking at the pictures I took
in London, I couldn't resist temptation to make this joke.

But seriously, during the conference I envied you for how naturally American and British people communicate in English and create body of knowledge together. For me Japanese, language is the highest hurdle to understand thoughts which are exchanged in the world of English speaking people.

I'm thinking how we can join this process. I need something like "yellow scarves".

Prof. Ikujiro Nonaka, the grand father of Scrum — he first defined the word "Scrum" with Hirotaka Takeuchi in 1986, as a knowledge creating process in his paper “The New New Product Development Game” — has recently been presenting a new type of leadership found in Japanese management such as Honda, with help from the philosopher Aristotle’s words.

I have been practicing Agile/Lean software development in Japan, and found that every Agile/Lean self-organizing team needs each member’s active and subjective interaction to move the organizatoin toward success. Also Agile/Lean cannot be taught by text books and need to nurture people who can think for themselves in their context by sharing experience to communicate tacit knowledge. (I blogged about it here)

Then, how can we make such knowledge portable? The vehicle is also people. we need someone to convey that knowledge with leadership and propagate the leadership through the organization.

I think the ability or attitude of the leadership role in Agile and Lean is very akin to what Prof. Nonaka named “phronetic leadership”.

He says that effective strategic management needs distributed wisdom (which Aristotle called “phronesis”) in each member of the organization. Strategy is created out of one’s existential belief or commitment to a vision of the future, the ability to interpret one’s environment and resources subjectively, and the interaction between subjectivity and objectivity. These abilities need to be distributed among organizational members. Strategy as distributed phronesis thus emerges from practice to pursue “common goodness” in each particular situation since a firm is an entity that pursues a universal ideal and particular reality at the same time. Such idealistic pragmatism means that in a specific and dynamic context knowledge can be created and refined to become wisdom.
Aristotle’s three types of knowledge are;

• Episteme (Scientific Knowledge)
  Universal, context-free and objective knowledge(explicit knowledge)
  
• Techne (Skills and Crafts Knowledge)
  Practical and context-specific technical know-how(tacit knowledge)
  
• Phronesis (Prudence/Practical Wisdom)
  Experiential knowledge to make context-specific decisions based on one’s own value/ethics (high quality tacit knowledge)
  

Phronesis is a concept that synthesizes “knowing why” as in scientific theory, with “knowing how” as in practical skill, and “knowing what” as a goal to be realized. Unlike episteme, it emphasizes practices in particular contexts. However, phronesis is not just knowledge within a certain, particular context per se. Since it is knowledge to serve the “common good”, it implies an affinity with universal principles.

Prof. Nonaka presents six abilities that constitute Phronesis;

• Ability to make a judgment on goodness.
  
• Ability to share contexts with others to create *ba*(shared sense).
  
• Ability to grasp the essence of particular situations/things.
  
• Ability to reconstruct the particulars into universals using language/concepts/narratives.
  
• Ability to use any necessary means well to realize concepts for common goodness.
  
• Ability to foster phronesis in others to build resilient organization.
  

He quoted an episode of Mr. Honda, the founder of HONDA;

Honda was trying to develop the CVCC engine, which had lower emission and higher fuel efficiency. Souichiro Honda, the founder and then CEO of Honda one day told his engineers that the engine would finally give Honda the opportunity to beat Big 3. The engineers looked at Mr. Honda, and said, “Please, don’t say such a thing. We are not doing this to beat other guys. We are doing this for our children.” Mr. Honda was ashamed of himself, and said that he realized that he had become too old, and decided to retire.

(source: Ikujiro Nonaka "The Knowledge-Creating Organization & Leadershipis")

Further readings;

• The Knowledge-Creating Organization & Leadership(PDF slides)
  by Ikujiro Nonaka
  http://www.jica.go.jp/project/indonesia/0061565E0/05/pdf/01_02.pdf
  His slides showing the concept of Phronetic Leadership
  
• The Practical Wisdom of Ikujiro Nonaka
  by Sally Helgesen
  http://www.strategy-business.com/press/16635507/08407
  Interview with him regarding the concept
  
• The New New Product Development Game(PDF paper)
  by Ikujiro Nonaka and Hirotaka Takeuchi
  http://apln-richmond.pbwiki.com/f/New+New+Prod+Devel+Game.pdf
  The first paper which defined the word "Scurm" in product development.
  
• Managin Flow
  by Ikujiro Nonaka et. al
  http://www.amazon.com/Managing-Flow-Process-Theory-Knowledge-Based/dp/0230553761
  His latest book discussing phronesis
  
• Knowledge Creating Company
  by Ikujiro Nonaka
  http://www.amazon.com/Knowledge-Creating-Company-Harvard-Business-Classics/dp/1422179745
  His classic book about knowledge management.
  

Thanks to SEA Tecnologia in Brazil, the Portuguese translation of JUDE/Community 5.5 is now available on JUDE website.

Let's enjoy using the Portuguese version of JUDE/Community.

1) Download and install JUDE/Community 5.5.

2) Download a resource file and unzip it. And, save it into JUDE install folder.

Please see details in JUDE GUI Localization

Introduction of JUDE/Professional, JUDE/Community (Portuguese page)

While I have been involved in Lean/Agile movement in Japan for these eight years, I have had several chances to talk with Toyota people. Among them, Kuroiwa-san(ex-Toyota manager) who is my Sensei(meaning teacher: although he doesn't like to be called so), one day asked me;

Kuroiwa: "Hiranabe-san, what have you learned from TPS(Toyota Production System) ? What is it in one sentence?"

Hiranabe: "Flow and Customer pull ?"

Kuroiwa: "Maybe."

Hiranabe: "Respect for People and Kaizen?"

Kuroiwa: "Not bad. But what is it all about ?
TPS keeps telling you just one thing. What is it ?"

I haven't reached to the answer for two years, but at last, I have...

---

On Feb. 22nd, 2009, Mr. Satoshi Kuroiwa delivered a keynote speech at Agile Japan 2009. he built his career as an IT training manager of Toyota Motor Corporation. In the 1980’s, Toyota Production System was introduced to the factory of NUMMI, a joint venture company founded by Toyota and GM and he had been a manager there. In the factory, more emphasis was put on people and human capabilities than on high technology.

At first, there were more than 200 job skills defined, but he reorganized them into only two rolls --assembly workers and maintenance/service workers-- to develop multi-skilled workers. Thanks to these improvements, the factory that had once been closed was successfully revived. Kuroiwa-san pointed out that excessively divided roles are distributed in the current software industry in a very funny process called "waterfall", and stated that higher efficiency would be achieved if workers gradually expanded their capabilities under shared goals instead of sticking on their segmented skills.

He also pointed out that one of the most important Lean concepts was “customer pull”, which means in manufacturing to produce just what customers need. "But what does this mean in software development?" he asked the audience ... "Think for yourself. You are software engineers. In software development, it means that developers should understand the _why_ of the customer needs, instead of the _how_ of realizing the needs using technology."

He concluded his speech by emphasizing that “Thinking for yourself in your context” is the heart of Lean, and ranted to the audience that they shouldn’t import anything without questioning why. A lot of software concepts have been imported from abroad and most Japanese software developers just use them without thinking. The problem to solve is always yours and you should think based on your context.

---

See ? The heart of Lean is;

"Think for yourself in you context"

That was the answer to the first question. As frequently stated, Toyota "makes things" and at the same time, "makes how to make things" i.e. process -- they produce 10,000,000 cars per year(lower this year) and at the same time, adopt 1,000,000 kaizen proposals from company members to improve the process in the factories.

But it was not just that. They "make things", "make how to make things" i.e. process, and "make how to make how to make things" i.e. thinking people. Process is meta to product, and people is meta to process, and we are people making the product through the process. TPS is a "Thinking People System".

During Toyota plant tours(you can apply via web), I saw a sign board in Motomachi plant where TPS stared, saying "Good Thinking, Good Product." This slogan is commonly seen in Toyota plants.

Here's a photo taken two years ago with Craig and Bas, under the sign of "Good Thinking, Good Product" when they came to Japan and met with Kuroiwa-san.

++ Another good reference would be;
http://www.toyotageorgetown.com/tps.asp

QCon Tokyo was held at Tokyo conference center, Japan on April 9-10, 2009.

I have attended several sessions and found some common trend. That is, "Simple is best".

In Martin Fowler's keynote speech, he presented Domain Specific Language (DSL). He highlighted readability of code, as role of DSL. It helps business people to understand an application.

Also, Rod Johnson, the creator of Spring, in "Spring in a Changing World" stated the failure of old J2EE at first. According to Johnson, J2EE failed because of its complexity. Now developers want simple solutions. and He concluded that "enterprise Java must get simpler".

Junzo Hagimoto, a Requirement Development Methodologist, described about how to bring business values into system development. There are misunderstanding and conflict between customers and developers. He recommended to show the whole picture to both and have strategy for generating business value. He said that he was seeking to think and do everything simply.

Yukihiro Matsumoto, the creator of Ruby, also introduced Paul Graham's word, "succinctness is power", in his keynote speech "Beautiful Code". He states that code is beautiful and simplicity is also beautiful.

As a developer, I believe that seeking simplicity will improve the quality of code and the working environment of developers. Since new technologies are constantly generated and the world becomes increasingly complex, the simplicity will be one of the key factors for success.