Here's an example of "User Wish" mind map including "Why", "Who" and "When" branches.



Gathering requirements or "User Stories" is always a challenging activity in Agile or in any other approaches. The primary factors that make this activity effective are communication and facilitation skills of the interviewer. In this session, I propose using mind mapping that focuses on those primary factors to explore “User Wish” -- a vague shape of user requirements before it is written into a form of User Stories.

Here's a whitepaper of the concepts.
http://astah.change-vision.com/en/zen/index.html

At the SPLASH2010 banquet, I sat with Prof. Kyo-chul Kang who is famous for his work on Software Product Line.

I tolked him I was from Agile community, then our conversation went to a fun experiment, an exploration for the concept of "Agile Software Product Line" as a desert brainstorming at the table !

Here's the picture of the napkin I took notes on. We decide to first explore "what is it ?" and "what is it for ?".

* Agile and Software Product Line(SPL) is both for achieving the same goal, "Business Value", but from different approaches. (the three circles above)
* From the economics point of view, SPL is asset-based(B/S focus) whereas Agile is flow-based(P/L focus).
* SPL stores knowledge of the domain of a product family as assets, and makes product development effectively by reusing the assets. The key -ility of software is reusability.
* Agile optimizes ROI of a one-shot project on a flow-basis, focusing on the context of one project at a time. The key -ility of software is changeability and simplicity within the project.
* Combining the two, runing each project in Agile, while accumulating the knowledge learned in the projects to the assets. There have to be a harvesting phase for asset creation after each project.(and maybe a planning how to reuse the assets before each project as well)
* By using the assets enterprise-wide, project instances can develop products in a shorter time to market and cost-effectively, increasing the enterprise's business agility.

And we (tentatively) defined Agile Software Product Line as;

Quote:

Prof.Kang told that we need more activies and contribution to software development methodologies from Asian communities, refered to Prof. Matsumoto whose work made a big impact for today's software product line.

Prof.Washizaki and Akio Iwai from Denso Corp. at the same table joined the brainstorm session to finish our first sketch of the concept "Agile Software Product Line".

What a nice conversation we had !

I attended a wonderful workshop "Architecture in an Agile World" led by Dennis Mancl, Bill Opdyke, and Steve Fraser at SPLASH2010 yesterday.

Quote:
The final Report is here, and with the last year's one, I think we had explored a interesting field of Architecture and Agile world.

After the session, I again thought about architecture. I was not able to speak loud in the workshop, but I'll ramble a little about it here.

A question still sticking to my head is "can a sound architecture really 'emerge' as Agile people say ?" (I like the concept of Martin Folwer's "HarvestedFramework", but questioning it somehow.)

Agile believes that the context matters most, and the most effective(simple and working) architecture can be havested in the course of adding business values to the system and refactoring through iterations. Software development is a learning process, and the architecture will emerge as you learn the problom as well as the solution domain.

I'm a strong believer of the latter part, but the learned knowledge can be used beyond one project, can't it be ? The application you are working on is not the same as the last one, but the knowledge around that area is stored in your head through experiences.

Not every piece of knowledge can be written (as patterns like POSA or other way). But you can use human beings as a container and conveyer of knowledge.

Architects are such people.

Grady Booch used a word "tribe memory" for the knowledge storage I described above.

Quote:
So what I wanted to say is;

* Agile says context is the most important thing, but
* There is also usable knowledge outside.
* Some is described as patterns in POSA-like literiture, but not much.
* Most of the knowlege is in experienced people's heads in a tacit form.
* Architect is a human being who can carry the knowledge across rojects he experienced. Using that knowledge, he balances the current business needs and long-term stability of the architecture.

And the bottom line is;

"Context matters but listen to your elders."

In the above discussion, I used design and architecture (and maybe framework, too) not very distinguishablly, but my definition of architecture is as Booch's: "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. --Grady Booch"

By the way, In "Ise", Japan, there is a big shrine called "Ise-jingu". There the main shrine building is re-built every after 20 years. They actually break it into parts, exchange some to new ones, and move them to the new place, and re-assembl them again. Do you know why they do that ?

Building a shrine is a difficult work, needing special knowledge and skill. There is a blue print but no detailed description of how you build it.

So, every after 20 years, elder generatoin and younger generation of "builders" get together and make a team, and do the shrine rebuilding project. This is how they transfer tacit knowledge in the elder people to the younger people. They know that not the whole knowledge is documentable, and experience is the most effective way to convey the knowledge.

Getting back to the workshop, I really want to thank Dennis Mancl Steve Fraser for nice facilitation and final write-up, and especially Bill Opdyke, who invented the concept of "refactoring" and started the new world of design.

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!

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.
  

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