Today’s Customer Is Not Going To Be The Same As Tomorrow’s Customer

go-where-the-puck-is-going

There’s an old Wayne Gretzky quote that I love, “I skate to where the puck is going to be, not to where it has been”. Similarly, an organization must focus the business around tomorrow’s customer, not today’s customer. The organization must continually learn from its customers to guide the business. It is imperative that the organization considers where, why and how the customer will be using the product.

For example, consider the evolution of the personal banking user experience. Traditionally, the bank’s customers would ask the teller at the bank to complete their transaction. Banks optimized this by creating ATM banking machines. ATMs were revolutionary because the banks could place the units in any retail space, providing the same core services to customers, at a greater convenience and less cost (fewer tellers needed) towards the organization. Banks have continued to optimize the experience for their customer by introducing internet banking and now, mobile banking.

evolution-of-customer-service-model

Banks valued evolution over optimization. If they continued to optimize the tellers’ workflow, the banks would have highly efficient tellers without many customers entering the bank. If your organization don’t continually evolve, another organization will.

Predicting the future is not easy. If it were, I would be in the stock market. However, there are certain processes change agents can implement in an organization to guide the product:

  • Customer Councils: Regular meetings with customers to discuss the product
  • Active User Community: Having an online presence where the users can interact with each other and your organization’s employees. Building active user communities will retain customers who may have been looking at other options.

Organizations that focus on maximizing ROI will inevitably fail. The organization fixates on the receiving the highest margin possible at the cost of losing sight of the customer. Instead, I suggest that the organization should focus on customer value, as satisfied customers will continue to buy the organization’s product thereby generating more ROI. This is a win-win for both parties.

David Dame

 

tomorrow's customer

At the end of the day, organizations need to transition from operational to strategic. They must take risks to predict and target where the customer is going, not just where it is today.

Building Change Momentum

This is the final post in a three part series. Please like, share and comment. Please click here for Part 1 and here for Part 2.

Suppose you have a persistent group in your organization who has been completing its job the same way for a significant period of time. They refuse to change despite multiple suggestions on areas where the team could improve. Why will the team not accept the change?

The group refuses to change because it does not see benefits of changing. Transforming an organization is a time consuming process and change agents will commonly go for the home run when implementing change. Spontaneously implementing a “large” scale change event every few years will lead to changes not supported by employees. Employees need to see the short-term wins, organizational improvement that can be implemented in 3 to 18 months. These short wins will create momentum and keep the organization engaged.

 

Organizational change is not a one-sized fits all solution. I size change into one of three sections:

  • Small: Small scoped, operational changes that are not dramatic changes to the organization. The scope of the change is contained in one function, department or level. For example, removing waste from your current processes (See my blog post on Organizational Hoarding for more).
  • Medium: Medium sized changes commonly span more than one function, department, or level within the organization. For example, ...re-defining a new workflow that spans across departments like release processes.
  • Large: Large scope changes span across numerous functions, departments and/or levels, involving a large number of people. These are changes that are radically new or foreign to the organization’s current environment or culture. For example, introducing new performance review practices, huge organizational structure/team/people design, a Fail Fast, Fail Often methodology, or continuous delivery/integration.

 

In my previous blog post titled “Is change ever over? Do we need middle management?”, I discuss how an organization must move from sporadic transformations to an environment setup to continually change if wants to succeed in today’s ever-evolving environment. Implementing major change takes time. Organizations cannot continually rollout “large” scale changes one after another. This will lead to chaos. Instead, the change agents should implement a few smaller, operational changes in between larger, strategic changes. Implementing these smaller changes will give the change efforts immediate visibility, manage the resisters of change, and provide all three layers (i.e. top, middle, and operational)) of the organization real feedback about the validity of the change.

The Change Team will learn how to work together

More importantly, the knowledge the ‘change team’ will gain from working together on small ‘quicker’ changes will help them evolve to a more cohesive, stronger team. The change team will go through phases that all teams do. Bruce Tuskman defined the five step process that most teams follow to achieve high performance. Many newly formed change teams never progress beyond the first stage: forming. In this stage, team members are cautious, positive and polite. Some might be anxious with the new team members. It is imperative that the change team moves past this stage and onto the next stages quickly. The team will need to deal with its own dysfunctions before it can tackle the organizations’. The longer the change team remains uncomfortable with each other, the longer implementing change will take. Team members must feel comfortable enough to giving and receiving feedback. Rolling out change cannot be done individually, the team must roll out the change as a unit together. Change teams are a microcosm of the organization. They need to update their membership regularly to provide new insights, perspectives, and  to adapt to the ever-changing environment.  

At the end of the day, the organization’s main goal is to continue delivering products or services, not implement changes. As change agents, your role is to make the implementation of changes as seamless as possible. Smaller sized chunks will prevent a large disruption in the workflow. The changes will allow the employees to grow accustomed to environment that is continually evolving, refocus the status quo and continue to make the organization deliver high value services.

David Dame

Organizational Change and the Vertical Slicing Approach

When implementing an agile transformation, do you start from the top or bottom of the organization? My experience has shown it is best to take a complete vertical slice of top, middle, and the bottom.

“Organizational design is the methodology which identifies dysfunctional aspects of your organization’s workflow and realigns them to fit current business goals (and supporting values).” (Dr. Allen, 2012).   The best way to align the organization’s workflow to fit the current business ways is an approach I call “vertical slicing”. 

Vertical Slicing is a holistic process where an organization is split the organization into small cross level and cross functional change teams. Each change team consists of members from each level of the organization (i.e. Scrum teams, middle management and executives). The organization will be moving together as all three levels will be involved in the implementation of change. Selecting a few of these teams as the change champions (pilot teams to test the change on), will provide you with a small sample of the organization to experiment with and test the interconnections between the different levels of the change. This is a cross-level approach.

There’s an important distinction to make between a cross-functional approach and the cross-level approach. The cross-functional approach involves removing barriers between roles within the same level. For instance, an organization employing the cross-functional approach would share knowledge between developers, testing and QA. The cross-level approach involves removing barriers between different levels of the organization. For instance, an organization employing the cross-level approach would be sharing relevant knowledge between finance, developers, and post-sales. The vertical slicing approach encourages you, as change agents, to combine cross-functional and cross-level approaches forming teams of different roles and different levels. This will increase the variety of your change champions and limit the areas of the change that are not tested.

Any change moving the organization from traditional job models to new job models, from individuals to teams changes the interconnections of the organization. To re-align these interconnections, you will need to visibly show the employees how this benefits them. This can be achieved through incentives:

  • Learning Paths: Employees will be able to interact with different facets of the organization. This allows them to experiment and learn. This will motivate employees as they will see the vertical slice teams as way to progress through the organization.
  • Performance Reviews: Employees will be evaluated on how well they interact with their new role from individual to  team

Vertical slicing will improve the communication between the different levels of the organization thereby increasing the feedback loops and ensuring the middle management stays involved. The middle management's main role is to find the balance of where the organization currently is and where it wants to be. However, the middle layer is typically forgotten about as the change agents prioritize convincing the executives to implement the change and the Scrum teams to adapt the change. Without the middle management, there is a lack of communication between the organization’s executives and Scrum teams. Implementing vertical management will start the the transformation of your traditional middle managers into new middle coaches (Providing customer focus/empathy, company values, relationship/professional development). 

Vertical slicing will guide the organization towards a culture of innovation and leadership. Each “change team” will consist of different levels of the organization where each level will be interconnected and allow the change agents to validate their experiments. Yielding control of change validation from the individuals to the teams will push autonomy down and build an environment where decisions can be made at any level. 

David Dame

Change is specific to your Organization...let your organization own their change.

Through my years of trial and error,  I have learned there is no one size fits all solution to transitioning organizations to agile..context is king! Every model is based on different organizational contexts. Each model’s context has its own starting and ending point. There’s no guarantee that your organization is at the same starting point and aiming to end at the same ending point.

 

Organizations commonly introduce (SAFEe) large agile models. A common misconception is if it’s big and prescriptive, it must be good! However, this leads to high disruption to the organization and a steep learning curve. This slows down the people as they must use new, foreign practices. The organization’s rush to become agile overnight by introducing a heavy weight model causes them to   lose sight of the fact that the primary purpose of the organization is deliver products/services, not to be agile. When organizations transition to agile, they need to walk the line between gaining adoption of agile practices and continual delivery of their product/service. They do this by phasing their rollout as a series of experiential learning by groups of people who do the work.



The Composite Model

I have developed a composite model based off the works of Jason Little. This model is separated into small bite sized chunks that can be consumed in any order. You do not need to implement this model linearly.

 

To achieve agility , you must fully understand the organization’s context. Organizations are built from the efforts of their people. These people can identify the impediments that are prohibiting their  team from delivering product or service to market quickly (i.e. the pain points).  Identifying impediments requires you to visually illustrate where the impediments are and select employees at all levels of the organization who are affected by this change. Involve them with every step of the process.  (HINT: This is the topic of the next blog post. Subscribe on the right and I’ll email you when the post comes out)

 

Once the impediments are identified, organizations should list out some possible solutions and identify success criteria for each impediment. Next, they can run experiments to test each proposed solution and solve them incrementally. The solution to the impediments may not be found from the first experiment. It might require several trials until the desired outcome is found.

 

This model is fairly generic intentionally. There’s no magic formula to solve how to make your organization agile. Every organization is different and will be facing different impediments. It’s up to you as the change agents to determine what those impediments are by encouraging small, incremental changes and prioritizing the people ahead of the processes and tools.

 

Organizational Agility is a journey, not a destination.

David Dame


This is the first post in a three part series. Please like, share and comment and I’ll be sure to update you when the next post in the series comes out.

context-is-king
 

Is your Organization hoarding?

If you have seen the TV documentary series Hoarders which depicted the real-life struggles of people who suffer from compulsive hoarding. Some victims suffered so severely that they were often drowning within their own filth. The disorder is immediately obvious to family and friends.

Don't be a process hoarder.

Don't be a process hoarder.

Similarly, organizations today are process hoarders. A large number of processes have been built for some purpose at a point in time that no longer serves its purpose. What commonly happens is that new processes are added in isolation without seeing how they all work in concert. The danger with continually adding processes is that organizations can’t see the process hoarding until it’s too late. Process hoarding is not immediately visible. It has reached the boiling point now as as organizations in pursuit to get products out faster are being suffocated by a pile of inefeffective and redundant processeses. All these processes need to be mapped into a big visual picture for us to analyze how an idea turns into revenue.

If we can’t see the processes of our organizations, how can we observe and improve them?

How do organizations see its process hoarding?

Visualization is the process of creating the big visual picture to represent what is occurring within the organization. It yields a graphical representation of the organization's processes. Visualizing the process is a team sport. This allows for group collaboration to generate ideas for experiments to improve the process. The people that work within the process should be the ones that work to improve them.  Working in a highly collaborative group environment will increase validity, employee buy-in and reduce individual blind spots. The experiments allow the organization to test multiple ideas instead of just selecting one. Check out Jason Little’s book titled Lean Change Management if you would like to learn more about visualizations through experiments.

Visualizing the process is a team sport

Visualizing the process is a team sport

In any agile framework (e.g. Scrum), we’ve provided the Engineering teams (or IT teams) a structure where they can work transparently and are able to inspect, adapt and continually change. Working transparently minimizes the process hoarding by increasing the visibility of our work where everyone can see the system under the same lens. This will be a difficult change to adopt for some, however, innovation does not come without change and change does not come without pain.

Before adding new processes, I encourage you to take a step back and ask yourself “Is there anything that can be replaced with this new process?”. If so, eliminate the redundancies until the organization is as flat as possible. If you wait until you’re suffocating by a pile of processes, the processes will grow to in complexity and be more difficult to eliminate.

Do yourself a favour and continually keep your house clean!

David Dame

Is change ever over? Do we need middle management?

Is there a way to help organizations move from a Change Transformations mindset to a Continuous Change mind set?

Traditionally, organizations implement large scale change events within their organization by spontaneously have an epiphany and transform every few years. 

The frequency of these transformations has rapidly increased from once every 10 years in the 1980s to once every two years in the present. 

Today, companies must sustain a continual change pace if they want to succeed in today’s ever-evolving environment. To achieve this, the organizations must prepare to be in a continually changing environment. 

This means collaboration at all levels, from executives all the way down to their development teams (or IT teams). Continual change helps make the uncomfortable - comfortable. 

When the executive level decides on an organizational change (e.g. going agile), the executives expect that once they announce it, it has happened. There is lag time between the decision and achievement. Agile is recommending to continually change. This explains why the change frequency has increased because we are moving towards a stream of continual change as the agile models that we’re instilling insist that we do.

In any agile framework (e.g. Scrum), we’ve given the development/IT teams a structure where they can work cross functionally, to be able to inspect, adapt and continually change. Executives have traditionally held their weekly meetings where they collaborate cross functionally as they have oversight of the entire business and pivot due to business conditions.
 
The corporation must be able to experiment, not just optimize. As change agents, we need to realize that the organization must continually change and set up a cross functioning structure for middle management.

What we failed to do is create a structure for the middle management layer. There is something special in the middle. We need to create a structure in which they collaborate and meet regularly in a cross-functioning way.

This provides two main benefits:

  1. Organization is continually changing all together
  2. Reduces communication distance from executives down to teams delivering product or service.

The middle management is crucial to the success of the corporation because they understand how all the functions of the organizations work and can find improvements to be made. They provide an objective higher level view and are aware of both the development team and the upper management’s goals. We need to utilize middle management. Not eliminate them. 

Agile has not provided a strong vision on what middle management does in an organizations. These managers (I prefer the term leaders) are champions and coaches. They are championing many of the changes and are the special glue between executive strategy and execution. They aren’t cogs in the organization’s wheel; they’re the ones that are going to help support/mentor/influence employees building a relationship, and drive change. 

As companies grow, the distance from the people building the product and the customer increases. The people lose sight of the customer they are solving problems for. They lose empathy and context. Middle leadership helps fill in that gap by keeping their people in the mind space of the customer. While building a relationship and satisfying their people’s need for inclusion, development and growth.

Better congruence between strategy, short term goals and execution depends on having a regular cadence set up of cross-functioning middle leadership. The middle leadership and upper leadership must be working together to support the groups entering the change to achieve balance. Otherwise, there are two ways of working: the executives sticking to their traditional method and the development teams implementing the new method. The only way the organization will change is if the organization moves together and receive continually feedback from both parties.



Middle Leadership has a major role to play in change. We need to help give them the tools to work in their new environment. They need to transition from delegation to enabling, managing to coaching, project monitoring to relationship building with their people,  and translating work back to customer needs.

David Dame

Are your HR Practices Lean Enough? - Scale Engagement Agility

