There you have it, your new shiny team. You have done everything by the book, all the agile events are happening regularly, everyone is getting used to each other. In your development team you have your testing experts, your database guru, your coding magicians, your continuous integration and deployment pipeline plumber. All is in place.
Then one day you have to stop all the work on the database, because the expert is taking a vacation. Two days later your testers go for a seminar. And all of sudden, the magic of the coders is not working any more. The database is not working, no one knows how to write tests or even to start them. Everyone is doing their best, but it is not enough. What to do now?
Not much can be done, when this is already happening. You can either try to hide it from the product owner, which is a very bad idea, or be honest with him, and try to patch your losses by borrowing someone from another team. But even that will be more a cosmetic attempt with little or no positive effect. It will probably backfire.
Could you have prepared? After all, you hired the best people on their respective field, you have done everything right, right? For some roles you even doubled up the people, for the case someone gets sick or takes a vacation. Is there anything else?
You’ve probably heard, that in an agile team, everyone should be able to do everything. But if someone can do everything, he can’t do nothing right, since he is not an expert in one specific field. So the common knowledge at least.
Welcome to the age of multiple areas expertise. This means your ideal team member is a so called T expert. He covers one or two ares really deep, and in other areas they are good enough to manage by themselves.
But where to find these new age experts? It is difficult enough to find good people for one area.
The answer is, that you don’t find them. You grow them!
You already have all the expertise you need in one place. All that has to be done is the distribution. And here are some suggestions how you can use each expert to teach the other one or the whole group.
Pair Programming Let the people pair up, when they take up a task. Pair up a tester and a coder. Let the tester learn coding step by step and let the coder train challenging the implementation. When you suggest this, everyone will tell you, that this will slow you down. People are used to the thinking, that nine women can bare a child in one month. So if you put two team members on one task, the number of tasks in the sprint will be cut in half.
Well, not exactly. See, what you would be doing is separate session, like coding and testing, is being done in one session. It will probably take longer than just coding it, but much less than coding and testing and fixing and testing it again. The probability that you will get things done in one run is much higher.
At the end of the day you got faster, and your team is getting more coders and testers every day. But don’t stop there. Pair up people on any task. Let them learn about databases, pipelines and architecture from each other.
Group Programming Sometimes team members have very different ideas of how certain code should look like. To speed up the development of team wide programming style, group programming sessions can be established. Especially at the very beginning putting the whole team in one room in front of one big screen can speed things up. Just give it a try and see what happens. The smaller the team, the better it works. Let the team work out the details and when they feel confident enough to break into smaller groups.
Reviews You are probably already familiar with the branching and merging concepts. The reviews I am talking about, are the ones in this context. Every time you merge your code from the feature branches, let someone review the developed code. Someone who didn’t work on the task at all.
At the beginning you can have your senior developers review the finished work. Take care, that the feedback given is constructive. As soon as possible provide the possibility for the senior experts’ work to be reviewed too. This will prevent the creation of hierarchies in the team, and at the same time allow people to learn by just reading the code. And even the most senior developer has a lot to learn from his teammates.
Don’t make any exceptions to the review rule. Try to prevent, people pairing up and reviewing each others code exclusively. This will prevent any feelings of exclusivity and will keep the team balanced and intact.
Architecture and Design Planning When planning a sprint try to establish a two phase planning. The first part of the planning should be conducted with the product owner. In the second part, the team should take their time to dive into the details of the architecture, technical solution, and implementation strategy.
Usually there is no specific task for developing a technical design, let alone for architecture. If this second part of the planning is omitted, you will end up with a big ball of mud, ridden by technical debts. When this second phase is promoted, the whole team will be able to pursue the same design goal, without anyone having to check, if they are sticking to it. They will be checking themselves, since they have a clear picture of what has to be done.
In this planning the techniques of strategic software development can be shared among the team members and completely new approaches can be born. Don’t let anyone full you, that agile teams don’t design and don’t need architecture.
One-on-one Feedback Talks This is something you will not want to do at the very beginning. Let the people build up their trust first by by using pair programming, by celebrating their successes, by practicing constructive criticism in the retrospectives.
If you are the scrum master, you can start this up by requesting the team members to give you feedback and suggestions how you can improve your work and relationships within the team. Listen carefully to what they have to say. And be sure to act upon it. If they ask for your feedback be sure to be as objective and clear as possible. Always reiterate, that even if you are trying your best, you are still inevitably being subjective.
Once this is established, encourage other team member to gather feedback for themselves, and if any way possible, from everyone in the team. This will make sure that the social competence of the team will dramatically increase. Blind spots can be discovered and personal development of each team member helped forward.
Refinements There is probably nothing you don’t know about refinements. As a product owner you sit down with you team, you go over the user stories, explain them and after everyone understood everything, you are good to go.
Unless you want to use this chance to inspire your team, to explain them the overall goal, show them the big picture, how the product is a part of a company’s strategy and what exactly you want to achieve.
If you use this chance to transport your vision the team will follow you. Since you are surrounded by talented people, they will have suggestions for improvement. Make sure to encourage this kind of feedback, since it will improve your product and implementing own ideas makes the team enables the team to identify with the product.
For the developers this is the unique chance to learn how the business is functioning, what matters when it comes to the marketing, sales and strategy, how products are developed. This is not something you would usually learn on a computer science class. Who knows, maybe one of these refinements will give birth to another successful startup.
Communities of practice This is where you leave the realm of your own team and make a step towards spreading the knowledge between different groups. If you want to know more about the community of practice, the wikipedia page is a good place to start.
Important thing is to make the attendance count. Share your solutions and approaches. And don’t have the whole team attending, but just one or two members who can transport the subject of matter to the wider audience. And let them gather ideas for problems you still didn’t encounter or you did, but your solution doesn’t make you that happy.
Communities of practice can create very valuable pattern and overall solutions and deliver templates for the overall architecture.
These are some of the ideas how to spread and create knowledge while using agile methodology. Scrum and many other approaches don’t have these as a part of their framework. Which doesn’t mean, that they are not needed. On the other hand, even if you are not officially in an agile environment you can use some of the measurements to improve your team. Please try them out. But never enforce them. Your team will return it to you many times. And in the end you will be the one to learn from them.