Agile Fashion

Product Design and Development Through Collaborative Consensus

Browsing Posts published in June, 2009

Lately I’ve been reading about people lamenting unsuccessful adoptions of Scrum within organizations. Somehow, these entities survived before Scrum was introduced. They are not just going to fold because they have not done it right. They may choose to ignore some of the principles of Agile and continue to bring in revenue without coming all the way around.

So the Agile community has some advice. Make sure good technical practices are in place. Have motivated and skilled people in the trenches with the will to change. Make sure there is executive support. Use some assessment tool. There are other suggestions, these just come to mind immediately.

If the right ingredients are not present, people are encouraged to leave the organization, or the organization to get rid of the misfits. Coaches are encouraged not to engage with dysfunctional organizations, or to fire the client when they discover that the resistance is too great.

This leaves me feeling uncomfortable. What about those left behind in the wreckage of an implementation gone awry? Fear, stress and lies are still the modes of operation. There is no hiding from the authorities. The overhead of the process is overwhelming. People are worse off, thanks to the mangled introduction of Scrum. For many reasons including personal and macro-economical, people cannot just leave the situation.

What should be done to help them?

  • Share/Bookmark

Aaron: How did winning the award help your efforts with Agile?

Kenji: Being honest, actually nobody in Japan knows that award. Some Japanese colleagues really congratulated me about winning and that made me cry. But, no other business effect.

Aaron: Why was it emotional for you?

Kenji: I have been long trying to introduce Agile to Japan, to change engineers’ lives for the better. That effort was acknowledged outside Japan. My colleagues and friends also helped me with the effort together.

Aaron: So winning the award was a collaborative effort?

Kenji: Yes. Along the way of introducing Agile to Japan, they came and formed a good community. Do you know that my speech of Gordon Pask Award is on YouTube? The last part I spoke in Japanese was acknowledgment to the community.

Aaron: Excellent! What would you say is the best way the lives of engineers changed with Agile? Is it the community? Something else?

Kenji: To me engineers themselves changed after Agile. They now know they can change, in other words. They know now that they no longer have to be just sheep. Agile is an anti-bureaucrat, anti-formalism, anti-establishment… I don’t know the right word. Something that says “no!” to the old way of thinking, and that often makes conflicts in organizations the engineer belongs to. I was lucky to have had a good boss.

Aaron: That always helps, to have the support. In your speech, you say it almost got you fired. Why was that?

Kenji: Many of us (Japanese engineers in the community) experienced conflict. So what I wanted to say was in the speech, as to “get fired”, was that we have experienced a long and unhappy, not-well-treated era up to that day.

Aaron: Different direction. How have you been applying mind mapping lately?

Kenji: 1) When I explore new features in the product. I do this a lot before writing user stories. 2) When we have a meeting to get a whole picture of the agenda together via projector, and 3) when I organize an article what to say in it.

Aaron: What else are you working on these days?

Kenji: Giving talks on how to make a good “informative workspace”, how to be a good facilitator. I have been giving that talk (“Project Facilitation: tools that improve productivity and motivation of collaborative work at Gemba” is the title) for 5 years, over 100 times!

Aaron: I bet you hardly need notes!

Kenji: I can automatically talk. I’ve been invited to give that talk to PM, QA, management, leadership and other communities, too.

Aaron: What do you like best about that talk?

Kenji: It includes a lot of pictures and it says “you can change” and you can help others. I think it has been invited to a lot of conferences because I hid Agile behind the talk.

Aaron: How do you mean that? I would guess that it means you introduce ideas about Agile in the talk? But don’t mention it ‘out loud’ or advertise it before the talk?

Kenji: The ideas are from Agile, TPS, and Facilitation. Mostly Agile. I don’t say Agile out loud on purpose.

Aaron: What kind of ideas come from Agile that help facilitation? Is it about letting people know they have the power to change their own situation?

Kenji: Agile is anti-establishment, so not many managers like it at the first look.

Aaron: So you cannot say the word or they will not let you talk (or not listen), right?

Kenji: Yes. Visualization using the wall, including Kanban, task board, burndown-charts with synchronization technique (stand-up) and self-process improvement (retrospectives) and a lot more.

Aaron: Since we all have to work with our managers, how do you include them in feeling comfortable with these ideas?

Kenji: I show them an example of a team in two separate places communicating with Kanban (or task board), but not much. Japanese managers, actually like Deming, PDCA, and Quality things a lot. So, when I say “Agile is PDCA”, they suddenly understand and start to like it. There still is a culture of QC circle.

Aaron: PDCA seems a lot like inspect and adapt, doesn’t it? Perhaps more formal?

Kenji: Yes that’s it.

Aaron: Does the QC circle help with continuous improvement and change for good?

Kenji: Yes, but old QC circles are getting “just-do-it”. or what to say, formal non practical and younger engineers don’t like them.

