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.

- 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.

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.

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"!

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)

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="" />


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


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.


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 method.

The following code is copied from the above link:

Saturday, May 2, 2015

Groovy's powerful collection methods

Recently I just realize Groovy provides some handy methods for collections.




Friday, May 1, 2015

Review of the talk: "Complexity is Outside of the Code"

Broadcast live streaming video on Ustream

Yesterday I watched the video: "Complexity is Outside of the Code" by Dan North and Jessica Kerr at craft conference 2015.  Here I summarize what I learned.

  • Learning is a first class task.
  • Follow the process: explore, evaluate, familiarize, understand and validate
  • Lean startup's "build-measure-learn" cycle, nothing should be built without any reason.
business impact <- learn <- measure <- test <- code
Dan uses the Kanban's pull based concept to describe the above concept: for example test pulls the code, business pulls the learn. This drives me to think more about TDD, in TDD we believe we should never start coding without a failing test.(Uncle Bob's 3 laws of TDD),  which is quite similar with the lean startup concept: "nothing should be built without any reason",  in TDD, the failing test is the only reason for coding, which means the failing tests pulls the code, Bingo! Now I understand why Kent beck said TDD is Kanban for code

The Goal of software development
The goal of software development is to sustainably minimize lead time to business impact

Develop a supportive community
  • Nurturing a supporting team is vital within software development
  • It is OK to point out bad things and not have a solution
  • Reduce specialist silos, encourage becoming generalist
  • Developing a supportive community, contribute open source to other teams


Wednesday, April 29, 2015

Regular expression: you should not use dot to match any character in Java/Groovy

Recently I just realize that in if you want to match "any character" in  Java/Groovy, you should not use dot match (.).

The reason is: dot match only works for single line text, will not work for line breaks.  For the multiple lines text matching, the solution to match any character is using [\s\S].

Please refer this article for details.

For example, following code snippet is used for stripping the javascript code in the text

Source code: