Sunday, April 10, 2016

Some thoughts about Toronto Agile Open space 2016

Here I just try to write down some of my thoughts about yesterday's Toronto Agile Open Space
1. I did another session: it was about the theory of constraints thinking process, I love it because I believe it will bring Agile community 2 important things: Scientific method  and problem solving tools. At the beginning I feel it might be too dry, but Shawn Button and Thanou encouraged me and told me it might be intersting, so I picked one empty space, and lobbied Thanou joined my session, and later 3 more audience showed up (Jim Rootham, Lee from Intelliware and an other TOC guy). I explained them the overview about the 5 thinking process diagram, looked like they got some ideas.
This is the the over view of the TOC thinking process I hand out to the audiences. all my talks are based on it.





 What I learned from this is Just Do It - there is no bad topic or good topics, as long as some one attend your talks, then it is a good one.
Next step what I need to work on:
 - Trying to practice it in daily work, collect all the scenarios I met and write them down into thinking process diagrams, and hopefully I can give them a name if possible. I assume all the software Scrum team will have similar issues I faced, if I created my diagrams, then it will more likely become a general solutions.
 - Share with other Agile coaches.

2. The most important thing I feel so pleased is there are more topics about technical side, for example: Thanou, Peter Yu, Paul, and Shawn Button all facilitated excellent sessions. I really appreciate them drew so many attentions. Also I was surprised that I met a lot more developers in the conference than before. This is definitely a good sign that technical side of agile is resurrecting.
This finding definitely inspired me to focus on the technical side of Agile. In future I will focus on my work on the growing Agile developers. If I have a chance to bring talks in future, my topics will focus on:
- What are the essential skills for the Agile Developers?
- How to become the a successful Agile developers?
- Transform from geek to technical leader
- Create Developers Guild and mentor ship in Scotia bank.
-  Software craftsmanship movement: define the ethics, code of conduct, and disciplines.
- The learning path of a software craftsman
- Mastery: what can we learn from Samaurai, Myamoto Mushashi and Shushi Master?
- Drefus/ Shu-Ha-Ri learning models
- The strategies for refactoring ( Mikado Method for example)
- How to convince people to practice TDD?


Sunday, March 6, 2016

Using Jenkins-cli to migrate your Jenkins server

Last week I spent some time to setup a new jenkins server, I need to migrate from the old server to new server, including:
 -  install all the plugins,
 -  and import all the jenkins jobs from the old server to the new server.
I found jenkins-cli is so powerful and so easy to use, it is a big helper. Now I would like to share how I use this powerful tool.

Download jenkins-cli
 You can download the JAR file for the client from the URL "/jnlpJars/jenkins-cli.jar" on your Jenkins server, e.g. http://jenkins.example.com/jnlpJars/jenkins-cli.jar

List plugins
   java -jar jenkins-cli.jar -s http://your-jenkins-server/ list-plugins

Migrate the plugins
To install plugins which are installed in the old servers, use the following command:
      java -jar jenkins-cli.jar -s http://old-jenkins-server/ list-plugins | awk '{print $1}' | xargs java -jar jenkins-cli.jar -s http://new-jenkins-server/ install-plugin

Migrate the jenkins jobs
   java -jar jenkins-cli.jar -s http://old-jenkins-server/ get-job "my job" > my_job.xml
   java -jar jenkins-cli.jar -s http://new-jenkins-server/ create-job "my job" < my_job.xml

Saturday, February 20, 2016

Making your calendar half full

During last 2 weeks, I found my calendar was really full, many back to back meetings. I feel busy but not productive.
I found the biggest problem is hard to deal with unplanned things: sometime a developer asked for help, but I was not available at that time according to my calendar; sometime when a meeting need to change, but due to hard to find another time, it had to be cancelled or delay to next week; sometime I found an issue and want to discuss with my Product owner, but she was not available, we have to wait until next week to discuss it.
So making my calendar full is really harmful:
  • it is hard to respond to change,
  • hard to solve the problem quickly,
  • making co-location less useful if everyone is busy with doing different things.
  • it focus on activity not outcome, it violates the Scrum's "inspect and adapt" principle.
