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

Project Kick-Off meeting – In the footsteps of the project manager {2}

Previously I have covered 2 posts about the kick off meeting and why they are important. Yesterday I mentioned about how as a project manager you can prepare for this meeting and help the team to be ready. Today I will conclude this discussion on where I left it yesterday.

Teamwork: Often, it is the same team that gets to work together in the same projects. At times though, there is cross-organizational projects involving external sponsors and customers. It is important that all the involved stakeholders are part of the kick-off meeting in such a set-up. It helps set the pace on how the team will collaborate, communicate, meeting frequencies and helps small details that would otherwise have been ignored to be properly addressed. The team members have a chance to be familiar with each other, which reduces anxiety. As a project manager, the important part that should be taken care of is to make sure that the expectations are well and articulately spelt out to the team and let them develop a working relationship on how to deliver results. The project should however still be monitored and managed but not micro-managed.

What next?

Yeah, that is always the big question. The team members have been informed of the new project and there is excitement in the room. There is always a temptation to jump straight into the work and begin working on the juicy part. As a developer, I have experienced numerous cases where

team members start to code functionalities of a program, they barely have understood how they work, which always ends up in defeat. As a project manager, the next steps involve keeping team members clear of their roles, expectations and milestones along the way. It is the moment that the kick-off meeting should be rolled backwards from anticipation towards results. It is also necessary that the project manager gets to know the client, their expectations and requirements before diving into any project. Traditionally, companies used to have clients come over for a meeting, which would be marked with very formal tones. Companies are now changing the trend and at times it may start with a company visit to familiarize yourself with the client and drop the “business” acumen. It works most of the time as it helps the client to know that these are people who are going to deliver quality to his work. The project managers should use this opportunity to get to know their clients and develop a working relationship and level of trust.

Before concluding the meeting, it is a good idea to have a recap of the meeting to give the client a review of the people who are going to work on their project. It is important that the team understands the roles played by other team members. A review of the SoW should also be performed to know what the team is doing, when to do it, how to do it and what they should expect to produce. Any other important issues that may be deemed necessary should also be put on the table towards the end of the meeting, as it is not always feasible to have all the team members and stakeholders in a single meeting.

It can not be stated enough how the kick-off meeting is important in any meeting, but any project manager worth their salt, will ensure that it is done.

Project Kick-Off meeting – In the footsteps of the project manager

Last week I wrote a post on how to set the right pace for project kick off, ensuring that the whole team is at par. As a project manager, holding this meeting with an informed team and a proper project management plan is key to an engaged meeting with the client and the stakeholders. A team that is well informed on the requirements of the project and what is expected out of it, works even better when they have an encounter with the client. This helps them to ask questions and raise concerns, something that may have been overlooked in the initial phases. Moreover, the team’s spirit is boosted, knowing that they have to create a working formula that makes the client feel confident. As PMI states, a meeting with the client is crucial in helping the team to make vital project decisions in good time, so that valuable hours, money and face-to-face client time are not spent on team debates, which the client may construct to mean internal-strife. In my earlier years of working as a developer, this was something that frustrated me everytime i was to start on a new task or project. i just had the work lumped on my board and a deadline issued. As I worked on the project, I spent countless hours trying to understand what the project was about, something that even the project manager had a vague knowledge on. From the project manager’s viewpoint, it was the business processes that mattered. From my view point, it was how to

connect the technical part to the business value. Later on, I started demanding to be part of kick-off meetings, something that made a huge difference in my approach to projects. But again, this is more of a company culture and how they prefer to approach projects. In large companies, it is usually the norm to have project kick-off meetings where players from different teams are briefed about the project and the clients get to know who will be responsible for developing the solutions. In smaller companies, kick-offs are very informal and there are usually no documentations involved. They prefer casual face to face talk over a cup of coffee and a whiteboard.

Preparation: As a project manager, the least one can do is to make sure that they are well prepared for the kick-off meeting. Documents regarding the project should be shared well in advance so that the team gets to know what the project is about. This helps the team to quickly get acquainted with the task ahead and consequently acquire any important knowledge that they may deem relevant. For instance, working on a new security feature, a team member may have concern on how this will impact a release they are set to have in production in the next year. The kick-off meeting should however not degenerate to a Q&A session, but rather a knowledge sharing platform to give a go ahead for starting. The project manager should therefore moderate the questions being asked until towards the end, to keep the meeting on track.

Who is the client? It is equally important to let the team know of how the project is important to the client. Is it a new client trying to find a new company, is it an existing client whose preferences are known to the team or is it a project that tries to check on feasibility of something else? Internal clients who have had projects with the project manager before, should also be invited to the meeting. The project manager should give an explanation of the client distinctively without bordering on the nitty-gritty details. For instance, “this project belongs to a client who recently was awarded the best htelier in the country”. This helps the team to Let them know who they are (internal/external), what we know about them, other projects they’ve worked on, and how the client likes to work

What is this project about? The project manager should address this question in the kick-off meeting, to help the team understand why they are doing the project. This should be viewed from a client’s perspective on how the project’s deliverable will help to drive their business. It is a key step that should be done with clarity to help the team understand what a success or failure looks like. Discussions with the team on how the project’s success will help to solve the client’s problems should be part of the agenda. The project manager should aim to maximize the positive customer experience by guiding the team to understand the need to deliver on the project’s success. It is the first baby steps for the team to develop a vision on why they should care about the project and also know that their work will contribute to something big. Lastly, it should also be clarified on what success means beyond timely delivery within the budget and the agreed scope. How will the project team benefit as a result of doing this project – will they develop a new capability or competency with a new technology?

