When my big team of almost 20 people split into two, I got to manage one of the newly formed smaller teams. It was a truly mixed bag of people – some were seasoned senior employees and knew each other very well, and about half of them were newcomers we had on-boarded in the past couple of months. There was even a girl relocating from Malaysia to Bulgaria, bringing in a whole different culture and perspective on things.
I’ve always believed in cognitive diversity is a major factor for a team’s successful growth and its resilience during hardships. I was quite happy with how my new team turned out – lots of different mental models, and ways of approaching challenges. But to really “jell” and bond my team, I needed a way to get everyone to get to know each other better, as friends, as opposed to just colleagues. I needed ways to foster emotional relationships and connections. Moreover, this new girl had no relatives or friends locally, and it was quite important to greet her with the warmest welcome possible and give her an “emotional kickstart” within our small community.
It was obvious that it’s the right moment to put Jurgen Appelo’s Personal Mind Maps practice to the test. So, I asked everyone to create a personal mind map that could be understood and presented by any other member of the team. I kept it lean and let everyone use their creativity – no hard rules on what exactly they should include. Everyone could create her or his mind map however they felt is most appropriate and most descriptive of their personalities. I sent some varied samples I had found online just to get everyone started. There was just a size limitation to fit within an A4 sheet of paper to keep things under control and not have someone eventually show up with a billboard.
Then I just had to wait. And I got myself working on my mind map during a weekend when I felt like drawing.
After a little while, I received all the maps. It took a few weeks but the waiting did pay off – each mind map was unique, funny, colorful, interesting, and carried a bit of the personality of its creator. Some didn’t even look like mind-maps – they were the works of truly creative artists. I couldn’t help but appreciate and marvel at how diverse and wonderful everyone is. I’m even smiling as I write this, so their maps were THAT cool.
*Keep in mind this happened way before Covid-19 was a thing. Still, I think it’s very doable in an online setting.
During our new girl’s first week we did a welcoming night out at a local restaurant. I decided to seize the opportunity because the setting would be as informal as possible. At a time when spirits were high, I took the maps out of my backpack. Then we went over them. Each was read by a different person from the team while others had to guess whose’s map was it. People marveled at others’ artistic talent, laughed at some funny bits, found coincidences, and asked additional questions.
What didn’t work that well was that the place was a bit noisy, so it was harder to hear from all ends of the table at times. Apart from that, the event went quite well and emotion and good feelings were in the air the entire time. So a more informal setting is worth it, just make sure it’s not too noisy.
Spreading the word
On the next day, with permission from team members, I took a photo of each mind map and shared it with other teams. Then, we had all the original maps put on a column in the office. It turned into a place where everyone can stop and take a look at our creations.
Our new girl was flattered by this welcome. We got to know her better, we gave her some clues she could use right away to start building her relationships. Us – “old dogs” also had learned some new things about each other that we didn’t even suspect before that session.
As of this moment, our newcomer integrated quite well and made valuable connections with everyone. But I’m sure that doing the personal mind-maps exercise had a positive impact on everyone involved.
I’ll be happy to learn about your experiments and experience with this and other Management 3.0 techniques. Please feel free to share!
A tale about how Traditional Project Management was Agile, before it was cool
Share with others
A most curious interview
Once, quite a while ago, I was referred by a dear friend of mine for an interview for a Scrum Master role in a renown company in Sofia. She warned me in advance, “Hey, Plamen, whatever you do, don’t say you’ve gotten the PMP certification. Better still, remove it from your resume…”. I was very confused – after all, PMP was the most recognized project management certification in the world, right? How would it do me any harm at an interview for a somewhat relevant position? My friend continued, “…they are all Scrum Masters, you know, and I’ve heard them mocking people who have the PMP certification all the time. Please, take my advice, don’t be too vocal about it and you’ll be alright! ”.
At that point, I must had already made my decision that I was probably not going to work for a company whose employees presumably cannot grasp the connection between project management and Scrum. But I decided to go and do the interview anyway – I was more interested than ever to see if these people are truly worth their salt.
A couple of days later I was welcomed in a pleasant minimalist meeting room, where, not one but four (a red flag, I know) Scrum Masters from the company already waited for me. After the usual smalltalk and introductions, they started with their first question: “Plamen, tell us about a recent achievement of yours. Something you’re proud of?”. It was written in the sky… I could not help it… “Certifying as a PMP”, I said clearly. Their faces changed, their eyes opened wide and we continued the interview in a different albeit still friendly tone – them asking their hardest questions, and me doing my best to give the best answers. And I did answer to each and every question confidently and in detail, with plenty of reference to my working experience at the time. Mind you, to this day I still believe this was my best interview performance ever.
Then, at the end, it was my turn to ask some questions. I asked some typical ones about issues that most Scrum implementations struggle to solve, due to lack of knowledge and experience, and I asked them to share their current approach. And, lo and behold, they were simply unable to answer. Awkward silence ensued more than once. I swear I could hear crickets at some point… They were pretty interested in the answers, though – I could see in their eyes that they knew the pain points first hand. The solutions they shared were rather naïve and flawed and they knew it – it was clear to me they were just kicking the can down the road.
A couple of minutes after I had left the building, I got a call from their HR. They offered me the job and asked me to get back and collect an offer letter right away!
I rejected politely and headed home.
The Relation between Scrum and Traditional Project Management
I firmly believe that all methodologies, no matter how agile they might be, raise against the same challenges. In the end, it is all about communication, about establishing some work rhythm, about managing expectations, ownership, visibility, commitments and getting things done. No matter which methodology you choose, you are going to run in these types of problems and you’ll need to find a solution that works for your organization. Traditional waterfall is not a panacea and neither is Agile. None of them solve bad culture.
Those who’ve studied traditional project management know that the PMBOK (Project Management Body of Knowledge) talks about techniques that are in fact, quite agile, way before agile was cool and popular. Some of the interesting techniques follow. See if you can guess their Scrum (since Scrum is the most popular Agile representative) counterparts:
Progressive Elaboration – “Progressive elaboration involves continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available. Progressive elaboration allows a project management team to define work and manage it to a greater level of detail as the project evolves.“ (from projectmanagement.com)
Iterations – these don’t need introduction. I’ll just leave them here.
Rolling Wave Planning – “Rolling Wave Planning is the process of project planning in waves as the project proceeds and later details become clearer. Work to be done in the near term is based on high level assumptions; also, high level milestones are set. As the project progresses, the risks, assumptions, and milestones originally identified become more defined and reliable.” (from projectmanagement.com)
The new edition of the PMBOK even dedicates a whole new chapter to Agile, but it was all in there for decades for those who read the thing carefully.
But finding “who did it first” is not the point, because as said earlier every methodology has to deal with the same issues. Getting deeper into risk management, stakeholder management, communication, planning, measuring can only benefit a Scrum Master who is serious about his or her job.
Traditional project management does offer a wealth of techniques and tools that could help and give a different perspective when things get real and you inevitably veer off the well-worn path of by-the-book Scrum. That being said, of course, one should still be careful to not turn into a directive and bureaucratic Scrum Master, which is a classic anti-pattern, but it was never exactly a good idea to become such a Project Manager either.
PMBOK tells about the Hybrid Approaches which combine techniques from different methodologies. Hybrid is what I’ve seen working best in most cases.
Imagine a couple of teams – one creating an API, and the other – the team of a customer, who in parallel, develop their business application that will heavily utilize this API. Both teams want to work with Scrum, but they’re over 20 people in total and when they try, everything becomes a mess. They cannot agree on sprint length, on rituals, on framework for scaling. Putting a traditional frame around the project makes everyone’s life easier. Procurement do their work and the project managers/scrum masters and their teams agree to milestones and overarching designs on both sides. Then everyone goes happily about their day, uses whatever methodology sails their boat and in the end they deliver the solution without stepping too much onto each-others’ shoes.
Now imagine a team that works with Scrum, but they want to organize and do a hackathon at some point. The hackathon becomes a mini-project that gets organized while the team continues to iterate. The mini-project has a mini-plan, an owner (who could be a team member), it’s own rhythm and reporting.
In my experience, it turns out that specialists always tend to meet in the middle – you either do waterfall on top, with iterations inside it during the execution, or you do Scrum and iterate, but then use techniques to improve ownership, planning and continuity between sprints for bigger initiatives and features.
This is why I believe the best Scrum Masters all have some project management background or at least good working knowledge of traditional project management.
So here is a heretic thought – Arguments between Agile and Traditional camps are just silly and they only show lack of understanding on both fronts. Project Management and Agile are the two sides of the same coin. They are not mutually exclusive – in fact, it’s quite the opposite – they often complement each other and they did for decades in well-managed projects. Getting to know both as a Scrum Master (or a Project Manager) is a very good idea… And no, Scrum is not dead, neither is any other approach of organizing software development work that delivers good results.
There are multiple anti-patterns in Scrum that revolve around roles, responsibilities and power distribution. In this post I discuss some common ones.
Share with others
Democracy and Scrum
Modern democratic countries have a common model that separates main powers. Political power is distributed into legislative, executive and juridical. This intentionally puts institutions in a configuration in which they control each other and have the chance (and obligation) to challenge each other. But at the same time, they need to be in synergy with each other in order to ensure success. The reason for this separation is clear – by definition “power corrupts”, so we should avoid letting too much of it concentrate in a single entity. On the other hand, unchecked power does tend to concentrate and aggregate, unless there are forces preventing it from doing so.
And even though democracy is far from perfect, leaving aside any political views and agenda, there are some good ideas about distribution of power within complex systems. We can borrow and use them in the smaller scale of our teams, which are also happen to be complex systems. Systems that work well all have mechanisms for self-control, feedback and power-balance at their core.
And indeed, believe it or not, a similar smart self-balancing mechanism is built-in into Scrum itself, but sadly, it is often overlooked in practice and even in literature. In the real world, this mechanism is often butchered to no end – key institutions are represented only formally. The result is power imbalance, which often leads to implicit conflicts of interest that can slowly but surely cause trouble and derail an otherwise perfectly capable and competent development teams.
Main Powers in Scrum
So which are the main institutions in a good implementation of Scrum and what are they mostly focused on? You have the following 4 key institutions with different interests, applying their own force on the system:
The Product Owner – an institution representing mainly the CLIENTS
The Scrum Master – an institution representing mainly the PROCESS
The Team Manager – an institution representing mainly the PEOPLE
The Team – the society – an entity that all aforementioned institutions are meant to serve. Representing the product and technology knowledge
The main point I want to make is that you need to have all these roles represented strongly and explicitly in a balanced model if you want it to be capable of self-balancing.
To illustrate the idea better, I like to draw these as forces pulling on a parachute I call the “Scrum Power Parachute”. This parachute will work as intended and open properly, only when all the forces that are pulling in different directions, are also relatively equal in strength and act together. Having forces that pull too strongly will rip the parachute apart, and having them pull weakly or in unbalanced way, will result in the parachute not opening at all.
So, these institutions, all pull the system in the direction that they represent. In a normal environment you will have these institutions in a constant love-hate relationship, that would result in proper balance – people that are happy, clients that are happy, and a well implemented process that works alright for all actors involved. Each of these institutions will need to compromise here and there and that is OK – this is exactly the way the complex system is supposed to work.
All that being said, these institutions do have the same ultimate goal (a democratic society has common goals, too). They all want to deliver results and do so in an efficient manner that makes everyone happy. So it’s natural that roles of different actors within these systems would overlap here and there. After all, everyone benefits from working with happy employees, happy customers and good processes. So it’s common for actors to support each other in these common goals, even though they might not be the ultimate decision makers or responsible parties for the particular goal.
Common power distribution anti-patterns
Anti pattern 1: Wearing multiple hats at once
In practice, you’ll sometimes see the same person executing two or even all of these roles. I’ve seen implementations in which even a person from the team itself is executing the Scrum Master role in a “by-the-way” manner. There are even some extreme cases where one person represents Product Owner, Scrum Master and is an active hands-on team member. While this might work in very simple scenarios and products in a very initial stage, such an approach is unsustainable in the long term and would cause all kind of unpredictable imbalances.
I’m not arguing that there is no possible way for a single person to perform well in all these roles at the same time. However, I believe this is extremely hard to pull off and requires quite a bit of experience and thought. Executing multiple roles and doing it well, means you understand in depth all nuances of these roles. I, myself, have been in this situation for a while, and let me tell you that I thought this was the closest thing to schizophrenia that I’ve ever experienced. The amount of context switching was enormous and I felt like the main character in “The strange case of Dr. Jekyll and Mr. Hyde” novel, even though I believed I knew what I had to do rather well.
There is another aspect to all this. In a more corporate environment that does regular, formal performance reviews, wearing multiple hats means you will need to have a very balanced set of yearly goals in place. These goals, must represent all the roles you execute and therefore they must complement and also contradict each other in some very sophisticated, yet clear ways. Otherwise, you’ll have to compromise between them in favor of the one with the highest priority and importance.
Here is what I mean. Take, for example the typical anti-pattern: the Team Lead who is also a Scrum Master and a Senior Developer all at the same time. As a lead, this person will probably have a goal of low employee turnover, and a goal of high employee engagement and perceived happiness. When confronted with a choice between facilitating a proper ritual on one side and doing what people want on the other (they might even want to stop doing planning altogether, because it takes time and is “boring”), a person with these goals, would rather opt for the popular decision of abolishing planning, just because it’s in sync with or his or her goals and incentives. After all, satisfied employees will bring you higher engagement score, and a bad process doesn’t directly harm these goals.
Building up on this example, imagine the person is in a senior developer role as well, and is running “a bit behind schedule” on a story to close a sprint. Of course, they will be more likely to cancel the retrospective for the team in favor of being able to work a couple of hours more. And I hope by now, everyone sees how this spells trouble.
These examples picture how unbalanced goals may cause quite a bit of problems when a person is put into a position to execute multiple roles. And now ask yourself: how many people in this situation do receive well thought out goals that really address the above concerns?
Anti Pattern 2: Overruling someone else’s decisions
Sometimes team members will take a prioritization decision by themselves, or they will simply ask the Team Manager or the Scrum Master to reprioritize things. This might mean that the product owner is not well-recognized and this can lead to problems. To prevent such occurrences in the future, they must be resolved on the spot by redirecting the person to the decision-making party, no matter how obvious the resolution might seem. This builds the habit of always making sure the order is followed.
Everyone involved should know what all the roles represent and what are the areas in which they are the ultimate decision makers. For example – the Scrum Master would make the final call on everything regarding rituals and the process, while the Product Owner will be the person to ultimately decide if something has high priority or not. These institutions can still influence each other, the team might also influence them, but no one is allowed to overrule the decisions in someone else’s domain.
So, be on the lookout about who makes the final call and address inconsistencies right away! Educate team members on who owns what. Resist the temptation of making someone else’s decisions when they are not in the room. It does take time for people to get used to some things. For example, that every question regarding priority needs to go through the Product Owner. But the effort is worth it eventually. I promise.
Anti pattern 3: Extreme bias toward one institution
Does your implementation have extreme bias towards client satisfaction while paying the cost with low employee engagement and happiness? Or are you’re in the opposite end of the spectre – trying to make your Scrum process perfect and people happy, but often failing to meet clients expectations?
If you are in these or in another similar case, you most probably have problems with power distribution. This might be due to some of the power representatives being too aggressive, too mellow, overly assertive or just inexperienced. You might also have problems with how goals for these roles are being set. Sooner or later you’ll need to address the causes if you want your Scrum process to balance itself out as intended.
Thanks for reading this article! I hope you found it thought-provoking and I’ll be happy if you share your thoughts and experiences.
If you are not familiar with LeSS, you may have hard time reading on. If that’s the case, I’d suggest checking out the website first or watching a couple of videos about how LeSS works.
More than couple of years ago, we had to split a big Scrum team of 18 people into two smaller teams. We had been growing rapidly and the team had become far too big to be effective by any Scrum standards. After all, Scrum recommends 5+/-2 people per team to keep things smooth and efficient.
We didn’t want to create some artificial division line between the newly formed teams, based on product specialization or function for a number of reasons – flexibility, knowledge retention and redundancy to name a few. Eventually, we set out to look for ways to scale our Scrum implementation in a way that was going to keep team competencies balanced.
We did some research on the most popular frameworks – LeSS and SAFe. Based on it, we promptly decided to go for LeSS because it seemed like a very straightforward and minimalist framework. It fit our idea of splitting the team without forcing specialization, and it wasn’t going to change too much of what we were already doing at the time. After all, we did not want to introduce “more“ process, and we were looking for something leaner.
We’ve been using LeSS successfully for a couple of years now and in this post I’ll be sharing some lessons learned and some challenges we faced. As with any methodology or framework, complexity still hides in the need for coordination, communication and ownership. Here are some thoughts of what worked and what did not, based on my experience.
Lesson 1: Backlog Refinement (Grooming) meetings will get messy
Grooming is by far the hardest ritual to pull off properly in any Scrum implementation because it requires good facilitation and an experienced team. But sometimes, when you have close to twenty people in a room trying to estimate a complex story, things are bound to become counterproductive. You need to establish a common understanding and let newer team members get used to estimation before introducing rotation, as LeSS suggests. Unfortunately, there is no easy way around this – it just takes time and effort.
Here is what could be done:
By all means do not rush into introducing rotation – people need time to get used to grooming and you cannot do much to shorten it. It is the price you pay to grow.
When eventually you start rotation, make sure you have representatives from both teams, from all key functions and if possible- seniorities. Reducing the meeting to 7-8 people would make it work just fine.
Preparing in advance is key. Ask the Product Owner to share stories to groom a couple of days in advance, so everyone can spend some time to prepare and understand all the stories. This also prevents rejection of badly-written stories at the meeting, which you want to avoid anyway, because it’s often preceded by a lengthy and painful discussion.
Introducing a separate regular pre-grooming session for collaboration between top seniors and PO gives venue for discussing strategic ideas and brainstorming. It also helps keep the grooming session focused mostly on stories and their scoring.
Strong facilitation is even more important with LeSS. Make sure you have someone experienced to keep the meeting on track, at least initially while you still have everybody-and-their-uncle in the room.
Lesson 2: Planning in two stages has some side-effects
Planning with LeSS is actually more complex as it’s carried out in two sequential sessions. One general, for both teams, and then separate ones for each team.
Every once in a while, an item that got optimistically picked in the first planning session, might not fit during the second (team-specific) planning session. This is mainly because in the second part of the planning team has more time to analyze in detail and decompose the story into tasks. When this happens, the item would pop-out of the sprint backlog of the team in question and this might become a bad surprise for the Product Owner unless communicated well.
Here is what can be done:
Thoughtful preparation for planning always pays off and the team must make sure they know in advance their recent velocity, capacity, any leftovers and dependencies. Having some stories in your mind to pick prior to the planning session helps avoid the issue.
The Product Owner must be aware that stories might sometimes pop-out in the second planning when examined in detail and decomposed into tasks. Setting clear priorities for the team will make sure they will leave the right story out if this occurs. Final commitment for the sprint must be done after the team-specific planning sessions to make sure everything fits.
Lesson 3: You will still need some time and effort dedicated to synchronization and communication between teams
To compensate for lost communication bandwidth when you separate teams, you can introduce some additional meetings:
Overall Retrospective – these are actually recommended in LeSS and you should make sure you don’t skip them after the Team Retrospective. They might feel redundant at first, but they make great venue for teams to address interesting accomplishments and common challenges, or just recap on how their common goals and roadmaps turn out.
Regular discussions between Scrum Masters, Team Managers, Product Owners. These short meetings help capture, discuss and handle issues on a higher level for both teams. Team retrospectives and the overall retrospective often generate some items for discussion on this level.
Form Communities of Practice (CoPs) – this is another Management 3.0 practice that I highly recommend implementing, especially when scaling Scrum. Communities of Practice cut across projects, teams and initiatives and give the opportunity for practitioners to synchronize, share their knowledge and challenges and develop their expertise further. In our case we’ve been doing regular QA and Dev syncs to keep the respective sub-communities in sync. This resulted in many complex challenges resolved within each domain and has been helping us immensely in reaching our team goals. People committees and social committees are also CoPs worth considering, especially if you want to emphasize on a culture of self-organization and freedom.
Lesson 4: Executing bigger initiatives that span both teams at the same time is still tricky
LeSS does not recommend introducing coordinators for initiatives, but nevertheless in my experience this works when done in moderation. It helps with complex features and ongoing initiatives that span multiple sprints and even quarters.
Here is what can be done:
Assign a reporting person (owner) to emphasise on authority and responsibility to report, drive and deliver on a particular major initiative. This makes sure the initiative doesn’t die off and has someone pushing it forward.
Form “virtual” teams committed to specific initiatives. They have their own communication, pace and rhythm, which is separate from the ongoing LeSS cycle, but they still take part in all LeSS rituals.
I know that in a way all of the above might sound like imposing some Waterfall on top of Agile. Even so, you still need to find a way to ensure continuity between sprints and keep the big picture in mind for bigger initiatives. This, of course, could ideally be done by the Product Owner, but if you want to create autonomous teams (and who doesn’t?) it is alright to delegate some of it to team members. Apart from that, using some techniques from traditional project management might often prove beneficial.
I’d say that LeSS proved to be a success for us as we got a bare-essentials process that allows us to deliver at twice the capacity. We did manage to scale up, and we are still Agile. Our teams can swarm up on a bigger story or even a feature if needed, which provides a great deal of flexibility.
LeSS also helped us maintain proper knowledge distribution between team members. Developer and QA sub-communities exchange knowledge and good ideas naturally flow between teams. Last, but not least, LeSS enabled us to have a common idea about what a Story Point is, which in turn makes our Product Owner’s life much easier, because he can work with a common measure of scope, size and complexity.
I hope you found this useful and I’ll be happy to know about your experiences when scaling Scrum with LeSS and other frameworks.
Sometimes, in the lifecycle of a software product, comes a time when it needs to be transferred to a new team within the company. Reasons vary. Most often they have some financial nuance on the surface, but their nature is always strategic. No matter the reason, these transfers often mean moving the product through whole continents, time zones, offices, cultures and processes.
Being a hands-on participant in multiple software product transfers to date, I’ve seen approaches and ideas that worked great and of course, some that failed. I had the chance to learn by observing the art of pulling off successful product transfers in completely different settings – of legacy products, of newer products, of products we got from teams that ceased to exist, and also from teams that continued within the company long after the product transfer had ended.
Working at a dynamically growing business in Bulgaria, I have mostly seen how this works from the position of the receiving entity. That being said, a transfer is always a joint venture and I believe sharing my thoughts could help you, even if you’re on the other side of the project.
Now, as a last quick disclaimer before I start… Managing a software product transfer is classic change management project, so all change and project management techniques still apply, but there are some specifics and tips that you’ll be better-off considering in advance, than learning about them the hard way (as I did on numerous occasions in the past). So, things like having a plan, tracking and reporting on it, managing risks, stakeholders and commitments, etc. go without saying and intentionally won’t be a part of this checklist. Keep in mind, that it still does not cover all the peculiarities you will need consider at 100%, so please, use it just as an additional sanity check of your existing plan so you can improve your chances of success.
So, let’s get down to business! What worked for me so far? This is my product transfer checklist:
Understand the product state and its future vision
Product maturity and its current state in the product lifecycle are important things to note in the very beginning. Is this a product that is developing rapidly or is it in maintenance mode? Does it have room to grow or is it the current Cash-cow of the company? Is innovation and growth expected, or the goal is to transfer and just reach business-as-usual state? The answers to all these questions will affect your hiring decisions, who you decide to put on the team and the project, and how you package and sell the idea to the team – the people who will ultimately be responsible to care for it and develop it.
Do not forget to also discuss the product with the current product owner or manager. See what their vision for the future is and act accordingly.
Do some due diligence
Assessing the current state of the product is crucial for the success of the initiative, so if possible, be sure to settle at least one, (preferably) very senior person in the existing team for a while, so they can see things first-hand and give you a good view of what you’re all getting into.
Ask your “spies” to focus on understanding the business domain pain points, the state of the code base and coverage of testing, the automation and the toolset that are currently in use. Transferring a product is a serious endeavor, so it is not a good idea to only rely on rumors and papers. If sending over a person is not viable, try gaining access to current documentation and code in advance and start exploring locally.
Secure crucial resources and clarify constraints advance
After an assessment is done, it’s important that you make sure you have all resources you’ll need are available. See what the structure and headcount of the former team were, see what their budgets amounted to. Compare these to the budget you have and your projected labor (this one is probably going to be about 80%-90% of the overall cost), IT, office, training and travel costs. See if it all looks realistic. Make sure you go over all other constraints and expectations in the very beginning – what is the deadline of the project, what are the main goals and milestones? Put all these into your plan.
Another point that’s important is that you must find the available office space to accommodate the new team and you need to order the hardware and software they will use early enough.
To be on the safe side, it is a good idea to develop a contingency plan and try to secure additional budget to cater for risks that are very hard to control. For example, you might need to get expensive contractors on board for a while, due to stagnation on the market and inability to recruit just the right talent soon enough. This plan will give you options in case something goes really wrong.
See what functions you get to own
Owning all of the supporting functions in addition to development – like administration, delivery or customer support, brings benefits in terms of simplified communication and better synchronization between functions.
That being said, it also comes with a much greater deal of responsibility and might put you in a position to own something you do not have the expertise to deal with. So, stop and consider carefully what exactly you’re going to own.
See if key roles are local and/or available
See if roles are well positioned and thought-out and would not put you in a position of difficult and cumbersome communication across timezones. Understand if the Product Owner, the Scrum Master and Line Manager are going to be local and try to secure this as it is going to make life so much easier for everyone.
If any of this is not viable, at least make sure all key people are easy enough to reach and are reasonably available when the team needs their help or input.
Partner with HR
If you’re going to be transferring a product, it’s highly likely that you’ll need to recruit a bunch of new people. This cannot happen overnight and Talent Acquisition is your most important partner in creating a market forecast and supporting your efforts for recruitment. You must discuss your plan with them and also consider alternatives like getting some contractors on board for a while if things are not looking pretty.
Remember that labor market is cyclical, and there are many socio-economic events that affect it. You cannot hope to know what’s around the corner at all times. No one understands market conditions better than TA specialists, so go and leverage their precious knowledge.
Rely on existing talent
Letting everyone from the former team leave, often proves to be an overlooked ticking bomb. See if you can arrange key people from the former team to stay with the company. It will be best, if you can engage them with your new team, but if this is not possible, hopefully there will be an alternative position that can still keep them around. It could be a new product, a more interesting role or something else, but it is crucial that you have someone to rely on, while the new team is picking up speed but is not yet fully productive and aware of all the details. Such key people can prove invaluable when new members of the team need some advice and, even more so, in the event a critical system failure happens. Make sure you have at least a part of their time officially dedicated to the team until they are ready to own the product by themselves.
Another thing that worked for me has been bringing trusted people I’ve already worked with on the team. It is often better to move someone from your existing seniors to help building the new team. This provides an opportunity for the seniors to build new knowledge and leadership skills and is often appreciated on their end. On the other hand, it will enable cross-pollination. Processes and culture will grow from within the team, because you already have someone who knows how it all works and can be on the lookout for any deviations.
Simplify the transfer by ensuring the product is in a fit state and is well-documented
Ask the former team to not leave anything hanging out the trunk at the last minute. Make sure there is enough and well-updated documentation. See if enough tests are in place for the team to use as a safety net – these are going to keep your back time and time again. See if any simplifications of environment and deployment processes can be done and also see if all environments are well-documented.
Help your team know their progress and give them a sense of accomplishment
It is a good idea to have a tailored schedule available for all knowledge transfer events and milestones. Thus, your team will know what’s next and they may ask for more things to be added to the plan, some topics to be extended or removed.
Knowledge transfer sessions are best to be recorded on video as most people won’t pick all the details on the spot. I’ve seen team members resort to available recordings from time to time. Remember that you cannot hire all members of the team at once, so these recordings also make for great entry-level trainings when you onboard new people.
You can help the team immensely if you do a stakeholder identification exercise together. This will help them understand their role and they will be much better prepared to work with all the stakeholders involved and manage their expectations.
Last, but not least – create a Team Competency Matrix that lists all key knowledge areas to be covered (might be product components, technologies or software tools). This has proven to be an invaluable tool and it is also a variation of the Management 3.0 practice.
Here’s how it works: first, ask the former team to assess their level of knowledge on a scale together. For example, 0 being novice, 5 being subject matter expert, or use the scale that Management 3.0 proposes. Thus you will know what is possible to achieve and you can establish a sane goal to aim for and compare to.
Then, regularly update the matrix for the members of the new team and ask them to set competency goals for the next period each time. In our case, we’ve been doing this monthly, and we often continued well after the end of the knowledge transfer because we’ve been finding it so useful.
The Team Competency Matrix will:
Keep people on track to understand and learn about all aspects of the product in a methodical manner ;
Demonstrate individual knowledge gaps, so the every team member can address them to balance their competencies;
Show the team their overall knowledge distribution, so they know where major risks lie and what to put more focus on next;
Create an environment of constructive competition that pushes everyone forward;
Give the team sense of accomplishment and progress, which will help keep their spirit high. This is especially important at the beginning, when there are often no other significant and tangible results.
This turned out lengthier than I anticipated and I’m still sure that I haven’t covered everything.
A software product transfer is a wild journey and you’ll probably stumble upon different challenges each time.
You’ll need to walk the walk yourselves, but I’ll be very happy to know I’ve helped at least some of you by sharing these practices and ideas.
Feel free to leave a comment and share your experiences in the field which shows up when you view a single article!
You may subscribe to the RSS feed, and you can also leave your email address, so I can keep you posted (occasionally and responsibly) with more interesting content and news.
I know this is not the standard way of starting a book reading list, but bear with me. I promise it is worth it!
The first book, I’m going to present is called “Leading” and despite the looks of the cover, it is not the typical autobiography. In fact, it’s not an autobiography at all. It’s a very witty, nice and light read and it contains a ton of anecdotes and techniques drawn from experience.
One of the greatest team managers of all time, Sir Alex Ferguson, shares his ideas of what makes great teams great and what it takes to be a leader. The book is edited by a business person (Michael Moritz) and he skilfully draws the parallels between the great game and the business world today. You don’t need any deep knowledge of football, though you may find more moments in the book amusing and interesting if you have an idea of who Manchester United famous stars were.
And before you decide against reading this book, because it’s some “football nonsense”, just think about the similarities between famous football players and fellows in your own software team. They are all well-paid, they want freedom to express and prove themselves on the pitch, they bear a huge amount of responsibility about the outcome and the end result and sometimes they need to endure some huge amounts of pressure. They have their ups and downs, they achieve success and then they mess up and vice-versa, and you, as their manager, are there to help them and make sure they do their best.
Now, think about your role as a team manager. Building the authority, coaching and developing the team to show their best on the pitch. Then, on the big game day, letting go and carefully observing the game from the sidelines, thinking of ways to optimize interactions, develop skills further and regroup to achieve a common GOAL!
To avoid spoilers, I’d only say that this book is a great experience and there’s a lot to gain from reading it.