In today's rapidly changing world of disruptive innovation organizations need to be nimble enough to support this.  We are asking our workforce to do this by becoming 'agile'.  We want the agility to quickly pivot and seize new opportunities.  We want to deliver to market sooner. We want our employees to innovate and deliver highly complex work more rapidly.  

Today's organizations are moving away from large transformational events and moving toward doing continuous change.  These organizations are flat.  How do we create a culture that inspire employee engagement to enable these organizations to thrive in this continuous change?

Agility is no longer just an IT or Engineering movement, it is something that the entire organization needs to embrace.  For this to be effective and long lived it needs the full involvement of human resources, organizational leaders, and change agents.  There is some thought leaders that are already forward thinking and creating events for all these disciplines to come together to align to this common purpose.  The Spark the Change event held in Toronto facilitated this movement.

"Individual commitment to a group effort--that is what makes a team work, a company work, a society work, a civilization work." --Vince Lombardi

In my last blog post - Scaling Engagement Agility, I voiced my concern Agilists (change agents) to think beyond scaling frameworks and tooling.  As Agilists, we need to rethink and adapt our beliefs.  For example, in the 1990s and early 2000's we took a strong stand on co-located teams.  We said this was a critical for an organization to adopt agile.  Although, co-location is the highest fidelity for interacting, it does not match trends in the workforce of home offices.  The technology tools available for collaboration has narrowed the gap of communication challenges with distributed teams.  This can help support the workforce trend of working from home or in coffee shops.

HR traditionally believed it's function is to put order and structure to the organization, yet Agile believes in rapid change by breaking down structure and order. - James Cleaver

Human resource practices need to adapt to this new fast-paced environment.  They need to become 'lean', they need to become 'flexible', they need to become 'agile'. There is no longer a guaranteed long relationship between employee and employer.  The balance of power used to be with the employer. The employer would be their only one for the duration of the employee's career.  In today's world there is more of a balance between employer and employee.   

Our workforce doesn't look at getting a job with you and staying there the rest of their lives unconditionally.  They see their job as a reflection of who they are, not merely what they do to earn money.  Our employees will always desire to grow and evolve because of this connection between what they do and who they are.  They have more opportunities available to them.  No longer are they restricted by the geographic location.  They have an ability to work for any organization around the world.  

The average worker today stays at each of his or her jobs for 4.4 years, according to the most recent available data from the Bureau of Labor Statistics, but the expected tenure of the workforce’s youngest employees is about half that.

Ninety-one percent of Millennials (born between 1977-1997) expect to stay in a job for less than three years, according to the Future Workplace “Multiple Generations @ Work” survey of 1,189 employees and 150 managers. That means they would have 15 – 20 jobs over the course of their working lives!

In this new equilibrium of power we need to treat our employees like potential customers.  I always hear the phrase that we need to make it easy for customers to do business with us.  I also contend we need to make it very easy for employees to work for us.  So how do we create an employee centric atmosphere in this new workforce?  We need to take a holistic approach in creating this employee centric environment.

Dr. Philip A Foster stated, "It was predicted that by the year 2000 that less than 50% of the working population would be in full time employment. In 2011 the number was actually less than 45%. If we play that trend out, by the year 2040 it is anticipated that there will be less than 30% in full time employment."

What are some things we can look at to connect with employees quicker and continually?

Job models.  How do we adjust this for the new rapid workforce?  If we want our organizations to innovate and change, how can we lock down long term career paths?  We still need some sense of how an employee will fit and grow within an organization but it doesn't make sense to make them so long and rigid.  Instead of projecting their career for the next 5 to 10 years we should shorten the horizon to 2 to 3 years.  We keep these as lean and flexible as possible.  As your organization innovates and changes new roles and job models will arise. Keeping open and flexible models allows employees to see themselves in a continually changing organization.

Training.  How do we training budgets closer to the employees?  How do we allow for more autonomy to the person of what they can choose for training?  If the training can only be approved based on today's goals, how do we open our employees minds up to training that might help the organization pivot to new opportunities?  We need to make these resources closer to the employee so they have more direct access.

Performance reviews.  In today's environment of rapid and continual change, I believe we need to accelerate from twice a year to continual performance reviews.  Continual performance reviews are just continual feedback loops.  These feedback loops are no longer just between manager and employee, but all the people that this employee interfaces with so they get this 360 continual view.  This continual feedback allows for continual positive reinforcement, frequent course corrections, and initiatives as needed.

Building a relationship with your people.  Your regular touch points with your employees need to be frequent and about them. This is all about them, not their projects or tasks.  Where do they see themselves? What's on their minds?  What are they dealing with.  If you are not doing this regularly, I guarantee that a recruiter from another company is. In today's connected world outsiders have access to our people and they know it's about them to steal them away.

The whole organization needs to work together to retain their best talent and keep them engaged.  No longer can there be disconnected independent initiatives working in silos.  We all need to work together HR, Leaders, Agilists, change agents and others.  I would love to hear your thoughts and what your organization is doing.

"Coming together is a beginning. Keeping together is progress. Working together is success." --Henry Ford

David Dame

Please join the LinkedIn Group to have discussions and share what your organization is doing on Engagement Agility



Scaling Engagement Agility

“To win in the marketplace you must first win in the workplace.” - Doug Conant, CEO of Campbell’s Soup

To create Organizational Agility you need to find the harmony between People, Process, and Tools.  Agile speaks of putting people first, however from my experience, people are the poor step child to process and tools.  People should be the driver, not the passenger.  Creating Organizational Agility means scaling the employee engagement to have and maintain the culture of a start-up.  My experience in scaling agile across large organizations is that even when you put the right process framework and practices in place, you are still missing something.  People are going through the motions but there is a lacklustre of excitement.  They are 'doing' agile, but they are not 'being' agile.  They don't have that passion to innovate the product or how they're creating it.  

People are the heartbeat of the organization.  They are the ones who represent you to your customers.  They are the ones that define you.  Their skills.  Their talents.  Their passion. The intangibles that only they bring as a person.  

If you look at start-up they have very few processes and tools.  However they have a collective passion to get product or service into the market place.  This is because they have the people who are emotionally vested in a common goal.  They know the 'why' behind what they are creating. They know what they individually contribute toward that goal.

As organizations grow, or scale, they lose sight of this.  They spend less time recruiting for the right people (focusing on the skills rather than behaviours), reduce training budgets, don't invest in coaching, and merely just lose regular touch points with their people.  They try to replace this with process.  Process can help people go through actions in a similar way, but does little to nourish that passion that motivates them to do something a different way, a better way.  Why do we move away from focusing on our people?  We know it works.  Process can't scale the behaviours, talents, intangibles, or passion of employees.  We need to foster people engagement in order to get bottom-up innovation.  This will build the culture you need to support agility.  

Instead of process scaling, think of engagement scaling.  Engagement scaling is how you build within your organization mechanisms to keep people passionate and purposeful.  

There is no silver bullet. This takes a lot of time and work. You need to build a relationship with the people.  

You need help them understand the problems you're trying to solve for your respective customers or market space.  Building that customer empathy that helps them understand the "why" the company is doing what they're doing.  The more they understand the problem the more collaberation and ideas to learn different ways to solve these problems.  They get vested in the purpose.  This relationship will make them feel more comfortable to propose and create innovative products and services because they are getting more insight from you.

Continually share the organization vision.  Explain how the organization is going to establish themselves in the marketplace.  Build the excitement.  Explain the values of the organization so that your people understand how the organization wants to be seen to the rest of the world.  Connect the dots to how your department or team will contribute to achieve and embody this.  Share your challenges...be transparent.  This will help them feel connected to helping you solve these challenges.

Most importantly, create a bond with your employee.  Have a deep understanding and interest into their goals.  What is their needs as an individual.  How can you help satisfy those needs.

 

Build a culture of 'fail-fast', learn, and make adjustments.

Develop problem solvers.  Let them discuss the challenges they are facing.  Resist the temptation of giving them your answers to these challenges.  Actively listen and ask questions to help them get a deeper perspective of their challenge so that they can come up with options to solve them.  Your job as a leader is not to figure out everything, but to coach your people to figure out solutions to their own challenges. Help them reflect on what they learned when they tried something and it didn't work.  

When they have a win, share in their happiness.  When they accomplish goals give them time to reflect.  Have them reflect on what they've learned from the success.

There is been countless studies that show that people are more productive when they feel the organization shares in their development and success.  This is all on you as a leader.  If you don't have time for this, question your role.  Engagement Agility is developing leaders throughout the whole organization to create an ecosystem of continual engagement.

How do you do this? I will be doing a series of blog posts digging deeper into the topic of scaling engagement and employee development in the agile world.  I will share things I have implemented - pragmatic strategies to achieve this.  I am calling this topic Engagement Agility. This is my passion that is inspired me to start writing a book on how to build this within large organizations. 

“When people are financially invested, they want a return. When people are emotionally invested, they want to contribute.” - Simon Sinek

David Dame

Please join the LinkedIn Group to have discussions on Engagement Agility

 

It's all about the results

On your journey towards organizational agility you will have to use many tools out of your toolkit.  You will use agile/lean models and practices, older models and practices, custom solutions, and common sense.  Organizational agility is about achieving the results not the means of getting those results.

Nobody is going to give you a gold star if you implement a purely agile solution.  There is no industry model that can be implemented out of the box to meet your organization's needs.  These models are a good start… But any transformation agent worth their weight does not stop there.  They involve this model in through numerous inspect and adapt cycles to constantly fit the context of your organization.


Authority vs. Influence in Leading Organizational Change

Authority – the power or right to give orders, make decisions, and enforce obedience.

Influence – the capacity to have an effect on the character, development, or behavior of someone or something, or the effect itself.

Authority is power.  If you want to rule the galaxy by power, then join the dark side of the force.  Influence is ability. If you want to lead the galaxy by working together with the citizens to solve the problems, then continue your training to become a Jedi Knight.


South_Park_Respect_Authority_Gray_Shirt.jpg

 

 

 

 

