Last year in November I attended the LeSS training with Bas Vodde in Singapore. After three days of immersion in LeSS and Lean I asked Bas:
“Would you hire a Scrum Master who is not a software developer?”
The answer was expected. At the same time, earlier in the course, we discussed engineering practices. Bas said if our engineers don’t do any practices, you telling them to won’t be effective (no matter your background). Don’t tell them what to do, make them excited about clean code, quality, finding code smells, refactoring and so on. Otherwise put, coach them.
And fortunately there are amazing Agile Coaches out there that prove that it can be done, even if you’re not a developer, such as my personal idol Lyssa Adkins, an amazing coach and author, former project manager.
At the same time, being non-tech has its own advantages. Let’s explore what you can do to be a better Agile Coach, if your background is product development, but non-tech.
- Learn to code. No, it’s not about you becoming a programmer but understanding how to solve problems with code, and at the same time you get a chance to practicing what you preach (pair programming, mob programming, TDD, etc.). I’m currently doing Harvardx’s CS50, but also recommend the MITx Python course if you want to go in depth.
- Talk to engineers about their coding philosophy, approach, practices, experience and so on. Understand what it means to be a good programmer or write good code and how they grow their skills. One thing I changed from constantly talking to our devs is to set meetings back-to-back in one day or beginning / end of working schedule, following Paul’s Graham advice on managers vs makers.
- Read software development books. Books like The Mythical Man Month, or The Pragmatic Programmer can bring a lot of light into how the developers think and the troubles they face. I made a small list of such books on my goodreads if you’d like to find out more.
- Push engineering practices through your seniors. As mentioned above, telling your team to do pair programming or TDD might not work if they’re not interested and passionate about it. My strategy is to use the seniors to bring these in, so I worked with the CTO, leads, seniors, CIO to validate my technical improvement proposals and help them bring it up to the team (through a learning sharing session, through seniors starting to do pair mob programming with their teams as an experiment and so on). Seniors are always open to improvement, teaching and mentoring, no matter if you’re a techie or not. If you got curiosity and the will to learn and help the team grow, they’re on board.
- Leverage your strengths. I worked in product management, project management, and I’ve been a consultant. I’ve been practicing for over 10 years clear communication, conflict resolution, persuasion, coaching, servant leadership, change management and so on. These are my strengths and also represent my comfort zone. This is the area where you can constantly be superior to a technical coach, so use those skills and don’t forget to level up.
- As a non-tech Agile Coach you can be more objective in your coaching the team. As a coach, you’re not supposed to tell the team what to do, but to help them figure it out on their own. So your focus is to create the right environment for the team to make their own decisions, facilitate their learning and make sure they keep being agile and continuously grow. Not being technical, makes the facilitation easier and makes it easier for you to not tell the team what to do. I’ve talked with technical Agile Coaches that have a lot of trouble to have the team following their advice to do one engineer practice or another. It’s not that the team doesn’t respect them or their experience, it’s basically that people do what they’re told reluctantly. When the initiative comes from them, the commitment is much stronger.
- Pair with a technical coach if you can. Work together, do joint retrospectives, learn from them and if there’s a technical area you need to improve, ask for their coaching. If you have more coaches in your company, this is an ideal combination.
- Bring outsiders in for training, workshops, learning sessions and so on. If you want to push TDD forward, why not a two-days workshop on agile testing. If no budget for this, approach senior software developers in your city (your industry or any if not possible) and ask them to come speak to your team about the topic of your team’s interest. Join your local Agile community and get to know technical coaches, trainers, engineers that are willing to come talk to your team.
- Last but not least: have an excellent understanding of Agile values and principles, frameworks, and agile transformation. You should be the in-house expert in all matters Agile, be passionate about it and inspire your team at the same time. You know when this is the case when your team comes to you with questions about agile topics outside of their working domain.
In the end, being a great Agile Coach in tech is similar with being a superstar NBA player at around 5’10”. You can do it but you do have to work harder, learn more, and get out of your comfort zone to grow into the role. Just be so good, they can’t ignore you.
The devs had a recent conversation about how they want to work. Their choices were mostly between stable component teams and flexible feature teams.
What’s a stable component team?
A team organised per application, or platform, or whatever other component the team choses to structure around, is called a component team. We have an iOS team, a few web teams, a design team, and an Android team. These are component teams.
What is a feature team?
A feature team is team of experts that deliver features to the customers. The team is not focus on a certain feature, but they only deliver customer functionalities, across platforms or apps. It’s customer-centric and everyone in the team will work to deliver the feature, no matter their speciality, e.g. to deliver a feature you need a certain amount of web, mobile, design, architecture work; if the designers finished their tasks in day two, they need to find different ways to help the team deliver the feature, either doing front-end, or some back-end, etc. It promotes full-stack and continuous learning, thus a lot of times it’t very hard to engage the devs into organising themselves as a feature team.
What is a flexible feature team? (according to Ralph)
A team of experts that work on a feature, then disassembles itself and the team members create another team with other colleagues to work on a feature, and so on. Considering this definition, it’s not really a team, just groups of people working together to deliver a feature. As they form and disengage from feature to feature, they probably don’t have the required time to turn into a proper team.
The team decided to work as flexible feature team. As an Agile Coach, I consider this to raise a lot of issues (slowing down delivery, lack of focus on quality, lack of ownership for maintenance as the team dismantles after the feature is done, wasted time to form a team, create working rules, and gel together to deliver their best work and the list can continue).
But at the same time, I can’t protect the team from learning and failure. The experiment has started yesterday, I’ll be back with results.
My question is: flexible teams or feature teams? What do you prefer?
I’ve been hearing a lot of people talking about stages in teams development – forming, storming, norming and performing, so I jumped into figuring out (1) where this theory is coming from and (2) how valid it is today in connection to agile teams.
The originator of the theory is Bruce W. Tuckman, who wrote a study in 1965 – Developmental Sequence in Small Groups, Psychological Bulletin, Vol. 63, No. 6, p.384-399 (with follow-up articles and studies (2001: Developmental Sequence in Small Groups, Group Facilitation: A Research and Applications Journal, p. 66-80; 2010: Stages of Small-Group Development Revisited, Group Facilitation: A Research & Applications Journal, p. 43-48).
According to Tuckman, there are four (later on five) natural stages that a group has to go through to become a high-performing entity.
Let’s see what the stages are:
- orientation / testing / dependence: forming
- conflict: storming
- group cohesion: norming
- functional role-relatedness: performing
Tuckman suggests that more studies are needed, as the researcher bias is a factor that influences the final theory. But upon further revisions in 1977, re-published in 2001 and revisited in 2010, and the model proposed by him still stands. Further studies were done that reached the same conclusion.
Now, what are these stages about?
- Forming refers at testing and dependence: the group members will test to find out what behaviours are acceptable in the group, figure out existing norms and behaviour boundaries. In relation to the task, orientation refers to identifying its ground rules and discovering the type of information they need to complete the task, but also orienting towards the leader (trainer) to find out more about the task (dependency).
- Storming: the group members are hostile towards each other in order to express their individuality and resist group formation. Interaction is uneven and common infighting happens. At the same time, the members will react emotionally to the task and resist its demands, this representing the discrepancy between individual orientation and that of the task.
- Norming, development of group cohesion: group members accept the group and the individuality of fellow members, thus the group becomes an entity. The group establishes new common norms to ensure the group existence; new roles are also adopted. Harmony is of importance and conflicts related to tasks are avoided.
- Performing: the group becomes a problem-solving instrument, directing itself and its members as objects, since the subjective relationship between members has already been established. This is the stage of solutions emerging, and constructive attempts at successful task completion. Roles become flexible and functional, and group energy is channeled into the task.
- Adjourning: or termination; this stage was added later on by Tuckman (1977). This stage refers to the team breaking up after the task is completed and emotions that come with it, as this creates a minor crisis.
How is this useful and how does it relate to agile teams?
The core of agile working is a strong team, that gels well together and delivers their best work. The challenges come when you first build that team. Tuckman’s model helps you understand where your team is and adjust your coaching accordingly:
- make sure the team is communicating, learning about each other, bonding
- give the team as much information as needed to be able to achieve their objective
- develop trust
- help the team find its own structure
- make sure everyone is heard, not only the most vocal ones
- help the team build a common purpose
- manage conflicts
- facilitate open communication, transparency
- make sure everyone is involved in the discussions, not only the ones that speak louder
- build primary working rules or guidelines
- include all ideas and opinions
- continue helping the group finding their purpose
- help the group define their identity (team name, working agreements, values, etc.)
- facilitate decision-making through consensus and negotiation
- make sure everyone is heard, and discussions are open and inclusive
- (facilitate) build a commonly agreed process for the task they are doing
- build on the working agreements and obtain a consensus on them
- make sure feedback loops are in place (for internal and external stakeholders)
- the team is delivering their best work, they work collaboratively and care about each other
- make sure communication is open and inclusive
- help the team find solutions to problems
- remove impediments
- push for continuous improvement, looking for better ways to work
- celebrate successes and recognise teams and individuals
- manage emotions of a dismantled team
- help the team stay together as long as possible.
I arrived in the tech office at 12:30 – coming from our other office. There were a few colleagues having lunch and discussion how they’d like to work. One of my colleagues especially was really strong in his opinion. Let’s call him Ralph.
“I think working in flexible teams would make everyone happier. I personally have more to learn from working with different colleagues, on different products every sprint, in a different context.”, Ralph said.
“That sounds interesting. How would you exactly benefit from that?“, I happily jumped into the conversation (I wouldn’t be able to stop the coach in me help him figure out how his theory would work for him and colleagues).
“It would be great if features teams will always have different people. Let’s say we start working on a feature, we bring in UX, mobile, design, data, all the people we need and we stick together until we finish the feature. Then we switch to work on a different feature with different people, or some from the same teams. This way, learning is maximised by (1) working with and learning from different people, (2) working on different features that might involved different platforms and skills“, he continued.
“I understand this sounds great for your personal learning and growth. How about the customer?“, I asked.
“How about the customer? They get the feature done and tested as normally, so I don’t understand your question”, he answered quite confused.
“Well, as a new working team, how well will you work together with your new teammates? How is your domain knowledge on the new feature? Will everyone work in his expertise area every single feature – design will do design, mobile will do mobile, back-end only back-end and so on? Do you think your delivery speed and quality will increase from feature to feature or stay the same as now?“, I tried to point him in customer-centric thinking direction.
“I don’t think speed and quality will be affected. And yes, each teammate will work on their speciality. From my point of view this is the most fun and it would make me the happiest“, he answered, without really answering my question.
“Doing something fun is also important to me. If the work we do is fun, then we deliver better code and better products!“, jumped in another developer in the conversation.
“How about customer value? Having fun AND maximising the delivery of value to the customer would go hand in hand together in this context?“, I asked as there was absolutely no mentioning and consideration of the customer in the conversation.
The conversation continued without much addition to the above. The issue here is that the devs would come to propose a different way of working based mostly on what would benefit them personally and what would make work more fun. Which is something I always consider when it comes to teams formation: the devs should agree among each other to do the work that they are more passionate about, or brings them more learning.
AND deliver maximum value to the customer. This discussion should not happen outside of the context of the customer. If the need be, the team should be flexible enough to reorganise themselves to deliver fast and quality, regardless of personal interest and growth. Of course these situations should be balanced with their own growth but an agile team should focus first on how to grow as a team, rather on how to grow individually.