Jas Chong

生命不止，探索不息

近日听到了这句话 – 生命不止，探索不息。引发了一连串的联想。现今工商的进步就在于探索不息，也因有了不息而驱使了生命力的源源不止。相反，主管层次上呆滞的往往就是应为探索滞闭，运作硬化。探索是创作的根本，窒息了探索便是灭绝了心跳，使工业走向老化。道理简单但处理不易。对创作的长期淤滞便是引导了大众的憋闷。这也是我最近学会的词汇 – 憋闷。

尊敬职业操守与人力资源发挥极尽的相同处在于人才的发挥。像是人体在大自然的环境中，自由呼吸，运作，发挥所长。相反在雾障咽气的环境中便是憋闷，呼吸不畅，欲言又止。

憋闷

腐旧的呈现方式

1）流程不变 – 管道不通
所有大机构的共同点便是时间累积的战绩。尤其与2000年代之前开创的机构便有累积的流程有法治。以现今科技发展的速度，老旧的流程已不能应变现有的工作程式。坚守腐旧的程式便是企管上层躲在法治和合规之后的借口。其实便是畏怯改进所需要的坚定与力气，也是不屑做持久战，害怕失去建立的职位。缺少大刀破斧的毅力，保留的陈旧的流程便集体压制的进展的速度。捷径无法实行。也就迟钝了市场回应。

2）人才流失 – 浮躁郁闷
机构创作核心在于有不同的思想碰撞而保持中心思想概念，新城代谢，不断求进。不管时代有多少的更动与变迁，老旧的意识还是回绕着所谓的自然条规 – 人性的动力。基本基础建立在个人对职业与自己的尊重，想做自己能骄傲的事。在没有发挥的环境中，委屈求全，为生活而畏缩，人才流失不止于人才离职而是渗透个层的憋闷，无心进取，自保形成工作定义。恶性循环，为自保而无胆迈前或改变，也形成了集成厚厚不透，维护守旧的遁甲。

3） 自我攻击 – 癌细胞蔓延
面对坚而不朽的守旧遁甲，任何新的冲击与思想就会被排斥，现有文化细胞围攻。呈现了群体结合，智商拉低的群体动作。若果没有足够的冲击力量就无法突破现状而迈前。所有新进的动力有一定的免疫能力与为理想而做的冲刺。效期过后便融入多数文化，大众化了思想。在前卫的文化，这种动力成了不断前进的鼓励。在腐败的文化，这种动力若是被排泄若是被纳为疮痂。

企业的生命不止无不意外，需对探索保持不息。而主宰企业命运的基层便是能维护新城代谢的健康细胞。主管基层有务对自己与企业人员要求前进。但这也是最难的。这需要：

• 保持理念与远视 – 花更多的时间与探索远方而迈进，任命下层时间近期前进策略
• 缩短客户与底层距离 – 花更多时间与新一代交流与客户交谈，对人才进入注视
• 坚定简化流程 – 花更多时间披荆斩棘缩短对市场回应的时间

高层人员对探索必须树立榜样，不外包创作而是进口新血，取入先进的冲刺。

Women in Leadership – A Deliberation

Last week, I attended my first training for women with only women. Every 2 years, I’ve had the privilege to go to a training that touches me immensely to propel me into action. And this year was “Building Relationships and Influence”. I attended the class facilitated by 2 strong and supportive women (thank you Lisa and Naju) with 18 other talented, stylish and beautiful women from my organisation. I am humbled. Everyone of them uniquely strong in their own ways, bringing their expertise and knowledge to the table and opened their hearts to learning and growing themselves and others. I am quietly moved by the humility in the room, the generosity of opinions and thoughts and the grace each one showed in sharing their own challenge and difficulties. I can learn so much from the poise and posture from each one of them.

Lianna – who taught me how to laugh in the face of adversity and the one I will go to war with. We will fight fearlessly and if we die, we will at least die laughing

Neha – who taught be the confidence to go after what you want and how to stare down any problem with a plan with economic precision

Monisha – who taught me how a smile can win the world and when she speaks, we will be left defenceless

Som – who taught me the patience to take down a problem and the value of taking small but sure steps to achieve the goal with tenacity

Ari – who taught the selflessness of support and I know with her friendship is won, she will stand with you, behind you and ahead of you in face of problems

Viola – who taught me how to shrug off anyone or any problem and how not to be taken prisoner by anyone. I imagine if you are in her court, she will be fiercely loyal

Grace – who taught me grace and how we will all be bought over by her cooking and she will probably take down anyone gracefully without you even noticing

YiLing – who taught me that words don’t have to be many, just those that count

Phyllis – who showed me a glimpse of her bag of secret weapons for any problem and taught me the value of showing them only when needed

Tun Kim – who fooled me and taught me that appearance is only a tenth of what’s inside

Joan – who taught me that strength can come from small and loud voices and passion for work comes in so many forms

Eileen – who taught me how to listen actively and how to turn a learning into practice by listening actively

Agnes – who taught me the love for life and she will outrun us any day with that love of life

Lee Hong – who taught me curiosity and listening intently to understand. If one day I were to be judged, she will be the fairest of all

SiJie – who taught me the keenness to learn and though she may be the youngest but will soon be oldest in wisdom

Cheryl – who taught me how to to move mountains with influence and the right influence

Diep – who showed me how the world can be so small to be held with her big heart inspire of it all

Lorinne – who taught me how to never stop learning and growing and perhaps one day, I will fulfil my wish to pick up flute like she did

And this is only what I was privilege to have a glimpse of in the 2.5 days. Everyone of them with years experience and expertise I can learn from.

I had never grown up with strong female models in my life. And I am constantly surprised at the rich variety of female women and leadership traits. And I am truly grateful to have participated in a programme that opened my eyes to all the possibilities.

We have to do more.

Because when I look up, it is not yet 50/50 at the table, when I look around, it’s a lonely number, when I look down, I can already see the young eyes starting to despair. And when I look further ashore, equality is still a luxury for some and forbidden in other places. https://wbl.worldbank.org

A colleague of mine asked, what if men have a training for men only, what would you say? I said, do it! Do it to understand that diversity is still a problem, do it to understand how or promote diversity, do it to enrich styles of leadership. Imagine how rich the discussion at the board can be with all different characters and strengths. And imagine all these strengths and passions were driven by a common vision.

Companies can deliberate on the benefits of diversity, leaders can wonder on the ROI of having both men and women at the top. I am proud to say I belong to a place where the deliberation of benefits is done and diversity is acted on with deliberation.

https://www.ibm.com/thought-leadership/institute-business-value/report/womeninleadership

Leaning in 2018 – My year of commitment as a woman for other women.

