TwoBadHabitsAllAspiringAgilistsShouldOvercome

Two bad habits all aspiring agilists should overcome

As an Agile transformation consultant, I regularly come across organisations that, despite their alacrity to transform team effectiveness, are often mired in a host of entrenched beliefs and habits that threaten to derail any concerted effort to effect positive change.

Indeed, before any Agile transformation can take place, it’s important that organisations assess their readiness from a cultural and behavioural perspective in as honest and transparent manner as possible. In this article, I’ll discuss just two of these pernicious habits and how organisations can overcome them effectively.

I can’t help because it’s not my job

Take this scenario: HR comes to software development asking for some basic training on a software tool or simply a comparison of software tools that could be used company-wide. Without even batting an eye, the software developer who receives the request states that HR should go to IT support.

For one thing, being Agile means that you never presume the intentions of others.

Now, on the surface, this response seems perfectly justified. Such types of requests may normally go to IT support, but in this circumstance, the software developer never thought to ask himself/herself why HR was approaching software development this time.

Was it a mistake, or were they looking for more nuanced assistance beyond what IT support may be able to provide? Indeed, maybe HR was approaching software development precisely because they wanted something they knew they couldn’t get from IT support.

So what should our software developer have done?

For one thing, being Agile means that you never presume the intentions of others.

Of course, sometimes a mistake is just a mistake, and you can leave it at that. But by assuming that, off the bat, you are clearly showing that the extent of your expertise lies solely with some categorised types of requests you receive.

The job scope presumption habit is toxic to organisational effectiveness and is one of the leading causes of the silo effect we see all too often within companies.

Instead of probing further, you cut off the opportunity for information radiation and continuous learning. So, in the case of our HR request, it could have turned out that HR was looking to justify a particular software development tool being used within the organisation, and not providing a nuanced answer from a software development perspective could have meant the loss of that tool.

The job scope presumption habit is toxic to organisational effectiveness and is one of the leading causes of the silo effect we see all too often within companies. Providing opportunities for information, and consequently, perspective sharing is critical to any agile transformation because it not only leads to greater organisational effectiveness but also can improve lateral thinking and brainstorming capability across departments.

What can organisations do to break this toxic habit?

Obviously, recognising and acknowledging it is a problem is the first step. As alluded to above, one option is to encourage more inter-departmental interaction either through project team formation, or simply, social gatherings.

Another approach is to have non-customer-facing staff interact with customer-facing staff during product brainstorming or marketing feedback meetings. Basically, anything that favours getting people out of their comfort zones yet still providing them with a safe environment to share ideas can help to break this habit.

Better I help you with that

Apprenticeship is a popular peer teaching method for information radiation and learning, but what if both peers have about the same level of experience? How does peer learning work effectively in that type of situation?  Oftentimes it doesn’t!

Depending on the personalities involved, things can quickly escalate until neither party wishes to work together.  This escalation can start with something as mundane as a request to complete something for the other party rather than attempt to understand what that person is thinking and then assist them along the way.

Remember that Agile is just as much about team productivity as it is about self-improvement.

Take this scenario for instance: two developers with about the same level of experience are working on separate user stories, but those stories affect the same UI functionality. The first developer makes a coding mistake and the bug is recorded by the tester. The second developer, being affected by that bug as well, goes over to the first and requests if she can fix it herself so that she can continue working on her story. The first developer interprets that as a slight on their coding ability and an argument ensues.

These types of situations arise all the time in development departments around the globe. So again we ask, what should our second developer have done?

Remember that Agile is just as much about team productivity as it is about self-improvement. In fact, you can’t have the former without the latter.

The Japanese Shuhari concept of stages of learning applies here as well. Being a team member means that you are aware that others are at different levels within their journey to mastery and that teaching is as much about imparting information as it is about learning what level of mastery others have reached.

It obviously doesn’t make sense to teach someone who is at a mastery level as if they were a beginner. Yet this crucial insight is what is missing from many conversations developers can have in the course of their workday. When we are talking about two individuals with near equal levels of mastery, the goal is for each party to understand what the other is trying to convey so as to improve each individual, rather than risk one party being condescended to. In other words, teaching is an opportunity for both parties to learn, not just one.

The “let me help you with that” habit is one that, if overapplied, can lead to a meltdown of team trust and stability. The correct perspective is to recognise that each team member is on a different stage in their journey to mastery, and that the job of peers is to further him/her along on their journey through insight and guidance, not impatience. Teams can foster this attitude through pair programming with experienced Agile peers who understand this learning dynamic and can serve as a role model for others.

 

Angry young man image courtesy [email protected]





There are no comments

Add yours

This site uses Akismet to reduce spam. Learn how your comment data is processed.

x
freshmail.com powered your email marketing