In every organization where I have coached several teams for periods of six months or more, I have found a few teams which stand out. It could be due to a dynamic Scrum Master or a sensible and knowledgeable Product Owner or a few motivated smart team members. These are the teams which keep approaching me pro-actively almost every sprint for something or the other even after the completion of my coaching for them. I have always enjoyed spending time with such teams as it has huge learning for me as well. It has given me excellent opportunities to improve my own knowledge and understanding of Agile and as a result, improved my ability to assist other teams.
I have experimented several aspects with such teams and believe me, often, ideas have come from teams themselves.I just become the enabler to implement the ideas. I would like to discuss a few of such experiences here. I would like to warn though that you would have definitely known this before! But then Scrum is itself common sense and everyone knows that teams should have a commitment, they should collaborate and so on. Still, when it comes to implementation we almost always face challenges, is it not? So, please do go through the blog and express your comments, suggestions etc.
I would like to address three practices which I have tried among many and found teams loving them over a period of time. I have seen visible benefits from these practices and hence thought of sharing them on this blog.
Part-time pair-programming
Pair programming is normally a practice where two persons in a team pair up for the entire Sprint. They sign up for same stories and work together on a single desktop and so on. But then that is not something very common in Scrum teams. But it has tremendous advantages. Since pair programming as such was difficult to implement, I introduced part-pair programming. What I mean by this is that two persons in a team pair up for some time in a day, say one hour or two hours. This happens for several persons in the team over the sprint. It is also good to make it a habit to pair up with a different member for a half hour or one hour every day in a sprint. This I have seen gives a great opportunity for team members to know each other and the way different people work in a team and also to learn new things from each other. I have found this practice very useful to improve collaboration in teams.
Team members picking work from areas other than their speciality
This is another useful practice where team members consciously pick some stories from areas other than their speciality. This takes time and is a slow process but after a while helps a lot in several areas. Initially, team members may sign up for such stories along with others but after a while, they will be able to contribute in many areas. A big advantage of this practice is that over time, knowledge of work being done by the team is distributed across several members and there would be fewer specialists over a period of time. One direct benefit of this practice is in estimation where many team members can confidently participate. A developer would have done testing or design or some database work or UI and so on and would have a fair amount of knowledge in many areas apart from a specialised area.
Knowledge Transfer sessions
The practice above would naturally lead to the need for knowledge transfer (KT) across team members. It would be much better if KT sessions happen regularly and more members of a team are aware of aspects which they may not be directly working on. But starting KT sessions needs a reason and the practice above of signing up for work in other areas would be the trigger for this practice. KT sessions could be in any area too and give a great opportunity for team members to improve their presentation skills, the capability to prepare and present content in specific areas, increase their knowledge in areas they are interested and also research and analysis skills. This is an excellent way to collaborate as well. I have found teams starting this practice and then making it a part of every sprint and giving opportunity to all team members.
There are many more such practices for improving Agility of teams in the broad sense and I have shared a few here and would like to hear from you about your experiences in this area.