Sometime towards the end of 2017, beginning 2018, I read the book Lean In: Woman, Work and the Will to Lead by Sheryl Sandberg. In many ways, reading this book now, in my 40s had shed light on many things I was experiencing but was unable to express in words exactly. As a woman, I was able to see clearer the topics she wrote about now then I was able to associate with in my 20s or 30s. And there were other topics that I saw parallels in my friends such as being a working woman and bringing up children and the support of a partner. And around this time last year, I made a decision to commit a year to contributing to growth of young women around me.

New year resolutions are sacred for me. I take a disciplined agile approach to my resolutions. There are minimal viable achievements, kanban flow of activities and iterations. However, this commitment was more like an idea, emerging through trial and errors with different personas. And in way, much more challenging as I actually have users other than myself. It wasn’t like I was my own product owner, scrum master and developer and customer. While the journey had its differences, the intent was the same – I wanted to equip young women with the knowledge of themselves and the skills to define the career they want for themselves. (knowing who they are, knowing what they want to do, knowing how to get there.)

Looking back, it was a challenging and rewarding year.

Trainer vs Coach vs Mentor vs Colleague vs Friend

These were the hats I wore in the course of the year.

As a trainer, I provide information and practical use of knowledge that they can’t just google and learn on their own.

As a coach, I ask questions to help them expand their thinking and guide them to arrive at answers on their own.

As a mentor, I share professional life experiences and market insights to give them a point of view to consider their options.

As a colleague, I share workload and collaborate at work and provide contextual guidance at the workplace.

As a friend, I listen and share personal life challenges and experiences and show sympathy or care when I can.

At least, I try to do the above. It’s not easy to navigate the different hats and I don’t wear all the hats with all of them. The minimum hats I will wear is to be a trainer and coach. It was not easy.

Switching hats whenever they need and knowing when they need which hat and wearing those hats comfortably were challenging. Sometimes, I was too much a friend when I should have been a colleague. Sometimes I should be a coach but I needed a friend. Sometime, I train because I’m impatient when I should have been a coach.

Pushing, pulling, persuading, cajoling, caring, crowding, sharing, showing, showering – every one a different path, every one a different means. Sometimes I get it right, sometimes, I miss the mark. I felt constantly the weight of the responsibility to do the right thing or at least, do no harm.

Being there for them also meant being there when I was not at my best. There were days when I thought my weakest was weaker than theirs. I couldn’t show up the way I wanted or show up at all. It also meant, they saw my most vulnerable moments when I should be showing them strength. And the lines were blurred.

And sometimes, I’m pleasantly surprised that I am also coached by them through these difficult corners. Their untainted lenses were refreshing and uplifting.

Female Leadership

Today’s female leaders do not have to deal with formal discrimination (in most countries) where the laws have allowed us to vote, to stand in office, to be as equal to men as possible. The fight for legitimacy is over. But is it?

As Sheryl Sandberg said, there are simply not enough female leaders today to provide a balanced view. When the majority of the leaders are men, we think majority is the norm when the norm is formed with representation from 50% of the population.

We do not have to dress like men to be a leader at the workplace anymore. We come as we are embracing our femininity. But how do we deal with physical transformations that are face only by women? Physically, we still face child birth, menopause that are unique and affects us chemically and mentally.

An exmaple, who do I talk to when I’m going through when I’m tearing all the time? Never had it when I was in my 20s or 30s. Suddenly, in my 40s, tears seem to come from nowhere and I can’t seem to control it. Wasn’t crying just tearing. Is this a norm? How do I deal with it at the workplace? I also wonder how my colleagues deal with situations when they lactate.

Reflection

When I closed the year in reflection, I had also had a new articulation of my commitment. It wasn’t simply to equip them for today, it is to equip these young women with a future support from other women. I feel keenly daily the lack of role models at the top I can chat with and a peer group I can draw strength from. And I hope more young women build strong relationships with each other for the support in the future. And I hope they will do the same with other young women in future.

Seeing the growth is rewarding albeit a growth that could be independent of our work together. Growth is natural and this year, especially meaningful for me to watch people grow in strength and stride.

This year, a new set of resolutions await, a new year of learnings. But I think this is one I will keep for another year.

Tumbling off the peak of mount stupid – lessons in building a cross functional team

To mark the end of the year 2018, I spoke at Agile Vietnam. Speaking has always been a clarifying process and this year’s theme was especially apt – learn, unlearn, relearn. And this year has been a year of unlearning.

I came across the Dunning-Kruger effect in a meet up by an experience and humble agile coach. Like Yoda, the wisdom he shared has been so simple and enlightening. So this year has been falling, tumbling, stumbling down the peak of mount stupid, caught in the valley of despair, seeking for enlightening, learning, unlearning and relearning.

All agile coaches talked about it, to some extend. We should have cross functional teams that are stable and perpetual. And I’ve proven the power of such a team in previous years of coaching. What made this year so hard and so humbling?

While preparing for the topic for conference this year, I invited a coachee / colleague to co-speak with me. In truth, the preparation was more like a long overdue retrospective for the year. And while I coach, I also learnt so much from that experience.

So what’s so difficult about building cross-functional teams? – The human need to want to be understood.

Traditional Agile

Yes, agile has also gone through transition and so should we, if we want to remain agile. For a very long time, agility was about shortening the build test learn cycle to launch products / features faster to learn from it. We brought the product owner into the scrum team to help prioritise and focus the effort. We put on the shoulder of the product owner, the voice of the customer. And we assume that with him/her with the team, we will know the right things to build.

And this has worked for many years as the technology teams race through years of release cycles to achieve a shorter release cycles.

Age of Lean Startups

With the explosion of digital startups, small teams work tighter together to release products to the market at a speed where we can see a mobile app in app store in as short as 2 weeks. These companies acquired users through ease of use and acquisition. User experience, design came to the forefront as winning edge as users are more and more fragmented in their digital behaviour. Demographics no longer rule the user behaviour and interaction with digital channels.

Small, cross functional teams that included product / service design with development teams worked well together to achieve fast time to market, investment driven development.

The purposeful collision of both worlds

Many large organisations today wants to innovate. They also don’t want to “rock” the base. Very purposefully, I’ve seen the rise of innovation labs who’s sole job is to innovate and design new products and services. On the other end, they tried to “do” agile to reduce cycle time to achieve faster time to market on the existing. The problem is that while innovation lab operated independently to build and test, the discovery path can be anytime from 3 – 6 months or longer. And post discovery hand-off to delivery follows the traditional path of funding cycles. Finally, when it reached agile development teams, they have a very short time to realise it.

Incremental vs Iterative