Early on in my career I would always say to myself… If only he had the authority to make these things happen. It would be easy. I had some misconceived notion that being able to say what needs to be done would equate to those things actually being done.  I would simply create a vision, tell the organization that they had to follow this vision and I can move on to the next challenge.

As I progressed through my career I moved into positions with authority.  My dream finally came true… I would not need to spend a long time campaigning to the mass number of people to get their buy in, I could simply give the marching orders.  Although this helped change move quicker, it was not long-lived.  The moment we achieved the goal or I redirected my focus to the next opportunity, the previous initiative would fall back to its previous state.

Authority gives you immediate change but it's not long-lived. You can tell somebody what to do.  They may do it for the moment.  Unless they understand what the problem is that you're trying to solve and why you're doing it, they will not continue doing so after the change.  

Authority causes people to act on orders/tasks.  Influence is working with people to understand and solve the problem collaboratively together.

In dealing with organizational change, I have learned a great deal of what is needed to help move the critical mass from their current state to the desired state, and to ensure sustainability.  I have had to develop a skill set to connect with people, build their trust, unleash their passion, grow their confidence, and move toward a shared vision.  Being able to influence takes a lot of work.  You don't get there overnight.  You need relentless pursuit. The ability to be open to refine the vision as you get insight from these people.  Give autonomy to those people affected by the change.  Lead by example.  Build long-lasting relationships.  Earn respect.

Influence is when others accept your ideas or direction. It means that people have internalized your message. They believe it. They might even be excited about it. 

Authority causes people to act on orders/tasks.  Influence is working together to understand and solve the problem.

For long-lived organizational change you need to put in hard work toward influencing the people.  People are very habitual.  To develop these habits it takes time.  We do not quit bad habits, rather replace them with good habits.  Make being a positive influence your habit.  Having influence with others does not only make you a fantastic change agent, it also makes you an fantastic colleague.

In future posts I will speak to this specifically in the context of Organizational Agility Transformations.

David Dame

Standardization and Autonomy - Can they co-exist?

Companies have two avenues for growth: acquisition, or organic growth.  Regardless of how they are growing their increasing size increases the difficulty of the company successfully responding to change.  Retaining as much as possible of advantage of that small company’s ability to rapidly pivot can be a key element of a company’s success.

In the past, large organizations were seduced by the notion of having a standardized process across all their product teams within the organization.  I can understand the appeal of having one “best process” uniformly across the organization.  However this appeal is based on a manufacturing paradigm of working with tangible items which does may apply in other industries.

Process standardization at the organizational level gives the benefits of:

  • common reporting/monitoring processes, formats, and channels
  • simpler governance decision-making

One other presumed benefit is a reduced cost of moving teams around the organization, but this is rarely realized because intellectual work cannot be mass produced.

A model of a large organzation

A model of a large organzation

Having a standardized process across the organization forces process design to accommodate the lowest common denominator.  It also takes a larger effort and time for the organization to be able to pivot and adjust  to move as one entity because of the critical mass.  From a people perspectives, employees feel like there a cog in the wheel and they're not motivated to improve how they work because they believe it is a big bureaucratic exercise (which it usually is in large organizations) that "other" people have bestowed down on them.  This standardization comes at a huge cost for productivity and efficiency within the majority of the product groups. 

Giving product groups (and teams) autonomy empowers them figure out the best way for them to work as smaller units to optimize productivity and efficiency.  Smaller teams can have shorter feedback loops and can inspect and adapt more frequently and progress more quickly.  Smaller scope for process design allows them to optimize more precisely because it is based on a smaller set of skills, expertise, team makeup, and particular product/technology.  

From the people perspective, giving the individuals autonomy to define how they work, how to best optimize their own work leads to higher morale, motivation, and productivity.  Even when the technology changes over time, giving the autonomy at the smallest reasonable unit allows them to rapidly go through and adopt the change quicker.  It also allows each product group (and teams) inspect/adapt/change at the rate that is within their threshold and within the context of their business needs.

Autonomy is one of the factors a motivation that Daniel Pink talks about in his book Drive.  I think we can all agree that we want to motivated workforce.

The downside of that autonomy is that the operations of the organization becomes less transparent.  Or simply, make it more complex to be able to see if your organization is moving forward.  

Can you marry the two to get the best of both worlds?  In my experience, YES!

You can do this by loosely defining workflows and processes from the above at a very high level and .  This way the organization knows that the highest level of the flow that goes through to deliver products or services.  When product groups (even teams within the groups) create their own processes and practices they do it and to detail out between the boundaries that they have to play with.  The organization themselves reports on the high level processes to be able to monitor how all the work is progressing to be delivered.  Each product group can define their own product group practices and processes for all the teams within their product group, trying to define them at the highest, but still responsible level to allow individual teams discern autonomy and how they specifically meet those.  

A good example would be The Definition of Done.

The organization will have guidelines that they want all their products and services to ensure encompasses what they call a releasable product.  Each product group will have their level of definition of done that meets their particular products needs in order to transfer the product is ready to be released to the market.  Furthermore, each team will have their own specific  definition of done that addresses all of the above in any specific things that they feel they need to do to produce releasable software.  This should help ensure transparency from the top down.  This also allows for easier updates at the appropriate level without it being all or none.

One thing that I did not mention in this post, is that this hybrid will cause more work for external auditors because they will not have one central place to review the processes.  However, I would rather put the burden on a few than many of the organization.  The regulatory auditors are going to have to just the way in which they audit software companies going forward to meet the new agile paradigm.

This is just one of the scaling mechanisms that I have seen prove successful.  I will be sharing more and hope to hear back from you about techniques that you have used in scaling agile across a large organization.

David Dame

Organizational Innovation requires Guts and Investment

We all have heard those stories of people on their death bed saying that their biggest regret in life was not taking more chances… I'm sure that there are companies that are no longer around echoing those same words.

Rip_Tombstone_Red.jpg

Medium to large organizations are good at putting out fires or dealing with crisis as death is imminent.

Complacency is the silent organization killer.  It is not in immediate death, rather a slow death by bleeding slowly until there is no more life in the organization to innovate and compete.

Organizations are always striving to improve their efficiency and productivity.  They put all of their time and effort into continuously improving their current processes and practices.  This is good to do, but it will only give you marginal gains. We see minimal benefit to this as people don't want to seem to put the effort in because the see a low return on their investment.

However, to achieve the biggest gains, organizations need to invest hugely in new and bold ways to do things.  They need to have the guts and take a chance to be able to embrace a managed disruptive environment to the current status quo.  They need to put an investment of time and resources independent from the ones that are running current operations to introduce out-of-the-box thinking that will totally innovate the way they deliver their products and services today.  They need a lot of courage to have a substantial return on investment.  

One Person with Courage Has Success, Others Afraid Fail

 

Referencing Dr. John Kotter's change model, as an organizational coach, you need to work with the leadership and create that sense of urgency.

Organizations (like people), have a threshold for handling change.  As an organizational coach, you need to be aware of what your organization's upper boundary is to change.  Although we strive to get them to be confident to handle the operational innovation disruption, you do not want to create an anxiety that cripples the company from functioning.  Working with them over time, you get to improve their confidence to embrace change and you also have a pulse on the upper boundary limit to which they can handle the disruption.

How can you manage this organizational risk effectively?  Use the scrum framework as a tool in leading these organizational change initiatives.  Establish a good time boxed cadence and leverage the built-in inspect and adapt component of the framework will help provide transparency to allow the organization to pivot to move toward their goal.

scrum.jpg

Your continuous improvement strategy needs to incorporate both  operational innovation initiatives  as well as continuous improvement of current processes.  These two things working in concert will help your organization to have a balanced portfolio to be able to lead and compete to an ever-changing environment to support their customers in the ever changing marketplace.

Organizations need to fully invest time & money to get a dedicated guiding coalition.

When companies go through a major organizational transformation (like bringing in agile).  The organizations that do not staff this change appropriately struggle in their agile adoption.  Asking employees to lead major operational innovations but still having to do there regular day-to-day job will stifle the innovation initiative.  Those organizations that staff  properly by either re-shifting internal resources, hiring new full-time resources, or by engaging in external consultants or change agents have had greater success in their organizational transformation.  

How do you create this sense of urgency and get the investment needed?

Develop a Change Vision.

vision.jpg

If you can visualize it, you can make it real.  You need to have a vision.  More importantly you need to communicate this vision effectively.  If you can't make this vision easily consumable to the organizational leadership team, its stakeholders, the people affected by this innovation, it will not get traction.  People already have a fear of change..  An effective vision will mitigate the fear of the unknown.  Jason Little, one of the most brilliant organizational change agent peers that I've come across has an awesome strategy on how to map this vision out.  You can review the slides here.

You can't compete in tomorrow's world with what you're doing today.  Instead of putting all your resources in trying not to fall, spend that time to be courageous enough to have your organization to succeed  Don't just say you want to do it… Put the resources into making this happen.

I rather talk about the success I have had from the mistakes that I learned from than the regret of not taking chances that might have helped me succeed.  

David Dame

Five ‘Ws’ of Code Reviews

WHY do we do Code Reviews? There are three reasons for doing Code Reviews:

1. Testing – Does the code do what it is supposed to do? Are there any errors in logic that can be corrected BEFORE we get to the test execution phase of the project? 2. Qualitative Assessment – How well has the code been written? 3. Management Supervision – Is there any code in the program that shouldn’t be there (i.e. fraudulent, malicious or unauthorized code)?

code-review-process.png

WHEN is a Code Review warranted? Research suggests that Code Reviews are up to 60% more effective at finding defects than the various forms of testing, making them a highly cost-effective way of improving the quality of the end product. Code reviews also present an ideal opportunity for knowledge transfer and skills development. More junior staff are given the chance to learn first-hand from more seasoned professionals, while the senior staff are presented with the opportunity to hone their coaching skills and pass on knowledge that might otherwise stay in their heads, preventing them from moving on to more challenging work. No wonder they are considered a “best practice!” While it is highly recommended that they be included in the overall quality assurance plan for every project, the decision to conduct code reviews rests with the senior management guiding the project work. Here are some factors to consider when deciding if they are warranted: • Complexity of the problem and/or algorithms the code must handle • Familiarity of the YOUR ORGANIZATION and/or the developer with the development tools (e.g. language) • Developer’s experience, both at YOUR ORGANIZATION and overall • Overall test plan (i.e. is this the only form of testing being done on this particular piece of code) • Risk of the project or work package the code is being developed in • Supervisory/management oversight requirements (i.e. are we due for a “spot check”)

