The Scrum Alliance is accepting new applicants to become Certified Scrum Trainers (CST) and I’ve decided to throw my hat in the ring. If you would like to know why I am applying, please feel free to read my letter of intent.
Tobias Mayer has a post on the new CST application process, including a link to the full process description.
The saying, “you drank the Kool-Aid” may be a derisive way to say someone has been indoctrinated. Similar to a Borg-related “you will be assimilated“. Admitting to drinking the Kool-Aid seems synonymous with “going native“. I think it’s worse than that. It’s forever linked to the Guyana Tragedy for me and is tantamount to committing suicide.
The concept of dogfooding I understand and I am a fan. Both of the verbification of nouns and of using your own product. Just not of the words. Similar to not wanting to be a pig, I do not want to be a pig noshing on some dog food. Although pigs are smarter than chickens. Pigs must not have that sophisticated of a palette, I guess. I wouldn’t want to work in a dog food factory that practiced this, either.
I am a fan of brew making and like to go wine tasting at smaller places. It helps me understand the craft so that I may try to practice it myself. Understanding all the ingredients, the process and the taste sought after. I think the phrase is gaining some popularity and I am now blatantly advocating for its use. Let’s drink our own champagne!
I am a member of a community of thinkers.
I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.
I challenge each community in the software industry to:
* reflect and honor the practitioners who make its existence possible;
* provide an excellent experience for its members;
* support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
* exemplify, as a body, the professional and humane behavior of its members;
* engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
* embrace newcomers to the community openly and to celebrate ongoing journeys; and
* thrive on the sustained health of the community and its members through continual reflection and improvement.
I believe that leaders builders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders the community’s builders.
I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.
”A community of thinkers” by Liz Keogh, Eric Willeke and Jean Tabaka is licensed under a Creative Commons Attribution-Share Alike 3.0 License.
So that we can easily find ways to constantly improve while collaborating effectively and sustainably, I like kanban as a tool which shows what constrains transforming concepts into cash. I believe it allows us to see the whole system and our part in what to do to help in the transformation of the system into a better one and our ideas in to innovation. It seems to me there would be greater benefits for all involved.
For software a kanban tool must be highly visible, with a policy to strictly limit work in progress and a policy to only accept work when there’s capacity. To be effective, it requires consensus on these policies from the people involved.
Kanban is a Lean way of saying, “I trust and respect you”.
Agile infiltrates an increasing amount of organizations. Changes in the jargon detect its influence. Phrases and words like “inspect and adapt”, “vertical slice”, “velocity”, and “collaborate” start getting batted around like volleyballs at a beach party. People ask questions in the serious tone of a late-night host discovering what is interesting about the guest: “What is the highest ranked item?”, “What are the acceptance criteria?”, “What does the team think?”. Zealots mutter incomprehensible phrases like “maximize the work not done” and “tracking actual hours worked is unnecessary”. People insist it takes a shift in mindset to understand, and yet we don’t sign up for loosing ours in the bargain. How should this be dealt with? Where to start?
Some current activities must be worthwhile. Utilizing these new Agile tools for working, the team can gain consensus on what those things are. It’s not that what we’re doing is under investigation like a new federal appointee. How can the team carry on the best of the organization while remaining willing to change that which does not work and moving on?
With the basics understood, one way may be through reflecting on what works right now. Retrospect and close out the old while opening up to the new. This may be intensive, as the scope of the session could be broad and wide.
What works well for the team? These are the team’s working agreements. What works in the process? Map out how ideas turn in to revenue with a value stream.
The best way to capture the information is with high visibility. Hung on the wall and written to be read across a room. While analyzing the information the team also looks for immediate improvements and prepares the way to embrace the new Agile culture.
Using a retrospective approach in this way helps the team build consensus through collaboration. Keep an active meeting objective visible, as well as an area to park off-topic suggestions and ideas. With the iterative approach of Agile the team can also safely begin transitioning away from traditional behaviors and courageously embracing this modern approach to software development.
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?
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.
Last 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?
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.
What is all this stuff?
Can we take a look at the Product Backlog? Does this backlog contain a long list of prioritized “stuff to do”? Does this list include defects, functional tasks and/or feature requests? What else? Does this list include everything? Are there more items in the backlog than we can see in one glance? Have we determined the business value in this “stuff” as a basis for stack-ranking these Product Backlog items? Can we estimate this “stuff” in terms of relative complexity and help with prioritization? In reality do we have multiple lists for the product being worked on simultaneously? I would guess if the Backlog exhibits any of these qualities the product suffers accordingly. Does it suffer? Don’t worry, we can sort this out.
Coherence
For some, transforming lists in to a Product Backlog of this stature appears daunting. Enthusiasm to just get it done may ignite a desire to take it on all-at-once. Through the application of some workshops to shape and strengthen the backlog followed with check ups at regular intervals, the highest priority needs of the product should be well understood by all while team members remain friendly with each other.
Step-wise refinement
AKA Inspect and adapt. AKA kaizen. AKA iterate and increment. We can apply it as well to the effort of keeping the backlog in shape. Starting with what we have let’s sharpen it up a little, evaluate it against the running and tested features, step back and take a look at what we need and tune the backlog a little more. Take breaks to help keep the energy up, and the perspective fresh.
Who should we involve in this?
If possible, the whole team and the customer who will use the product and led by a single Product Owner. The team may be large, customers busy and the users many. Representatives from every role involved in definition, analysis and design come together to shape the backlog in these instances. Led by Product Management, common roles for the Product Ownership Team include Business Analysis, User Experience, Technical Publications, Software Engineering, Quality Assurance and Customer Support. The people involved should include those who can represent Product Ownership for the Scrum teams involved. The team should be broad enough to ensure a shared understanding by everyone of why we make what for whom. This team should be small enough to maintain consensus and get things done in a collaborative manner.
How important is it?
Everything captured in these lists are important, or should be removed. What critical needs should the system provide to the market, customers and users? Leaving some in vague terms is all right. What objectives do we satisfy and what outcomes are we looking for in a release? Write these up in a largely visible way for everyone to see.
How many items do we have?
If there are more than 3 or 4 Sprint’s worth of items on the backlog, we can walk through the backlog and prioritize based on the visible goals. Anything that can be easily agreed to as necessary calls attention to why they are valuable. It may necessitate adding to, or modifying the goals as well. Along with breaks keep sorting and look to see if about twenty percent, and/or enough for about three Sprints, of the items have bubbled to the top. Along with the visible objectives and outcomes, this will help ensure we concentrate the rest of our efforts on the things we need to work on now.
What do we have?
Let’s determine what types of “stuff” dwell in these lists of requirements. Could there be features, system specifications, use cases, tasks, defects, change requests and other errata? Does anything answer to the format of a User Story? Could it be considered a good one? Does the story have any acceptance criteria attached to it? At the end of these exercises, the backlog items should be identified by type. Characteristics of good User Stories have been discussed and examples are now identified. The teams start to have a better understanding of what is being created to fit the domain.
What’s it worth?
Starting with the first item, the team should discuss how this may fit in to a User Story. If there are items identified as User Stories, check for clarity what makes that the case and refine as necessary. The story may need some rephrasing, split if complex, or combined with others if not really valuable. Capture as acceptance tests the confirmation agreed upon as the scope and value of this user story.
Features and change requests are close to user stories. Once a couple of user stories have been discussed these are easy to reformat to fit the template. If it is not a user story, it could be part of acceptance criteria of one. Use cases and tasks are likely candidates. Otherwise, it may be a non-functional requirement or a constraint of the system. These are likely found within the tasks listed. Defects encountered should have the actual and expected outcomes recorded. This helps make sure they are not really change requests. If they are enhancement or change requests, it is easy to rewrite as User Stories.
What else needs to happen?
Now that the backlog format contains User Stories we can estimate relative complexity with Planning Poker. Look for the themes that the User Stories belong to, and identify Epics and Spikes. Keep the non-functional system constraints visible. We can turn it in to a Backlog Map, AKA Story Wall, to help prioritize and discern viable releases. Mid-Sprint pre-planning meetings will keep the backlog in shape, ensuring there remains 3-4 Sprints’ worth of Stories and well-understood acceptance criteria.
Is that all?
Keeping the backlog in shape with well-sized User Stories and acceptance criteria is an ongoing process continuing for the life of the Product using routine collaboration sessions, design workshops and Planning Poker. This is the input in to the system and Sprints will only go as well as the shape of the Product Backlog.
This is the submission I had accepted for Agile 2009. Since the link to the submission may still be password protected, I’ll include the session here.
Stage: Leadership & Teams — Type: Panel
room: Toronto — time: Monday 11:00-11:45, Monday 11:45-12:30
The Agile Alliance states that “The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the Award Committee, people others in the field should emulate.” This panel brings together some of the previous winners so that they may share their contributions and help encourage others to participate in building the body of Agile knowledge. For the intermediate practitioner, it should reinforce the notion that as we practice Agile and learn how to adapt for the best outcome, sharing what we learn helps the whole community.
Process/Mechanics
The target audience is David, Agile Developer, who is a practicing Agilist. David may not be aware of the award, nor the Panel of who David is. David is out there doing incredibly good work and too humble/busy/whatever to say much about it. Past winners may be looked up to by David, and he might like to share his ideas if he felt camaraderie with the group. Let’s find out what he’d like to know from the previous winners, and what he would like to contribute about what he has been up to.
The audience will come up with questions to ask and ideas to present. We will end up with a prioritized list for the session. For those who wish to continue the discussion, we will have a final iteration of the session in the Open Space area.
Each question will be given one minute to ask, 2-3 minutes per person to answer, for a total of 10 minutes per question.
Each idea will have 3-5 minutes to present, and 2-3 minutes to answer questions, one-at-a-time, for a total of 15 minutes per idea.
Time limits will strictly be adhered to with a signal.
3 iterations of 30 minutes each, with 20-25 minutes in each iteration dedicated to the discussion.
Iteration 1
Iteration 2
Iteration 3
Take it to Open Space for one more Iteration
Primary target persona
Constant Change by Aaron Sanders is licensed under a 