The problem with the above is that development teams are working to release incrementally. There is still a phase gate between design and development. Even though we had built a cross functional team of development and testing to have shippable products at the end of the sprint, we still had to cross the design phase. That meant that problems with design can only be uncovered in implementation phase. If all design problems were already solved, we are still in an incremental development loop.

Exploration vs Implementation

For any idea to warrant time and effort, it has to create value for the organisation. These can be to acquire new customers, retain them, get them to spend more or provide review. An exploration phase is important to uncover the value and justify for the build. This phase must also review the feasibility to build them, the desirability in experience and the viability for the business. That’s what the innovation lab can help with – if the innovation lab is well connected to technical feasibility study and business owners to justify needs. But the dichotomy is that innovation wants to be free from constraints to imagine and so should they.

Hence, the design (user experience, visual and interaction design) requires exploration. And in this process, I see usability testing as a form of quality assurance for good design. The challenge is feasibility at the end of innovation cycle that can completely throw out exploration outcome or require such and effort to build that lowers viability for the organisation.

User Feedback vs User Acceptance Testing

At the end of a scrum sprint, we have sprint review. The review is to showcase the work and gather feedback. Even if the product owner was accepting work on a daily basis and even if the product owner is reviewing work with stakeholders on a daily basis, the work is still not being reviewed by real users. Acceptance testing is biased as the work was built based on requirements by the same people who created them in the first place. For real feedback, we need real users. This is when usability testing and user research adds value.

However, sponsored users are hard to come by readily. If we use traditional marketing efforts to recruit users, there will be a lead time and that meant that the sprint will have to planned in testing and integrate feedback into testing.

End to end cross functional teams?

Not so. (Well, at least for now) I experimented with exploration squads that are split into design squad and tech squad for the sole purpose of exploring an idea and working on a possible solution. And to support the release of the idea, delivery squads that are cross functional to include product owner, scrum master, designers, developers and testers.

In theory for 2 week sprints, the first shippable product from design to deployable should be 4 weeks, 1 sprint for exploration, 1 sprint for build for a small, broken down idea. And that was when I tumbled down the slope of mount stupid.

Problem #1 – the hunt for perfection, in other words, “no rework”

Exploration has to be just exploration. The moment the idea becomes too big, it will miss out in synch and take a longer time than needed. And it’s hard to ask designers and architect to stop exploring and release what they have – that which they consider “not perfect”.

Exploring an idea and ideating is hard to be disciplined. Knowing the definition of done for an exploration is hard as exploration can turn into different corners and morph into different monsters.

In addition is the notion of “no rework”. That seemed to be a common mantra. No one wants to release or take on something that isn’t perfect and may incur future rework. Even I’m in conflict as to what is perfect to wait for perfection or releasing to reap value prior to perfection. Sometimes, perfection is so attainable that it would seem stupid to do something that falls short. Yet often, what we think is perfect is actually just another version of our thinking.

Problem #2 – the need to belong, in other words, “you don’t understand me”

Designers and developers and testers user different tools and language. While developers and testers are more attuned to each other from working in the same requirement. Designers and usability testing (as QA) are more attuned to their own language and ways of working. Putting them together becomes a trial of alignment and understanding.

When we have 1 or 2 designers in a delivery squad, they feel far from the rest of designers who are working on exploration and no one to spar off to discuss their work. On the other hand, it’s easier for developers when we have 3-4 developers and testers in the squad. Even the developers also felt the need to sit with other developers to discuss solutions and spar off ideas.

For this, chapters were created for the sole purpose of having people of the same kind role across multiple squads come together often enough to spar ideas and learn from each other. That works when there is support for this to happen and regular uninterrupted from to work together.

Learning Unlearning Relearning

Debating with my colleague and myself while preparing for the conference taught me something. I don’t think it’s a perfect solution but something I want to try to improve.

• exploration team should be cross functional too. Design and tech to sit together to explore an idea with a product owner breaking down the idea into workable pieces
• flow is not 1 directional. When exploration is completed and given to squad to delivery, if there are problems, they should be able to pass it back for problems to be solved.
• exploration squad should also have capacity set aside for “defects”. Design (both ux and tech) defects should be able to absorbed into work.
• delivery cross functional squad (design and dev) should be empowered to solve implementation problems as long as they don’t change original intent.
• usability testing should be in both exploration and delivery squads so user experience is tested in each phase.

Things I would not change will be:

• definition of done for both squads will be defined and adhered to.
• no matter how much the initial resistance, cross functional teams is still a benefit and should sit together (as much as possible).
• high level architecture should be a point of reference to understand solution implementation effort
• high level user experience principles should be a point of reference to define design directions
• real users are used in usability testing

Things I still struggle with and need more learning:

• how to bring exploration and delivery in synch
• how to account for effort in micro-exploration in delivery (PO & design effort to define requirements, 1 or 1.5 sprint ahead)
• Are we still 1 – 1.5 sprint ahead?
• how fast can we really be? Exploration is done 1 release ahead or exploration is part of release or partial? How should we know?

Looking back, this year has taught me much. I’ve always believed that having a goal and a clear objective will clarify the path. Yet this is hardly so in working with teams and people. It can only be achieved when we have a common goal. And achieving this common goal is a lifetime in learning.

Tumbling down the peak of mount stupid and crawling out of the valley of despair, I know fear is the impediment. The fear to see myself in the mirror and face up to failures, the fear to be vulnerable, the fear to let go of what I know for the unknown, the fear of the comfort of knowing and the discomfort of unknowing. But I know, to be a master of my practice, I have to conquer it.

“Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.” – Yoda

“To be Jedi is to face the truth, and choose. Give off light, or darkness, Padawan. Be a candle, or the night.” – Yoda

http://agilevietnam.org/avc2018/ Thank you.

Building The Right First Team

Recently, I’ve been asked, why build cross-functional teams? And I have been asking, who do you consider as your first team? Almost immediately, I get a blank look followed by, “you mean the team reporting to me?”

It’s not a new concept, Patrick Lencioni wrote in “Five Dysfunctions of a Team” with a management fable to illustrate the first team concept. In agile, we create cross functional team and that team is the first team.

Recently, I’ve been entering into the beauty gadgets age. And I’m playing with this new research of how LED light is great for skin. When I bought my gadget, I remembered my science lessons on why white light is white when there are a spectrum of colours in light that we only see in a rainbow with water in the air separating the rays.

Recently, I went back to singing. And I remembered my training in the choir as an alto, the melody is great for sopranos and altos had the un-fun game of singing off the melody. And everyone else accompany the melody to make the chorus sound great.

And I return to my point on first teams. Any organisation can’t survive with only just finance, only just customer service, only just sales, only just operations, only just technology. Whenever I ask the question, “who do you consider as your first team?” I can almost be certain to tell if the organisation is built on foundations of cross team integration and collaboration by the answers I get.

So why is it so important? Why do I get so worked up when people ask me, can’t we just have design squad, front-end squad, back-end squad, API squads?

Let’s start from the board room.

When the leaders in the board room is a team of cross functional team, each leader is representing his/her agenda from his/her lens. Each voice has to be clear and strong to represent the interest of investors, employees and customers with the operational areas of their business. When the views are clear and considered, decisions made are considered.

What It Is Not

A compromise – it is not about compromising each party’s stand. That is the spirit of win-lose.

A balance – it is not about balancing each party’s desire. That is the spirit of democracy and political pull of votes weigh in.

A compromise and finding balance is always precarious when forces hit and we try to do all by multi-tasking.

What It Is

Prioritise – it is about timing the needs and considering what needs to be done first. And priorities are broken down (like user stories) so we don’t get blocked by a chunky priority and lose sight of others.

Focus – it is about focusing on what’s right for the time. And the focus gives each priority a time to build and test and realise it’s potential but not so long that it becomes cross-eyed.

And small priorities focused in a short time span can provide data for pivot because there is a time to look far and look near.

Real World Agility

In the real world, it’s often hard to form first teams. So many times, personal agendas and turf takes over. So many times, survival instincts and prides take over. So I ask, “what is the right thing to do?”. It’s the hardest question to answer. What’s right, in whose eyes?

So I say, all things considered, a beautiful constraint, what is the most beautiful thing we can do with all the constraints we have? When all things are truly considered, any decision can be made and acted on with confidence of best intentions. We run it, test it and learn from it.

And I will always say, the past can only inform us, it cannot determine our future. What we know today will always be more than what we knew yesterday. Keep learning and doing.

Agile Coaching@Scale – A Case Study

It’s been a while since I posted. This post was 4 months overdue (very sorry to people who were waiting on slideshare). As a reflection of 2017, I had spoken at Agile France in December 2017 on agile transformation, a case study of my work in Asia. Mid 2016 – Mid 2017 was a trying year and possibly the first time I combined change management, HR and agile in 1 single assignment. On reflection, I used Agile France speaking opportunity to synthesise my learning. And honestly, if I were not selected to speak, I was not sure if I would have taken time to reflect and retrospect. (Yes, very un-agile of me.)

Unplanned Work

I was starting a coaching assignment in a bank and the original ask was to coach a few teams on agility. Most agile coaches will be familiar with this. Coaching a few teams in a large network of people meant that you can only be as agile as your system and lowest denominator.

Working up the hierarchy of problems, I met with the leader of the group who had also recently joined. His support for agility is not only unwavering but involved. And this began the journey to transformation.

The System Within The System

The group consisted of over 500 people who later grew to 700 people of largely contractors and project work. This meant contracting and re-contracting every 6 months with a break of possibly 3-6 months in between that made up a financial year. And they were supported by back end systems belonging to another unit and waterfall in their approach.

Sounds familiar? This is your typical agile sandwich, front and back of value stream in waterfall and agility in between. End to end cycle time of 18 months. Agility within those short 3-4 months of development. Here’s the composition: 6 months business approval and requirements writing, 3 months to recruit and kick off, 3-4 months of development, 4-6 months of SIT, UAT, release and deploy. That’s if nothing changes. (Budget, workforce, market, stakeholders). In today’s world, I’d say pretty utopia to expect no change.

Ca Se Fait Pas (We Don’t Do This…. Or Do We?)

If I had continued coaching as I intended, coaching 3 teams for 3 months, it would have taken years or a large team of coaches to get this many people to agility. And by the time I’m done with 3 teams to move on to another 3, they would be so frustrated by the hampering of the entire system that they would have reverted to waterfall or worse still, some hybrid of waterfagility (my new word) that combined the worst of both worlds because it’s way easier to pick up bad habits then form good ones.

In truth, I did it for 3 months before I realised that it’s not going to work. Every problem I solve for the 3 teams I was coaching was the problem I had to solve at platform level. So this was what we decided together, we will not try to perfect agility. We will take a release by release approach. That meant, everyone will be on the journey together and agility will be like a product release, release, learn and pivot, release, learn and pivot.

HR Biased

I’d admit, I have a people biased. That meant that I start most transformation with an organisation structure and development lens first. We formed teams first. It’s also what I found required for agile, we simply cannot function with project teams with large groups of people. The only difference, we form 65% full teams and as multi-discipline as possible to start with. Cross function teams comes later through resilience building.

Every initiative (I threw out the word project, along with many others like off-string, in-house) started with forming teams, inception and scrum. Every squad has to have a PO, BA, Scrum Master, Developers and Testers. Everyone was dedicated except PO and Scrum Masters who can be dedicated to 2 teams. Every squad has a name. And I cross checked names religiously to find no repeated names in 2 squads. (Imagine 15 names x 20-30 teams and long Indian names.)

With the roles defined, it also meant I could coach by roles. Every week, I spent 1h with all scrum masters and 1h with POs and BA in coaching sessions. We started with basics then moved on to more complex issues.

Tooling & Compliance

I believe in forming good habits at the start but not all at the same time. I was strict with the squads, they didn’t have to do everything, but some things were compulsory and non-negotiable from the start. Jira-Confluence was the chosen tool and everything had to be there. Since they were distributed teams, Jira is the source of truth for the work to be done. Although inception material can be on post its etc.

Quite early on, we tackled the problem of documentation. It wasn’t easy to change the way requirements were written and kept reminding everyone that we can be more compliant when documentation is actually what was built even though they were just in time.

Coaching @ Scale

There is no way humanly possible to ensure 500-700 people were coached. And there was no way I can attend all the ceremonies. Thankfully, we also didn’t start everyone together. On average, we have a new squad forming every 2 – 3 weeks. So while the next one is getting ready for inception, I focused on starting 1 “properly”. Let’s say cleanliness has degrees, there were dirty corners, hidden trash but overall, the house was neat and mostly clean.

There are 3 indicators I use religiously to know if the squads were having problems:

• scrum masters, POs, BAs missing weekly coaching sessions. When they don’t come for the sessions, they would send apologies due to conflicting meetings etc. It usually meant they have not been caught up but were caught up in a bad cycle.
• burn down starts to look like a burn up and then sudden dip end of sprint or not at all. Since everyone had to use Jira and I was strict with estimation standards and use of issue types, it was easy to see burn down charts of all the teams. Just from the burn down, I can usually tell if the team was over committing, not slicing down work, bullied by PO, skipping their ceremonies or sprints.
• scrum of scrums had the same issues repeated more than once. Since every week, scrum masters synch on issues and report out impediments, it’s also my opportunity to know where there are problems.