In future I decide to change my strategy, instead of making me busy, I will try to make my calenar half full:
  • only half of my time can be scheduled for meeting in the morning;
  • only half of my time can be scheduled for meeting in the afternoon;
  • try not to schedule back to back meetings 
Also I will encourage other team member doing the same thing, especially product owner and people with shared roles like me.
and also our scrum team can also considering make the board half full.
I hope it will help me:
  • will be more responsive to unexpected situations;
  • will have less waiting time on fixing the problems;
  • will be more adaptive and more focused;
  • will be easier to coordinate with other team members if they are doing the same thing;
  • improve the collaboration;
  • help me focus more on effectiveness instead of efficiency;
  • have more slack time, so I can focus more on learning and researching.

Sunday, January 31, 2016

What I learned from the Lean startup training

Earlier this January Our Agile coach Carlos Oliveira did an excellent training session about Lean startup in Scotiabank's Credit Card RapidLab, for me this is eye-opening event, I realize there are so many things needs to digest, to dig deeper. Here I try to capture what I learned.

About Lean startup
Lean startup process is focused on discovery, learning, reducing the uncertainty through the rapid feedback loop. It is more about exploring instead of exploiting; it answers the questions of "Should we build it?" instead of "Can we build it?".
In lean startup, failure is good, failure is valuable, as long as we can learn from the failure; learning itself is valuable, MVP does not have to be valuable to the customer - which means in Scrum, at the end of the Sprint, it is still OK if we delivered something which is only valuable for ourselves learning but no value for customers.

Learning vs building
In lean startup the objective is learning, to learn we need to build first to validate our hypothesis, which is build to learn; in regular development, the objective is building, to build a better software, we need to learn first, which is learn to build. It looks like learning and building can support each other instead of conflict each other if we can embed the lean startup concept into our Scrum process.

Go out of the building, leave your comfort zone
Lean startup encourage us to close to the customer: go out of the building, learn from customer. It means leave your comfort zone, be open minded, leave your predefined opinions, discover different insights and experiences.
For managers, it means manager shouldn't rely on emails, report or spreadsheet, they should go to the team, listen, observe and sense the problem.
For team developers, it means everyone should leave their own familiar domain area, try different tools, lean different languages, take different roles, do it mindfully and deliberately.

In the book Toyota Way, I know an inspiring story about the improving the Sienna by applying principle of "Go and See",  this blog post gives you a brief summary.

How can I apply Lean startup into my daily work
As a technical coach, my customer will be the Scrum team members, my job will help the team apply new tools, technical practices which moving toward the journey of continuous delivery. There are lots of uncertainty and concerns, to reduce the resistance, lean startup is a perfect strategy for me:

  • Close to the team members: sit beside them, observe how they work, listen their conversation, sense their pain, work with them, don't wait for them asking for help; go to other teams to get insights,
  • Close to the product owners: Attentively participate the Sprint plaining meeting, meet with them regularly, understand their business goals, trying to help solve the product owner's problem first, then ask them to help me.
  • Doing experiments as strategy, for example for automated functional tests, I will try to offer different solutions, and compare each solution's pro and cons; for reporting tools, I will try different solutions as well.
  • Instead of doing the whole team wide changes, I will focus on small group of people, each time focus on one single solution, focus on one specific area.
  • Find early adopters like DevOps Champions within the team to help me.

Some thoughts about learning
Learning is my favourite topic, this Lean startup training inspired me to summarize some quotes about learning:
 - Software is a discovery process
 - Deliberate discovery
 - Learning is the first class task for developers
 - Learning is the constraint
 - Learn early, learn often, learn from failures

It also remind me Alistair  Cockburn's article about "Disciplined Learning", which is a great reference.

Resources:
- Alistair Cockburn's learning patterns
- Toyota Sienna's "Go and See" story, and this

Tuesday, June 16, 2015

Fearless change - my presentation in Toronto Agile Open Space 2015

On June 6th I participated the Toronto Agile Community's open space event. it is a whole day meeting following the format of open space. This is my second time, and I feel more confident to contribute a presentation. My topic is called "Fearless change - how to drive technical changes in large organization". it covered Linda Rising's book "Fearless change", and how I get inspired and applied some patterns to guide me build the RobotFramework community in TELUS. Now I would like to share my experience of this presentation.