WHERE in the process do we do a Code Review? To satisfy the “Testing” and “Qualitative Assessment” reasons for the review, the review can be done before unit testing so that defects can be detected and corrected quickly without the effort of testing. To satisfy the “Management Supervision” requirement, the review must be done AFTER the developer has finished his or her testing, just prior to hand-off for the test execution phase. At this time, the code should be “frozen” from the developer’s perspective, such that he or she no longer has the ability to change it. Regardless of the reason for the code review, it needs to be completed and the results incorporated into the code BEFORE the Test Execution phase. Changing code after testing invalidates the testing, resulting in at least one more pass of testing.

WHO does the Code Review? The Senior Development Manager is ultimately responsible for ensuring that the final system matches the approved design and coding standard. It makes sense, then, for this individual to conduct the code review. However, there are a few things to keep in mind when deciding who will conduct the review. • Does the reviewer have sufficient experience in the technology and/or development language? Does he or she know what constitutes good coding practice in the language/technology being used? • Is he or she adequately familiar with YOUR ORGANIZATION’s environment and standards? • Is he or she sufficiently knowledgeable about the application the code belongs to and the database/data model the application uses? • Does she or he have a “big picture” view of project and what it is to deliver? • Do they have a good grasp of the requirements, what role the specific code under review is playing in delivering to those requirements and how the code in question fits into the overall design?

WHAT do we look for in a Code Review? As per the WHY section above, code reviews serve three purposes: Testing, Qualitative Assessment, Supervision/Management Oversight. The testing component of the review focuses on WHAT the program does and the results it will produce. The following questions should be considered: • Will it produce the results expected as per the requirements? • Are there logic errors? (e.g. using AND instead of OR) • Does the program handle all situations or are there “gaps” in logic that would cause the program to hang or loop continuously? The Qualitative Assessment looks at HOW the code was written. It focuses on the performance and maintainability of the code by considering the questions: • Does it follow coding standards? • Is it efficient? • Does it follow the “KISS” principle (Keep it simple, stupid) or is it difficult to understand? • Is it formatted to allow for easy reading? • Is it adequately commented, including “tombstone” or history of changes information? • Does it follow the “one function per module” principle? Or is it a several-thousand long program that “does everything”? (really a design consideration but if design hasn’t gone to this level of detail, it should be looked at here) • Does it employ readily understood features of the programming language while taking advantage of time-saving functions, etc? • Has the code been written as simply as possible? • Does it match design? • Does it take full advantage of existing code? (also a design consideration) • Is there inappropriate “hardcoding”? • Is there indiscriminate use of “global” variables which will make maintenance and debugging difficult? The third component of the Code Review is management oversight. This is focused on ensuring management knows exactly what code is being implemented into production and on protecting YOUR ORGANIZATION from fraud or unauthorized update. The following questions should be considered to satisfy this aspect of the code review:

• Is there extraneous code – code that is not necessary to satisfy the requirements? • Does the code go beyond the bounds of authorized work? • Are there more modules checked out or modified than there should be as per the design?

HOW do we do a Code Review? There are three types of code reviews: Code Reading, Walkthrough and Inspection. Code Reading is the easiest form of review to implement. As suggested by the name, it consists of the reviewers reading the code and looking for errors. They can also comment on the qualitative aspects of the code and, depending on who is doing the review, can provide the management supervision. Feedback is provided to the author either in a meeting or via written communication. Because the meeting is not strictly necessary, this approach can be effective from an elapsed time perspective. It is an especially effective technique to use when the reviewers and code authors are geographically dispersed. Walkthroughs are loosely defined and can be very informal. It is usually a working meeting moderated by the author, where the focus is on improving the technical quality of the code, so it can be used for both Testing and Quality Assessment purposes. Walkthroughs should be considered when code is particularly complex and/or the technology is new to YOUR ORGANIZATION. An Inspection is a very formal, facilitated discussion where a specially trained moderator leads a discussion of the code. Other participants in the inspection are one or more reviewers who are actively looking for errors in the code and the author of the code, who is there to provide further explanation, if needed. Inspections are only meant to address the “Testing” component of reviews. It does not include discussion on the quality of the code, or check for the existence of unauthorized code. For this reason, and because it requires specialized training to do it effectively, this approach is not recommended for use at YOUR ORGANIZATION at this time. Regardless of the method used, the reviewers must make the following crystal clear to the developer/author of the code: • What changes MUST be made to the code before it can be released for testing • What critiques are suggestions, meaning the author can choose NOT to make the changes • What further review process, if any, must be followed.