Conflict – Is it Good or Bad – It depends on how you treat it within your Team

Subscribe to continue reading

Subscribe to get access to the rest of this post and other subscriber-only content.

Already a subscriber?

“How Might We” – A Tool to solve issues that surface @ Retrospective (Innovate your Retrospectives and Product Backlog Management)

The How Might We framework is quite often called HMW. The framework was originally created to define and frame design challenges, but you can use it to address a lot of different challenges you might encounter.

The How Might We framework is basically a way to reframe a problem. You’re not only trying to see the problem from a positive perspective, but also opening your mind and consequently your possibilities to new solutions. This can be an amazing opportunity.

This concept has been borrowed from Design Thinking approaches. I have personally used this concept to resolve issues and impediments in my clients Agile transformation and adoption journey. It is a different way and a method to tackle things that would bring different views and perspective to life.

Normally HMW question can be quickly formulated if good findings / issues / problems statements have been identified. This definition of HMW should not take more than 15-20 mins / issue or problem. We would typically do this with a lot of white boarding, using Post Its, Pen and Paper.

When we redefine our problem with the How Might We approach, we are actually turning challenges into opportunities. It’s a process, and you might not get it right the first time. It’s an important tool for mastering the ability to develop creative solutions to problems. Redefining our problems in this way can unlock a world of possibilities.

Make sure your team is empowered to come up with even silly and crazy ideas. Create a safe environment where brainstorming is truly valued. At this point, don’t worry about the feasibility of the ideas, just brainstorm and go crazy. In some cases, the crazy-impossible ideas can be reframed in a brilliant and innovative way, so don’t constrain your mind or your team. HWM questions are a way to foster brainstorming and other ideation sessions.

Why are they called “How Might We”

“How” part suggests that we do not yet have the answer. It allows us to consider multiple avenues for innovation and reinforces that we are still exploring the problem and solution space.

“Might” emphasizes that there are many different paths we can go down when thinking about solutions. This allows for open-minded creativity and brainstorming and thinking about the problem from multiple perspectives. This “might” is where innovation becomes part of the process.

“We” immediately brings in the idea of teamwork. “We” should all work collaboratively to come up with a joint understanding of the problem and put our heads together to come up with a joint solution.

How should this work for an Agile team?

Reflect upon all the issues / challenges / Improvements as needed and identified during the retrospective, then reflect upon them to see and understand the context a lot more better (at times, we are emotional during the retrospective and want the whole world to improve)

Motivate the team to explore and come up with several HMW questions that could address the needs or the problem statements

Each question should follow the logic of “How Might We” and it should be followed by a verb, noun and type of the user base that we are trying to address the problem for

As a passing thought this approach of HMW can be used for any type of problem solving or identifying new ideas / thoughts / innovations or opportunities – this could be used in resolving the issues or challenging the current status quo of the Product backlog approaches, how user stories are to be developed, what solution would address the problem in hand.

I have seen a lot of people using HMW statements to invoke discussions leading into innovation, but as the case with some other models, they can go horribly wrong… Like too much of Open Ended Ness

• How might we make our app more usable?
• How might we redesign our website to make it better?

Or at times, we go so deep, that we have created a narrow view:

• How might we make our app’s add to cart experience more functional?

When HMW statements are too narrow, we lose all the incredible, innovative ideas that can come from them. With too much focus, we are stuck on one particular solution already. We want several different ideas to test at the end, so focusing too much on one solution will limit creativity and innovation.

Always remember that in addition of the description of the problem, a target customer must be defined for the project / problem to be resolved. In doing so, we are now trying to highlight the user and his / her needs (now notice we have got Persona as concept involved here)

Have multiple HMW ‘s for each problem statement, Each HMW question can then be understood as a prototype and testing in a short brainstorming session, The one that is the most appropriate one will then be chosen and pursued.

Key elements to take care of:

• Do not discuss a HMW question for too long, Timeboxing should be performed for each HMW and do not get bogged down in the phrasing of the question.
• It is essential to be optimistic and close to the needs of the user to come up with several good HMWs

