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.
The Dignity Of Work 
Discussion
No comments yet.