Every week was a habitual meeting with leaders 1-1 sessions. These 1-1 sessions combined with observations on team performance was how we know what problems to tackle first and predict what might come up.

As a coach, I used all my consultant cards to tackle the rest of the system including:

• business stakeholder requirements – I think a scrum master actually recorded me saying that this release can only take x points, it cannot take x++ and played it back to business. And x was a stretch leaving no room for unplanned work, full capacity and assuming component teams behaved.
• component teams and code drop – they can be as waterfall as they want but we will negotiate to death for weekly package and if not fortnightly and if not monthly.
• vendor teams to be co-located – finding seats and having ceremonies in the same location if they were in the same city / country
• audit and compliance – I kept asking, who’s rule is this and dig as deep as possible to the rule writer to have a conversation.

Reflections

In truth, I think I could have written a book just on the experience and learnings. I would probably not have 1 coach but have 2-3 and work as a team.

And in deeper truths, some coaches will this way of coaching without finesse, a bit of brut force. Some were appalled with the elements I used that looked like SAFe, some were puzzled by the lack of framework, and some were upset with some non-agile elements.

And I would still say, what’s the minimal viable version of agility? And iterating as we go.

#SGSIN Open Space Sharing – PO & Scrum Master, Grow Your Own

In the recent scrum gathering 2017 in Singapore was a day of open space. Open space was initially created and practiced by Harrison Own who also wrote a book called Open Space Technology, that was initially in his paper on organisation transformation. In the scrum gathering, Dan Mezick facilitated the open space. Dan wrote a book called Open Space Agility that focuses on using open space format for the adoption of agile.

The power of open spaces in an organisation is in its self-organisation format. It directs people to voice up and voice out towards a common theme or compelling problem they are trying to solve.

In a conference like scrum gathering, I have often found the intent diluted in practical use but heightened with cross pollination of ideas. Before I share the topic I attempted at the conference, let me briefly explain this. In a conference on agile with people from various stages of the adoption and interests, it is very difficult to have a compelling topic that is focused enough and specific enough in context for depth of discussion. At the same time, with the variety of background of participants, it becomes a unique market space where ideas can be shared as a form of sampling. Instead of the depth of ideation outcomes from an open space in an organisation, it becomes a breadth of possibilities everyone can take back to explore further.

With that, I attempt to explain how my session morphed into something I had not expected nor intended.

In my previous article on scrum gathering after thoughts, I mentioned that I had an idea to talk about product owner and scrum master with my friend and fellow agile coach in Japan on a bus. (I encourage bus rides, it creates incredible conversations like the kind we have in cars.) The compelling problem has been this:

With every agile adoption, the consistent talent issue is the need for new skills and competences to operate in the new ways of working. The most marked initial challenge are roles of product owner and scrum master. They didn’t exist in the company before agile adoption, there aren’t that many in the market place. So what can organisations do? And how can they scale when the recruitment of these roles are not at pace with the transformation?

I had used a few methods to help organisations where I coached to tackle the problem. Using my past HR and talent management background, I had always approached this topic with “grow your own” over hiring.  And I wanted to find out what other people had done, gather new ideas. That was the intent of sharing the topic.

At the gathering, 2 things happened. I presented my topic and someone else wanted to present a similar topic so we combined our sessions. During the session, my co-chair wanted feedback on a training program that he is promoting to the market. Alarm bells went off in my mind as I hadn’t planned on being part of a sales pitch. (By the way, open space market place shouldn’t be a sales opportunity.) So very awkwardly, I tried to check the audience temperature and needs. And we asked the audience if they wanted to continue with feedback on the training programme or play a simple game I use to uncover the competences of PO/SM.

And very lucky for me, my co-presented stepped back from his topic and recommended mine.

So here’s the thing, I had not intended to have a session on the techniques I used but I was happy to share. And more importantly, it was by a sheer coincident and divine intervention that I brought my competency cards to the conference. I grabbed it from my desk in the morning while walking out, thinking, I’ll use it to show an example of what I did as part of the sharing / conversations. I almost walked out of the door without and something made me run back to my desk to grab it. That was what happened. I think I just winged an openspace session with no prep at all. For better or worse, I think the people at the session didn’t realise it.

Alright, here’s the real deal. In the rest of the this article, I’ll explain in better coherence what I shared at open space.

The workshop topic / technique: Co-creation of competences for PO/SM

The purpose: To co-create competences of product owners and scrum masters and a peer mentoring program to help them develop their skills. To create a strong chapter and/or guild of each role for continuous learning and scale.

Participants: Product owners, scrum masters, with team, leaders (optional) See variation below.

The materials: Any existing competency program used in the organisation. (I used Gallup’s strength finder strengths in the session).

Variation to the workshop: It can be for any role. The important thing is for people actually performing the role and/or working with the role to participate. This can be agile teams, leaders or HR. Although I tend to think HR is the consumer of the outcome not the contributor.

Example: Product Owners Competency Workshop

Set up: In a very simple version of this, only POs are participants of the workshop. A set of competences are used and there is no level to the competences, just the name and description. Each competence is written on a card. I used Clifton’s strength finder that has 34 strengths, hence 34 cards. (You can buy the book and take an assessment to find your strengths).

Round 1 – Individual Assessment

Participants are handed a set of cards each. They have to select the top 5 strengths they consider to be essential for a product owner.

Round 2 – Consensus workshop

All participants take the 5 strengths they had individually selected and pick them out from a new deck that will their common deck. Each different strength is represented by 1 card only no matter how many people picked them. You will end up with the minimum of 5 (if miraculously everyone pick the same one) or 34 (if everyone picked a different one and all the strengths are selected).

To gather consensus, you can use wall planning technique or MoSCoW method. The idea is to get to a final 5.

Note 1: For wall planning, you line the cards in order of importance starting with 1 and then add the next one left or right to the first card and so on. To the left is most important, to the left least important. The left most 5 is selected.

Note 2: For MoSCoW, the must have pile should only have 5.

Note 3: You may ask, why 5, not 6 or 4 or 7. You can have more or less but too little and the role is too singular in strength, too broad and no one can embody them. To do 5 well is usually the tipping point.

Round 3 – Self Assessment with Peer calibration (we didn’t do this at the open space but I talked about it)

Each participant has a flip chart paper on the wall and they draw a radar chart frame with the scale 0 – 5. On each of the lines, they should write the 5 strengths they had selected in round 2. For each of the strength, they should score themselves on a scale of 0-5 on their effectiveness in displaying and/or exercising the strength. 0 is not at all and 5 is highly effective.

