My Thoughts on Innovation Days and Free Days

Start from Failure

Free days idea has been popular ideas. There are different version of it such as Innovation days, FedEx days and others. For improving best engineering practice, we have tried different format. It is not a success. I do believe there were some things that we were missing:

  • Commitment to show business the outcome
  • Get fully support from management
  • Freedom to choose topic

Learn and Fly

Now our team have decided to choose "Innovation days" as name. And with discussion from both Altassian and REA Group, we have decided few rules to follow.

  • Have a theme meeting to vote on ideas presented by team members
  • Team members can self-organized into 2-3 teams into highly voted ideas
  • Team members decide deliverable features (can be prototype)
  • Team will present outcome to business
  • Participants vote on teams
  • Winner team have prizes
  • Team should not be distracted

Things We Learn

It has been great success. There are few team members even work much over time in the first day.

As normal innovation days, there are lots of risk involving for each project to achieve goals. Different teams have tried to achieve goals using different ways. A team knows risk earlier is able to make good decision to which actual feature to achieve. Another team knows risk in half way has failed to deliver most of features as discussed. A team to be success in such iteration with very short time box requires extremely and mature way for developing. And it is great way to test agility of team members.

Great in helping
. Team Work
. Urgency about Due Date
. Discover personality against pressure
. Risk assessment about what to achieve
. Quicker try and error (fail quicker)
. Prove team's ability to deliver


Information Radiation for Agile/Lean Team


Information radiation is important, esp for Agile/Lean team. Personally, I don't like people to ask me about providing updates or so. I prefer the way that the information is at the place if they want. And information about team can be communicated back to business in a more predictable way.

It has been a hard trip for me to make "information fridge" become a "information radiator". Partially it could be that I am not a very communicator even in my mother language Chinese. The following will summarize my experiences.

Info, Info and Info 

There are lots of kinds of information that needs to shared in a dev team and across to other teams in business.

I have categorized into following info:

 . Work Items

 Stories that team is working on and/or is ready to work in next 3-7 working days.

 . Activity Stream

 What team members have been working in past 8 working hours or some other specific time frame. And communication between team and other stake holders.

 . Build Light

 Build success or failure status

 . Quality Metrics

 Like code coverage, Afferent Coupling, Efferent Coupling, Cyclomatic Complexity Number and others

 . General Metrics

 I love cumulative diagram. But sprint burndown, control chart and others are good candidates.

 . Blocker Items

 It is very good to communicate blocker items across team members

 . WIP Limits

 If you use Kanban, WIP limit status is a very good criteria to be communicated to other team members.

 . Next Deployment

 Days to next deployment and related items


 There are different kind of pullers and readers. And every business has structed their teams different. And I believe there is a need different kind of visualization interface to different user groups in the company.

 I always categorized into different groups. Different groups have different interests.

 Radiate Now

 There are few ways to radiate, the following ways are the ones that I have used:

 1. In Team

 - Standup
 - Grooming Session
 - Retrospective

 2. Across Team

 - Face to face communication
 - Whiteboard with printed metrics
 - In-office screen with tools like JIRA Wallboard
 - IRC like tool, such as Campfire, for distributed teams


 Information radiation for distribution teams are big challenge for me. I will share further information when I have some confident about those.


Trunk Based Development + Feature Flipping Vs Hybrid Mode (Trunk Based + Feature Branch)

Our team is using Hybrid model for source code management which is trunk based development + feature branch develpoment. It has been working quite well. And I have seen frictions moving towards trunk based development + feature flipping/toggling. With today's decision towards Kanban, trunk based development + feature flipping seems nature fit in the case for me. But most team members are not comfortable with that. And I do think team has made right decision.

In the meeting, team members have pointed out that

(1) If we don't experience now, why we need to move to new model
(2) The feature flipping would make code design less elegant
(3) What is adavantage of Feature Flipping

And team decides to continoue hybrid mode. And I believe in their decision. But there were still some doubts.

I have a better thought on it while I am on train. And the following summarize some of my thoughts.

If a team member don't experience any problem with current source code management methodology, I am strongly support decision to stay with current metdhology instead of moving. But if team expects large growth, I will suggest team to experiment some stories with feature flipping and be able to avoid difficulty of merging feature branches when team grows.

An elegant design is a fair point. It is not a time to think about feature flipping because the lost of software design doesn't provide any value with current infrastructure and testing frameworks that we have at the moment. But in the same time, I do think some design concept can be broken if it will bring more values such as performance driven scripts. But in the same time, the feature flipping can be base on very good OO design. But at the start, we don't need elegant design of feature flipping. A single configuration file and a general checking script should work.

Feature flipping's major advatanges:

(1) Minimize costs for merging branches in large teams environment
(2) Be able to hide features if features must be hidden because customer requirement or market decision


(1) Codes will looks a little bit more messy
(2) Team must commit themselves to remove feature flags after a while
(3) Without clearning flags, your code base will be a big mess