agile coach

The Agile Mindset And Why It’s Important

Posted on by

agile-mindset-why-its-importantWhat Is an Agile Mindset?

In the agile community, many newcomers have not yet adopted the Agile Mindset, and most don’t actually know it exists. They’ll see Agile as something they’d like to use as a tool, process, or methodology. But that is like comparing someone who wants to play a video game without getting into the story-line about what the actual game is about. Surely that will not prevent someone from playing the game, but their advantage compared to the rest of the players, will be heavily hampered. In order to be fully immersed in the experience, one must consider that there are others involved in the game as well. Some may also be better (or worse) than others in some aspects of the game.

To keep a team performing optimally, all members should adopt a similar mindset to level the playing field and keep everyone engaged to handle high complexity. In today’s world, it’s important to consider that we have an increased level of complexity. We all are part of complex environments, whether we think certain situations are simple or not, and the more we are aware of that, we can better circumvent these issues when they come up in the future.

Why Is An Agile Mindset Important?

Agile methodologies are best suited to handle today’s level of high complexity. But for this we need to consider what “complexity” is? In our day-to-day, everything can be perceived as complex, even just the drive to our workplace, or having to debug a line of code. One thing we need to put in perspective is that every large structure or concept is typically built over smaller structures or concepts. With that in mind, we also need to consider that we’re being subjected to and we may quite possibly be bombarded by many smaller elements of one entire complex process on a constant basis. Sometimes it may appear that we’ve tackled the daily simple task, but in reality, it’s part of a month’s worth of seemingly non-related tasks. 

An Agile Mindset is not a silver bullet to being fully immersed in Agile principles. It is a formal setting for your mind that will open doors, rather than close them once you are involved with an Agile team. The level of complexity that we all face in our teams could lead us to thinking that some things are not possible, and depending on the mindset of that team, that could potentially bring everything to a halt if they are not prepared to resolve it collectively. If you think of a mindset as a switch, such that if any one person in a 5 to 6 person team is not switched “ON” to the Agile Mindset, they may stick out like a sore thumb. They might not completely jive with the rest of the team’s discussions. Although they may still perform well overall, their synergy to help resolve issues and deal with the system of a complex situation will be less likely.

How Does An Agile Mindset Help With Today’s Problems and Issues?

Once we see a situation in which all members of a team are switched on to an Agile Mindset, where they are working in a complex Agile environment, it can be more easy to see that problems get resolved quickly and more easily. An organizational structure could benefit from a more flatter one since all members rely less on a hierarchical structure, specifically one that relies on top-down delegation. When all members are sharing synergies and giving all their optimal levels of involvement, decisions are made more easily and become more self-managed, wherein everyone knows their respective part, external blame and distractions become less prevalent and overall processes become more streamlined.

How Do We Adopt And Develop An Agile Mindset?

Genuine openness and engagement from each team member is necessary for the individual parts to work as a whole. This is crucial and works like any moving parts in an engine. The moment a gear, cylinder or plug in an engine doesn’t do what it’s supposed to do, the rest of the engine will need to compensate, other gears will grind, and the engine as a whole will risk overheating. In this same way, an Agile team must be aware and conscious that there are vulnerabilities throughout their performance. Some vulnerabilities may be individual, and others as a group. This is why an Agile team, although it should be shielded from external factors that could distract from the current focus, should also be well informed with the necessities that could possibly enable the team to perform effectively. A perfect example of this scenario would be to have an Agile Coach on-board, but it is also possible to get relevant reports and analytics from members of the team itself. In general, a diverse team, diverse backgrounds in culture or language, either technical or business or both, are all areas that could promote discovery of hidden problem-solving or creative avenues and provide the best overall direction for an organization.

[Image courtesy of Sira Anamwong at FreeDigitalPhotos.net]

The Importance of Time Completed and Time Remaining in Estimations

Posted on by

importance-of-estimates-time-completed-time-remaining/One of the first things many team members on Agile projects lose sight of is the importance of tracking their time spent on their tasks identified in their Backlog Item. Whether it’s a User Story, Sub-Task, Enhancement, etc., logging hours spent is of absolute importance to make sure further Sprint burn-downs, velocity, and estimates will continue to reflect increasing accuracy. The tendency of some teams is to use their Backlog Items (in either of the forms mentioned above), as a scope tracker. However, time-tracking on a daily basis is of absolute importance.

How Your Hours Should Really be Logged

Once a backlog item has been completed, only then do team members log their hours, and it most likely ends up being the hours set in the original estimates. Not only is it best practice to log hours spent on your backlog items on a daily basis, but also to re-assess what the remaining hours are. Just because an item was estimated to take 16 hours, and you performed 8 hours so far, it does not mean 8 hours remain. Sure it would seem logical that it would come down to a simple mathematical equation, but it’s truly not what is meant by “Time Remaining!” So what should be put in Time Remaining? It’s really about what should be required to complete the task at the moment of logging your time mid-course. What that means in our previous example; if you logged 8 hours for a task that was originally estimated at 16 hours, you may come to realize, there’s only 4 hours left. It’s as if you are re-estimating or re-assessing what is left to do. A number that does not match what was originally estimated, is perfectly fine either from a downward estimate or an upward one (assuming it’s done correctly of course!). This is by far the best way to know if original estimates were done accurately, and gives team members a gauge on whether those estimates continue to be assessed correctly in later sprints. Better yet, if needed, the variance of estimation accuracy can be calculated as well.

When Time Remaining is Not Taken Seriously

The problem arises when developers mark down remaining estimates as a straight-line mathematical equation, since it would imply that all original estimates were done properly, and makes it impossible to weed out the estimation imperfections during Sprint Planning from Sprint to Sprint. The other issue that may happen is that there could be a skew in estimations since some developers will take their time to complete a task (if they see that they’ve completed it early), and then hurry their task, or worse, bust the estimates if the task was underestimated. From there, it may escalate to having only underestimated tasks as being incorrectly estimated. What that gives is a mix of underestimated, and on-time estimates. As you can see, when the hours are totaled up for that sprint, the skewed results give an impression that generally all tasks were underestimated, and the lack of transparency will make the team draw separate conclusions. This also affects your burn-down charts and interpretation of velocity, all the while the cycle of trust within the team is broken.

How This Helps Continuous Improvement

Seeing the above situation in a different light, if you were on a trip where the original travel time was supposed to be 10 hours, only to find out the ride is shorter than expected, you would probably want to know, right? The same would apply if it would be longer than expected. To make the point clearer, your expectations, and that of others depend on the transparency of what remains to be done on any development effort. This aids efforts for future estimations and weeds out any further potential to be disappointed.

The next time you may be faced with a seemingly obvious question “How much time is remaining?” it may need to be seen as “How much time is needed to complete the task?” It’s not just a simple math calculation. Remember that estimates are called “estimates” because there is a chance that they will not be “accurate.” Having those numbers accurately represent “time remaining” allows for the estimation process to get better and better, as the team looks back in retrospect and compares their estimations for future Sprint Planning sessions.

 [Image courtesy of lekkyjustdoit at FreeDigitalPhotos.net]

Automation is Key to Agile Implementation

Posted on by

automation-key-agile-implementationWhile most of us in our day-to-day would typically adapt to change whenever possible, it is very likely that we mindlessly have too much to manage. This is why automation is key to agile implementation. With a mindset to find ways for automation we promote a rhythm to the workflow, the process, the communication, etc…

Agile Ceremonies and built-in automation

When we look at the agile ceremonies overall there’s a flow that we can say exists, for example: (a) scrum or standup calls should take place at the same time every day, (b) sprint planning, sprint reviews, and retrospectives all take place on days that everyone has already preset, or (c) sprints should usually keep the same duration of weeks from sprint to sprint. We may ask ourselves, are these times and dates just a random practice (or requirement) of agile? The answer is no, not necessarily. There’s a reason behind all of this.

Keeping it Simple

While you may look to adapt to change throughout all the times of the workday, it is best to make the repetition as consistent as possible. This is similar in concept to what Einstein or Steve Jobs wearing consistently same clothing every day. This is just an example to make the point, but somewhat of an interesting revelation for those who are looking to simplify their day. For some we may think this “clothing” example is a little extreme, or irrelevant. Fair enough, this would be extreme in most cases. But when we are looking at our work environment, this principle makes a lot of sense for those who want to just concentrate and make decisions on what matters most. Putting in place what doesn’t matter so much, leaves time to make decisions that do matter. This in itself makes a lot of sense.

Consistent and Regular Adaptation

With reference to automation in the workplace, we’re not referring so much to setting up your schedule or planning in advance, although this is definitely a good habit, and better than not having any at all. We are referring specifically to having meetings, code reviews, or testing done in a way so that the agile team doesn’t have to constantly think about when it needs to happen. As an example, think of this question: What do you foresee being a problem if scrum meetings change times every day? It’s obvious, the team members will most likely be late as they try to figure out what time the meeting is at, or they missed it, and therefore all that time is just wasted when it could have been used more wisely and effectively. Some may even think, that “this inconvenience is minor,” but if you add that time up over a few sprints, you may be shocked to find out the cumulative amount isn’t as minor as you may have thought. Others may think, “this is just the normal workday or workweek,” and that it’s expected. However consider the advantages of setting this automated “rhythm” so that all that is less important is already out-of-the-way, and all the more important ideas and decisions can take place without distraction or resistance.

Admittedly, finding ways to improve a process and simplifying it in a way that is conducive to automation can be tedious, but once it’s in place, it does save a lot of time in the long run. More important than time, is the quality of the decisions and thought process that will come out of it. Think of it like a slow blockage that is eventually unclogging and allowing for a release of free-flowing ideas and productivity. Look to your sprint retrospectives to point out where areas of automation can be of benefit. You may already have some in place, but that should not stop an agile team from finding others. Incrementally and over time you can automate processes infinitely, but certainly it’s best to prioritize them where the benefit is worth the effort.

For More Articles, Be Sure to Visit our Homepage

[Image courtesy of Idea go at FreeDigitalPhotos.net]

How an Agile Mindset Enlightens the Subconscious Mind

Posted on by

how-agile-mindset-enlightens-subconscious-mindAccording to many experts on the subconscious mind, there’s a very close correlation to our actions from what we think. That is to say, generally there’s a link to what we do because of the way we think, and vice versa. The interesting part is that the subconscious is like a database that is either controlling or being controlled. It controls us on a regular basis and is based on what has happened to us in the past, and can be controlled when we consciously choose to do so. Much like the example of beliefs, if we don’t know why we believe something, but continue to express those beliefs, we are being controlled by our subconscious. Somewhere and at some time, we were led to believe something and have locked it in so that our actions continue to reflect it. Knowing this, we can look to see how the agile mindset enlightens the subconscious mind.

Understanding our Thoughts

If at some point we ask ourselves why our beliefs are there, we may actually be able to change them if we ask the right questions, and refer back to the time when the belief may have been etched into our subconscious. We can however, de-magnetize our thoughts by performing actions that were purposefully and consciously done to overcome subconscious blocks.

Ever wonder why some companies have a culture of having constant meetings, with numerous (and possibly unnecessary) attendees? They may not actually realize that they are wasting each other’s time, and possibly inviting coworkers that could have been best left uninvited so that they could use their time more productively. This leaves many in the workplace crippled from doing their tasks when needed and may need to double efforts to catch up on the more important stuff. To a great extent it comes with learning to self-respect and then in turn that exhibits respect toward others. The best way to respect oneself is to know oneself. You owe it to yourself and others around you to understand the duality of our conscious vs. subconscious influences and the power they can give or take away.

Making Conscious Decisions and Following Through

When we practice agile on a daily basis, and follow the agile values and principles, we may have to take that first step in understanding why we are actually agreeing to do things and think along the lines of what agile represents. Is it because one person had an idea to do things according to agile values, or was it a collective decision? Regardless of the answer, this is the “first step” type of question you need to start asking. Some decide on what they heard, some from their experience, and others go by what is based on faith. If you really want to get your Agile teams set in the right direction, it is important as an agile coach, or as someone championing agile within the organization to ask those questions and get feedback. The result should be from a collective consensus to agree that there is a genuine desire to adopt agile methodologies.

The law of your mind is the law of belief, so all events will follow from that as you work as an individual and as a group in an organization. So as someone practicing agile, you have to make a conscious decision and commit that you will cooperate and apply what is available, and keep it simple and lean. As we know that beyond the agile tools, events, ceremonies, is actual thought process that makes someone do things in a way that promotes the agile values and principles. Have you taken the first step in actually reading the Agile Manifesto? Have you read a comprehensive book on agile to understand some of what the great minds and gurus on the topic have to say?

How This Ties into Agile and our Subconscious

We have a lot to owe to our subconscious mind in allowing us to follow habits whether good or bad. Something as simple as why we brush our teeth, was at some point a conscious decision to properly practicing good hygiene. At this point you probably brush your teeth guided by your subconscious. Putting this into the concept of agile practices with set time-box durations (sprint planning, sprint demos, standup meetings, etc.) we are programming the subconscious as if to say, “this is something that I’m going to commit to doing regularly and repetitively. For those who have been on their umptieth sprint or agile project, they have already realized the almost seemingly thoughtless process when starting and ending their sprints. It can also be said that there’s an almost intuitive insight as to what the consequences will be if things fall outside of time-boxed events or get left out entirely. With that we can see at that point how the action-based practices have tuned the subconscious mind and helps keep in place what the agile values and principles were meant to represent.

[Image courtesy of ratch0013 at FreeDigitalPhotos.net]

The Values of Being Self-Made For Agile Learning

Posted on by

the-values-of-being-self-made-for-agile-learningYou can never lose if you are determined to learn. Having the will to learn empowers you to know what to do, even if it is eventually to find out what not to do. Agile learning experiences allow you to do just that. To put this simply, you typically have 2 paths to learn, you are either told what to do, or you find out for yourself through your own experience on what to do, i.e. trial and error. With the analogy of getting burned on the hot stove, you can be told it is hot and will burn you if you touch it, but you will never really know what that means if you’ve never been burned before. Being told relies heavily on someone else for your growth, but what happens when that other person is not there?

Why is Being “Self-Made” Important?

Give yourself the ultimate test, ask yourself if what you’ve accomplished at any stage in your life was because you were told (or expected) to do it, or you did it because you yourself were trying to determine what to do. One path removed power, the other empowered you. We tend to get distracted by true sources of power, namely money. We strive to gain monetarily, but what if someone was given that source of power, but didn’t know what to do with it? It would go to waste wouldn’t it? Placed in the hands of someone who can’t think for themselves, it could even be used to do harm. This is where the term “self-made” comes into play. There are certainly much higher value to be considered a self-made person since it solidifies and confirms that you have gained through personal choices and experiences. This also means that a self-made person gains the added toughness of dealing with failure without being able to blame others for it. This builds character and if overcome, creates innate abilities to succeed and make further attempts to make things right.

Being Part of a “Self-Made” Agile Team

The structure of the agile team is one that should rely on the concept of being “self-made.” Why? Because learning is at its peak when you have a sense of self-consciousness. You are aware, you know that what you know is not enough. We tend to look at knowledge as finite, i.e. you took the course or made the grade so now you know everything there is to know about the subject. But that couldn’t be further from the truth. This is in part what many in the workplace dislike about those who claim they know everything. A team runs much more smoothly when the stage is set that they are all in in it to learn together and if they persist unconditionally, without pointing fingers and with compassion, there is a very high likelihood that they will succeed.

Wanting to Experience: The Key to Learning

When a group of people are proud of their greatest moments, they will likely stick together for the long run. Some may see learning experiences as a stepping stone to other new ways to learn, and others see it as a one step to being complacent. However if there is one factor that is certain from successful people is that despite all the experience they have, they refuse to stop experiencing and learning. This creates efforts that other like-minded individuals can be drawn into, and the learning cycle continues. The roles of the Agile team are there for a purpose, servant leadership being a huge part of it. We all think that the Scrum Master is the only one practicing that type of leadership, but that doesn’t necessarily have to be the case. Remember that the Scrum Master is not just a role, but also a role model, so it should not be left to one person to display specific and/or positive behaviors. Admittedly, it takes good synergy and team development before you get to a point of comfort and working efficiency within teams, but it is attainable and the benefits can be realized.

In order to get started with your learning path, ask one simple question “why?”. There’s a reason why children at an early age ask that question incessantly, as humans we are wired at an early age to want to learn, but then socialized into a system where we tend to stop. Go through your list of personal “why’s” and you may notice for yourself that there is something you may not have realized is stopping you from learning.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

 

7 Reasons Why Some Corporations Hate Agile Methodologies

Posted on by

7-reasons-why-some-corporations-hate-agile-methodologiesConventional business wisdom will tell us that we should tell our shareholders what they want to hear so that the price of company stock will rise. This displaces the value that corporations will aim for toward the shareholder and not necessarily toward the customer. This is where Agile methodologies conflict as the goals of a conventional vs. agile mindset are not the same.

Below we will outline how conventional corporate mindset thinking conflicts with that of an agile mindset:

1- Focus on customers over shareholders

As a company you would likely be trying to appeal to both the shareholders and customers, however it’s usually shareholders that will come first and customers second. Based on agile principles and agile mindsets, the priority undeniably reverts to customers first! Everything in the agile value mindset reflects a goal toward delighting the customer and the accepted agile methodologies and processes show much evidence to conclude this is always the case.

2- Perceived Loss of control

The thought that there could be teams that are self-organized and self-managed leaves a sense of control loss by management at any level. Management may argue that if the teams are self-managing, then what is the use for management in the first place. Unfortunately this is a false perception, since management would likely still be needed for areas of business operations that are not covered by the day-to-day of agile processes. 

3- Perceived loss of authoritative rank and power

Most conventional businesses will follow the militaristic approach as the known command-and-control approach to business structure and organization. Companies with a highly vertical (hierarchical) structure being at one extreme and the more flat (horizontal) type of organization at the other end. Those with a heavy emphasis on a vertical structure tend to harbor many of the anti-patterns of an agile approach. Be it either from lack of trust or lack of willingness to let go of authoritative power, many companies that have a top-heavy structure will not be easily capable of converting or adopting agile.

4- Focus on delivering immediate customer value over immediate revenue

As many have noticed the periodic reporting of large businesses, especially those whose stocks are on the market exchange, the revenues that were forecasted must hold up in the later quarters or else face the consequences of lost share prices and market share overall. This places emphasis on how soon work can be done and made billable rather than concentrating on the actual scope and process of work to be done. The best interest of the customer is left behind as resources are stuffed into the work processes, rather than allowing agile methodologies to take their course.

5- Too much learning and too much change

Most who have reached a respectable level within their company whether it be in management or non-management (technical) levels, may tend to sit on their laurels all too often. Although we seem to hope that society is a meritocracy, let’s face it, some people just get to the higher positions based on years of experience rather than actual willingness to continue learning and changing. To this point, there are some who live up to their titles, but others who don’t and wouldn’t care to collaborate with their fellow colleagues either because they have underdeveloped people skills, lack of extensive knowledge, or because it’s seen as too much work to learn and share.

6- Customer value is cumulative while overall benefits only come if done properly in the long run

If there is anything we can’t promise is what will happen in the future. It is highly unlikely that an executive management team will wait to see if there will be continued commitment and support from their existing customers. Since much of what builds up customer satisfaction retention accumulates over time, most companies do not factor that in and will take the shortest path to generating revenue. Building quick untested solutions for the sake of having something billable does not look after the best interest of the client. This extends further to the disappointment of employees who are being told what to do, without buy-in. Some companies would rather sacrifice growth of their existing team synergies to result in high turnovers from unmotivated employees, rather than keep them on-board. This is why at the first sign of lost profits, most companies will take the immediate route of terminating their employees. The reason? It’s the quickest and easiest way to lower costs. However in the long-term it proves detrimental, and usually leads to further “voluntary” fallout where employees lose sense of purpose from the previous setback of layoffs. This affects customer relationships as the level of expertise and direct customer engagement from employees diminish.

7- Increased level of transparency perceived as very risky

Most companies do not share at many levels for fear that the truth may  reveal too much for many to be comfortable with. High levels of transparency bring about a sense of fear that the information provided can be way too sensitive or used against the company. Although transparency may reveal positive and negative aspects of a company and its operations, most companies tend to err on the side of non-transparency to avoid the risk at all costs. This approach of course lowers the level of trust and therefore the level of engagement from customers as they find out from latent communications throughout the project life-cycle.

[Image courtesy of cooldesign at FreeDigitalPhotos.net]

 

Agile Coaching and Mentoring – Wisdom Explained

Posted on by

If you’ve heard of situations where the “student becomes the master” and “the student becomes the teacher,” you might be asking yourself exactly what does that mean. Most think there is a distinct difference between the role of a teacher or master to that of a student. If there is one thing to consider is that they certainly cannot exist without each other. The main distinction behind how a student becomes the master is usually by the amount of practice the student had, and how he or she may then stand when compared to their own master when it comes to wisdom. This is also what happens in agile coaching and mentoring toward the agile team relationship.

Coaching and Mentoring – What is the difference?

agile-coaching-and-mentoring-wisdom-explainedMany consider the role of a business coach to be a mentor, and vice versa. A coach’s role is diverse and really depends on the background of the individual. Some might have specialized industry knowledge and experience in which they are taking part, but others might have process and/or procedural experience from a more diverse or general industry background. There’s no better or worse when it comes to those differences, however where there is a more distinct ability in question as to how much that individual analyzes, learns and gives back to those they interact with. That being said, an agile coach can be a mentor, and an agile mentor can be a coach. The difference there is how much time, dedication, and direction that takes place between the mentor and mentee, or coach and coachee. The mentor role might be better suited when the role is specific, i.e. a mentor for a developer is usually best suited when the mentee is also a developer. In agile circles, those lines are somewhat blurred and most of the agile coach role is taken on by the Scrum Master role. The agile business coach however, can be a separate role and is just as important as any other role.

When is the Coach a Student?

Remember when you were a student in class back in school, college or university? You were always thinking about how the teacher, separated by many years of knowledge, would always be the prime source of information, direction, authority, etc., on the class subject. We had the distinct notion that the teacher had taken on the role of the “all-knowing” in the classroom. But what we need to realize is that the teacher was also in an environment where they too were learning, and looking for answers themselves. Certainly many teachers had many styles, some better than others. Do you remember what made the great ones great? and the not-so-great ones not so great? What you may have realized is the level of involvement but also the level of in-depth conversation with the students. You may notice that the teacher although being a source of information and specialization expertise, was immersed in getting to know why their students thought the way they thought. They were learning too! This is very much the same way an agile coach and mentor would be with the agile working team and its members. The coach, just like the teacher, is also being a student to some extent. Why? Because they are in a state of constant learning, despite their high level of knowledge.

How Does Knowledge Transfer into Wisdom?

While in the student vs. teacher scenario, we can see that the student is the one always looking to prove their knowledge to their peers and teacher in a classroom. Many students might be motivated to attain a certain grade and use their knowledge to show everyone just how much they know. Wisdom comes when there’s a higher sense self-motivation, self-control and knowing when to use the knowledge, not just to get the grade, but also when to use the knowledge in and outside of the classroom. This also goes hand-in-hand with knowing that despite having increased levels of knowledge, nobody can ever know enough. This is the true turning point on wisdom. Much like power, it’s not about using power at all times, but when to use it that brings a better sense of refinement to any situation.

Creating Genuine Purpose to an Agile Coaching Philosophy

For those who become ambitious in their line of work, whether in agile team roles or not, there has to be purpose and thought to the “why” in their role. When ambition is driven by getting to the top of the ladder for popularity or for a sense of superiority, there is true lack of wisdom. The difference happens, as an agile mindset will show, when one’s purpose is to share with others. Much like a coach or mentor, they should not aim to become one just for the title, as someone in a highly regarded role that gains a lot of attention from all stakeholders in an agile organization.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

5 Ways an Agile Coaching Philosophy Enables Agile Teams

Posted on by

5 Ways an Agile Coaching Philosophy Enables Teams to BE AgileAdopting an agile coaching and mentoring philosophy for your team can be very beneficial. Most believe that all that is needed to keep the agile team in good shape, is with the scrum master role. This may be the case sometimes, however the agile coach brings about much more than what the scrum master can do. This also applies more to larger scale teams where there are many scrum teams, and their respective scrum masters. The agile coach can take on the role of scrum master of scrum masters, but generally they can represent the organizational coach and mentor with the agile mindset. The title in most cases is not important, but the role itself is relevant to take on the following ways to inspire their teams.

1 – Showing the team how to be open

Many teams whether in their beginning forming or norming stage will need to build on their openness throughout their communication process. The agile coach would be there to explain and show the benefits of being truthful and communicating openly, without hidden agendas. Also they can help build on agile team roles that might be lacking direction or depth. Occasionally some roles haven been taken on without necessarily knowing the full extent that role may need to contribute. The agile coach can provide this additional support to getting those particular team members to acquire communication skills, and the benefits thereof, to their fullest potential.

2 – Modelling what it means give and earn respect

There is an old saying that “respect can not be bought, it must be earned.” This is saying rings true in all levels of an organization. The agile coach knows that they can’t go around asking that everyone respect each other, but they know that with proper demonstration of leadership, others within the team will get to see from the agile coach how the proper use of communication and demeanor truly benefits everyone through the interactions with the teams. By earning respect from their peers, not just by title, but actual use of meetings and personal interaction.

3 – Bringing out special talents of each team member

It is very likely that peers within a team will compliment each other on the great achievements they’ve accomplished. The agile coach however, can make note of skills and talents that each individual will have. Being able to reach out to those looking for continuous development, the agile coach can provide mentoring sessions and guidance. The agile coach may also be able to set up agile games that promote deeper learning for the team, as well as agile training courses specific to each role or situation.

4 – Optimizing team performance

When the team has reached its top performance and velocity is steady, the agile coach can look to make sure the dynamics of the teams are protected. By that, it means that despite any change within the teams, the agile coach can identify if there is a good fit for the current team if someone leaves or joins. Also, where there is concern for self-organizing capabilities, the agile coach can explain how everyone can take on challenges and decisions on their own. This can be done by story-telling or giving real examples of how top performing teams have accomplished similar accomplishments.

5 – Keeping a positive outlook in the face of failure

Inevitably with all new developments and innovations that team attains, there is a likelihood of failure and disappointment. In those instances, the agile coach should be able to reach out to the agile working team and explain that it is normal and acceptable. The other important aspect that the coach will do is keep the team’s spirits up despite that. True team building comes with being able to show that everyone can get back up and do better the next time. Regardless of the number of times failure may occur in their agile solutions, the team can learn that it will be able to accomplish a lot more by not complaining or worrying about the past.

As we can see, the adoption of an agile coaching philosophy can facilitate many of the organizational aspects that we take for granted. Some of the points raised above may happen on their own, or may even be forced. Having an agile coach on your side is a choice, but when it comes to company values to keep their teams in top shape, wouldn’t you rather have someone there to give proper encouragement that teams need when looking for guidance?

[Image courtesy of David Castillo Dominici at FreeDigitalPhotos.net]