Aaron: Too rigid?

Kenji: No, ineffective. Empty. They do it because they are told to do so. No soul or motivation in them. A “let’s get this over with” kind of event. So QC circles remains its “shape” but not working effectively these days. And managers who saw my slides (not knowing it is about Agile) recognize it as a new articulation of self-improving process. And managers and engineers start to talk. They haven’t talked with each other… talk about not Agile, but improving Gemba. And that is fine for me. It doesn’t matter how it is called… Agile, TPS, or QC. What matters is the fact that they started talking to one another and changing their way to improve their engineering life.

Aaron: Why do you think that is? I mean, that something as simple as the “information workspace” helps this?

Kenji: Not only that, I should add retro, standup meeting. I talk about how you can do the job together and how you can improve the job at the same time.

Aaron: I see… Are you still using niko-niko? I find the concept fascinating and wonder how the information may be used.

Kenji: Yes. It is used to exchange conversation. I’m not sure you can understand. Japanese engineers don’t talk so much. I mean, culturally, they don’t talk about themselves a lot.

Aaron: So it is like indirect conversation about how they feel?

Kenji: Yes, indirect conversation, AND it is a good trigger to start talking. Culture of shame. As Ruth Benedict called it in “The Chrysanthemum and the Sword”.

Aaron: So they are embarrassed, or find it … rude?

Kenji: Yes, embarrassed. Or uncomfortable to start talking loudly about themselves.

Aaron: So it is a nice tool to help them overcome that shyness…

Kenji: Yes that is one and the other is, for the manager to notice like “everyone seems like they’re happy but there is one who is unhappy for the whole week. I should talk with him in person”.

Aaron: An invitation to a conversation, almost like a story card!

Kenji: Yes. you can say that.

Aaron: We’re about out of time, is there anything else you would like to mention?

Kenji: I’d like to say that the Gordon Pask Award helped us (Japanese community) start a phase II Agile movement in Japan. As a concrete result, we successfully held “Agile Japan, 2009”, the first Agile Alliance sponsored conference in Tokyo, on April 22nd, 2009 with over 200 attendees.

In that conference, we prepared “Pair discount” pricing and strongly recommended the attendees to come with their boss or clients. The result was 75% of them came in pairs! I believe it is a sign that engineers, managers, and clients have started talking to one another to make this software development world better with Agile (or whatever they call it.) I think this is the greatest effect of my winning the Gordon Pask Award.

Thank you very much.

Aaron: Thank you so much, Kenji.

  • Share/Bookmark

fail sign from failblog.orgLast night at the BayAPLN, Jean Tabaka from Rally Software gave a presentation about the typical failure modes of Agile. This is distilled from her observations and being asked from people who have heard the hype, what are the real problems with adopting an Agile approach?

Which is your current favorite?

  1. Checkbook commitment doesn’t support organizational change management. CEOs create within the company their own personal family dysfunction.
  2. Culture doesn’t support change. Reward plan, and a static and prescriptive standard of work. Try to keep cross-organizational uniformity and use PMO as enforcers.
  3. Do not have retrospectives, or they are bad. Actions which come out get ignored or written off.
  4. In a race to finish features, the infrastructure gets worse and architecture becomes unstable. Distributed teams make this worse.
  5. Lack of collaboration in planning. Like having the whole team for release planning.
  6. None or too many Product Owners. Both cases look the same. Agile is yet another hat to wear and the person is already too busy. They check out and ask the team to just do Agile. Can’t get past the ‘this sucks’ phase of adoption if the business is not bought in.
  7. Bad Scrum Master which uses a command and control style with the team to look faster, yet in reality slows things down. Low morale lowers IQ. Take decisions away and it actually makes people stupider!
  8. No on-site evangelist. If the teams are distributed, need one at every site. Can’t reap the benefits of Agile or offshore without an on-site coach at each location.
  9. No solid team. Actually missed this one, inferred. Empowered teams amplify learning.
  10. Tsunami of technical debt if don’t pull tests forward.
  11. Traditional performance appraisals. Individual heroics rewarded, glad you’re not a team player!
  12. Revert to traditional. Change is hard. Hit the threshold where this sucks. Revert back to old ways of doing business.

Jean then challenged the group to choose the one issue they would like to see changed at their work and come up with an action plan right now to change it. In a month, retrospect on how well it went. Perhaps that would be an interesting open space subject in a couple of meetings for the BayAPLN?

It isn’t all bad. In writing this blog, I found that Rally has also started posting the top 10 characteristics of an Agile organization.

Update: Adding the video from Agile Australia mentioned by Mike Alber.

Day 1 – 9.45am – Jean Tabaka from Zoltan Deak on Vimeo.

  • Share/Bookmark
Design by SRS Solutions