After they had scored themselves, they form groups of 3 to discuss their scoring and explain their idea of the scale. Eg, what does a scale of 3 means for that strength.

Repeat this for several rounds, each time swopping members to have better calibration of their scale.

After a few rounds, they can rescore themselves.

Note 1: Self assessment should be an honest assessment of their own strengths and effectiveness. Hence, the workshop space should be a safe space where their managers are not present and these are not being used for KPI and promotion purposes. The intent at the beginning of the workshop has to be clear.

Note 2: Depending on the maturity of the group, the set of competences and self scoring can be skewed but usually, they can recalibrate through the conversations. The importance is to have the conversations and have as many rounds as possible for discussions on their scoring and scale.

Round 4 – Peer Mentoring

To close off, participants will find peer mentors and mentor their peers for each of the strength. They will indicate the person they are mentoring (where they score high) and the person they will be mentored by (where they score low).

Typically, participants can end up mentoring multiple people in 1 or 2 strengths where they are better at. Each participant should have at least 1 mentor for each strength they want to improve on.

Note 1: Participants may often choose their “friends” or people they are familiar with as mentor or mentee. I often encourage seeking people they had not worked with or in their social circle.

Note 2: Mentoring events should be specific and regular. So I encourage agreement up front on the cadence (when and how often) and how they will have the session. (where and what goals).

Closing Note

This exercise is best conducted every 3 – 6 months in the beginning of the agile journey and 6-12 months along a more mature agility path. This way, the competences created are just in time and relevant to the context and their abilities. With maturity, the competences or strengths selected will often change and the scoring will be more calibrated.

The facilitator should be someone outside of the team(s) and is not performing the role.

Use of Outcome

There are various ways the outcome of each workshop can be used. The most immediate outcome is for the group to have common understanding of the strengths required for the job and have a peer support system to help them grow.

The outcome can also be shared to identify potential people who can perform the role along with an understanding of the responsibilities of the role. (For this, it’s best left to another conversation and post.)

After thoughts on scrum alliance #SGSIN

This year, with everything that was happening, major transformation at client’s, changing jobs and the french election (yes, I was worried for a while), I didn’t propose any topic. Not that I would be selected to speak but a proposal to speak at the conference is always a self-reflecting exercise to crystallise my thinking and a report card of sort of my learning since the last topic. It was also more appropriate to say, I couldn’t put into words what were brewing thoughts in my mind.

On a bus with a fellow coach from Japan to go shopping (of all things), we started talking. If you have conducted training to people who speak a different language than yours or tried to learn a different language, you would find out very quickly 2 things, 1) how to say what you want to say in shorted possible sentence and as clearly as possible 2) you have no understanding or baggage on the language (hence, sarcasm is lost on me, wouldn’t understand the double meaning).
While cutting through all my jibberish in the mind, trying to explain my frustration in coaching this year, I found myself getting from 1 aha moment to another. And that was how I came up with 3 topics I’m excited to share and wanted to propose at the open space. I managed 2 at the open space for which I will share in separate articles.

• Scrum masters and product owners – How to grow your own using HR competences program?
• Agile coaches – how do we find continuous integration with others to grow in our craft?

The 3rd one was about the top 8 things to focus on in the first 10 weeks of agile journey. While on the very long bus ride from west coast to orchard, I rattled on about 5 and couldn’t quite work out which other 3 would be more important. I wanted to ask the audience to help me during open space but decided there were far more interesting topics to attend than to occupy a slot. So I conceded.

Coming back to my aha moments and learning a different language. Learning all these languages wasn’t just for fun (it’s actually not that fun to be in a class, loss for words, especially for me) but it was for me to relate to people in different cultures better and become more efficient in communicating. I learnt about their food, language and culture so I can see their perspective. Agility was about doing things the way it should be, really. Getting to the market faster, learning to do things better and of higher value to the people who uses them. Isn’t that what we wanted when we first started?

Secondly, because I came from a long history of change and talent management & aquisition and not from technology, I didn’t learn agility with the “baggage” of someone who had worked with it and then taught it for years. I had to learn “why” and logic in structure unlike a kid who has learnt to speak a language from birth. And that’s how I learnt agility. I didn’t have to unlearn things, I learnt it in 2010s when the world has started digitisation.

That was how I came to talk about my frustrations and how I came to those topics. Being at war with what it was and reinventing what is becoming and always, coming back to good practices and habits that just work (at it’s purest form). I sincerely believe we just can’t be not agile but we have to keep reinventing our practices to achieve the why.
I love scrum, in it’s simple list of events and artefacts is an opportunity to invent practices to meet the objective. It never ends because the “why” is true. Agilists have to keep reinventing and improve. It is our cause and or being. 

I like the story Peter Berhens told at the closing, in an environment to be the best, you have to fight to have a place in agility. It’s not a given or a mandate. And I think that fight is to be constantly better in our delivery, constantly clearer in our objectives, constantly sharper in our understanding.
When I returned to my team this week, a scrum master came up to ask my opinion on something. I asked him, what he thought. He said it smelled a little bad and I said, well, if it looks bad, it smells bad, it probably is bad. Abandon and rethink.
We have to hone our gut feel, sharpen our senses, learning about the newest and clarifying it for use. When you look at it, we’ve been living in distortion from what it should be. Yet in a conference like this, how do we absorb so many things to find crystallisation of thought. That’s why I think, I’ll be reflecting for a while, distilling and adapting till it is not gooey in my mind. I shall be seeking clarification for a while.
Quoting Pete: You’re (I’m) not done!

I want to build a SWAT team for agile transformation

This last year, I was deep into agile transformation in an organisation as an agile coach. On the eve of my handover, I had realised that much has been done and yet much more to be done. When I surveyed my body of work, I had also realised that the transformation had taken a direction with my background in organisation structure and human resources. And I was keenly aware that I had not been able to reach deep pockets of agility in other areas outside of my specialisation. It has been a while now since I talked about a SWAT team. On retrospection of my work, I knew that this is what I want to do going forward. Build a SWAT team for agile transformation. A special weapons and tactics team focusing on helping organisation be agile.

Let’s assume I don’t have to reiterate the benefits of agility. So many people have done that. But in case of any doubt, let me summarise by saying, there is no technology or business agility. An agile organisation that has a strong learning quotient to learn from the market and react accordingly cannot be agile in 1 area and completely lagging in another. That will be like saying, I need a strong right arm and the rest of my body can be waning. Physically, I am not possible you have isolate a part of the body to be strong while the rest is weak and lethargic. So I go back to systemic change and change that impacts all level. And this is why I think 1 person can’t do it all and neither can 1 type of person.

