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

View fullsize

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.

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.

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

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!

View fullsize

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