Tips to mess up your Agile Transformation / Adoption

We, for ages have been attending a lot of workshops, trainings, getting coached, reading a lot of material on the internet, wherein all of them are providing guidance on how to implement / adopt the right and the correct practices of agile / scrum / Kanban.

My blog today is a high level summary (not all points) of anti-patterns for everything that the world is preaching, teaching and more importantly NOT IMPLEMENTING

My guidance would help all the organization and respective managers to know and learn how to mess and manufacture a disaster for their agile ways of working.

We all know 3 important roles in Agile or should I say Scrum (in specific) – We shall today take the most neglected role of Agile – “THE PRODUCT OWNER”

Off-late watching and experiencing the world and the behavior with the product owner, I have become more educated on ideas, thoughts and tips to mess around with the role of Product owner and thereby understand methods and ways in which the value of Agile adoption goes / can go down the drain.

Fasten your seat belts, Here we go …

TIP # 1

Never Empower your Product Owner: Giving power for decision making to a product owner could be injurious to the health and wealth of the Line Manager / Sr. Manager. Always tell the PO what to do, how to do, ask them to document each backlog item with every possible scenario (in the same PBI – even though the PBI would now qualify to be a large feature or an EPIC by itself).

Never give liberty to the PO to decide how to maximize the value of the product, the order of the product backlog items, making their only job is to do documentation of the requirements in complete fashion / manner as we desire, they should not be able to move an inch without our approvals. We are more interested that our PO act and behave as SCRIBES … rather than as Product Owners.

If you do what I am recommending here … Bingo you have achieved Level 1 Maturity of Messing up with the agile ways of working …

TIP # 2

Have your PO also double up as Scrum Master: Well every organization that I know is always short of right resources and talent. If one FTE can double up and do the job of two, nothing like it – a bird in hand is worth two in the bush. It would always help the team as they know they have to look up to one person only and it saves a few dollars of the table (nothing like saving money), it prevents challenges and issues or managing the expectations of 2 people, conflicts are reduced (as we have 1 person only – never heard of a single person is having conflict with themselves).

If you implement and adopt this approach as recommended here … Bravado – you have achieved messing up with Scrum Guide itself … and that deserves kudos and a bravery award to those who take, implement such decisions.

TIP # 3

Have a Proxy Product Owner (who is powerless): Our true North Star “THE PRODUCT OWNER” is across the oceans and in those time zones, that is difficult for any sane person to be wake and sit late at nights and interact with the team (when the team is working). Every problem has a solution and this case it would be to create a replica of the actual product owner in our own location and call them as Proxy PO’s (well we have just introduced a new role in Scrum – Who cares of the Scrum Guide).

Using a Proxy PO is an attempt to superficially treat a systemic issue and push the actual problem below the carpet. One should never allow the Proxy PO to take decisions, they are like glorified Postman / Post Woman here … they only have to take orders from one side of the coin and communicate (with gaps of course) to the other side (aka Development team).

In case you implement and adopt this approach as given above … You have installed insecurity, confusion which effectively breaks down communication in Agile, well who cares for Agile Manifesto statement… Individuals and Interactions over Processes and Tools

TIP # 4

The Partial Product Owner (Allocated to more than 2 teams): One nice way to making our product owners ineffective is to give them multiple products / projects to take care of … So that more than 50% of their time will be spent in doing Scrum events (Sprint planning, Sprint Reviews, Retrospectives and so on …) across all the teams, they should never get time to do quality work on the Product Backlog, think about prioritization and ordering of PBI’s or discussing important elements with relevant stakeholders or end-users. Always work with the approach that – we shall cross the bridge when we come to it.

If we have created such situation, we are at the prime of not messing one but multiple projects, we have actually graduated in our approach and thought process and we deserve a pat on our back

TIP # 5

The Over worked Product Owner (working for more than 14 hrs / day): Working in normal times would get you a rating of 3/5 in your appraisal system, which states – Meets Expectations. These days all organizations need people who would work beyond the normal hours. We have unrealistic deadlines and commitments. Management and Sales folks make an unachievable commitment and then the development team (along with the PO) has to deliver … in order to do this we have to work beyond a normal timeline or cut corners – we end up doing both.

This results in Technical Debt, Poor quality of product and services, dis-satisfied team and unhappy customers – but guess what – we are hitting the clock more harder than before …

If your products / projects have managed to have this situation, then we should be proud of our achievements, any-which ways client and management do not understand the concept of Technical Debt (so it is cool and fine).

Conclusion:

I believe these 5 tips are great source of Anti-Patterns (should I say – Industry ways of working – Anti Pattern would sound rude). If you want Agile to be messed up, use these ideas (they are free and no copy right issues – you can take and update them to be become more fancier).

Nothing that I have said today, is new or rubbish – it is actually practiced in our world by all the agilists – who have great certificates and knowledge, but we buckle under the pressure of having a job, regular income, management, peer pressure and so on …

For ages I have failed to understand why management wants to spend money and hard dollars and still not receive value … well the answer lies that nobody wants to implement AGILE. It is just a buzz word in the system.

