Parenting and Agile Team – A Case of similarities

There are only three things you need to be a good parent – patience, patience, patience. What about love, affection, attention and other such things, you’d ask. Sure, that’s important as well. But while those things, in most cases, come naturally, patience is something that needs to be cultivated. The lack of patience leads to stress. Stress leads to frustration. Frustration leads to anger. And anger leads to bad parenting.

Now think about this in terms of developing a matured Agile development team and you’ll realise where this column is heading. Parenting and developing a good matured – self-disciplined Agile team are both long-term processes. The immediate effects of any decision that you take are rarely satisfying, but the long-term results can be copacetic if you have the patience. Ironically, you need to be patient to cultivate patience. And that is not easy. The developing teams, much like your children, will behave erratically. They’ll do things that are out of your control. The more you try to be patient with them, teams as well as children, the more they’ll make you lose your patience. It’s a vicious circle.

But there’s no way around it. If you lose your patience, you lose the chance of enjoying the fruits of your efforts. Somewhat similarly, to young one who would behaves like an angel on some days but on other days, they won’t eat her food properly, will throw around their stuff when one has guests over or just be unrelentingly stubborn about something they wants. Such instances are when parents easily lose their patience. But scolding or smacking the kid is hardly the solution. Just the way stopping your teams when the process will fail.

These are decisions that are taken under the influence of impatience. They’re almost guaranteed to fail. I know children aren’t going to become the best-behaved young one in the world if I scold them, but they might listen to me if I calmly keep telling them why they should or shouldn’t do certain things. Whereas Agile teams are expected to have a mind of their own (as they are supposed to be self-disciplined and self-managed), which makes it even more futile to lose your patience with them. Just stick to your approach and plan and you’ll be set to meet your goals and objectives. The agile team’s misbehaviour won’t matter in the long run, but any decision you take after losing your patience will.

But there’s no way around it. If you lose your patience, you lose the chance of enjoying the fruits of your efforts. Somewhat similarly, to young one who would behaves like an angel on some days but  objectives. The agile team’s misbehaviour won’t matter in the long run, but any decision you take after losing your patience will.

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.

My grand daughter, who is 5 year old, operates my Samsung note better than me. Contemplating on why is it so – I spend almost couple of hours on note everyday myself – I realized that what makes her better is her childlike curiosity.

This curiosity to learn something new, day after day, every day.   When was the last time you learnt something new?  When was the last time you took a conscious step towards self-development? Curiosity to learn something must be backed by an innate desire to improve oneself, to become the best version of ourselves. It is the only way to remain relevant in the hyper-competitive markets today.

The same concept should be applied in the Agile projects, we are always running after getting the user stories done and churned out for the product owner. Yes, this is required, but one should step back and take a different view, are we learning anything new, have we added value to our existing knowledge base, are we much better skilled as compared to the start of the sprint, can we proclaim that we now know a trick or two.

When speak of adding value to our customers, shouldn’t we not add value to ourselves, as we are the first customers to ourselves

We always talk and speak about the improvement in velocity and team work, that cannot happen automatically, the organization needs to invest in this area, by providing and allowing a time-box element to each and every member of the team, I recommend a time-box of 5-10% of the sprint time allocated to each team member of the development team (on a different thought, it should include the scrum master and the product owner also). If the sprint cycle is 2 weeks (10 days = 80 hrs.), then the minimum time-box would be 4 hrs. / sprint to a maximum of 8 hrs. / sprint.

Organization should be aware that providing this time to learning and development will reduce the velocity in near term, but there would be major impact in terms of quality, knowledge gain, productivity improvements, team collaboration.

This time allocation should be used by the team members to improve their skills in any area of their interest, which would ultimately help the product to develop and grow better and thereby improve the required velocity. It should be the task allocated to the Scrum Master to ensure that all the team members are using this time-boxed element in the most productive way. One also needs to understand that a Scrum master would also be required to improve and master the skills that are important to the role that he / she is playing to.

Each sprint , the team should have a dedicated time and name it as – ‘Learning with Agility’.
• Define a dedicated time slot. It would be a good idea to have a time slot of 4 hrs planned in the early part of the sprint cycle in week 2
• This week, every sprint, learn a new thing – pick up a functional skill from a colleague, or improve the product knowledge, master an automation tool, learn new elements of coding (do a little unsaid spike)
• learn about a behavioural skill

Learning is not about mastering the hard skills, it includes all those elements that make you a better team member, a team player and more so a better person

Your learning is in your hands and you are the product owner of the product that is you. Take advantage of the fact that you spend 8 hours every day most of the week in an organization that promises you learning opportunities. You have, at your fingertips, access to a whole host of behavioural learning through social media , hundreds of thousands of articles in web, , ride the huge wave of Massive Online Open Courses with the many courses that are available online freely – make use of all these resources to better yourself today.

The above mentioned are but a few of the avenues for learning. Such platforms are present everywhere – the internet, libraries, even in day-to-day interactions with colleagues, it’s you who has to take the first step.

At the risk of re-iterating, I’d say again – that the onus of your learning lies with you. No one can help develop you but you yourself. This week and for the ones to come, promise yourself a week full of rich learning.

The day you stop learning, is the day you stop practising Agile ….. So Learn each day and be agile every moment