cross-functional team

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.