Roles definition: the project kick-off is also important for the team to understand what roles they will be playing in the project. The project manager could develop a RACI chart and a RAM chart. These helps the team to understand the context of how they will fit into the big picture by clarifying their roles and responsibilities. To improve clarity, the project manager should map these roles to the statement of work (SOW) and clarify the deliverables associated with the roles, why they exist and what has to be done to make them a success. This helps to mitigate any uncertainties and improves comfortable levels of team’s understanding. This should be the area that gets the central focus of the kick-off meeting. Failure to do so, can easily derail the project.

To keep the topic juicy, I will let this first sink today and will tommorrow, give a post on the last part of this series.

What drives values in an organization?

In my last week’s series of “Benefits and value realization, why do many companies struggle?” (I encourage you to go and read that first), we delved into how BRM can help organizations achieve value. In this post, we will be focusing on the same side of the coin but from another perspective. Executives work hard to achieve values and realize startegic goals and objectives. But rarely they miss to recognize the bits that drives values in the organization. However, this can be done in futility if the strategic goals are not integrated in the organization culture. It is not surprising to find companies with employees who have worked for many years, but don’t understand the values the company stands for. It simply means that they have no idea which direction on the compass, the company is taking.

The importance of values was once captured by Edward de Bono, a famous author and inventor, “Effectiveness without values is a tool without a purpose.” The same is true today for organizations whose management don’t seek to improve and nurture the core factors that drive the organization. It is true that businesses vary in nature, culture and attitude but all have a common focal point in working towards some defined goals to be relized within a given time frame. The question is what drives these values in an organization, and align them to the organizations’ strategic goals, making the management and employees share a common platform?

In agreement with Abdollahyan, F. (2012) in his conference paper, values should be understood to be an inseperable relationship between benefits, costs, and risks which are incurred in running a business. I would therefore say that the company culture and the mindset that has been developed comes first and foremost as a value-driving factor. A clueless management that does not instill this in their culture, no matter how well they may wish to run their projects, will repetitively succumb to hurdles and only manage subtle values despite their best efforts. In my view, a company culture drives values by guiding the whole organization on what the target is. It is like a magnet sticker on the fridge that anyone on the family knows the text on it. For instance, Apple is well known for producing high sleek phones with prices soaring above their competitors. However, one of the cultures that the company has embraced is peer-vetting, to uphold their name. They value quality and brand image and have made extra strides at ensuring that these are met. Of course this has seen their revenues driven up, since they came to the market and are today big players in the technology domain. By having a value driven culture, the employees begin to feel a sense of ownership and passion to deliver outstanding results.

Another aspect of driving values in a company can be realized by being innovative. Organizations that not only strengthen the market brand of their products/services but also seek new ways of doing things end up staying ahead of their competitors. It gives them an advantage in the competitive market, expands their customer base and drives value realization helping them achieve their strategic objectives. Often, it involves spending a fortune before introducing new ideas in the marketplace but then it is better to be innovative than imitative. Value realization may take time, but then being a trend setter gives room for discovery. Employees will also have the thrill of being the first of the first and as they seek to be dynamic, new innovative ideas responding to the market needs eventually translate to emergent benefits. It is not surprising that according to Forbes, organizations that are trend setters have a higher tendency of enjoying value-realization, increased consumer-confidence and thriving revenues more than their counterparts.

Respect!! Either it exists or not. There is no in between. Organizations where employees feel respected for who they are and what they believe in, feel more appreciated and are more committed and productive. Team work becomes interesting as they learn from each other and freely challenge ideas, which makes them achieve professional growth and quality outputs. Organizations have responsibilities of promoting respect if they are to ensure a low employee turnover, dedication and a healthy workplace environment. Committed employees work hand in hand with the management to achieve growth and profitability. It boosts emloyee confidence and morale as they management focuses on a higher level of achieving the values and the employees feel confident and at times even indespensable. This drives them to perfrom even better. It is not uncommon to hear organizations firing their employees who have publicly shown disrespect or misconducted themselves. Whether it is done to suit public expectations or not, the bottom line is that companies treasure values and should not compromise it for an employee’s misconduct, whether be it management or employee level.

Ethics and integrity are also key to achieving values. When employees are honest and do their jobs correctly in a honest, fair and responsible way, then it becomes natural that trust is built. This gets extended to the customers and the other stakeholders, building a good product reputation and customer confidence on the products/services. This in turn leads to value realization in an organization.

It is not hard to see the importance of these key factors that drive values in an organization but whether they are practiced or not will ultimately lead to value-realization or not. Some other factors that will definitely be important include being team focused, client focused, professionalism etc. Of course, best practices at observing these factors alone will not guarantee success, but they play a bigger role in casting an organization in the right direction towards value-organization.

References: Abdollahyan, F. (2012). Management of value as PPM driver. Paper presented at PMI® Global Congress 2012—EMEA, Marsailles, France. Newtown Square, PA: Project Management Institute