RSS

Tag Archives: organizational-transformation

Are leaders and the company culture the real problems to agile adoption?

Most surveys about the state of agile, point to the existing culture and leadership as the primary causes of agile struggles. But are those two, and their derivatives, really the culprits?

Isn’t it curious that our goal, as agile coaches, is to deliver value by ascertaining how best to meet the needs that are determined by the organization, and yet we consider the organization itself to be the biggest impediment to doing so. Is it possible that the problem is not in the organization’s culture and management structure but in our own assumption that there is a singular definition of value and our determination to deliver on that definition despite the organization we are trying to transform? Could it be possible that the client organization understands what is value in ways that we do not?

G. K. Chesterton in this 1929 book, The Thing, said:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.

This paradox rests on the most elementary common sense. The gate or fence did not grow there. It was not set up by somnambulists who built it in their sleep. It is highly improbable that it was put there by escaped lunatics who were for some reason loose in the street. Some person had some reason for thinking it would be a good thing for somebody.  And until we know what the reason was, we really cannot judge whether the reason was reasonable. It is extremely probable that we have overlooked some whole aspect of the question, if something set up by human beings like ourselves seems to be entirely meaningless and mysterious.

There are reformers who get over this difficulty by assuming that all their fathers were fools; but if that be so, we can only say that folly appears to be a hereditary disease. But the truth is that nobody has any business to destroy a social institution until he has really seen it as an historical institution. If he knows how it arose, and what purposes it was supposed to serve, he may really be able to say that they were bad purposes, or that they have since become bad purposes, or that they are purposes which are no longer served. But if he simply stares at the thing as a senseless monstrosity that has somehow sprung up in his path, it is he and not the traditionalist who is suffering from an illusion.

In other words, an organization’s culture has evolved for a reason and has likely been strongly influenced by what the organization has found to deliver value in the past.

Culture is a pattern of shared tacit assumptions that was learned by a group as it solved its problems of external adaptation and internal integration that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems. ~ Edgar H. Schein

Since it’s inception, any organization has had to learn what strategies, values, procedures, behaviors, and norms work within its environment. Those that do not further the company’s mission are discarded; those that do are retained and progressively improved over time. This history of learning, by trial and error, is rarely written down but forms the basis of tacit assumptions and norms — the collected wisdom about what leads to success within the organization. What is valued by the organization, then, gets encoded in the company’s culture and their bureaucracy. To the uninformed, this bureaucracy may at first glance seem capricious, brutal, and wasteful, but it is simply a way for the organization to ensure that people pay heed to what is considered important in that organization. For example, the “burdensome” security scans, reviews, and audits in some financial institutions only point to the organization’s belief that doing right by the client is important and that their personal data must be protected at all costs or that our brand is everything to us and we shouldn’t needlessly take on risk that might harm our brand image and reputation.

The Chesterton’s fence principle applies to agile introductions as well. Again, Chesterton’s fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood. Just because there doesn’t seem to be a readily apparent reason for this fence to be here doesn’t mean there isn’t a reason. What this means is that Agile coaches must first come to understand those values, strategies, and goals that are embedded in the client organization’s culture.

Most agile proponents however, are far too eager to tear down what exists, without first understanding why that exists, in order to put in place what they believe is “agile” and “better.” It is the rare agile coach that takes the time to first understand what the company values — most coaches are aware of one way of doing things (insert the name of your go to agile framework here) and want to jump straight into the mechanics of implementing it. They often do this because they want to demonstrate, to the client, that they themselves are adding “value.”

The result of not heeding Chesterton’s fence is that the agile coaches frequently run into “resistance.” This resistance is chiefly due to the client management’s perception that what they value and what their concerns are aren’t being considered.

Agile proponents come in and say we should discard X and do Y instead in order to not have to deal with the negatives of the existing X.


X     |       Y
|
+                |
-----------------|---------------
-                |
|
|

But clients believe (whether incorrectly or not) that the benefit of the agile evangelist’s point of view (Y) leads directly to a loss in what the client believes is important to her (X). In addition, they perceive that the new approach simply swaps in a different set of negatives.

What coaches could do instead, is to work together with the client to come up with a solution that explores how to get the “new” benefits without losing the benefits of the existing approach/culture. Instead of approaching the transformation in a “big bang,” where the existing culture and structure is swept away in one fell swoop, a measured incremental approach where we learn as we go might be better. Agile coaches could take an agile approach to agile adoption — drive organizational change incrementally and make course adjustments based on what they learn about the organization’s true needs and dynamics.

But clients believe (whether incorrectly or not) that the benefit of the agile evangelist’s point of view (Y) leads directly to a loss in what the client believes is important to her (X). In addition, they perceive that the new approach simply swaps in a different set of negatives.

What coaches could do instead, is to work together with the client to come up with a solution that explores how to get the “new” benefits without losing the benefits of the existing approach/culture. Instead of approaching the transformation in a “big bang,” where the existing culture and structure is swept away in one fell swoop, a measured incremental approach where we learn as we go might be better. Agile coaches could take an agile approach to agile adoption — drive organizational change incrementally and make course adjustments based on what they learn about the organization’s true needs and dynamics.

 
Leave a comment

Posted by on August 25, 2018 in Agile, Coaching, leadership

 

Tags: , , ,

Can we get out off the Agile weeds?

I’ve been having far too many conversations regarding Agile frameworks, their implementation, and scaling recently. It seems to me that a majority of agile coaches and their clients seem preoccupied with rituals over results and I get the sense that people are too mired in the weeds and losing sight of the few basic things needed for becoming a more nimble and customer centric organization. So, here are some things to ask yourself:

  • Are we truly a customer centric organization? Do we actually get out of the building enough to understand our customers, their needs, their problems, and how they use (and struggle with) our products. Can team members do a “follow-me-home” or some other customer discovery practice – journey maps, customer interviews? Are product teams primarily focused on gaining customer insight in order to better meet their needs? Do we even care about customer delight?
  • Are we open to disrupting ourselves without the motivation of a crisis? Does our culture allow us to preempt crises, without much drama, by reinventing products and services offered or by changing the existing business model? Or are we complacent and reactive and buffeted by what are competitors are doing?
  • Do we have true business and IT partnership? No, I don’t just mean that a PO sits with the team or that there is a Product Manager who ensures that her POs are aligned on the order in which to build the identified features. What I mean is that the business folks and IT have the same goals, the same targets, the same key metrics – and that they together focus on the same desired outcomes (and not just the outputs). Think X-Matrix and OKRs here. Think collaboration (in the true sense of that word) and not just communication, cooperation, or coordination. Think the CIO meeting daily with the Chief Marketing Officer (CMO) to strategize.
  • As a company, are we good at making accurate decisions quickly? Can we get the right information to the right people making the right decisions at the right time? Can we provide the decision makers with relevant and timely feedback about their decisions? And then, do we encourage them to learn from mistakes and improve?
  • Do the IT folks sit together with people from Product, Marketing, UX, Finance, and Operations so that we have true cross-functional product teams? Do these product teams (small, collocated, long-standing, cross-functional) have the autonomy to determine their own best solution to meet the defined goals? Do they have license to experiment and learn? Do senior leaders trust them to do the right thing?
  • Are we providing open collaborative spaces for the collocated product team members? Or are we still struggling with ineffective communication amongst the distributed and/or dispersed team members?
  • Are teams keeping design simple and writing good code? Can they rapidly get feedback by integrating and deploying continuously? Can they release on demand? Do they demonstrate their working product frequently to their stakeholders and to their customers? Yes, inviting real customers to a demo is a good idea.

You’ll notice that these are independent of any agile framework used. You can actually start improving on all of these without even using the term agile. So what’s keeping you from moving off the rituals bandwagon and focusing on what truly matters?

 
Leave a comment

Posted by on November 24, 2017 in Agile, Improvements, leadership

 

Tags: ,

Why do organizations limit their agile focus to just development?

Seems like I’ve been suffering from frequency illusion (aka blue car syndrome) recently. I’d been mulling over the fact that a majority of clients I serve don’t invest wisely in DevOps or simply don’t know how to proceed. A recent one, for example, has been crafting a DevOps strategy for over a year with nothing to show for it. Sadly, the DevOps initiative and group is considered separate from all the teams doing agile. Interestingly, I suddenly started seeing lots of data supporting my belief — most likely, I was primed to see it crop up everywhere.

