Tag Archives: Nirmaljeet Malhotra

My recent podcast on the future of Scrum Master role

SM

In this recent podcast, you can watch me in conversation with Samir Penkar on the topic of “The future of Scrum Master role”. This is part of Samir’s recent research study.

Add your voice to this research study:
https://futureofprojectmanagement.com/2017/01/26/future-of-scrum-master-research-study/

 

When a plumber gave a crash course in consulting

photodune-3476677-hand-writing-consulting-m

Source: rlmconsulting.be

 

The idea of consulting is typically associated with an individual with certain specialized skills that makes him an expert in an area. While the term “consultant” is generally associated with high profile areas of specialization, other kind of areas fit rather well into the definition of a consultant.

A close friend was recently sharing his experience where he needed to call in a plumber to a fix a leak behind a wall, however; he also went about researching the internet about how to solve the problem. Not to mention he used certain keywords while searching like “cheap ways”, “quick ways” and some more. He also searched for specific information about how plumbers have a tendency to exaggerate the problem towards generating a high margin. As it was time for the plumber to arrive, he was ready with how the problem should be fixed, what tools would be needed, how he would ensure that the fix was successful and steps he would take to shield himself from getting ripped.

screen-shot-2017-02-28-at-11-19-47-amThe plumber who seemed like a master in his trade had other thoughts. He was quick to diagnose the problem and suggest the fix which obviously was different from what my friend was expecting. During this period, the plumber was patiently listening to all the research that was done. There was some back and forth and the plumber left without fixing the problem.

Human mind is constantly engaged in the activity of forming opinions about people, society, profession etc. We try to appear smart, knowledgeable and experienced in the most unknown territories. This isn’t necessarily because every human knows everything but because we feel uncomfortable with how the person in front of us will perceive us if we said “I don’t know”. At the same time, this behavior does change in situations when the outcome has a higher degree of risk involved. For example, talking to a doctor about a possible fix to an ailment, we tend to trust the doctor to make the right decision with the end objective of a successful and full recovery. We do not even want to confront the doctor if what our research suggests is otherwise.

While organizations like to have control over what and how consultants solve problems, consultants needs to exhibit certain characteristics and ethics to justify the value for the price paid. Below are some characteristics that identify great consultants from the rest:

  • Listen – A consultant’s first strategy to build confidence is by listening and paying close attention. The 5 stages of listening (receiving, understanding, evaluating, remembering, and responding) supported by active listening (a technique that required the listener to provide feedback of what he or she hears to the speaker) help in empathizing with the situation and subsequently providing solutions or asking relevant questions.
  • Comfortable saying “No” – The fact that consultants are experts in their field gives them a upper hand in making recommendations that are based on skills, knowledge and experience. This also implies that addressing the problem in hand using the right means takes precedence over other measurements including doing things a certain way to keep the client happy. As an expert, a consultant should feel comfortable to disagree with the customer and provide evidence to support it.
  • Align strategic goals and measurements of success – Engagement of a consultant suggests that a certain expertise is needed in order to address a problem which the organization is unable to address by itself. In such a scenario, it becomes vital to understand the strategic goal behind engaging a consultant and the measurements of success both long term and short term. Often these discussions never take place and consultants are asked to follow orders and paint a picture that is expected.
  • Challenge and persist – Great consultants don’t give up. They accept frictions, unforeseen circumstances and negative feedback, they learn from them and they move on. They will analyze and learn from every setback in order to prevent it from happening again.
  • Do not get ahead of yourself – Being a consultant in a specific area does not mean that one works on the same set of problems. For example; the symptoms for the doctor to diagnose a problem can vary from patient to patient. A doctor cannot afford to assume that the second patient has the same problem as the first one given that the symptoms are same. Think and assess before giving a reference to how you faced similar challenges in the past and how they were addressed. Assessment of the problem along with creative thinking should happen before influencing the solution approach.
  • Expose problems and facilitate solutions – Consulting done by providing immediate solutions to problems is done with an intention of creating dependency. A great consultant refrains from providing solutions and instead helps in exposing problems so the organization can solve the problem itself. It is impractical for a consultant to get into a problem solving mode having been with the organization for a short period of time. Instead, a great consultant will use enquiry and facilitate conversations to expose problems so organizations can find the best possible solution(s).
  • Have a exit strategy – A consultant needs to have a well defined exit strategy which should be looked at all along the duration of the engagement. Exit can be a result of a successful solution of a problem or completion of the engagement or a realization where the consultant cannot fathom the value to be added. Either way, exit at the right time goes a long way in building trust with the customer and ensuring a long term relationship. As it a said, the greatest measurement is success if by how soon a consultant can work him/herself out of a job leaving behind a organization that is self sufficient.
  • Maintain transparency – Consultants need to feel comfortable sharing both the good and bad news. Consultants are bought in for a reason that things are not working in the first place. Given the high rates consultants get paid, some consultants refrain from or delay sharing bad news with the client assuming they will address the problem without bringing it to the notice of the customer. The fact is that most issues exposed sooner than later. Consultants should establish transparency as the key criteria of their relationship with the customer right at the start of the engagement. If this is done, a bad news will not come as a surprise for the customer and will only help in building trust and ensure ongoing collaboration in addressing issues and risks.
  • Accept you don’t know it all – Not knowing everything is normal, however; accepting that I do not know everything is difficult. No matter how experienced or qualified a consultant is, s/he will run into situations where the consultant might not have a opinion or an answer. This isn’t necessarily bad news. Acknowledging that I do not know something and then making an effort to research the solution elevates the relationship and provides opportunity to learn something new.