In Europe, I’ve often seen and was part of the agile community formed by individuals. Most agile coaches are independent and operate independently. That or they were engaged in-house as part of a group of agile coaches. There were various models of engagement and I had also experienced them myself. One time, I was hired as an independent change consultant, another, I was hired as a scrum master / agile coach. Some of the people I knew were hired as agile coach to coach a few teams, others as trainers. Often what I see (not always) is a fragmented market of demand and hence a fragmented market of supply. And the type of demand changes from medium to large organisations. The small companies are usually inherently agile and lean from entrepreneurial background. For medium to large companies, sometimes scaled agile is used to create some order in process.

In Asia, I have started to see some similar trends. Companies look for agile coach, trainers, scrum master / agile coach. Before I generalise further, I think I can say that there is a growing trend towards adopting agile. (For good or bad reasons.)

So what has all these got to do with SWAT?

Let me first lay out a few common observations and challenges to overcome in an organisation that is starting to think about agility.

•  Business Cases – There is usually an investment accountability process for any product release. This means long research and requirement writing to finalise a strong business case for investment and a funding process that follows.
• Project / Phase Approach – Large requirements are broken down into phases for delivery and usually, there is no respiration period to learn from the market if they were playing catch up. And teams delivery each phase can be made up of different people.
• Silo Functional Organisation – In a project or product delivery, the people writing the business case, detailing the requirement and then explaining to technology team are independent functions not belonging to the same group. And there is hands off in the process.
• Large and Non Stable Teams – Each silo function is probably a large group of people (over 10). For delivery groups, it is a large group of people gathered together for 1 project and they may or may not work on the next project together.
• Lean and Cost Saving Infrastructure – Development environment is shared and there is no or little automation to handle multiple releases and shorter development cycles.

So it is not uncommon when a company thinks about trying agile, they use a project as a test bed and hire an agile coach to coach this project to see how that works. And then the next project and then the next. It would be ok but usually with a systemic environment that is not conducive, the initial team that experienced success will probably hit a break wall very soon. And when teams are formed for a project, the team building is gone to waste when they join other project teams and work with new people.

For an organisation convinced and committed to transform itself, I think it requires a pace that allows for sustainable momentum of change. But there is an initial stage of transformation that will be institutional followed by sustainable pace. That is when I think we need a SWAT team.

And these are the special weapons and tactics that will be needed in different order and combination of sequences. And it will be a tall order to expect an agile coach to embody all of these to help an organisation transform. And a team works together to focus on these areas to achieve the initial transformation before going into a sustainable mode.

Organisation Design Change

Teams have to be formed to create stable and dedicated teams. In existing context, this is not easy as each person can be involved in 2-3 projects that can finish at different times. They will need to be transitioned to form teams to start working together. Some of these roles may not even exist in the organisation chart and incumbent HR may not be able to support the creation of these profiles let alone the hiring of these people.

In tight labour markets and where labour laws are strict with strong unions, attrition, work contracts are common issues during this transition. Acquisition of external skills will also be difficult in particular skills area. In response, the design will have to have elements of transitioning, skills upgrading and development.

Product Driven Change

Where projects govern the way things are delivered, products thinking will have to take over to make way for stronger product integrity and innovation. Product driven thinking will mean a stronger focus on product performance and delivery where most valued. It will also require stronger design thinking to ensure products can be delivered incrementally in response to value driven in each delivery. To achieve the “cheaper” in a “faster and cheaper” agile delivery, it has to do with doing less and delivery more value to customers. Targeted delivery ensures each delivery enhances the product in a way the customer desires. And when objectives are achieved, stop developing the that area to focus on other areas of value. But this means better business domain knowledge, stronger design thinking and focus on innovation and market response.

Process Change

A waterfall or handoff type of process can be entrenched in the decision making process. For this to change towards agility without losing accountability will require process change to review both. When we lose the long business case and requirement gathering stage in place of agile delivery to build-test-learn from the market place, we need a different process of communicating requirements and account for investment. Often, this also means a process of “testing” and “learning” that may not be in place or as strong as the “building” and releasing process. Without it, the organisation will only be releasing in shorter spurts of time that may not also end up to be more expensive to support these frequent release.

Budgeting & Financing Change

Budgeting and financing is an integral part of process change but deserves a space on its own especially in large public organisations with stakeholders and shareholders to answer for. Inherent in any agile delivery is a shorter decision making cycle coupled with shorter release cycles so the over response to the market is shorter. Traditional funding and budgeting model is anything but short as it calls for scrutiny in investments and upfront accountability to ensure the money spent will deliver the said outcome. To move away from upfront promise to outcome driven accountability, the budgeting and financing process will have to be continuous and more frequent, as many as the release cycles intended.

Engineering Change

To respond to agile delivery, the engineering practice will have to change. Shorter delivery cycles requires teams to work at a sustainable pace but consistent. To ensure quality development that can be released “any time”, test driven development practices, test automation, code quality will have to meet those standards among others. In a longer release cycle, teams can handle a sudden surge of activities near release date where late nights ensued and adrenaline pumps high. With regular but shorter release cycles, the quality will have to ensure releases are smooth and each release doesn’t become a mayhem but just a regular exercise.

Infrastructure Change

There is almost always a need to change infrastructure to support agility. This can mean creating possibilities of automation to support the releases, newer technologies and transition to these technologies. It can mean cloud, different supporting systems and many more. (And this is where I am lost.)

So you see, I can’t do it all. I am your organisation design change and process change person. And I wished I had a design thinking person, a devops person, an XP person and a beyond budgeting person to come together and form a SWAT team.

In my dream, my team will study the state of the organisation and chain up the changes so each organisation design change is hooked up to the right process change and the right engineering change and etc. And each change is dosed at the right amount for that organisation to create the different layers of transformation. And we will work at the leadership level to create systemic change to the environment so the teams can work in a fail fast fail safe environment while delivering products they and customers love.

And the SWAT team will only apply our expertise where required for the areas required for “just in time” change. While one organisation is going through transformation, another organisation can be sustaining change. And the SWAT team can be an agile coach for those sustaining change and come together to SWAT through a transformation. And the SWAT team is stable, we know our strengths and we cover for each other when we are applied. We have all the ego in the world and yet none with each other. We push each other to be better. We fight, we work, we build. We are the best together and can stand on our own. (Now, I’m getting really idealistic.)

It changes nothing. It changes everything. I want to build an agile transformation SWAT team.

Moving to Singapore – Agile in Practice