Preparation
I treated it seriously because I feel this is a great opportunity of practicing my public speech. Thanks Toastmasters club gave me the courage.
 - A month before the meeting I asked the advice from Joanne Stone, she gave me the positive feedback, also provided some tips.
 - On the day before the meeting, I printed out the 10 copies of 48 patterns list, and 10 copies of the colorful mind maps based on the book.
 - I brought the paper book with me.
 - I brought the mind map of my presentation note.
 - I wrote down the names of the patterns on the Post-It note and brought with me.

Presentation
Before the meeting I met Paul and asked him some advice. also I met my colleague Dimitar, I asked him help me facilitate my presentation. It turns out he was one of my best audience.

During the presentation, I introduced the book of "Fearless change" written by Linda Rising. I tried to provide the answer of this scenario: when you learn a new tool or idea from internet or conference, how you can promote them in your organization, where can you start?  The answer is using the 48 patterns in the book, they are easy to follow, very concrete and actionable. I can apply to anybody who aspired to bring changes to the team or organization, especially those are powerless, no official titles. I gave the example how I use some patterns to guide me build the RobotFramework automation testing framework in TELUS. I covered the following patterns:
- Evangelist
- Just Do it
- Connector
- Early Adopter
- Study Group
- Ask for Help
- Involve everyone
- Dedicated Champion
- Do food

One of my favorite pattern is "Just Do it" - it means don't wait for permission from your boss, just do it, DON"T LET YOUR BOSS KNOW. when you get experience and successful, then tell your boss. My experience is if you ask permission to your boss first, he will ask you several questions: What is the benefit? Pros and cons? How much time/money it will take? But since it is at the beginning, you will not able to answer those questions, then you boss will likely say NO, once  he say NO, then you will not be able to work on it. This is Catch-22 problem, to prove its benefit, you need to do it first; to do it, you need to prove it is valuable. So the solution is "Just Do It"!


Retrospection
The feedback from Dimitar was positive, he likes my topic and hand out of the mind map. I believe I am the only one to prepare the materials hand out to the audience.
I found I can still make it better: firstly I chose the wrong room, which is too far from the main hall, limited my audience; secondly I need to provide more information, like the website of the book, and url of the mind map image, and my personal email address, etc.

Next Steps
I felt very good because I feel I can contribute something to the Agile community. A great starting point. In future I am interested in the following area, and hopefully I will provide more topics for the next year:
- Software Craftsmanship movements and coding dojo
- Self-organizing team, what/why/how
- build learning organization
- build cross functional team
- To sell is human (from Daniel Pink's book)

Resources
1. Linda Rising's book page 
2. The url of fearless change mind map

Friday, May 8, 2015

How to submit a form using javascript in ATG

Today I spent lots of time to figure out how to submit a form in ATG platform. I tired many times and with the help of Google, I finally find the solution,

1. make sure to set type="hidden" to the input field of the formHandler  handleXXX method, like this:

<dsp:form id="myForm">
   ....
  .....
   <dsp:input type="hidden"  bean="MyFormHandler.handleMethod" value="" />

</dsp:form>


2. in  your javascript method, you just need to call:

$(#myForm).submit();


I found when I typed type="submit" for the input field, and  the handleXXX method is never called when the form is submitted through the javascript.

Resources:
1. https://community.oracle.com/thread/2471843
2. http://stackoverflow.com/questions/29300501/atg-formhandlerneed-to-set-some-values-before-calling-the-handle-method
3. http://www.mkthakral.com/j2ee/oracle-atg/atg-formhandler-ajax-call-using-jquery-json/

Wednesday, May 6, 2015

How to mock a for loop using mockito

Today when I tried to use mockito to write unit test cases, I found I need to mock the for loop operation. Then I found the solution from here in stackoverflow: the basic idea is to mock the iterator class and collection class, and base on your situation, you need to set the expectation of iterator.hasNext() and iterator.next() method.

The following code is copied from the above link: