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

Matured teams – Do not create great Scrum Masters

Disclaimer – Not many may / would agree with the thoughts as expressed in this post.


A successful Scrum Master must lead by example, must have an open mind to listen to others. A good scrum master is the one who is able to visualize the future for the project and lead the team in that direction. A good scrum master has a deep sense of commitment to the project, its stakeholders and more importantly to its team, He should be a person with a lot of passion about the future. Guiding the team from the front in times of crisis. Scrum Master should be constantly encouraging his / her team to get the very best through his infectious energy and unwavering optimism

When you have a matured team, which has worked together for many products and sprints / releases, they start to develop understanding of each other’s behaviours, skills, strengths and areas of improvement. They have worked together for a longer time, they have good coordination across and among the team, They excel technically well and are producing the outputs as needed and required with quality built, In such a kind of scenario, Scrum Master would be relegated to back seat, as the process of Scrum would be typically on a cruise control mode. Having said this, I do not mean, that there would no issues / impediments to resolve, but they would far and few due to internal coordination of the team.

A matured team is excepted to have a climate of trust and openness, that is, a positive atmosphere. A positive atmosphere indicates that members of the team are committed and involved. It means that people are comfortable enough with one another to be creative, take risks, and make mistakes. It also means that you may hear plenty of laughter, and research shows that people who are enjoying themselves are more productive than those who dislike what they are doing. In such a scenario, the role of the scrum master is to provide minimal inputs, as the things are working
Trust is by far the most important ingredient of a positive atmosphere. Matured team members reach a point where they can trust one another. Trust and credibility can be described behaviorally. They can be seen in a more logical way than you might think. Consider this …. What do people need to do to build trust with you?

What came to mind first? Was it honesty? Dependability? Sincerity? Open-mindedness? For a tenured team, all these elements would already be factored in …

A mature team, by definition, also offers little room for bigger improvements and growth. Even if you succeed in making room for yourself in the team, it is difficult to find new processes and introduce significant innovations that push the team forward. This challenge also introduces a key benefit of entering a mature team with a strong, innovative thought process. However, finding new ways to distribute ideas or attract interest from the team is tough.

It is important for us to understand that going from ZERO to SIXTY is much simpler, easier and faster as compared to moving from NINETY to NINETY TWO percent, as the areas for improvement reduce and the smallest of improvement takes a longer period of time to implement.

The costs to enter a mature team successfully are usually high. It takes much more time, effort and energy to enter as a new minted Scrum master, because you have to establish a reputation and promote yourself to get team to understand you and move away towards a new thought process. You also have to invest in research and development to give team something distinct in your ideas and thinking.

The opportunity for the scrum master to demonstrate his or her skills in this kind of an environment, gets limited and this would reduce the elements of learning and improvement for the scrum master. It is important for us to realize and appreciate that rough seas, make skilful and great sailors, smooth seas would not, the same analogy can be applied to the Scrum Master scenario also. Grooming of an individual is also a function of exposing the person to variety of elements, situations, challenges and more importantly sufficiently empowering them.

When we have a new team freshly minted, there is a huge amount of opportunity for the scrum master to demonstrate and utilize the skills, as issues, knowledge, processes, approach would all be required to be explained to all , there would be high amount of coaching, mentoring opportunity available for the scrum master. Scrum Master in such scenario’s would be required to use his skills to the full potential, as the team is new to agile, new to this concept, may be working together for the first time, exposure of small deliverables and increments.

Many a times it has been observed, that post the training of certified scrum master, the person / resource is now supposed to act as a Full time, well prepared Scrum Master, it is as good as learning to drive by reading a manual. This thought process needs to change in the industry.

New Scrum masters may be paired with veterans. Innovations and new thought process should be encouraged. Different personalities, voices, values, and approaches spark interest, keep attention, and prevent boredom to the team also

A good scrum master should and always emphasize that all five fingers are equally important and each of them has a role to play in perfect synchronized coordination of any act by a person. The same hold true for the a good agile team

As we say in Agile, that the team should be allowed a set of time to improve, excel and learn new elements each sprint / iteration, the same logic needs to be applied for the scrum master also, We need to ensure that the scrum master also upgrades his skill sets at end each sprint.

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