If you believe in doing the things right and in the right approach, follow the reverse of all the tips given here … you would notice a more productive, safe, guilt free implementation of Agile.

Try for the true Agile for 4-6 months – do it in the true spirit of the game … if you still do not see results … go back to your old ways – nobody would stop you (anyways nobody is stopping you today also). I would be coming out with such blogs as a series on all roles of Agile / Scrum and then move to events and outputs.

How to manage sensitive issues in a team – What is the magic recipe?

Have we ever wondered how to handle and deal with a sensitive issue with our teams? How do we bring our observations that certain set of folks always like to dominate the discussions in all teams? How do we talk about the teleconferences always scheduled at the time which is most convenient to the Onsite team or where the management of the team is positioned? How do we mention that the team is caught in the group thinking mode and agreeing to poorly conceived decisions for the sake of team harmony?

In your role as a team member or the leader of the group, there are times when you need to bring up sensitive issues within the team, you should always begin with the self-awareness that something of relevance to the team’s functioning is occurring. You need watch and assess what you noticed and observe its impact on yourself, the other team members and team at large. You need to decide whether you should intervene or not, whether it should be dynamic? Will that be more helpful or harmful or not relevant at all.

Let’s assume you have decided to raise a sensitive, touchy issue in your team. To review how you arrived at this point, you need to pick the functioning of the team, the pattern observed. Your goal should be to get the team to explore the issue for its impact and decide what to do based on this exploration. How can we raise this issue in a way that is most likely to accomplish the goal?

Some interesting fundamentals are necessary for basic human relationship:

First talk about yourself, your feelings, your behavior, Make statements with ”I”: “I am thinking”, “I am feeling” … something on similar lines. Self-disclosing your own reaction to what’s happening is always the safest way to begin wading into potentially troubled waters.

Second, avoid using words that are pejorative, inflammatory terms, judgmental labels and generalizations, such things trigger words or phrases that flare the team members defensiveness and make it hard to respond for them to your comments.

There are 2 strategies, that I have experienced for making a decision on the level of focus and intervention. One is the “Deep end of the pool” approach. Intervene where you think the action is the hottest, if the whole team is caught in the groupthink act – supporting, agreeing and reinforcing with each other at the cost of in-depth investigating the issue on hand – jump into the deep end of the pool and say things like: “I think we are sacrificing the quality of our decisions for the sake of getting along and it makes me uncomfortable”. If you find one person dominating the discussion, it is just fine to say “Ash – it seems to me that we have been hearing mostly about your ideas on this issue, I would like to hear some of the thinking from the rest of the team”. This type of direct approach is likely to get the issue recognized and discussions going but it can’t be carried off comfortably by everyone, nor in every situation by anyone.

A different approach would be to focus where the action is less hot, the “shallow end of the pool”, once you have the team in the waters with you, you can begin to navigate them into the deeper side of the pool. You might like to create an individual focus like “Sam, I have seen you have started to something couple of times, but stopped and I am wondering if you have a different view or perspective on the issue that we are talking about”, Or the approach could be focusing on the team level directly and say “I think we need to revisit our team working agreements about how we handle conflicts between us”

Another factor to consider about raising the sensitive issue is the degree of intensity you want to build into your intervention.

Low intensity usually takes the form of carefully worded statements. This style helps to understand how an issue is dealt by the team and how they respond.

A moderate intensity usually consists of an observation followed up with a question, such intervention declares an issue and press the team to respond to it.

High intensity intervention really put pressure on the team, they usually consist of an observation and interpretation of the cause of the pattern observed. They are high intensity because they label the action with an interpretation of the underlying dynamics, their directness at times can be shocking to the team.

The point is that regardless of the type of intervention you are most comfortable with, you need to be able to effectively use all combinations, so you can match your choices to the contextual demands in the team at the time you are intervening

Teamwork – The ultimate approach to succeed

I am writing this blog, as I watch the World Hockey League Finals (India vs. Australia). It is a classic game, where the coordination, anticipation of the team members is required, one needs to know, when to pass the ball, whom to pass the ball, which would result in team work that is of utmost importance, it is a game of 11 team members (how cool, even Scrum team’s maximum size is also 11, 9 development team members, supported by Scrum Master and Product Owner).

No vision or strategy or technology can help an organization meet their operational goals and business objectives, if teamwork is not in place. Team work remains the ultimate competitive advantage for any organization to succeed and delight their customers. With this fact known to one and all, not sure, why it is the most neglected element of the system, we are all focused on productivity, velocity (oh this can be gamed). If you could have all the employees of the organization align and work towards the achievement of the vision and move forward in the same direction, one could rule / dominate any industry, in any geography, any market against any competition at any time.

For all the attention that this topic has received over the years from Guru’s of various industries and from the Agile Guru’s since last 2 decades, it is still one of the rarest commodities in any company. The fact remains that teams, because they are made up of imperfect human beings are inherently dysfunctional. It is not to say that is a doomed concept, but building an effective team with synergy and ethics in place requires patience, trust, empowerment and time. Building great teamwork is both possible and simple, but is painfully difficult.