Use the above ideas and thoughts in your next retrospective or product backlog refinement session, do share your experience and help us improve the approach and tool sets for continuous improvement approaches.

I propose this approach to be added to the concept of Liberating Structures

The softer side of Agile – Neglected and unnoticed ….

The word agility is on the lips and tips of most business executives throughout the world as they try to increase their employees’ and organizations’ ability to anticipate change and respond efficiently and effectively.

Agile adoption requires all departments and functions to be aligned and think likewise, which includes the HR function.  However, many HR executives are clueless on the intent and the focus of agility in the current HR processes. Creating the Agile Organization turns its focus on agility itself and asks the question. What is the role of HR in the agile adoption in the organization, how and where and what should the HR folks contribute to make the organization Agile.

Well the answer: learning and performance management.

In fact, a major challenge is organizations are trying to move from a historical management approach that is highly structured and perceived as more safe to one that is less structured and perceived as more risky.

There are numerous elements that go into enabling employees and leaders to behave in a more agile fashion—and many of these elements are outside the influence of HR. To that end, HR should first establish a strong collaboration with senior leaders focused on evolving the organization to a more agile model before making changes to processes. Without this agreement, efforts by HR to increase organizational agility are likely to be mostly futile.

Assuming HR has this agreement, the question becomes, “Where should HR focus its efforts?” While many talent processes are important, our research indicates there are two levers of talent management that are at the core of enabling agile behaviours: learning and performance management

Learning enables individuals to anticipate changes as a result of constantly enhancing their understanding of the organization, its markets, and future opportunities and challenges. Further, learning also enables individuals to respond effectively and efficiently to those opportunities and challenges, if that learning can occur in the moment and in response to specific needs.

Traditional performance evaluations, which focus solely on individual performance, create a “chasm of disconnect” for agile team members. Because agile is all about team performance and trust, the typical HR performance evaluation system is not congruent with agile development.

Performance management enables agility by establishing clear goals and reinforcing and rewarding those who respond effectively and efficiently. If performance management does not reinforce the importance of acting with agility but instead emphasizes following the historical plan, then employees will not perform in an agile fashion.

Many companies shifting to Agile. But, most continue to use their existing performance evaluation methods! Agile organization with Traditional measurements will always behave and do the following:

• Rewards the wrong behaviours
• Creates/exacerbates the chasm
• Individual stature
• Promote myself
• Me first, team second
• Me versus everyone else
• Desire to become an SME

We like it or not, most executives love to measure and measure wrong things and have no linkage with the organizational goals and strategies. Most of the measurements in the SW industry has been due to the adoption of models and frameworks like CMMI and ISO’s of the world, which focus on the measurement driven system.

No, No, No, I am not against the measurement, but would have reservations against what is getting measured and why it is getting measured and the usage of these numbers in the system.

Measurements drive behaviour, why team measurement is important, what to measure, and what not to measure. Agile introduces tangible techniques for measuring agile team performance-end of sprint retrospectives, sprint and project burn down charts, peer reviews, and release performance reviews. To demonstrate Agile uses role plays to contrast traditional, dysfunctional annual reviews with agile-focused performance reviews. Take back practical knowledge, based on fundamental agile principles, about how to integrate team measurement techniques into your existing environment-whether the HR department buys in to this practice or not.

As Eliyahu Goldratt mentioned …. “Tell me how you will measure me and I will tell you how I will behave.”

It is human nature for people to modify their behaviours to match the evaluation system.

• A very important part of any agile rollout is to align the performance evaluation system (and other HR practices) with what Agile emphasizes.
• Not doing so causes dysfunction that will erode the team’s effectiveness.

As with any new approach, introducing an agile performance evaluation system will have its challenges:

• Resistance to change
• Fear – too revealing
• Deflates the general optimism
• Loss of control
• Cheese mover comfort zone, Etc.

Some final thoughts on this front ….

• It is human nature for people to modify their behaviours to match the evaluation system.
• A very important part of any agile rollout is to align the performance evaluation system (and other HR practices) with what Agile emphasizes.
• Not doing so causes dysfunction that will erode the team’s effectiveness.