Consulting in the area of business, technology and other recent areas of innovation has forced other business like staffing to get into the consulting fold. Individuals and so called consulting organizations have started using the term rather loosely. While this has resulted in smoke around who consultants are what they do, it is important that consultants practice the above characteristics to bring some credibility back to the professional of consulting and help organization realize the benefits of value consultants offer.

If you are a consultant who exhibits a characteristic not captured here, I would love to hear from you. Please leave a comment below. Happy Consulting..

My podcast interview about Agile, Scrum and the Scrum Master role

podcast-istock

Image courtesy: cbc.ca

I am excited to share my latest podcast interview with Vasco Duarte where we discuss about agile and Scrum and get into details about the Scrum Master role all through this week. This podcast was recorded for the site http://scrum-master-toolbox.com/ to discuss various topics around challenges related to the Scrum Master role, some anti patterns to Scrum, change leadership, measurements of success for Scrum Masters and agile culture and mindset.

First 2 episodes are live now. Don’t forget to watch the upcoming 3 episodes (Wednesday through Friday) this week.

Please provide your feedback on the podcast, leave comments and like. Also reach out for any questions or if you would like to record a podcast for your site.

1463196442815

How empathy can help you build a great product and a great team

empathy-9550064_l

Doing some research on the subject of design thinking, I stumped upon the term “empathy” and interesting enough, it is the starting point and the most important aspect of design thinking.

The way design thinking mentions about empathy is that it is a way to put yourself in the user’s shoes and observing in a empathetic way. This is done to  focus more on the human aspect, trying to feel for the person who lives in the context and has a series of needs that can be satisfied.

Screen Shot 2016-06-06 at 3.41.27 PM

The design thinking model

[em-puh-thee] – the psychological identification with or vicarious experiencing of the feelings, thoughts, or attitudes of another.

The whole aspect of empathy makes a lot of sense because simply put, it is a method to know a person and their desires. However; interestingly enough, empathy loses its importance when the focus moves from product users to development teams.

It is important for leaders to communicate with your team members, they want to know you understand where they’re coming from and what they’re feeling. So, how do you as a leader show empathy at the work place? Here are some critical steps to demonstrate empathy:

  • Listen – Listen to understand. Refrain from processing the information too soon and arrive at solutions
  • Understand the feelings – Keep a balance in understanding what is being said and the feel with which it is being communicated.
  • Reflect back to what is being said (“so what I hear you say is….”)
  • Validate their feeling (“I understand your feeling….”)
  • Assure support and conclude the conversation
  • Make no false commitments – Don’t sympathize and make false commitments. This can impede trust.

Showing empathy, and reflecting back feelings when appropriate, not only demonstrates good listening, it shows you care for the team and provide a sense of security to encourage the team to ideate, innovate and take risks.

As a leader, your behavior tells the employee  you care; increases the transparency and at the same time, helps you and your team member build trust.

So next time you have a conversation with your team, pay a little extra attention to how empathetic you are towards them. The payoff will be totally worth it.

Scrum, the solution to all problems

improving_scrum

If you are someone who has had limited or no success with Scrum and the title of this post forced you this way, well, I have met my first objective.

Last couple of years I have had an opportunity to connect with multiple teams that have been doing Scrum but have had very limited or no success with it. What I hear most frequently is “this does not work for us”. Further analyzing the data talking to these teams, some very specific reasons surfaced and I am listing them below:

1. Too much focus on Scrum “process” – The biggest reason why teams are unable to derive any benefits from Scrum is because they look at it strictly as a process. Scrum is a methodology but every single aspect of Scrum has very specific objectives. However; most teams are seen going through the motions without necessarily fully understanding the objectives and benefits of all Scrum artifacts and ceremonies.

2. Not doing Scrum right – Scrum is intended to be done in a specific way. Talking about the “Shu-ha-ri” approach to Scrum, the teams are initially expected to follow the rules of Scrum, however; teams start to make changes to it to often to suit their environments and projects which for obvious reasons reduces the effectiveness. Changing the frequency of ceremonies, micromanaging the team, forcing teams to deliver defined velocity and to dates instead of value etc.. are most common anti patterns that have been observed.

titel

3. Fear of being exposed – Scrum is not designed to solve any problems, however; Scrum is designed to expose problems as early as possible with the belief that teams will be able to address them. Inability to produce incremental value for business, inability to measure business value, not having a well defined backlog, carrying work over from sprint to sprint, and many more of these data points expose teams ability to plan, execute and deviating their focus from the three pillars of Scrum (transparency, inspection and adaptation).

4. No slack time – There have been very specific areas where teams enjoyed huge slack periods due to the phased approach to software development. Teams would develop code and then sit back for defects to be identified or environments to be refreshed thus giving teams slack periods. In enforcing the need to deliver value continuously, Scrum and other agile methods have forced the team to be on their toes all the time. This obviously makes people uncomfortable and increases the risk of them getting exposed.

5. Resistance to change – Analyzing the previous points, it all boils down to the fact that the failure of Scrum can be attributed to the resistance to change. Companies, teams and individuals are not willing to change even if their current processes are not working. The possibility of getting exposed or the pressure to get out of their comfort zone brings the resistance to agile and Scrum.

The mindset

As you might have heard before, agile/scrum is not a process but a mindset and needs a completely fresh approach to how problems are identified and solutions are arrived.

I read an interesting analogy about Scrum and the impact of not doing right. Trying to make your grandmother’s recipe of Carrot cake, if you make your own decisions instead of following the exact recipe, you cannot expect your cake to taste like your grandmother’s. In the same way, Scrum needs to be done as prescribed before teams can start experimenting with it.

Having spoken to hundreds of team and maybe thousands of individuals, the observation is that companies are not doing Scrum. At best they were doing waterfall with iterations. The idea of continuous improvement does not seem to exist and this is a serious problem.

I love how Philip Grove, CEO at Confluex puts it:

  • Scrum is like whitewater rafting. The rafting team members each have a job, they know how to perform it, and they know the team’s short term goals very well – “get beyond the first rapids.” They vaguely understand the approximate long term goal – “Get to the end of the river.” And, they know they have to work together, and help each other succeed. Finally, they know that everything else is pretty much going to change. The rocks aren’t always in the same plae, the rapids are moving faster, a log is floating alongside the boat. The team has to pull their strengths to get through, and make collective changes along the way.
  • Waterfall project teams are military ships with a crew, a captain, a detailed set of orders, and an admiral relaying changes from command.
  • Scrummerfall is taking that rafting team, with a captain, the orders, and the admiral relaying changes. This is a recipe for failure.

Post Script

Companies need to create a culture where failures are not necessarily looked as a sin but what you learn from your failures if of paramount importance. This will help create an environment where the three pillars of Scrum (transparency, inspection and adaptation) will help create a very strong foundation for continuous success.

Agile and software rewrite

Talk about software rewrite and one comes across varied opinions. With the advent of cutting edge engineering practices that facilitate opportunities to build things right the first time, many look at the need to rewrite software as a sin. When coming across developers and architects who want to rewrite software systems, you hear them saying things like the software is way too complex or the system was probably written by a dumb developer etc..

As you investigate the need for a rewrite, some of the more common reasons include:

  • System is not performant
  • System is too complex to understand
  • Technical debt
  • Unfamiliarity with domain and legacy code
  • Use of old technologies
  • Business feels the system is out dated
  • More..

So what is the right strategy for a rewrite?

Most business want to take a “like per like” approach, which means that the software be re-written to implement improvements without introducing any change from a customer experience view point since selling a change to a customer can be challenging. This mentality results in under estimating the complexity of the system and ignoring the opportunities for improvement.

A real world example that one can relate to is a new version of an existing car model that gets offered every couple of years. Would the car sell more if the company was to build a new version in the same exact way as the existing one? Well, not really. Customers look for improvements across the board, from improvement engine performance, latest features, more mileage and a refreshing look. So why should software be treated any different?

Is a complete rewrite acceptable?

The second is the most dangerous system that a man ever designs” Fred Brooks, 1975 & 1995