It’s been a year I’ve moved to Singapore. Almost 9 months since my last post. Think of it as a release, after many iterations in the making. My first MVP was September 2015 when I tried out 1 month of living in Singapore. The next iteration was November 2015 where I actually stayed for 6 weeks, found a job and started working on a project. And I moved out of Paris and 10 years of my life in an apartment in all but 10 days. And it’s almost 10 months since I made that decision. My life adopting changes in numbers.

Singapore was where I was born and bred, I had studied and worked here all my life before moving to Paris 10 years ago. But Paris was home to me. To move out in 10 days a life I made for 10 years took all the agility in me. I developed a kanban flow of work, mapped out my life in various epics and sliced my first release. Everything else waited till February 2016 when I returned for another 10 days for another slice in release. Let’s take my move as an examination into agile application since I’ve always said, “you can apply agile to anything.” – Probably the most dogmatic thing you’ll hear me say.

Proof of concept – Working Freelance in Asia

To move to Singapore, I needed to proof that the concept works. (Notice I didn’t use the word ‘back’. It’s hard to say there is a notion of moving back since I never really felt at home in Singapore. And it’s just easier to consider it a brand new country move.) As an independent in Europe, I wanted to see if the concept of freelance works in Asia. There was a lot of time spent in front of Linkedin. A lot of skype and email conversations with people operating in Asia in the agile space. And I lined up as many conversations I can get for my September visit. I also wanted to see the appetite of Agile HR in Asia where it has taken me 2 years to build in Europe and only just seeing the beginning of a form of recognition and adoption. In addition, I had lined up a potential business opportunity to practice Agile HR as an independent in Singapore. It couldn’t be more encouraging.

Sept 2015 – My visit has proved wrong a few assumptions. Since I was going back for my sister’s wedding anyway, it was really fail fast and very safe. I had found that independents are still in the budding stage of being recognised in the Singaporean work society. Coupled with a new adoption to agility, being an independent in this area of work meant that work is limited and largely in training areas. In addition, procurement practices in large organisations where there were signs of agile adoption have not evolved to retain independent contractors. Work contracts are still signed through preferred supplier agreements and large supplier qualification exercises. Singapore is also a very expensive city to live in. That meant that without initial work, the upstart cost will meant large investments upfront. My business opportunity also stalled due to budgeting discussions and interventions from HR.

Round 2 – MVP – Minimal commitment move to Singapore

The minimal viable product / solution-more-like-it was designed to be a small test to the market. I was accepted to speak at 2 conferences in November 2015, Agile Tour Vietnam and Agile Tour Singapore. Since they were at the beginning and end of month, I had another 4 more weeks to see if my move to Singapore could be finalised. Both tours gave me good understanding of the agile community in the region and where the standards and appetite was. I was also confirming an offer in the mean time.

Nov 2015 – Minimal commitment / maximum output. In November, somewhere between my travels, I confirmed my work engagement. There was no contract but I had an offer that I could work with. And I found a place that I could rent into. I was travelling with a cabin luggage for 4 weeks of travel and speaking engagements and ended up staying for 6 weeks. I had started and completed a 6 week projects and signed on for a job while I still have everything in Paris to sort out. In 6 weeks, I sorted out all the essentials to give me the move I need.

2nd Iteration – Release 1.0 – 10 days to release

I returned to Paris knowing that I had to go back to my new job in 2 weeks. Excluding weekends and jet lag, I had exactly 10 days to sort out my move including French administration. (If you know about French administration, you will give me a 2nd oscars for lifetime achievement award in doing all these in 10 days. The first was to set up a company in France). It requires extreme estimation and every feature valued to give maximum benefit while the rest would just not cut it.

Dec 2015 – I story mapped my life in Paris and found a slice for release. All others will have to be abandoned or left to next release in Feb 2016. The 2 biggest themes were french administration and my apartment. My apartment were divided in different parts of living epics. Each epic had essentials that I had to take in and others nice to have that I had to abandoned. But I had allowed a few “wow” features that would give my life a sparkle to get over all the nice to have that I had to leave behind. Since French administration has large dependencies and hard to estimate in effort, I had to draw up my risk charts and focused on the riskiest ones to mitigate risks and manage them through a kanban board. The flow method worked better ensure that daily planning and prioritisation can helped when new information comes up. I’ve also added a new column for “pending comments” where there is no limitation on WIP since I can pile as many there as I want pending feedback from all external parties. Some items moved up in level of importance and some had to move down (very painfully but necessarily). I sacrificed a few wows but kept at least 1 box of wows to last me through the new move. I had 3 checked-in luggage, 2 cabin luggage and 2 boxes I can post. Everything else that didn’t fit won’t qualify. On Christmas day, I left Paris and 10 years of my life in 10 days. There were still many things left in the “pending comments” column but largely, my release was secured. Among the “wow”s were 2 boxes of fois gras, 1 bag of champagne truffles, a slice of truffled brie and lots of champagne and whiskey on business class. The most riskiest french administration items were tackled or mitigated with the rest in wait of release 2.

Managing an agile backlog with a waterfall French administration backend was my waterscrumfall release.

Release 2 – Closing my company in France

Feb 2016 – 2.5 months after moving to Singapore, I flew back to Paris to close my company. Release 2 afforded me with some additional wows and must haves. Depending on your point of view, French fashion was on my must have list. My reason, can’t get it here or at the price I can procure. But release 2 was largely for french administration of things. All the items that had large dependencies that I had put in motion had paid off.

Waterscrumfall – yes, we all hate it. It brings goosebumps everything I hear of it. But on hindsight, I had learnt much with my waterscrumfall release 1.0. Release 2.0 was integration with backend some of the front end user stories for a more complete release. I had exhausted cosmetic releases and all “integratable” items. It’s not ideal but it’s how I learn about agile transformation in less ideal places.

• RAID – Risks, Assumptions, Impediments and Dependencies is a very important step and essential in prioritisation.
• Dependencies are dealt with up front and allowed it’s time to complete and to avoid a lot of grief in the future.
• Slicing of user stories include prudent pruning of features with dependencies.
• Don’t focus on just must haves, a “wow” item can be much more valuable than a few “must have”s, it’s all a matter of perspective.

On that last point, think about the new iPhone 7, it has removed a “must have” of the last 10 years, before even smart phones came to the market. The phone jack is gone and the wireless ear phones is finally wireless.

And so is life with its many surprises. I also had to let go of a few assumptions for my move. The most painful was missing 4 seasons and its colours, the most compelling was Asia’s thirst for new expertise and a very very fertile ground in agile transformation. And so, I had left the city of lights for another. From a hunter of work to be a farmer of new approaches. And many aspirations. So release 3 will be brand new, in the making.