Agile : a long road ahead
We were a little team of Offy’s Agilists to join the Agile Tour Vietnam 2012 in Saigon Tech on the 8th and 9th of January. For this second edition, the Agile Vietnam team has organized a two days event in order to cover subject like Scrum manufacturing, management 3.0, Marketing, Sales & Public Relations, how to energize people. This edition was the occasion to gather not only people from different companies in the IT ground but also future Agilists and graduate students.
The success of this event was thanks to the organizational team who make these 2 days as SMART as possible and thanks to top notch speakers:
- Kiro Harada, Lean and Agile Coach Expert
- Joe Justice, WIKISPEED CEO
- Ken Schwaber, Scrum co-founder
- Peter Stevens, Scrum Coach, Trainer and Mentor
- Alaxandre Cuva, Agile Coach, Trainer
- Duong Trong Tan, Academic Head, FPT University
- Daniel Teng, Agile Coach Expert
The event was organized as a scrum framework; except that the project was only 2 days. After each session of conferences, workshops, debates… values and knowledge has to be delivered; they can be considered as a sprint. At the end of the first day, we made a retrospective of what people learn, what was good, what was bad and what can be improved for the second day.
In order to give a clear message to the attendants and to make all theories and practices understood, we were involved in every activity:
- The keynote: conference opening the 2 days by Ken Shwaber with a team building game.
- Conference: theory and practice with team building games
- Workshops: case studies or practice of an Agile Methodology
- Panel Discussions: a time to ask questions and share experiences respecting to Agile methods
These two amazing days were full of energy, knowledge sharing and constructive meetings.
My advice for the Agile Tour Vietnam 2013, bring all your sticky notes and run to this event. Even if you are an expert in Agile, you will learn a lot. At least you will come back home full of motivation and ready for moving mountains.
By Minh Khiet
I participated in Daniel Teng’s session: “Retrospective on Retrospective” where the audience learned about the retrospective and its role for the Agile’s team. During his speech, I was very interested in the fishbone diagram which is used to identify the root cause of the lack of retrospective. But I still couldn’t figure out its structure and how to apply it correctly.
When I got home, I researched it on Internet and I found out there are too many methods which can be applied on the fishbone diagram such as: the 5 Why’s, the 4 Ps (Policies, Procedures, People, Plant/Technology), the 6 Ms (Machines, Methods, Materials, Measurements, Mother Nature, Manpower)…and I thought that our team can try to learn and apply the 5 Why’s method.
The fishbone diagram gives a better retrospective to improve our team’s quality after a sprint. Here is a definition of these methods for your reference:
- The Cause and Effect (aka Fishbone or Ishikawa) diagram was invented by Dr. Kaoru Ishikawa, a Japanese quality control expert. This is a visualization tool for categorizing the potential causes of a problem in order to identify its root causes. A fishbone diagram is useful in brainstorming sessions to focus on conversation.
- The 5 Why’s is a question-asking technique used to explore the cause and effect relationships underlying a particular problem. By repeatedly asking the question “Why”, you can peel away the layers of symptoms which can lead to the root cause of the defect or problem.
- Once all inputs are established on the fishbone, we can use the 5 Why’s technique to drill down to the root causes.
How to create a fishbone diagram:
- Create a head, which lists the problem or issue to be studied.
- Create a backbone for the fish (straight line which leads to the head).
- Identify at least four “causes” that contribute to the problem. Connect these four causes with arrows to the spine. These will create the first bones of the fish.
- Brainstorm around each “cause” to document those things that contributed to the cause.
- Continue breaking down each cause until the root causes have been identified.
How to complete the 5 Why’s:
- Write down the specific problem. Writing the issue helps you formalize the problem and describe it completely. It also helps a team focus on the same problem.
- Ask Why the problem happens and write the answer down below the problem.
- If the answer you just provided doesn’t identify the root cause of the problem that you wrote down in Step 1, ask Why again and write that answer down.
- Loop back to step 3 until the team is in agreement that the problem’s root cause is identified. Again, this may take fewer or more times than five Whys.
Furthermore, we can use 4W1H (What? Why? Who? Where? When? How? ) to fulfill the fishbone diagram and figure out all the root cause of the problem. This can avoid making mistake next time.
I hope that all the information above will help you to well understand Daniel Teng’s fishbone diagram. If you are interested in this subject, you can find the template of fishbone diagram online here:
Automation testing: Step by step.
During the Agile tour, I asked the coach so many questions to enhance the Scrum process in our team. I was very glad that they answered and gave me a lot of insights.
- How to maximize the story points in one sprint,
- how to keep the sprint’s stability,
- how to estimate amount of work during the sprint planning…
Furthermore, I asked them about the testing enhancement using Agile methods. Surprisingly, they all gave me the same advice: “To reduce a time and gain more benefits, automation testing is the best way.” But, it requires too much experience on testing and a coding knowledge. This is a big challenge for testers because most of us are young and we lack of working experience and coding knowledge.
That’s why, to accelerate the progress and reduce our research time, we have tried to form a pair-testing group working on the same testing tool but applying it on different projects and asked the support from our developer to form a group dev-tester.
By sharing the information, knowledge, testing experience, we will improve the collaboration between developer-tester and tester.
Truly, I really hope that our team is on the right way and at the end of June, 10-15% test cases in our project will be automated.
After all, thanks to Agile Tour 2012, I have gained a lot of knowledge and made a new relationship with the coach whom I will ask my questions in the future. I’m eager to participate in the next Agile Tour 2013 in Ho Chi Minh City.