Forrester’s 2014 report, “How Can You Scale Your Agile Adoption?” and Cloudbees’, “Four Quadrants of DevOps Maturity” reinforce the notion that the late stages of the software development cycle are usually given the short shrift.

We know that software development entails more than just development. To keep the discussion simple, software development can be thought of a sequence of activities (and associated information and work product flows) encompassing understanding customer and stakeholder needs, planning, designing the offering, coding, building, integrating, testing, releasing/promoting, deploying, operating, and getting feedback for the next cycle.

While a decent percentage of companies are focusing their agile efforts on the pre-integration stages, less than 15% have introduced agile principles, techniques, and practices in the integration and post-integration steps. So, while companies get better at developing software they still are gated and held back by unnecessary delays in the later stages of the life-cycle.

As an aside, I’m not considering funding, sequencing of work across the stakeholders, and requirements being pushed to teams without regard to their capacity and ability to deliver here — areas that still need tremendous work in most organizations. Also, SAFe has rightly emphasized attending to the team structures but often overlooked in agile transformations are the facts that teams don’t have all the skills needed, team membership is unstable due to shortage of necessary skills, there is a lack of focus on minimizing dependencies (highlighting dependencies is not the same as minimizing them), and the business and teams aren’t often aligned.

This issue of lack of agility, post-coding manifests itself in a few major ways:

  • Teams struggle with lack of environments for developing, integrating, and testing.
  • Extreme risk aversion in the second half of the cycle at times often precludes teams from promoting their own code — they then face significant challenges in testing their work in a timely manner.
  • Deploying to higher environments can at times be a cumbersome, bureaucratic process — infrequent promotions and deployments delay defect discovery and slow down feedback. Consequently, feedback cycles of 2 weeks or less in development balloon to weeks and even months in the latter stages.
  • In a handful of cases, development organizations start using tools (whether open source or not) that Operations does not have the skill or personnel to support.

Quite a few companies treat DevOps and Operations as separate from development. Most don’t treat DevOps as a function but as a team. DevOps teams with managers are just another silo and a significant number of people think they do DevOps just because they have a team called DevOps. Even worse, I’ve far too often seen QA, Automation, and Development as separate groups with their own goals and agendas. Throw in the fact that different vendors (often competing for additional business) often perform each of these activities and you just make the situation worse.

So, here are a few things to think about:

  • How can we change the mindset of the folks doing and managing the second half of the activities to be more agile?
  • How can we create a true DevOps function, where the business, development teams, and operation staff collaborate from the start? How do we break down the boundaries between these roles?
  • How can we encourage larger organizations to start their agile journey with aligning on a DevOps strategy quickly and improving the DevOps function to immediately address the huge delays and waste?
  • How can we make it easy for developers to request and get environments to build and test against?
  • How can we help companies recognize that a repeatable infrastructure and application deployment process is extremely necessary?

We would love to continue the discussion and talk about our experience in making Agile work for DevOps. Please reach out to us (Jon at 702-389-8160 or Alex at 949-667-1008), or if in Las Vegas, attend a DevOps centric meetup (more information at http://hatech.io/community.html#meetups).

 
Leave a comment

Posted by on February 20, 2017 in Agile, Improvements

 

Tags: , , ,

Five Stages To Organizational Agility

Building on the previous blog post about the importance of focusing on and continually improving flow, quality, and value delivery, we can turn to the stages to achieving organizational agility. Achieving organizational agility involves deliberately improving the following (in order):

  1. Visibility
  2. Predictability
  3. Time-to-market (Flow)
  4. Value / Outcome driven
  5. Organizational Agility

All steps are underpinned by cycles of: assessing, defining the improvement strategy, training, and coaching.

1. Visibility

Visibility presupposes a culture of transparency, openness, and safety (protection from retribution and loss of reputation, health, money, and relationships). Without such a culture, you will not have true visibility and visual management will be a sham. Michael Ballé, in The Lean Manager, defines Visual Management as “seeing together, so we know together, so we can act together.” When information is hidden, people cannot see together and are likely to act in sub-optimal ways.

2. Predictability

With clear visibility you can begin to gauge and improve the predictability of your overall process. Predictability implies the ability to accurately answer, “When will it be done?” Making your processes more predictable and being able to reliably and consistently meet delivery commitments is the first step in building trust with business partners, stakeholders, and customers. Predictability can be gauged by studying Cumulative Flow Diagrams and work item completion cycle time scatter plots. These give you a baseline from which to start your improvement efforts.

It is important as a first step to regulate the arrival rate of new work to the completion rate of work by the teams. Work should not be started at a faster rate than work is completed. If it does, then you are faced with a situation of ever increasing work-in-process (WIP) and lengthening cycle times — the perfect recipe for increasing unpredictability. Stabilize the system (i.e., prevent cycle times from increasing) to have any hope of achieving the goal of predictability.

3. Time to Market (Flow)

Once you have a baseline and a sustainable stable system, you can begin experimenting with a view to increase flow and predictability. A fundamental approach is to begin by removing impediments. Use the scientific method. Determine what to improve, propose a hypothesis (an impediment to remove), plan the implementation, define expected outcomes, implement the change, compare the actual results to those expected, and then determine next steps: persevere, pivot, perish (or kill).

Improving flow (to shorten the cycle to discover ideas, develop and deliver solutions, and validate learning) can be discerned by the increasing rate of progress of work items from left-to-right on the team’s work-flow visualization board and by the lack of large buildups of work somewhere in the process. Flow is enabled by ensuring alignment around intent while granting autonomy around actions — state the goals clearly, but let teams navigate towards the goals by determining the best approach locally.

4. Value- or Outcome-Driven

While value is important, it has been mentioned fourth for a reason. If the delivery system is broken, inefficient, or unpredictable, it makes little difference what is fed into that system or in what order. With a stable, smoothly flowing, system you can now really start focusing on ensuring that you are providing the most value possible.

Improve your capability to define and deliver working solution increments that meet customer needs and solve their problems. Use a clearly defined purpose and these sequenced increments to align business, technology, and operations. You will now likely run into challenges with how funds are budgeted and allocated to projects and/or products. Having conversations with Finance about alternate approaches will now be much easier because you (IT) already have a track record of execution and predictable delivery.

Being value- or outcome-driven implies building the right thing, being focused on product rather than execution, and having the skills to figure out earlier what to make. Start with the end in mind then ask, “What experiments can be run to affect the outcomes?”, “What capabilities do we need to develop to realize the outcomes?”, and “What behaviors do we need to develop?”

5. Organizational Agility

There is a laser focus on identifying measurable goals, determining probable success factors, identifying necessary conditions for those factors to occur, and implementing a plan that helps create the required necessary conditions. Leaders are proactive in designing organizational structures, rules, and policies that enable agility throughout the organization. Agile practices have permeated the culture and have eliminated most or all of the business pain points. Finance, budgeting, HR, and governance groups are all agile and can work with agile artifacts for satisfying audit/governance needs.

Everyone understands the dictum that “Lean is not about removing waste but about problem solving towards a vision!” and without prompting continually strive to improve himself, the process, and the organization. This is also where leaders can set challenging goals for teams and help them improve via self-development learning cycles.

An Approach to Achieving the Agile at Scale

Table 1 provides a little more information on steps 2-4 discussed above for improving your organization’s ability to deliver value to customers. Over time move from Level 1 to Level 3 for the three areas: Product, Team, Management.

3-step-approach

Table 1. Steps to realizing Agile at Scale

This journey is not easy and can easily take you a couple of years or more to become truly nimble and customer-focused. There is significant additional detail about the practices recommended and behaviors required for each of the nine cells above.

Conclusion

While this blog provides a high-level view of the approach we recommend, it doesn’t go into all the detail needed to move from stage-to-stage (visibility to predictability to flow, etc.), what aspects to pay heed to, and how to sell and implement the changes.

We would love to continue the conversation with you. Reach out to us if you’d like more information or if you think you aren’t seeing the business benefits you had originally envisioned before starting on your agile journey.

 
2 Comments

Posted by on February 8, 2017 in Agile

 

Tags: , , , ,

Three things that matter when embarking on an Agile transformation

When it comes to transforming an organization to Agile, it is far too easy to get caught up in the details of implementing a methodology and its associated practices and lose the focus on realizing desired Business value, i.e., to lose sight of what you are trying to achieve and why. The goal of a transformation is never to implement Scrum, or XP, or SAFe, or what have you; rather, the goal is always to get better at achieving the value that matters to the organization. Having well-defined outcomes and a plan for achieving those outcomes is key to keeping the transformation effort on track.

Simply training employees on the mechanics and implementing the recommended practices often does not lead to, nor guarantee, the desired business results. In our experience helping companies transition to Agile at scale, we’ve found that they struggle to achieve desired outcomes when they start out focusing on the “how” and fail to appreciate the “whys” that underlie the practices. These organizations frequently do not understand which bits can be adapted, which can be jettisoned, and which practices and tools could enhance the process. As Al Shalloway, CEO of Net Objectives says, “Practices are designed to solve a problem in a context. When challenges occur, look at the intention of the practice. Then, using principles, look for an alternative to the practice.” To that, I would add, “Finally, make your decision about what to do next, but define your expected outcomes before starting your experiment (or implementing the countermeasure).”

Nearly all organizations want to improve business measures that matter and the best way to do so is to improve flow, quality, and value delivered. When we reduce the principles of Agile and Lean to their essence, we discover that the goal is to focus on, and continuously improve, the effective, efficient, and predictable delivery of customer value — development teams strive to delivery more-and-more value with minimal waste; managers in turn seek to create an environment of dependable, unimpeded, measurable flow. Success, therefore, requires a focus on three critical aspects: flow, quality, value. These are not one-time improvements, but a never-ending series of small improvements.

1. Focus on: Flow and Predictability

Flow is the regular, never-ceasing, forward progress of products, services, and information to the customer, who might be an external client or user or an internal stakeholder. It is work moving from one step to the next, within the value stream, without delay or rework. Improving flow often involves removing roadblocks that delay or prevent the continual forward motion and throughput of work.

Closely related to flow is predictability. Predictability implies the ability to accurately answer, “When will it be done?” Making your processes more predictable and being able to reliably and consistently meet delivery commitments is the first step in building trust with business partners, stakeholders, and customers. However, before worrying about predictability, you first need to ensure that there is complete transparency and visibility so that managers and team members can see what is really happening in order to make informed decisions.

Without visibility, it is nearly impossible to make and keep commitments with any degree of certainty. Attempts to improve flow simply become shots in the dark and it is not possible to see and evaluate the effects.

The last aspect of flow is the notion that people are engaged and productive when there is a match between their skills and the complexity of work required — lack of required skills can lead to fear and stress; mundane work to ennui. Self-organizing teams should keep this in mind when allocating or self-selecting items to work on.

2. Focus on: Quality

Quality is assessed by the customer. By definition, the quality of a product or service is the degree to which a set of inherent characteristics fulfill a need or expectation that is clearly stated, generally implied, or obligatory. It is more than simply being free of defects. Quality involves meeting customer expectations. And yes, some of these expectations can be subjective. Interestingly, performing higher does not necessarily mean higher quality if the buyer balks at buying the unasked for add-on functionality.

It is a common misconception to believe that you have to proceed slowly in order to produce quality work. But, speed and quality are not dichotomous options and they should go hand-in-hand — you can get better quality and a higher rate of work completion. Companies that invest in automation and in preventing defects (vs. finding them at the end of the development cycle) find that quality does not have to be compromised for speed. Quality affects flow. When work is not done right the first time, when quality is not built into the process (vs. checking for defects after the fact), and when the product or service does not meet the customer’s need, we end up with rework and defects that have to be addressed. This unanticipated rework makes it harder to be predictable, impedes flow, and delays completion of work. Speed and quality are not mutually exclusive.

3. Focus on: Value

Value can be a fuzzy concept. It can be viewed from different perspectives: customer, business/organizational, operational, and individual and each will have likely have a different understanding of value. Imagine how each perspective might think about a “pizza delivery business.”

  • A pizza maker competing with other pizza makers for a single job at a local pizza store
  • The manager of the pizza shop
  • The owner of the pizza shop to whom the manager reports daily or weekly
  • The customer who ordered a couple of pizzas to be delivered to her home

What is perceived to be “value” by one role may not be by another.

Some companies make the mistake of losing sight of who they are building the product or service for — delivering business/organizational value is important but being uninformed about what customers’ value is extremely dangerous. To complicate matters, value is not constant — things can become more or less valuable over time depending on the circumstance.

Once you’ve agreed on what value means and who is being provided that value, you need to define the minimal cohesive increments of functionality that together will meet the needs of the target customer by either solving a problem she has or by making her work easier, better, or faster. To do this, you have to take the time to understand your customers and stakeholders, their problems, their needs, their actual usage of the product or service. This practice of customer discovery is deceptively simple: form hypotheses about the product, about the problem that your product solves, and test these hypotheses with those who could be your potential customers to verify, iterate or exit. An “I already know what customers want” attitude, based on their perception of market opportunity, is a good indicator of failure. Additionally, you need to verify or refute your product’s value proposition, its sales roadmap, business model, etc. After all, you don’t want to develop something if it isn’t worth it to your enterprise.

Lastly, defining a clear value metric across all the portfolio of work being considered makes it possible to sequence the order of implementation of the minimal cohesive increments based on Cost of Delay or another mechanism.

 
2 Comments

Posted by on February 8, 2017 in Agile, Improvements

 

Tags: , ,

Our Agile #transformation is struggling without #management support — can’t we just fire them all!

While nothing is easier than to denounce the evildoer, nothing is more difficult than to understand him. ~Fyodor Dostoevsky

A significant number of agile coaches and agile zealots often portray managers as evildoers. But, how often do these agilists:

  • Practice empathy and try to put themselves in the manager’s shoes?
  • Consider the very real fears that managers have to face — fear of looking silly, fear of all their effort over the years coming to nought, fear of being sidelined, fear of taking “unnecessary” risks, fear of not delivering and looking bad?
  • Say what needs to be said without embarrassing, humiliating, or otherwise offending the manager’s self-worth?
  • Make the managers “feel felt?” Not just heard, but also being aware of and demonstrating awareness of how the managers are feeling and the emotions they are grappling with.
  • Take the time to understand what managers want, what they feel, what they struggle with, what they enjoy, what irritates them, what they fear, what pressures they face, …?
  • Realize that managers feel lost in the new world and are asking for help in making the change stick?
  • Suggest approaches that works smoothly and take a load off managers’ shoulders?
  • Spend time 1-on-1 with the managers to guide them in impediment removal and more importantly in creating the right structures of fulfillment?
  • Spend time 1-on-1 with the managers in co-designing a step-by-step approach versus just talking in generalities?

Not very often, I presume. It’s so much easier to point fingers than to consider your own role in exacerbating an “unseemly” situation. So is it any surprise that a potential ally is often turned off by the behavior of the change agents?

 
1 Comment

Posted by on September 22, 2015 in Agile, Coaching

 

Tags: , , ,

Why most #agile and #lean #transformation efforts fail

I’ve seen far too many change efforts run into a stone wall and fail to achieve the initial expected results. In simplistic terms, C-level managers who are less than happy with the results they are getting (or not) determine that doing things differently is the right way to obtaining the better results desired. Makes sense logically, but works rarely!

People do the things they do for a reason — their actions are guided by their beliefs that have been formed based on past experiences. For example, I might believe that making mistakes is career limiting because I experienced this firsthand somewhere or saw what happened to a peer who tried to make an improvement and “failed.” Beliefs like this may lead me to value, “avoid risk taking.” Now when you, the Agile proponent, come to me and say, “Alex, I’d like you to experiment and inspect and adapt,” I’m more likely to have a visceral reaction and to write you off. Experimenting might make sense theoretically, but that’s not my perceived reality. And that’s the challenge — asking people to do different things (or things differently) doesn’t work if what you are asking is counter to the person’s existing beliefs and conditioned values.

Successful change happens when the champions of the change attend to the management systems (leaders’ behaviors, expectations, tools, common practices, etc.) and also engineer new experiences that lead to a questioning of the validity of existing beliefs. Sadly, few leaders are good at either.

 
Leave a comment

Posted by on September 16, 2015 in Coaching, Improvements

 

Tags: , ,