Team members should remember that they would get respect or recognition not because of their individual brilliance or degrees each member would carry, but because they would have performed well as a team and delivered the desired results.

Managers and organizations should realize that building a team is like building a delicate eco-system of powerful force. It needs to be crafted with strategy and care and every piece counts as it brings you closer to the vision of your company. I believe that people join an organization and its journey to do their best and perform at their own peak. So as a Scrum Master your role is to trust them, provide them with safety net and be their cheer leader as they grow. A motivated work force can do wonders.

Effective teams don’t originate randomly. They are the result of Scrum Masters who lead by example and build healthy habits into the team’s dynamics. But sometimes things happen outside of the Scrum Master’s control, and some problems are harder to spot than others — a lack of diverse perspectives on a team, for example, means a team may be too comfortable to innovate.

All teams, even the great ones, often face challenges, periods of time when everyone finds it harder to work together effectively to create splendid work. There are several ways a team might become dysfunctional and usually, there are multiple reasons. Contributing factors might include burnout, personnel changes, a loss of key people, or unexpected changes in the market.

Let’s be clear, dysfunction refers to a deterioration of performance, inability to perform effectively as a team.

What are some signs your team could be nearing dysfunction? If you can recognize the symptoms of the problem, you can take steps to get your team back on track.

A Communication Breakdown 

A breakdown in communication is a clear sign of team dysfunction. It can manifest itself in sidebar conversations, low morale, decreased engagement, and even workplace bullying. The first step of a Scrum Master is take to the correct course to gain a clear understanding of the challenges — and its team members.

Absence of Trust 

Trust is the foundation of all successful teams and the absence of trust is a roadmap to dysfunction. Teams that don’t trust each other assume negative intentions, dread spending time together, and don’t ask for help from each other. Scrum Master should start cultivating trust by creating a culture of vulnerability, rewarding honesty, and most importantly, leading by example.

Unresolved Conflict 

People working together on teams will have conflict. However, if they don’t seem to be working it through and are holding on to resentments, it will lead to a failure to perform. Some signs to watch for: missing deadlines, gossiping, forming of cliques, complaining, and sub-par work products. Scrum Masters need to be watching for early warning signs and intervening as necessary.

A Mass Exodus of Talent 

If your turnover is very high, something is dysfunctional within the team. It could mean there is a lack of trust, the culture is oppressive, or the pay is not competitive. Create a formalized exit interview process to capture the sentiments of exiting employees and use this data to create change within the organization. Schedule regular employee meetings to assess needs and build engagement.

Withdrawal 

As teams turn dysfunctional, members start to withdraw — often before they’re even aware they’re doing it. They’re just not as invested in the process or the outcome. Scrum Master who sees less creativity, enthusiasm and communication needs to re-engage the team. Share project ownership. Help team members see how they each strengthen the team. Be generous with positive feedback.

Becoming Too Comfortable 

Teams become comfortable. Instead of diverse ideas, they “Groupthink.” This is ineffective. Productive teams need multiple perspectives. Team members must understand distinct roles, and respectfully challenge others. When teams “Groupthink” they avoid debate to the detriment of the team. Scrum Masters  can remind the team of their roles, review why the team is in place, and explain how it can best operate.

Lack of Decision-Making 

The inability to make decisions reflects the lack of cohesion and trust within a team. Conflict over decisions builds cohesion and transparency. When teams are stuck, they fail to move forward. Decisions are delayed, accountability is reduced due to lack of buy-in, which leads to delays, low productivity, and low morale. Lack of decision-making is a symptom of dysfunction and impedes all team progress.

The role of the Scrum Master – In Team building

One of the most difficult challenges for a Scrum Master would be to instill the concept of accountability in a team. At times strong Scrum Masters naturally create an accountability vacuum within the team, leaving themselves as the only source of discipline, this creates an environment where team members assume that the Scrum Master is holding others accountable, and so they hold back even they see something is not right.

Once a Scrum Master has created a culture of accountability on the team, however, he or she must be willing to serve as the ultimate arbiter of discipline when the team itself fails, though this should be a rare occurrence. It must be made clear to the team that accountability has not been relegated to a consensus approach, but merely to shared team responsibility, and that the Scrum Master would not hesitate to step in when it is necessary.

Perhaps more than with any of the other dysfunctions, Scrum Master should set the tone for a focus and result oriented approach. When the team members start to sense that the Scrum Master values anything other than the results, they will take that as permission to do the same for themselves. Scrum Masters must be selfless and with goal oriented mindset with success as the only target.

Success is not a matter of mastering subtle, highly bookish theory, but rather embrace common-sense with uncommon levels of discipline and persistence.

Interestingly, teams succeed because they are human, by acknowledging their imperfections, members of the team overcome natural tendencies that make trust, conflict, commitments, accountability and a focus on results so elusive.

I am yet trying to understand as to why organizations find it difficult to create an atmosphere where teamwork can flourish.