Leading Dispersed Team – An Art or Science or a piece of Luck in your journey of excellence

Dispersed teams have members who are not in the same place, they come from different countries, cultures and time zones. Simply out, a dispersed team brings out elements where human-technology interactions, teamwork and communication among people separated by time, culture and distance. Dispersed teams have started to gain importance in organizations because of influence of international markets.

Coordinating the efforts of team members across differences and at the same time maintaining and boosting team effectiveness make up the challenge of leading a dispersed team
By default all successful teams need to be well designed, that would include purpose of the team, building project management expertise, defining clear roles, setting clear and crisp direction towards completing the work as planned or assigned.

Team work and trust both are important facets of building a great team and dispersed team is no alien to this concept.

Some elements to be taken into account would include:

  1. Keep the team informed of long-term organizational changes
  2. Ask the team for input on critical organizational issues
  3. Encourage personal contact and communication among all team members
  4. Hold face to face meetings (as much as possible and where required – Not do compromise

 

Dispersed teams require more direct and careful maintenance than local teams to reach their potential, for example one advantage of dispersed team would be working around the clock and thereby serve the customer with a greater degree of efficiency and effectiveness. Dispersed teams can be a richer source of innovation than a local team, Insights from team members / colleagues around the globe brings new dimensions to the work, influence how the product would be developed and delivered to the client.

Dispersed team should be encourages to:

  • Learn new communication approaches and technologies
  • Get exposed to new ideas and learning methods
  • Learn about different cultures
  • Develop capability to resolve problems in a 24 x 7 model

 

There is decent amount of challenges in managing a dispersed team:

  • Becomes more difficult to schedule common meetings
  • Identify overlapping hours
  • Robust infrastructure problems in effective communication
  • Members do not feel aligned to Org goals
  • Members feel or have not authority for decision making, too much politicking with internal stakeholders
  • Overall project management would be difficult

When launching a dispersed team, take care of the following:

  1. Assess the readiness of the organization to work with dispersed teams
  2. Create a goal / vision – communicate the vision
  3. Kick off with a face to face meeting (a take photograph and share it with the team)
  4. Plan how communication and Information sharing would happen
  5. Usage of standard tools and techniques
  6. Define cadence for meetings and other schedules
  7. Are there HR policies in place to deal with dispersed teams
  8. Kind of infrastructure required for effective communications
  9. Plan PTOs
  10. Identify local holidays and events and plan for them in the cadence
  11. Give authority for local decision making
  12. Are lower level employees empowered for decision making?
  13. Define approaches for conflict resolution
  14. Regularly recommend a get together of the whole team
  15. Approach to introduce new member to the team? – The How part?
  16. Develop guidelines for conflict management – Remember it is not one size that fits all
  17. Make space for cultural differences, respect all local rules of the game (still keeping the big picture in mind and view)
  18. Ensure you appoint a team member across location for logistics coordination / technology coordinator

Identification of team members to work in dispersed teams:

  • Team member would be willing work in a team environment
  • Are good self-starters and are self-directed
  • Are highly motivated
  • Have tolerance for the unexpected
  • Are open to experimentation
  • Are curious and exploratory
  • Seek out relevant information
  • Are willing to learn and un-learn
  • Are willing to play multiple roles (when the demand arises)
  • Are careful listeners
  • Are risk takers
  • Can build upon ideas of others
  • Enjoy working collaboratively

There is no standard recipe for a successful dispersed team, one would have to inspect and adapt, Issues will be there, it is how you respond to these issues, that will make or break a dispersed team concept successful or …

Reverse Mentoring … Time for the Old Dog to learn some new tricks of the game

I own a new Samsung Galaxy S8+ phone which was recently purchased. It is a struggle to understand and get used to the  new settings and features. Where do I go to solve my issue, where can I seek the answers to my questions? I had no clue until my daughter came to my rescue to solve the current issues on hand and explained me how to use the gadget. This led me to thinking that over the years I have been coaching / teaching / explaining her different things and now she is becoming my coach / mentor / problem resolution person. She is my go-to person for the phone at-least.

Do we all face or have similar kinds of situations / problem at our own work place / organization? To larger degree Yes, but we all fail to recognize the issue and its relevant impact. We do not want to acknowledge our own short comings as they would show us in bad light and put our own experience to shame.

What are the current market demands? What is the organizations expectation from myself … well we all need to understand ……

  • Larger and more global organizations function
  • Impact of changing global economy is relevant to our work
  • Leaner organizational structures, less is more
  • More dynamic labor markets
  • Increased importance of human capital (well that is the only raw material one needs in the system)
  • Enhanced leader pipeline to offset demographic trends
  • Growing leadership capacity
  • Developing strong leaders

Organization have a decent budget for their L&D department, who are in turn tasked to upgrade skills of their current employees or make them more deploy-able. Many companies try to increase diversity with earnest training sessions. Has this ever-going experiment yielded results? What is the ROI that the L&D team can show? Is the budget really justified? No, I am not against the training’s / workshops conducted (well that’s my own bread & butter), but I am questioning the method and the way the money has been spent.

If one see’s the trends and graphs of the L&D, there is hardly any sessions / workshops planned for the Leadership team. At times, the argument is that LT does not have time available to attend these sessions, if they do not have time for improving their own productivity, which in turn impacts the whole organization, I always wonder, how could they improve their own business unit or the organization and take it to the next level.

How do we overcome this issue?

Well the solution is “Reverse Mentoring”.

Reverse Mentoring is a novel concept that is gaining popularity in today’s fast-paced, tech-savvy world. Have you ever wondered what reverse mentoring is all about? Here are some answers to a few frequently asked questions on reverse mentoring.

Reverse mentoring is an approach that acknowledges everyone in the organization brings something to the table. Reverse mentoring partnerships generally include an older, more experienced executive with a younger, less-experienced newcomer. As the name suggests, the younger employee serves as the mentor. Yet, reverse mentoring is indeed a two-way street (at times this can be hard to digest for the senior folks in the organization, how can a junior coach me … well this is the mindset that needs to change)

On one hand, reverse mentoring gives Senior folks an opportunity to stay up-to-date with the latest business technologies and workplace trends. On the other, it helps junior employees see the larger picture and gives them a glimpse of macro-level management issues. Reverse mentoring also increases retention of millennial employees and gives senior executives the satisfaction of sharing their knowledge with the next generation. It increases multi-generational engagement and reduces conflicts between generations in the work place. More importantly, it is not a one-way traffic.

At one of my own customer, they started a reverse mentoring program, the aim was to train CXO in the tools and culture of social media. With entry-level employees in their twenties as mentors, the business leaders soon began to appreciate the power of “searching” for answers on the spot, and they wanted others in the company to benefit from the same flexibility. As a result, social networks that were previously off-limits to company employees were now unlocked. It also helped boost morale and retention of younger employees at the firm

How do we implement Reverse Mentoring @ our work Place?

Well here some ideas and thoughts to start with …

Identify / Find a perfect match

Reverse mentoring involves two people with extremely different experiences, backgrounds and cultures; therefore, creating the ideal mentoring partnership is vital. Choose mentors who possess good social skills and have the confidence to interact with and teach senior management.

Set a level playing field

Start the reverse mentoring program with a fun and informal orientation. The orientation should give the mentors and mentees an opportunity to interact with each other as individuals – not as the boss or as the newbie who is fresh out of grad school. This will set the stage for the entire program and in time help erase traditional hierarchies.

Set specific formal goals but allow space for individual innovation

It is important to list out what the reverse mentoring program aims to achieve in general, for all participants. However, each mentoring partnership is unique. Mentors and mentees may also enjoy and benefit from helping each other in ways not defined by the program. A young mentor might help a C-suite Exec on how to use the gadget or a CEO might share tips on how a new entrant can advance his / her career. So, factor in the need for informal goals to be met as well.

Consider program automation

If your program has many participants, consider using software to help run your program. It can help you make mentor matches, track progress, and report on results to help you measure program ROI.

Track and Measure Mentoring Outcomes

We always say, measure, measure, measure! It’s the only way to determine what your results might be and prove to senior folks that the program is working. The key to this is determining what you’ll be measuring. Something like employee satisfaction, while nice to have, probably won’t be enough to prove the importance of your program. I suggest focusing on tracking metrics like retention of employees who participated in the program as compared with those who didn’t. Of course, it’s also important to track other information too, such as changes that are happening because of the program and positive feedback, especially from the higher-ups who may be getting mentored for the first time in years.

Reverse Mentoring – A Key Component of Cultivating a Talent Strategy

Remember, reverse mentoring is just one aspect of a comprehensive talent strategy and it’s important to build that out. Comprehensive talent strategies are imperative for refining and retaining employees. They are beneficial in providing both a clear path to success for employees, as well as cultivating successful long-term employees. Research finds that organizations that perform well on business outcomes have a talent strategy and we do hope that you’ll implement reverse mentoring as part of that.

Concluding thoughts …

Reverse mentoring is an innovative use of mentoring. It emphasizes the idea that learning never stops while supporting the idea that the young have something to teach, which is why we see so much interest around it. Consider implementing at your organization to support your talent development goals.

Reverse mentoring puts a face to a concept—it’s easier to ignore a slide show than the compelling young person in front of you.

Now come to think of it, can this be applied in Scrum Teams? Why not, can the Scrum Master learn innovative ideas, thoughts and concepts from a fresher in the team?

Will the Old Dog (Scrum Master) be ready to take a leap of faith and trust the team members to move its own career ahead?

Should I remind that it is needless to, that we need to inspect and adapt (Agile should be a part of our DNA by now).

Influence – The only tool that a Scrum Team needs

Influence is an essential component in any project, organization or relationship. At times in Organization or in a project, your position in the system is not sufficient or adequate to motivate people to do what you need / ask or want. Influence is the key solution to this problem. Developing your influencing skills can help you gain commitment from people at all levels in the organization or a project.

Leaders are often challenged in learning this skill on how to influence different & diverse set of stakeholders. One cannot apply a single standard approach or technique, even with the same stakeholder, with different situations the techniques would be required to be changed or modified. Knowledge alone is insufficient, but it reminds leaders that positive results often depend on variety of different influence tactics.

By considering whom you want to influence, one can settle for a tactic that is likely to produce the best results. Reviewing the outcome of those events creates an opportunity to learn from experiences and to become a more influential leader and a more powerful contributor to your organization’s / projects on-going success.

People forget that Influence has more power than formal position in an organization or a project.

Speaking about Scrum teams and the 3 roles it has. Each of the role is a leader in their own rights and approaches, each role brings different flavors to the table, each of them requires to possess this skill of influencing to have the work completed.

For example, Product Owner would be required to influence the stakeholders, business users on which PBI’s to be prioritized, what business value it would bring as compared to the other items on the backlog, On the other hand the PO would also be required to influence the development team on adopting his / her strategy or agree on the order of development. In the entire contrast the development team would have to influence the PO why a particular item should not be prioritized for the current sprint (could be due to technical issues or dependencies with other PBI’s or dependencies with other Scrum teams), development team should also exercise the idea of influencing the Scrum Master to help understand which impediments requires more urgent attention of theirs as compared to the others or how a process should be adopted based on their teams requirements. Development team needs this tool most during estimations of various PBI’s (when the entire team is supposed to estimate and come to a consensus to a common ground or a bare minimum agreement that all of us can live with or atleast nobody is opposing it, though it may not be their 1st choice).

Coming to the last character of this play i.e. Scrum Master, well this one must influence the PO, the team, stakeholders, sponsors, business owners (where and when required), the strategy of influence would change depending on the role that needs to be influenced. SM should and must influence the PO to emphasis the idea on how to maximize the ROI from the development team, or Influence the development team on an approach, idea or a new concept to be experimented.

At times, due to business exigencies PO may be required in the middle of the current sprint to change a PBI item (yes, this goes against the Agile principles and values), this is a place where logical discussions (with the development team) take place and discussions have to be more of influencing (in nature) and selling the concept of why a particular PBI is more important and how would it hurt the business if not done now.

Sometimes during sprint planning meeting, when the development team has a little bit of spare capacity, it needs to influence the PO to not push for more PBIs but allow them to focus on technical excellence or reduction of technical debt or refactoring the code / design or spending a few available hours to learn a new feature or experiment something that can be of larger use to the system / project later.

What power cannot achieve, influence can. It is a tool that should be used instead of power, it also shows the influencer’s ability to motivate people / resources to act according to a given situation or the respond to an issue in desired manner (which otherwise would not be the case).

We all influence the other party (or a person) to act in your favor or bring them to the alignment of your thought process

There is no dearth of ideas / situations where this influence as a theory can be applied to get the desired results for the success of the project.

Influence as a strategy to be successful requires, the influencer to understand the psychology, social psychology and dynamics of human politics, Technical competency are no longer enough to succeed. It is important to note that you cannot influence what you do not understand.

Influencing as a strategy would work, when you start to identify your own personal values and that of others. Each situation of influence one faces is circumstantial and this is a dynamic process and which would require to judge the factors (on ground and as per situation).

The following are the recommended steps to be followed:

  • Preparation (Intelligence gathering, mental preparation)
  • Pleasantries (rapport building and management of impressions)
  • Position (reaching a common understanding of the current situation)
  • Problems (Coming to an agreement about the issues associated and build a case around it)
  • Possibilities (Not locking yourself to a single approach / solution, but negotiating around a range of possibilities, create a sense of joint decision-making process)
  • Preference (By explaining your thoughts and ideas, you seek you get agreement on specific action that should be taken)
  • Proposals (Skills of persuasion required, appealing to both logic and emotions, showing at times assertiveness in stating what you want and to build the proposal collaboratively)
  • Proactivity (leading the other person / party to take action and getting commitment to proactive positive action)

Finally; a word of caution: Influencing comes with a theory of adaptability.

As we say in Agile … Inspect and Adapt …

Common mistakes that Scrum Masters make when giving feedback to Scrum Team Members

How many of us give good and consistent feedback to the people / teams that we work with? There would a handful a people who put their hands up for the question above. Why so few? The reasons are varied: It is hard to do; I am afraid I will say something I will regret; People get emotional when they hear things they do not like; It will mess up with my relationships. All of these concerns are valid; but the all stem from the common mistakes that people make when giving feedback:

The feedback judge’s individuals, not actions.

This is the number one mistake people make in giving feedback is putting it in judgmental terms. If the Scrum Master says to someone “You were to abrasive” or “You need to a better tea, player”. This is judgmental feedback, by the time these words are received by the feedback recipient, He is already thinking “Who do you think you are calling me abrasive”. The energy spent in defending themselves from your attach defeats any chance of having a meaningful conversation

The Feedback is exaggerated with generalities

Another key mistake is using language like “always” or “never”. Hearing these words people naturally get defensive as they can remember plenty of times when they did not do what you claim they did.

The Feedback contains implied threat

Telling someone her job is in jeopardy (“Do you want to be successful in the organization or the team?”) does not reinforce good behavior or illustrate bad behavior. It only creates animosity

The Feedback uses inappropriate humor

If giving feedback is uncomfortable to you, or if you sometimes speak before thinking, you might use sarcasm as a substitute for feedback, But saying “Good Afternoon” to a colleague who is ten minutes late for a morning meeting doesn’t tell that person how that behavior affected you or provide reasons to change that behavior

The Feedback is question, not a statement

Phrasing feedback as a question (“Do you think you can pay closer attention during our next meeting?”) is too indirect to be effective. It may be also be a interpreted as sarcastic, or rhetorical, to which the recipient may respond with indifference

One can avoid common feedback mistakes by learning how to communicate important information about the performance to colleagues, peers or superiors in a way what you are saying and helps them identify ways in which they can improve. During the course, of giving feedback to various people and system, have developed a new technique called as “SBI – Situation Behavior Impact”.

Using this concept of giving the feedback, the recipient can more easily see that action he or she can take to continue and improve performance or to change behavior that is ineffective or even an obstacle to performance.

SBI technique is effective because it is simple and one while giving feedback, they describe the behavior you observed and explain the impact that the behavior had on the system or the team or the project.

Be Simple, Direct and Effective – Learn these 3 step and practice them regularly.

Remember capturing the situation is only the start of the feedback session. Here are some examples to start with:

  • “Yesterday during the Daily Scrum, while the team was discussing the status of XYZ user story ….”
  • During the Retrospective, while the team was speaking on a ABC issue ….”
  • This past Friday during the Release celebration cocktail party ….”

Specificity is important when recalling the situation. The more specifics and details you can use in bringing the situation to mind, the clearer you message would be.

Describing the behavior is next step to providing effective feedback. It’s also the most critical step and is often omitted, It is also the most difficult one to describe. The most common mistake is giving the feedback happens when judgments are communicated using adjectives that describe a person and the person’s action.

Consider the phrases below:

  • You were rude during the meeting
  • She seemed to be bored at the sprint review
  • He seemed pleased with the report as presented to management

These phrases describe an observer’s impression or interpretation of a behavior. Now let’s have a look at some other list of actions as observer might witness that would lead to those impressions and interpretations:

  • He spoke at the same time another person was speaking (Rude)
  • She yawned, rolled her eyes and looked out the window (Bored)
  • He smiled and nodded his head (Pleased)

The list of phrases as given above actual describe a person’s action. The focus is on the actual behavior not on a judgement as to what the behavior might mean. By focusing on the action, not the impression, Scrum Master can communicate clear facts that person can understand and act upon.

So when giving feedback using SBI, it is not only important to capture what is said or done but how it is said and done. You can capture the how by paying attention to three things: Body Language, tone of voice and speaking manner and word choice.

Body language is non-verbal communication can include facial expression, eye movement, body posture and hand gestures.

The final step in giving feedback is to relay the impact that the other person’s behavior had on the team, project or anything else.

By communicating the impact a behavior has had on the you (personally) or on the team or the project, you are sharing a point of view from your perspective. This would help build trust, which in turn can lead to even more effective communication.

To develop your effectiveness in carrying out the impact stage of giving feedback, practice putting your feedback in form of “When you did (behavior), I felt (Impact)” or “When you said (behavior), I was (impacted)”.

Putting it all together

Review the situation, behavior and impact steps that build effective feedback and practice those steps at every opportunity. Take time to reflect on your feedback efforts. Ask yourself “Why did I pay attention to this particular behavior?”, What does this say about me?

Reflection also gives you time to understand the true impact the behavior had on you.

You will in turn will benefit from developing a useful skill that not only helps to raise productivity of all people around you, but also bolsters your personal Leadership skills.

Improving people engagement and Retention – In an Agile World

One factor that impacts our ability as organization / project to have a consistent and predictable velocity is in-stability of our team members, we are in the industry, where employee stability is a major issue. This bring to my mind a bigger question, as to why organizations are not able to retain their best employees. It is important to remember that your best employee is the person who desires to leave, under performers do not leave.

Employee retention refers to the ability of an organization to retain its employees. Employee retention can be represented by a simple statistic (for example, a retention rate of 80% usually indicates that an organization kept 80% of its employees in a given period).

In addition to performing exit interviews to learn why employees are leaving, consider asking longer-tenured employees why they stay. Ask questions such as: Why did you come to work here? Why have you stayed? What would make you leave? And what are your non-negotiable issues? What about your team members, your scrum master? What would you change or improve? Then use that information to strengthen your employee-retention strategies.

Communicate your business’s mission and the current project vision. Feeling connected to the organization’s goals is one way to keep employees mentally and emotionally tied to your company.

In a recent research / survey done, it was identified that …

More than half (59%) of respondents believe that chief executive officers (CEOs) are focused on the numbers, rather than their employees, according to research by Coleman Parkes and the Workforce Institute at Kronos. The ‘The £60bn question report’, interviewed 500 people including business/operations managers, HR professionals, and employees amongst a cross section of UK-based organisations

An organisation that engages its employees will be more successful and profitable than one that does not. Organisations of today need employees who are psychologically connected to their work, especially in an economy of service and information industries

Engagement is not the same as motivation. Engagement is when employees are experiencing job satisfaction from a shared understanding of organisational goals that results in enhanced productivity or service levels. Motivation sits on a solid foundation of engagement. It is about firing up employees to achieve specific goals such as sales targets or meeting the defined and agreed service levels.

Employee engagement is not a tick box exercise. It demands a holistic approach to create the conditions that foster engagement. In some cases, that may mean driving a sea change in corporate culture. In an ideal world employee should be presented with a balance between the demands made of them and the resources they can access to meet those demands. Resources may be physical, such as having a laptop for mobile working, but just as often resources may be social or even emotional, in the form of support from colleagues and management. This type of support may look like a ‘nice to have’ but actually organisations derive much of their performance from it.

Just as importantly, engagement cannot be imposed on employees. There needs to be commitment to employee engagement at a senior level, and organisations need to recognise that Scrum Masters and Product Owners that provide support also need to be supported themselves.

Achieving engagement can have a dramatic motivational effect, resulting in low levels of cynicism and excellent performance. Employees demonstrate the best job performance in challenging, yet resourceful work environments. With engagement, a high workload can in fact be a positive motivator rather than a negative issue.

Low engagement can be seen through factors such as high absenteeism and staff turnover, as well as poor staff satisfaction levels as expressed in anonymous qualitative surveys. A Gallup poll found that engagement levels could be predictors of sickness absence, with more highly engaged employees taking an average of 2.7 days per year off sick, compared with disengaged employees taking an average of 6.2 days per year.

Conduct “stay” interviews. In addition to performing exit interviews to learn why employees are leaving, consider asking longer-tenured employees why they stay. Ask questions such as: Why did you come to work here? Why have you stayed? What would make you leave? And what are your non negotiable issues? What about your managers? What would you change or improve? Then use that information to strengthen your employee-retention strategies.

On a very honest side, I would have to say, that in my large expanded career, not a single organization has ever conducted with me or with others (that I know), a STAY interview, is this unheard of? Is that so difficult? Why do we react and try to retain an employee when they put in their papers, all of a sudden we wake up. Can’t we have a type of alarm done to spot these elements and be pro-active … We have also failed to apply the basic principle.

Risk Mitigation is always cheaper than Issue resolution … or put it in simpler approach. Prevention is better than Cure …

I am not sure if in my life time of career … I would see this change coming in … we are heavily engaged in target meetings …. Without understanding the basics, that it is the people who would help us meet the target.

Uninspired Team – Reasons why your team is not fully engaged

As a scrum master your main role is to ensure that your team stay motivated, productive and more importantly happy. It is also your job responsibility to identify what is causing them to be de-attached with the system, why are they non-responsive, what is causing them to be dis-engaged and uninspired so you can correct the situation

Inspiring teams is not about just keeping your employees happy. It’s about having well-defined roles that allow your people to advance in their jobs as well as make meaningful and useful contribution to the company goals.

Let’s explore a few reasons as to why teams might be feeling uninspired:

 

You Demand Perfection

Perfection seems like a recipe for success. But when good is no longer good enough, your team will have a hard time starting things and an even a harder time finishing them. Great leaders don’t complicate things by obsessing over every last detail. They understand that solution is to simplify things. Allow your team to choose something that they think will work and let them give it a try. If they fail, consider it as a learning experience and move on to the next assignment / project

You are not approachable

Too many times managers lock themselves in their office claiming to be busy the entire time. What they do not understand is that being approachable is essential to building inspired teams. When you’re approachable your team can comfortably discuss the latest happening with you and will not try and cover up problems once they arise. This also allows your team to share new ideas with you and they will be confident that you are open to their suggestions.

You Mirco-Manage your team

If you keep insisting on doing things your way, don’t be surprised when you team stops pushing for a change. A micro-manager is someone who holds back on delegating and focuses on minor details and discourages the team members from taking their own decisions. Micro-Management is now an old style of management and is no longer productive in trying to control all aspects of the team’s work. It hurts the team morale and productivity, and is often ranked as one of the top reasons why employees quit

You Cannot tolerate mistakes

If you want to have a creative, innovative and inspired team, you need to give them the permission to fail. If you respond to mistakes and unsuccessful ideas with disappointment or blame, your team will be de-motivated and dis-couraged. However, when you turn challenges into a learning experience, you build up the confidence of your team. Create a culture of creative confidence, which is the ability to come up with new ideas and trying them out. Change your team’s mindset from being risk-averse to being empowered to seek new ideas, thoughts and endeavours

 You Hired a wrong team  

The success of your company depends on the people you hire, if you team seems to be uninspired for good reason, then there’s something fundamentally wrong with your hiring process. It’s either that your employees are not well informed about what is expected of them or you just don’t know what you want in the hire. Successful recruitment is never an easy task. You need to look for successful patterns that have worked in the past to guide you through. Super performers are out there, but just as in good old days, you may need to do some detective work and to actively seek out the people who will turn your company from good to great

 

Servant leadership is no longer about managing and stepping back, it is all about identifying when to step back and allow the team to take the control of the situation and doing it on their own. It is all about guiding the team to do better, achieve higher altitudes.

Yes, I agree we all are humans and have a legacy approach of command and control, it is difficult to do away on day one, the old thoughts and embrace the new world, but if do not change now, we shall never change, do not expect the team to change, the change has to start from one own-self and that is difficult, but again not impossible …

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.

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

Agile Scrum – Nothing more than a COMMON Sense approach

Last few years has really seen the growth of Agile – Scrum adoption in the IT Industry. Organizations are adopting dime by dozen concept in moving towards Agile. Every Software person (whether a developer or tester) is bent on adopting and having the agile experience on their resume / profile. Well nothing wrong with this, But if all (or should I say most) of the organizations are adopting agile and its related frameworks and all the workshops are going full, why the quality of the SW delivered has not improved in the same proportion, Are we not having things which are behind schedule?, are we not working late to complete the commitments that we have given?.

Same happened with Lean applied to manufacturing; people learned the Toyota-ish words but didn’t embrace the philosophy. We all have got certified in various elements, but have not improved. Well, i ain’t talking about the improvements exponentially, but at least by some percentage. So do we say that the agile model is fundamentally faulty or it is our adoption which is creating the unnecessary trouble.

If one thinks that Agile is defined by buzzwords, it is no wonder you not sure can will come or can’t, to me it should come can make it work. Agile is a mindset that leads to:
• Centralized change management to projects
• cutting projects into manageable chunks,
• Insisting on end user ownership, etc.

One of the areas that the industry has defaulted itself is in the area of focusing on Project Management and forgetting about Software Engineering piece of the system. We have conveniently forgotten the idea that every coin has two sides and unfortunately we have focused only on one side of the coin in agile

Just because you’ve travelled in a CAR doesn’t mean you can drive it (like for me, “I can travel in CAR, but cannot drive the same”). Same thing with an agile process, too many people use the buzz words and get the quickie certifications that the industry requires in order to get the job. They did the same thing to RUP, OOAD and OOAP when it came out; everyone was doing it theoretically, yet they really didn’t apply practically and that’s where they failed. If you’re going to say you are using an agile process then really learn it, really do it, and really be it or stop saying you are agile and find something else to blame piss poor requirements, design, and software on.

Personally, for me, Agile Scrum comprises of good common sense elements, doing small things, and doing regular and periodic delivery to the customers / clients or management / end user (whatever the case may be). My concept of Agile is to deliver less, but deliver of good quality, Even if one delivers a great amount of software, but if it does not work at the customer site, how does it really matter. But as they say these days “COMMON SENSE is NOT SO COMMON”.

My belief is that there is a wide range of people using the term “agile” but of these also there are two types of people
1. Some people have a lot of experience doing software development and can use it to create much better software.
2.And other are those people who use the term vaguely in order to sound intelligent and flexible.

There is a fundamental understanding flaw of what agile development is about. There are many people who see agile as anti-process and an excuse to work in an informal and ad hoc manner, While the actual objective of agile development is to follow an agile process and not eliminate process completely. There are unfortunately companies who operate in a chaotic manner and try giving this approach legitimacy by calling it “We Work the Agile Way”. On the other hand, there are companies which, using an agile methodology in the way it was intended, have seen great success.

Agile is abused as a methodology, particularly in India, where there is a culture of pathetic unplanned and managed software development is prevalent. Most of agile principles are not followed and adhered to… It is more of a jargon that is used in the industry to boost up a few resumes and profiles. It is quite surprising when we get assignments to have resources certified for CSM (Certified Scrum Master) or PMI ACP (Agile Certified practitioner), because the client / customers who are giving business to my local clients (In India) want certified resources on the project, I am not sure if the customer understands that getting a certificate and implementing the practices in true spirits are two different ball games… but alas who cares and why should we. On one hand we are getting business (so I am billable) and secondly the resource is getting a new additional element on his / her resume, who would complaint and not sure if the original customer, over a period of years has performed a ROI or cost benefit analysis of having all the resources working for their project certified of any value ….

The bigger question for me is yet to be answered … our management, customers and clients want agile to be practiced, how many of them even understand agile, have they ever got oriented on agile, do they understand the basic principle and thought process behind agile … I afraid not ….

In my long experience in IT industry and more specifically in SW development, certain things are consistent, and they aren’t Waterfall. Project Managers want software rushed out, often on the basis of inadequate specifications. They want something now, and they’ll worry later about having something maintainable. Developers don’t like to comment their code and don’t particularly like to take the trouble of documenting their unit test plans and so on …

One should not forget that we live in the real world, we are also the development team who would have to maintain the previous developers’ uncommented, unplanned spaghetti code, and that isn’t fun. We’re the ones who’ll have to deal with unexpected changes later on, and that will be hard if we wrote novella-sized subroutines that do everything. We should be pushing the idea of communicating with users without swallowing the whole package of bad design practices. Maybe that could have its own element or buzzword.

Could I rename it to Sensible /Common Sense way of SW Development, anyone?

Certifications Boon or Bane? – You Decide

“Third party certification through reputable organizations can be an important tool for small businesses and the gives company the assurance that your suppliers are comprised of the ownership they claim.”

Certification is now a full-fledged industry, everyone is running around it like there is no tomorrow, The craze of the certifications is more seen in the IT sector as compared to the other sectors, specifically for Project Management, Agile, Six Sigma and not to forget at the organizational level for things like CMMI and ISO’s of the world

Senior management should now take 2 step backwards and perform a review of all the money that was spent on certifications, did we really get the ROI or the Cost Benefit analysis? Can we provide the measures that certifications have really helped the productivity of the individual or the group or the organization improve. Would the organization be able to show visible improvements in their TOP or BOTTOM line?

I have my own doubts of the data availability, a good part is that most of these certifications like PMP, Agile , CMMI and so on …. Advocate the usage of metrics and measurement to understand how things are moving in the system, but we rarely use these measurements to prove that the money that we have spent has been really put to good use.

Industry and organizations are going crazy over certifications and spend a huge amount of dollars in acquiring a certificate, to be there on the Wall. I recollect an interesting conversation with a Quality Head for one of the esteemed organization, who had just delivered a CMMI Level 5 successful appraisal for the organization, He was mentioning that his job is over here and with the experience of this journey he plans to move on to a different organization at a better position and obviously a better packet to carry home, On response to my curiosity based questions, he responded that the he has nothing more to add to the current organization. This made me think, that did the organization hire him to get a certificate on the wall types, Is getting certificate the only requirement of the organization, where there improvements in the system, did the ROI of the organization improve? Did the defect count go down, or did they have better schedule performance.

We, in the industry have failed to understand the value and reasons for certification, It has become more of a decoration element on the wall and to gain a few bragging brownies

Project management certifications are booming. However, it seems to me that the main beneficiaries of the certification gold rush are the certifiers, not the certified. There are a lot of articles aimed convincing people of the value of certifications. Here I take a different, and possibly contrary approach: I’ll give you two common, but (in my opinion) wrong, reasons for pursuing PM certification.

My motivation for writing this post is a recent conversation I had with a participant of my PMP batch. It went like this:

“Do you think a PM certification is worth the effort?”

“Depends on what you want out of it,” I replied.

“Well I reckon it will make me a better project manager and help me stand out from the crowd .”

Now I don’t remember what I said in reply, but he’s wrong on both counts. Here’s why:

1. To become a competent project manager: A cert does not a PM make. Preparing for a certification will teach you formal project management processes as decreed by a particular certifying authority. These processes are easy to learn by reading a book or two. The “hard bits” of project management – negotiation, people skills, crisis management, conflict resolution, prioritization, stakeholder management (I could go on and on but I’m sure you get my point) – are not, and cannot be, learnt through certification.

2. To stand out from the crowd: The fallacy here is easy to see: certifying authorities push their credentials like there’s no tomorrow, hence the number of people gaining certs is growing rapidly. That being so, the “stand out from the crowd” factor is getting smaller and smaller every day.

Before I conclude, I should come clean and admit that I have a cert or two. My main reason for getting certified was (is!) that it is a good way to learn about commonly used project management processes and the associated terminology. The certs don’t make me a better project manager, and they won’t help me get that dream job either. However, they do help me recognize jargon-laden bull dust when I hear it (which, unfortunately, is quite often).

In the end, formal knowledge is always useful. So, gaining a cert won’t hurt, but be sure you aren’t doing it for the wrong reasons.