Agile, But not Agile

I am sure that is post of mine would resonate with the readers with respect to that we are Agile, but Not Agile. The best part of the story is that most of the organization in India are doing something or the other in the world of Agile and trying to make their hands dirty with the concept and implementation of Agile.

Not sure if the organizations that have adopted Agile, have done any retrospective on their adoption of Agile, we expect that at the end of the iteration / sprint cycle, the team would perform the retrospective and learn from their practices that needs to be improved. Not sure why the same yard stick is not applied at the organizational level. The management expects all the principles and practices to be applied at the team level, but when it comes to its own application, they have washed their hands off

I am finding it very difficult in India for Agile to be practiced in true spirits, not saying that all organizations can be clubbed together, nor am I trying to paint the town red, but the real story is that in most of the places, I have not observed majority of the Agile Manifesto and Principles adopted and done in the true manner

Most of the people and the Agilist that I have met have given the impression of working with Agile and related stuff with the waterfall mindset. Not sure if the required change would come via this element / approach.

Speaking on the same, Lets discuss one of the principles of Agile …. “Customer and the Development Team should speak daily”, All of the agile methods require that the Customer (in this case the Product Owner) would be based at the same location as that of the team, but this is hardly practiced in real life execution of projects, due to the Onsite / Offshore engagement models, where the product owner is not located in the same location as that of the development team. Have observed practices such as proxy product owner, it is like complicating the matters beyond repairs, If the Proxy PO can do the job, then why have the PO? During my training and consulting with various customers, Have always heard that if we have any query to resolve with respect to the user stories, it is difficult, as we have nobody to bank upon, the queries are delayed, at times information is provided at the eleventh hour. This has its own impact on the quality of the deliverable that we make to the customer.

One of the other major issues faced by team adopting Agile and related elements in India is the changes that come in the sprint after the commitment has been done during sprint planning meeting. It is stated and given that no changes in duration or goals of the sprint, but this is not in place for majority of the organization. Every change has a cost, but agile does not account for this. The result? People often change really big things late in the game using the rationale that since it’s an agile project, it can handle it. This encourages poor and irresponsible planning while hiding its effects. As iterations / sprint continue and the defect list grows, the customer becomes more frustrated—not only because of the lack of quality, but because delivery expectations aren’t being met either. The only way the project can handle this is by adding iterations / sprints. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.

Remember, the goal is to deliver a quality product on time and to budget; as a rule, there are always some elements that have to be sacrificed to fulfil the needs of the others. It’s the How to Develop Next-Generation Scrum Masters / Agile Project Managers role of the project manager to define and maintain the project priorities so they can function as a decision framework for team members as they carry out their tasks.

Off-late I am in touch with a number of customer, who want to actually redefine the concept of Agile to suit their requirements and needs of working, well I see nothing wrong in this approach, but my recommendation is not qualify that we are following Agile, it is a misnomer, We are giving false impression and views to the world of our capabilities and understanding of Agile

People love certifications in the industry where I work. But when a particular methodology gets popular enough that a certification industry rises around it, organizations try to adopt that methodology without bothering to understand it. It’s as if certification replaces the need for thinking or experimenting. It becomes a check in a box: “We’re certified, therefore we know what we’re doing and you should hire us.” The primary focus becomes figuring out what you need to go to get certified; figuring out ways to actually improve productivity becomes secondary. That’s the problem I have with certification – I’ve seen it happen multiple times (and even been involved in it), but it’s particularly ironic with Agile development.

There’s a reason behind the demand for certification – it’s human nature to want a simple way of discriminating those who know what they’re doing from those who don’t (especially if you don’t either) – so I’m not sure there’s a good solution. In any case, I don’t have a problem with scrum training, just certification.

It high time, that we re-channelize our focus and energy to do the real thing rather than running after pseudo stuff ….. My prediction, Agile has lived its utility (though more than 70% of the IT industry does not implement and practice the way it should be done), We are now waiting for the next BIG wave to come in and that in my view would be DEVOPS