Virtual Teams, do they perform? Or….

With the advent of Covid-19, most teams in practically every industry have been hard-hit with uncertainty on how to sustain performance and ensure they remain actively engaged to the goals. Stakeholder satisfaction has gone south for most of these teams and it is increasingly becoming frustrating for leadership to regain their glorious past of co-located teams. Talking to one of my friends who is a project manager, he told me “I have simply lost it. Nothing is working anymore, and our backlog looks like a jungle.” This is not unique for only this team but is something that most teams are continuously experiencing. It is even worse for teams that previously were struggling to function when they were co-located and have now been thrown in unfamiliar territory. Within the last two years, my experience with other teams has shown that there is a myriad of challenges but there are some which are common, despite the industry the team is working in. I will highlight 3 of these issues and then in my next series, I will address my supposed approach to handling them.

Lack of unified goals

It used to be easy to define a goal around which a team could rally their focus while working on a set of issues. In Scrum, this has always been the norm before any set of issues are chosen by the team. The product owner defines the goal and a whole list of prioritized issues from which the team chooses, based on their understanding of these issues and their velocity. Arguably, most teams did not find this to be an issue and it is quite impressive that Agile defined this approach so well, addressing the traditional centralized authority. However, while working remotely, it is increasingly becoming difficult to have an understandable unified goal which teams can use to deliver the next increment. This is not because they don’t communicate, but it is because the level of team engagement has been severly compromised, that most people find it frustrating to remain actively motivated. I have seen fluffy sprint goals such as “Solving issues from Revision 3.2.4“. The problems with such goals are that they create dependencies and do not really motivate the team. Some of the goals are defined based on a single stakeholder feedback, which in actual sense creates imbalance in stakeholder satisfaction. By using feedback from a single stakeholder, the whole team gets blinded to the needs of the whole stakeholder fraternity across the spectrum. There is a genuine need that goals aren’t individual-centered, if the whole team is to gravitate their efforts around them to achieve satisfaction equilibrium.

Lack of Support from Top Management

Teams working without the support of the top management are prone to experience instability and disruptions within their iterations. This is commonly in the form of in-coming work from customers and colleagues, urgent hotfixes, or even changes of the team’s plan by the management. Such teams suffer from being unable to execute their work within locked timeframes that allow them to deliver an incremental release of the product. When management is not in tandem with the activities of the team, do not participate in reviews nor are they aware of the current status, then the two units drift apart. It is common to see efficient agile teams being managed by leaders with old-mentality of project management. This causes rifts in achieving any meaningful progress, mostly because the team feels that they are not respected by the management and their efforts are not appreciated. The bigger and “ugly” caveat is that the team finds it difficult to tie their activities to the goals and objectives defined by the management. On the lower side, it leads to a frustrated team at a crossroads on achieving their sprint goals and satisfying the demands of the management. On the upper side, it leads to an organization that cannot adapt appropriately to changes, failing in achieving to align the teams’ activities to the strategic goals and non-achievement of BRM.

Sect-like/Religious practice of Agile

While agile is flexible and can be customized to different industries, it is not uncommon to see teams embracing agile and following it rigidly. Often, when top management advocates for teams to embrace agile, there is a poor change management process to help the team transit to the new way of working. If the team does not understand why they should use agile, or the activities and ceremonies of agile are followed in a sect-like manner without any understanding, it is doomed to fail. Team members sooner or later feel the pressure to deliver incremental value during each sprint. It feels like being put on a pedestal without having any room to gasp for air. Working virtually, compounds the problem because the team members lack face to face interaction (one of the 12 agile principles). Additionally, it introduces long waiting times that delay the workflows. Teams should be allowed to embrace agile and suit it to achieve their objectives. Sure, this does not mean compromising on the activities or goals of the team, but by remembering the 4 values of agile, it is believable that agile can be embraced even by the faint-hearted. The beauty of agile is seeing the incremental value the team produces at regular intervals. Combined with the transparency of the team’s progress, it enables the team to be reflective and adaptive, ultimately becoming even more productive. The team should be able to see the outcome of their activities and relate to the goal they are achieving, and whether it is delivering value or not.

Disaster Management. How prepared is your organization?

This week brought forth a popular yet less revered subject to the limelight. Disaster management or crisis management is one of the things that most leaders know that they ought to have drills on, but is seldom taken with the seriousness it deserves. I find this to be true, whether in small, medium or large organizations. In the software world, disasters have led to multi-national companies being dragged to endless court battles, often loosing their reputation and invites competition to hawk-eyed competitors. This is not only true for blue-chip companies, but also for small start-ups that often ignore the need to be reflective and adaptive. Take the case of Barrings Bank, London, which faced one of the greatest banking disasters, when one of their employees brought it to it’s knees. Nick Leeson, a rookie who quickly escalated the career ladder in the banking sector, transacted on the Singapore International Monetary Exchange (SIME) for close to a year, unnoticed. While it may be termed as a poor oversight on the business operations of the bank, it also leads to different thinking on how many disasters can be avoided, if the leadership is proactive and there is a clear definition of responsibilities.

Back to what happened this week, our IT team lost the storage server that controls the VM’s, the domain controller, and a host of other critical servers. Initially, it was underestimated to be a minor problem that could, as usual, be resolved by restarting the storage or some other server in the server room and bingo!!! No, it was not the case in this situation. The situation quickly escalated to a series of “Yeah, we are almost back to business…” to “No, this is not true, it is not happening…” to “How come we did not see this…” and in between, there were accusations and counter-accusations. This did not help the situation either, as the environment soon became too toxic, and meanwhile, there were frustrated employees and customers who could not get their concerns addressed. The whole situation was even made worse by the fact that there was no proper communication on the whole situation and no one took charge of the chaos to restore normalcy. After realizing the magnitude of the problem and undergoing through the denial phase, they had at least undergone half a cycle of the Kubler-Róss change management model. Realizing the magnitude of the problem, the next step was to contact a consultancy company to help resolve the problem.

To say the least, it was an uncomfortable situation to be in, and I had my fair share of lessons learned on what “Chaos” can do to an organization. The following three invaluable lessons are things that I walk away with, from this situation.

Communication: It cannot be said in any better way, than simply telling the team to COMMUNICATE. This is both within the team and also outside the team. How are the stakeholders kept informed of the situation? Do we push information out or do we sit pretty and wait for stakeholders to pull the information? In what platform is the information delivered? What content is delivered to stakeholders? How do we manage panic and stress levels amongst our stakeholders? Who is in charge of the communication process? Are we delivering information frequently and in a timely fashion? All these are important factors to consider if we are to ensure that communication is well managed and monitored.

Leadership: In the midst of a disaster, it is at times difficult to remain sensible, making it natural to panic and make blunders. It is even easier to point fingers and imagine that someone else should take a fair share of the blame. Does it solve the problem? Not at all. In fact, it does the opposite. The leadership has to take responsibility and give direction on how to restore normalcy as soon as possible. Engage your team to understand what the problem is before trying to “solve any problem”. Is it Unknown-known, known-known, Known-unknown, or unknown-unknown? What is the relationship between the cause and effect of the problem at hand? Which constraints are involved in the situation at hand? As a leader, are you asking enough questions to keep the team engaged? How are you as a leader helping the team to collaborate and work towards coming out of the chaos?

Problem-Solving: How do you resolve the problem? Is the whole team working jointly on one issue at a time or are there well-defined responsibilities to widen coverage? Are the team members continuously regrouping to compare notes or are they working in silos? What valuable lessons are you learning from each other along the way and how are these leveraged to quickly come out of the woods? How are decisions being made in the midst of the disaster? This is very important as there may be no time to make a proper analysis and evaluate the consequences of the decisions made.

These three lessons are important in the midst of a disaster. But there are even other equally if not more important lessons, which should be covered after the disaster. How does your team handle disasters? As a leader, how do you handle disasters? If you never had a disaster, then it is time to take heed and be proactive, making simulations of how to handle such situations. Kindly share in the comment section, your experience in disaster recovery.

Clarity In The Steamy Channel…

Getting a team to transit from their old working ways and embrace a new “unorthodox” way of working is never easy and requires patience. The team I have been working with has proved to be the exact opposite of what I expected. While I was initially optimistic that things would sail with less opposition from the team, it has actually turned out to be a daunting task. Moreover, the leadership is curious to see if there is anything coming out of “the many meetings” and has continuously urged me to train the team but reduce the frequency of the meetings. I find it contradictory that the team should be “trained” but at the same time they should be allowed to “work” in a domain where there is almost zero collaboration. Withut causing unnecessary extra pressure, I decided to spend time to understand the dynamics of the team. I did not want to come in with past experience from other teams, ut decided to first and formost understand the challenges that the team was facing. What problems did they have and why was I involved. The latter part was particularly important for m to hear it from the horsens mouth. Firstly, at the team level, and secondly from the leadership level. This was crucial in finding out where the disconnect came from and how this could be bridged. Over the last one month, I came to learn several important issues that the team was unknowingly struggling with. I narrowed down on what I considered was the most significant ones, in terms of productivity and harmonization of team efforts.

Disoriented Management or Absurd Company Culture?

I knew from the beginning that to have success on this mission, I had to win the management’s support. While talking to the project owner it occurred to me that he was not actually keen on having the status qúo change, but yet wanted to see improvement in the team. On the other hand, the project sponsor was laid back and trusted the project owner with the decisions he made. This was unsettling, to know that power was vested in one center and I had to spend more time working from his perspectives, even when I knew that they were counter productive. It was indeed an absurd company culture that was causing quire resentment especially at the team level but no one dared raise issues about it. The team did not feel psychologically safe to address these issues. But I knew that it was a safe approach if the management was to be convinced that there was need for change.

Secondly, decisions were frequently being made and changed without involving the team. It made the management appear undecided and unsure of the direction they wanted to take. Agile advocates for adaptation to uncertainity but it also highlights the importance of inclusivity and dolving decision making. It was quite odd to see that team members would need permission to make tactical decisions which affected their productivity level. Developing a tool to be used by the team, would require managements permission to spend time on that, and even then it would need to be scrutinized closely, planned at a detailed level and then strict time estimations were then provided. Phew!!! That was hard for the team but looked like they had resigned to fate.

I have now had two meetings with the business sponsor, business owner and the scrum master to raise this concern. Using this approach, I intend to introduce inclusivity in decision making. I do acknowledge that there will always be strategic decisions and tactical decisions, and my desire is that these two levels should co-exist harmoniously where the actors in each domain feel included. The meetings have been positive so far, and I have been facilitating it with the knowledge that there is need to improve psychological safety and empower the scrum master to not only feel like a participant but an active representer of the team. We have joint meetings on Fridays just before midday, and it is one of the meetings I always look forward to.

Lack of visualization

The second problem that I noticed was that the projects and tasks that the team worked on was not visualized on a common platform where the team and the management could have a common focus on. Borrowing from Lean’s principle on mapping value streams to actual actions needed to satisfy the stakeholders, it was apparent that lack of visualization was a problem. I soon started to understand why the management changed thei minds frequently and the team was informed in the last minute. It also began to make sense, on the couple of times that the team members would unknowingly be working on duplicate tasks or get derailed on side tasks that did not add any value to the customers. The scrum master was mostly working using spread sheets to keep track of what they were working on, but this was not visualized to the team. After a weekly meeting, the scrum master would update the spreadsheet to mirror the progress the team had made. What was puzzling was that the scrum master then had to meet the project owner and discuss the progress based on the reportings made in the spreadsheeet. My curiosity got me thinking, how much misinformation could be taking place by having the “middle-man” in the process. To increase the complexity of the process, the project owner would then use a copy of the spreadsheet to communicate to the project sponsor. It became apparent that this process introduced other underslying challenges; Missing expectations management between the team and the leadership occassioned by the absence of a common alignment, poor understanding of what the different team members were working on and lack of commitment due to absence of a common goal in between the sprints. Goals were defined for each quarter but then that was it. There was no further breakdown.

I raised these observations with the scrum master and why it was important to have a web platform that could visualize what the team was working on. Her major reservation at this point was that management would now be willing to spend on a platform that they felt was nott improving any value. Secondly, she also felt that it might take a long time to know how the platform was working. After much talk the last three weeks, we finally decided last week to start with JIRA, which I recommended due to its simplicity and also because they could get a free version for limited users. We have created users in the platform and the team is now able to see what each other is working on. there is a sense of curiosity and eagerness in the team. For the first time, they are feeling a sense of unity is starting to creep in, creating impact in their working approach and I am happy to see that we are slowly turning the wheel towards the right direction. Albeit for now. Will it be a success? I bet so. the enthusiasm in the team can be smelled miles away.

Have you had similar challenges? How did you approach them with your team? I would like to hear from you, please share your comments

Challenges in Going Agile

This week has been a fascinating one, packed with suspense and speculation. I have supported a team that is transiting to Agile from a chaotic state and I came face to face with the challenges of embracing change within a team and at the leadership level. I have seldomly worked with this team, but it is the first time I am getting to understand their working process. It is a team comprised of 6 developers and a product owner. One of the developers doubles as a Scrum master and is the one pushing the team to embrace Agile. While there are a few baby steps that the team has made, they are still in the dark about what to expect and what to do. I had the following observations, which made me wonder how other teams experienced their transition to Agile.