Complete rewrites will make sense if one can stop the world from changing but unfortunately that is not an option. So the first approach should be to refactor your way out of the problems. Most issues can be resolved by addressing the issues in a prioritized fashion. Systems when rewritten are mostly NOT written very differently from when they were written originally. There are still requirement gaps, architecture does not resolve all of the problems and teams still build a lot of technical debt.

Refactoring your way out turns out to be the most efficient both in terms of effort, cost and risk. Engineering practices like Test Driven Development (TDD), pairing through the issues and refactoring code can go a long way in making an existing system performant, allow teams to familiarize themselves with the domain and inside of the system and cut the effort of rebuilding features that never get used.

How can an Agile approach help?

Does Agile make sense for software rewrite? It absolutely does. Agile is all about continuous improvement and systems are rewritten to make them better in many ways including emerging improved architecture and value driven development. One huge benefit rewrites potentially provide is to get away from features not providing business value resulting in eliminating waste for development and maintenance activities.

In general, there is no reason to treat rewrites any different from a green field project. Agile approach if followed in a organized way should help building the right system maintaining a view of expected benefits. Lets assess one area at a time.

  • Requirements – Business and market situations change by the day. Rebuilding what you have today is not an option. Requirements should be captured and backlog created from scratch. While breaking requirements and creating stories, right amount of focus needs to be on the value each requirement offers. Systems with legacy code built over several years always carries a certain amount of risk. With churn in resources and changing business landscape, it is hard if not impossible to be aware of all legacy business rules. Hence, there is significant risk involved in assuming a complete familiarity of existing systems.
  • Small shippable increments and feedback loops – with focus on key improvements provide an opportunity to compare smaller increments with existing systems and adapt to missing pieces. This will also result in the need to understand only the part that is being recreated. Small shippable increments facilitate continuous feedback loops for faster validation and confirmation.
  • Speed to market – Continuous improvements in existing systems made in small shippable increments can be made available to customers frequently. This can go a long way in meeting customer satisfaction.
  • Customer collaboration – What better than engaging existing customers in making the product better. Most customers will be open to provide feedback about the system. Agile development principles encourage active ‘user’ involvement throughout the product’s development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project’s progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.
  • Team collaboration and knowledge building – Giving the team the space to understand existing system and propose what the new system should look like brings out the creativity to resolve business problem in more innovative ways and facilitates domain knowledge creation.
  • Engineering practices – are the key facilitators towards building software right the first time. Rebuilding is no different. These practices encourage refactoring to address issues with existing code and help in building quality with rewrites.

There are enough benefits to leverage agile principles and practices for software rewrite. Writing the software the way it exists today does not provide any benefits but results in significant waste and limits focus on improvements. I can say that Agile can be as effective for rewrite as it if for greenfield projects.

So, evaluate the opportunities through refactoring before you walk the road to rewrite from scratch. And if rewrite is the only choice, going with an Agile approach will provide the right tool towards building the next version.

Have you used Agile for a rewrite? If yes, do share your thoughts.

Actions for retrospectives | Innovation games

Wanted to share my experience facilitating a retrospective for my team using the “Action for retrospectives” from innovation games. This is a excellent technique/game that allows the team to think about a retrospectives from multiple angles.

Image

The “appreciation” angle came as a big surprise. Appreciations came in from everyone, both at personal and team level and setup the right environment for the more difficult discussions to follow. It was a very clear indicator of the fact that the team members appreciate each other but never had an opportunity to bring that in the open. In fact the appreciations clearly out numbered the other angles mentioned below.

The “puzzle” angle was about raising issues that existed without any member of the team having any knowledge about any possible resolutions. However; it turned out to be slightly different. A key finding being that a puzzle for one team member was not necessarily a puzzle for others. It remained a puzzle for one due to lack of conversation and collaboration between team members. As soon as it was bought out, potential solutions were discussed and actions items identified.

The “risk” angle highlighted issues that team members were experiencing as individuals but rarely had an opportunity to bring it in front of the whole team. There were issues that belonged to more than one buckets, in which case we allowed the team to have duplicates across multiple angles.

The “wish” angle was all about inviting innovative ideas from the team to focus towards continuous improvement. The team thought outside the box and came up with great ideas.

What makes this tool effective is that it brings out the high priority issues that might have not have been noticed by the team. If the same issues exists multiple time as a problem under puzzle or risk and there are ideas to address it under the wish angle, the issue just emerges as the highest priority. The team can then choose to identify the top issues and define action items to address those issues.

Click here to see a detailed description of the technique and access the online version to use this tool with distributed teams.