Leadership

The “Scrum Master” has been tasked with streamlining the team and coaching them on the benefits of transiting to Agile. However, a caveat in this approach is that the leadership has a laid-back approach and is also pessimistic on whether there is any value coming out of the process. The team has been in existence for the last 5 months, and the leadership is yet to officially communicate to the team why they believe that they should go Agile. What happens to a team where they can clearly see that the Leadership is paying lip service to the process, but going contrary to what they are advocating for? There will be lackluster in the team and however much the Scrum Master works hard to help the team embrace Agile, it will be an exercise in futility. Because human beings naturally tend to be followers, the leadership has to be supportive of the process if they are to exceed. In his 2014 book, Accelerate, about Change Management, Dr. Kotter observes that Leadership involvement is necessary if real change is to happen and the value sustained so that things do not ultimately drift back to default status. This team needs the leadership to step up and back the efforts being made to transit to Scrum way of working.

Overachieving

While the leadership is skeptical of the process, the “Scrum Master” is an overachiever who is so zealous to get the process injected into the team. She has been busy having uncoordinated meetings with her team and shoving down their throats on what is Agile and what is not Agile. Interestingly, she gets mixed on her own facts and when asked about the claims, she has a standard answer “That is what we will do for now”. This has left the team frustrated and feeling hopeless about the situation. This is because the developers believe they have proper control of their workspace and understand what is needed of them.

The team members have occasionally stopped me at the coffee machine or in the corridors to ask whether “this and that” is Scrum practice or not. While in some situations I have been able to answer them, in most cases I think their concerns are genuine and I always end up telling them that Scrum by definition is a Guide and should not be used as a metric standard for working in a team. For example, if I am driving from Copenhagen to Hamburg, I know that the GPS will guide me through the most convenient route, but I have to define the criteria for convenience. But this in itself is just a guide. I could drive from Copenhagen to Odense on the highway, and then drive along the countryside for the next 30Km, drive from small cities to cities in the next 50Km and then round it up again on the highway. What matters is does the route suit me and my passengers? Are we in a hurry to come to the destination or we would like to explore the routes as we drive? Are we willing to have some stop-overs along the routes to drop or pick someone? These specifications will define the parameters for my “convenience” criteria. Similarly, when starting out on Scrum/Agile, the Scrum Master does not have to whip the team to abide by all the practices that are embodied in Scrum. Start with small practices, ensure transparency in the process and importantly help the team to understand WHY they are doing something. Surely, not all practices will be suitable for the team from the beginning, especially the ceremonies. So, allow them to Inspect the processes and Adapt as they go along the way.

When starting on Scrum, I advise teams to take a stance of zero heroism. No matter how much a team member understands Scrum, the ultimate reason of engaging the team is to work collaboratively and keep on improving the process at a sustainable pace and continuously satisfy the stakeholders. This is analogous to being a top scorer in a football team that is under threat of being relegated from the league. It is then better not to score a goal for a whole season, but support your team to avoid being relegated from the league. Being a top scorer and the team is in relegation zone, earns the team no credit. Zero heroism!!

How did you transit to Agile and which practices were difficult for you to embrace? Have you finally embraced them in your processes and how do you handle lack-lusture leadership and/or overachieving Scrum masters? Please share your thoughts and comments

Change management

It is quite baffling how managers struggle with introducing change in their organizations and keep the changes permanently. Change is inevitable and is the only thing that does not change. Organizations expeience change eveyday, whether in their operations, management or culture. However, most of the times, the changes are short lived and soon everything rolls back to live in its previous status. I have met managers who didn’t understand why the company was unable to attain the set goals because “the employees were not embracing new ways of seeing things”, department heads who could not streamline operations to company strategies, developers who were stuck with the first generation of a technology that they learned while still in university and so on. What all these scenarios have in common is failure to manage change effectively. Managing change can be daunting, especially where there is no goodwill from management and the resources are scarce. But that is not a scapegoat, there are several change models that can be used to achieve the end means. Depending on the management model of the organization, some of the models that can be used to effect change include but not limited to Kotter change Model, Kurt Lewin’s 3 stage model, Orlikowski’s Imrovisational model and so on. An overview of what causes difficulty in implementing changes can be seen in the image below, copied from Knoster (1991).

In the next post, I will explore change management models, the kind of organizations they are suitable for and how they relate to each other.