Category: Agile Page 1 of 6

5 Ways To Improve Agility and Adapt a Product-Driven Mindset

The concepts of improving agility and adapting a product driven mindset are not new. Yet many companies struggle to make any meaningful change. Why do they struggle? In short, they invest in Agile training and focus on processes but fail to address culture, roles, and talent skills. They slap new labels onto old roles without changing organizational structure.

Below are five adjustments companies can make to have success changing to a product-driven model with measurable results:

Form stable cross functional teams. A stable cross functional team is made up of people from different areas within the company (IT, business, operations…etc.). This is a shift away from functional silos where resources are farmed out to various projects. Allocating resources to projects follows the outdated Taylorism philosophy that people are replaceable. 

Within cross functional teams, experts work together to achieve a common goal. Over time the team develops synergy and becomes high performing. The team synergy exceeds the productivity of individual efforts.

Work is brought to teams instead of “bringing people to work”. Teams that stay intact allow for expertise and relationships to build over time, improving velocity and moral.

The picture below represents the product team model made popular by Spotify. The squads are teams, and the chapters represent skillsets.

Hold business and technology organizations accountable. Agile delivery is not only an IT practice. The business needs to be committed and held accountable for the success of product outcomes. In a recent study conducted by Deloitte of companies that implemented Agile methods, they found that 31% of the business still did not understand Agile. The business must have skin in the game, and they must go through Agile training.

Hire and train for emotional intelligence. Tech skills are essential, but interpersonal skills and business knowledge are more critical than ever. Since the product driven model is team based, team members need to be able to collaborate. This is all dependent how well the team can harmonize, which requires emotional intelligence or EQ.

What is Emotional Intelligence? | OneDayU
EQ represents self-awareness, self-regulation, motivation, empathy, and social skills.

When a team is made up of people with high IQ and EQ, the team has a strong group IQ. Group IQ is the sum of the talents and skills on the team. In Daniel Goleman’s book “Emotional Intelligence”, he writes: “The single most important element in group intelligence, it turns out, is not the average IQ in the academic sense, but rather in terms of emotional intelligence. The key to a high group IQ is social harmony.”

Managers need to empower and coach, not command and control. In a product model there is a shift away from command and control towards trusting teams to make decisions. This removes the organizational bottleneck of decision making and enables work to get done faster. Management hold teams accountable for results, but teams are empowered to make decisions.

Agile training can help managers understand their role in an agile product-driven organization. They will learn how to let go of control and start coaching. Sir John Whitmore, author of coaching for performance, defines coaching as “unlocking people’s potential to maximize their own performance” (Whitmore, J, 2017).

Develop technical acumen for business leaders. Business leaders today must have technical acumen, this is the new normal. Business and technology work together as one. Technology leaders also need to have strong business acumen. More and more we are seeing the need for technology leaders to step up and lead beyond their role in IT. Leaders with strong technical and business acumen are best positioned to lead their organization towards increased agility.

*********

There has never been a greater need for agility than our current era of digital transformation. By shifting to a product-oriented approach, companies can stay competitive and deliver value early and often to their customers.

About the Author: Mike MacIsaac is a principal IT consultant for MacIsaac Consulting, providing IT Agile and cyber security consulting.

How To Destroy an Agile Transformation In 3 Easy Steps

Getty Images

Agile transformation continues to be a goal for many organizations. The old sequential approach to product delivery (Waterfall) is no longer adequate. To respond to change and compete with the speed of globalization, companies must move to an Agile model. The goal to improve agility is not limited to the tech industry. Financial services, retail, healthcare, and many others are all on board with Agile.

Many companies find the shift to Agile difficult. As a consultant, I know the challenges firsthand. Some of the problems are more difficult than others. For example, companies with a culture at odds with Agile values is a major problem. No number of Agile consultants will be able to come in and change a company’s culture. Other, more avoidable problems are due to managerial decisions.

This article is about how management can destroy an Agile transformation in three easy steps. To be clear, this is what not to do.

1- Put a non-Agile person in charge of the Agile transformation

I know this sounds ridiculous, but I have seen it happen many times. A CEO, who does not understand Agile, provides a bucket of money to a senior leader, usually in IT. The CEO says, go off and do that Agile thing you keep talking about. Unfortunately, the CEO does not realize that they put the wrong person in charge. It is difficult for people who spent their whole career working in a traditional Waterfall setting to change their mindset. They might claim on the outside that they are for Agile, but often their behavior conflicts.

There is no surer way to destroy an Agile transformation than to put a Waterfall person in charge. My recommendation to companies is to create a new position for the role of the Agile leader. Look within the company to find the right person, someone with an Agile mindset, to fill the role. If the right person does not exist within the company, then hire one from outside.

2 – Keep using a balanced matrix organizational structure

The balanced matrix organizational structure is suitable for Waterfall, not Agile.  Agile is about using stable cross functional product delivery teams. Work gets flowed through the teams, as opposed to forming teams around work. Agile organizations use a Product delivery model, not a Project model. For more on how the balanced matrix organization conflicts with Agile, see my post “Why Middle Management Is The Ultimate Agility Killer“. For more on the importance of changing from a Project to Product model, see my post “Why Product Focus Is So Important“.

3 – Force teams to use specific tools and processes

In Agile, individuals and interactions are valued more than processes and tools. The traditional PMO mindset loves processes and tools. Some of the clients I have worked with would have meetings upon meetings discussing processes. You need processes but PMOs bogged down with processes and bureaucracy kill agility. The same is true with tools. Forcing all teams to use the same tool, like Jira or VersionOne, is not good. Often management will want teams to use the same tool for reporting purposes. This is wrong because Agile teams need to be empowered and have autonomy.

Summary

If you want to improve your chances of having a successful Agile transformation, do the following. 1) Put someone in charge of the transformation who has an Agile mindset. Do not use someone who has worked their whole career using Waterfall. 2) Do away with the balanced matrix organizational structure. Put in place stable product delivery teams with single line management structures. Start delivering using a product model instead of a project model. 3) Let teams be autonomous, do not impose rigid compliance to processes and tools.

About the Author: Mike MacIsaac is the principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

3 Ways To Start Your 2020 Projects Off On The Right Foot

Here we go, 2020 is here and you are ready to kick off those new projects. Before you dive right in, now’s a good time to do a quick check to make sure you are setup for success. Below are three ways to ensure you start your new projects off on the right foot:

1 – Clearly define and communicate the project goal: Many projects fail because the goal of the project is too ambiguous. If there isn’t a specific goal outlined in a project charter, you end up with a team that goes in different directions. This causes scope creep and chaos, and I’ve seen it time and time again. It is the responsibility of the project manager to work with the sponsor to define and communicate the project goal. The communication about the project goal needs to happen often for the project team and stakeholders. This will create alignment and keep everyone marching in the right direction. In my post about managing business analytics projects, I described a good framework that can be used to define the project goal.

2 – Set boundaries for non-project team members: When it comes to high visibility projects, often too many people get involved. The project manager, with help of the sponsor, needs to communicate who is on the project team. Some people may have their feelings hurt when they learn they are not part of the project, but this must be done. Only core project team members should be in team meetings. Anyone who is not a core team member distracts from the team chemistry and productivity. Often in software delivery projects, small cross functional teams are the highest performing. If your core team has more than eight people, you may need to check whether you have people on the team who don’t need to be.

3 – Plan for change: Whether you are running a Waterfall or Agile project, plan for change. Today’s project teams must be able to adapt to uncertain or changing requirements. This requires recurring retrospectives to see what needs to be improved or changed. The caveat is that if the team has a low level of Agile maturity, it is important they follow a change management process. If they don’t, change can cause big problems. For mature Agile teams, late changes to requirements can be a competitive advantage.

Summary

As we kick off the new year, take a step back and make sure your projects are setup for success. If you know that any of the three areas I mentioned have been neglected, address them now while it’s early. What you don’t want is to be 6-12 months into a project and realize the project goal was unclear.

About the Author: Mike MacIsaac is a c0-founder and principal consultant for MacIsaac Consulting. MacIsaac Consulting, based out of Minneapolis MN, provides IT Agile delivery consulting and staffing.

Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

How To Avoid Common Pitfalls of Business Analytics Projects

business analytics

We live in the early stages of a data analytics revolution. Data is driving the world and transforming the global economy. In a report published in December of 2016, McKinsey estimated that “45% of work activities could potentially be automated by today’s technologies and 80% of that is enabled by machine learning.”

While big data and AI investments are on the rise, many companies are struggling in their efforts to be data driven. A 2019 HBR article found in a study that “An eye-opening 77% of executives report that business adoption of Big Data/AI initiatives is a major challenge, up from 65% last year.”

To better understand business analytics and why companies are struggling, I recently attended an executive education course at the Carlson School of Management. The class covered a range of topics including artificial intelligence (AI), machine learning, big data. As a consultant who manages IT projects, I wanted to learn about what it takes to deliver analytics projects.

What Is Business Analytics?

Business analytics is an exploration of an organizations data, with emphasis on statistical analysis. It enables companies to make data driven decisions that help gain a competitive advantage. Companies that deliver business analytics projects treat data as a corporate asset. Below are the four main types of business analytics:

  • Descriptive Analytics – Descriptive analytics answers the question, what happened? It is an exploratory analysis that provides visualization and BI dashboards. This can help companies to use key performance indicators to understand the state of the business.
  • Predictive Analytics – Predictive analytics answers the question, what will happen next? It analyzes trend data to predict future outcomes. Data mining, machine learning, model lifting, and forecasting are techniques used.
  • Prescriptive Analytics – Prescriptive analytics uses past performance to generate recommendations for the future. Optimization, simulation and rules are used in prescriptive analytics.
  • Causal Analytics – Causal analytics answers the question, did x truly cause y? Before business decisions can be made based on analytics, you need a high degree of confidence. It’s not enough to go by gut feel, data trends or correlations. Casual provides the confidence using a/b testing, econometrics and experimentation.

Why Most Business Analytics Projects Fail

Gartner CIO research reports that more than 50% of analytics projects fail. Why do they fail? In short, most fail because companies neglect to connect the analytics to business value. They focus on analytics output, tools and technologies verses business outcomes. Some common pitfalls include not knowing what the problem is, force fitting a solution, or trying to boil the ocean. Poor data quality and a lack of technical expertise are also big issues.

Another reason business analytics project fail is due to the way they are managed. The traditional plan driven approach does not work for analytics projects. “Business analytics projects are often characterized by uncertain or changing requirements and a high implementation of risk. So, it takes a special breed of project manager to execute and deliver them.” (Viaene, Van Den Bunder, MIT Sloan Mgmt Review).

Setting Up Analytics Projects For Success

The best way to setup analytics projects for success is with framing. The goal of framing is to define the problem boundaries, break down the problem and determine the analytics method. This helps to reduce ambiguity and the risk of project failure.

There are different frameworks that can be used throughout an analytics project life cycle. Below is a description of a common framework that can help:

Situation, Complication, Key Question (S, C, KQ) – The S, C, KQ framework helps gather the information needed to provide a clear and holistic problem statement. The Situation provides the information relevant to the problem. It is the context that sets up the complication. The situation must lead to the complication. The two must connect.

The complication clarifies the need for change. It specifies why a change is needed and a decision must be made. The key question then follows from the situation and complication. It is the one focus of the project and it makes clear the decisions to be made. The key question should use the SMART guideline – Specific, measurable, action-oriented, relevant and time bound.

Below is a basic example of what the S, C, KQ framework might look like in a project definition sheet. The example provided is to solve a business problem for a health club:

The example gives provides a basic idea of the S, C, KQ framework. Once the problem statement is clear, the analytics project team can decide on which type of model to use. The final step in the framework process is to provide an outcome that is measurable and actionable. The outcome explains what business decisions will be made based on the results of the analysis. The outcome also explains how success will be measured.

With a solid framework in place, a cross-functional analytics team can then develop a model. A typical deliverable from an analytics project team might include a web dashboard that provides predictive or prescriptive analytics. Data engineers and data scientists write algorithms and build the models. They also perform data cleansing, aggregation, integration and transformation.

Summary

Companies need to treat their data as a corporate asset. The ability to use data to predict future performance provides a competitive advantage. While business analytics is growing in importance, many companies are failing in their efforts to become data driven.

A key to success with business analytics projects is to use a framework that will align the analytics with business value. Analytics projects must be managed in an agile way that adapts to changing requirements. An iterative and experimental approach to project delivery is best.

Often the biggest roadblock to business analytics success is the business imagination. Companies must find ways for human intelligence and machine intelligence to work together. 

A special thanks goes out to the Carlson Executive Education program and professors Ravi Bapna, Gedas Adomavicius, Ellen Trader, and De Liu. Below is a picture of our business analytics class filled with business leaders from the Twin Cities.

About the Author: Mike MacIsaac is the founder and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master/Coach. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Why Middle Management Is The Ultimate Agility Killer

“So much of what we call management consists in making it difficult for people to work.” – Peter Drucker

For the past seven months I have been managing a difficult IT project for a large organization. The experience has me convinced that middle management is the ultimate roadblock to agility. I get why they call it the frozen middle. To understand the root of the problem, you must look beyond managers themselves. The core of the issue lies within organizational structure and culture.

While many companies are undergoing agile transformations, most still use old organizational models. The matrix structure is a top offender. Loaded with hierarchy, bureaucracy and management layers, it is anything but agile. If an agile team were superman, the matrix organization would be kryptonite.

Below are some of the ways the matrix organization impedes agility:

Disjointed Functional Areas

The matrix organization splits functional areas into groups. In IT for example, developers belong to one group, QA analyst to another, and so on. The employees within the group’s report to a manager. The manager then places employees on projects within the company.

Here’s the problem. Functional groups are setup to be in conflict against each other. I can’t tell you how many times I’ve seen functional areas point blame at each other when challenges arise. “It’s development’s fault”, or ” its QA’s fault”. Instead of promoting an attitude of one team, the matrix environment sets the stage for political strife. Managers snipe at one another as they fight to stand their ground.

The result of all the political warfare is hindered project teams. Team members just want to accomplish their work. Instead they get harassed by managers who need ammo to defend their functional area.

The Value-Add Dilemma for Functional Managers

IT functional managers working in a matrix environment have a dilemma. They usually come from a background of product delivery, where their contributions were clear to see. When they leave the trenches of project work to become managers, they realize their new role is about staffing. How then are they to prove their value if they are not delivering work? They attempt this in two ways.

First, they involve themselves into areas where they aren’t needed. As a project manager and Scrum Master, I have had to ask functional managers to not attend project team meetings. In teams, the presence of non-core members causes disruption. Teams operate at peak performance when each member of the team knows and trusts each other. The moment you introduce someone who is not part of a team, especially a ‘manager’, everyone clams up. The team reverts to the ‘forming’ stage of Bruce Tuckman’s four stage team building model.

Second, functional managers try to prove their worth by raising ‘concerns’ to leadership. Since they are on the sidelines for projects, voicing concerns about potential issues gives them an outlet for exposure. It’s a way for them to say, hey I think there is an issue, see how I’m adding value? Unfortunately, this often results in a lot of noise and distractions. While their intentions may be good, they end up stirring the pot.

These behaviors are not the fault of the managers themselves. They are usually good people with strong backgrounds. The problem is not the people. The problem is the functional management role itself. It doesn’t give people a way to add value.

Forming teams around projects

The matrix organization forms teams around projects. It’s not uncommon for people to be on two, three or even four projects at a time. This results in switching costs, the cost of doing more than one complex task as a time. Studies show that when people switch their thinking to different topics, their productivity goes down.

Poor team development is another result of forming teams around projects. Assigning employees to new projects doesn’t allow enough time for team development. It takes people working together for a while before a high performing team emerges. The moment you assemble a new team for a project, the team building process starts from scratch.

PMO’s

When it comes to process overload, the PMO (Project Management Office) is the worst. PMO’s force organizations to follow rigid standards, processes and tools. Many are trying to adapt to agile practices, but the results are the same. Too much process and bureaucracy. It goes against the first principle outlined in the popular Agile manifesto. Individuals and interactions are valued more than processes and tools.

While processes and controls are necessary for organizations, too much is an agility killer. Forcing project teams to create wasteful documentation is a common problem. I once had a manager ask that a large test plan be created for each Agile two-week sprint. The result was a QA analyst spending more time working on a test plan than collaborating with the team. To achieve agility, you must value working software more than documentation.

The Solutions to the Middle Management Conundrum

The best way to combat these issues is by forming stable, cross functional, capability teams. True agile teams. The teams can use whatever framework, processes or tools that work best for them. They don’t have to follow arbitrary processes from a PMO.

There are many benefits to the stable product delivery teams’ model. It eliminates the need for excessive management by doing away with functional groups. This puts emphasis on product delivery and providing value to the customer. It also reduces the internal politics that the matrix organization creates.

By keeping teams intact, it allows enough time for team development. Instead of forming teams around projects, project work goes through teams. This is a mindset shift away from traditional project management to modern product delivery.

Agile teams report up through one line of management. Managers are responsible for strategy and ownership of their capability. This gives managers clear roles and responsibilities that provide value. They engage in product delivery.

Part of the goal with the product team model is to create a flatter organization and to adopt an agile culture. While these changes are hard for large organizations, many companies are having success. In Minneapolis, where I live, companies like Best Buy, Target, United Health Group, and TCF Bank are making significant progress. They understand that the balanced matrix organization is no longer adequate to stay competitive.

Organizations still using the balanced matrix structure need to change. Implementing a stable product team model improves agility and benefits the customer. It also provides a more enjoyable work environment for managers and employees.

About the Author: Mike MacIsaac is the principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Agile is Value Driven, Not Plan Driven

Agile

How many times have we all experienced this? Leadership asks for project status. What they want is a color. Is the project green, yellow or red? If it’s green, all is well. If it’s yellow, there is cause for concern. If it’s red, sound the alarm!

And how do we justify whether a project is green, yellow or red? We check the project schedule, budget and scope. If one if these areas doesn’t align with the plan, the project is red.

If we were talking about waterfall projects, this wouldn’t be an issue. The problem is, many companies manage “Agile” projects in this same way. They want to be Agile, but fail to let go of a plan driven, project focused approach.

Agile is a value driven approach, not plan driven.

A plan driven, project focused, approach is what we learned when we got our PMP’s. Everything is planned up front. Requirements are fixed, and cost and schedule are estimated. We then report status based on how the project is doing compared to the plan.

When it comes to software development, we know a plan driven approach is flawed. Yet, many companies continue to use it. Why? Why do we punish project teams for being over budget or behind schedule when we know it’s the process that’s broken?

We need to shift our mindset from project focus, to product focus.

Product focus is a value driven, adaptive process. It doesn’t punish teams for change. It anticipates change and even welcomes it.

In a value driven approach, cost is fixed, and features are estimated. It’s the reverse of a plan driven approach. Investment is made at the product level, not a project level. People are dedicated to teams, and the teams stay intact.

This move from project focus to product focus is not pie in the sky. It’s not for small tech firms only. Target, for example, has completely shifted to a product focus model. They get it, and they’re not alone. Many large companies are organizing cross functional teams around products. They are bringing IT and business people together to focus on delivering business outcomes.

If your company is going Agile, ask yourself, are you ready to move on from traditional project management? Are you ready to no longer have a PMO? Are you ready to change? If yes, then it’s time to embrace a product focused mindset. If no, then continue using Waterfall, but don’t call it Agile. 

About the Author: Mike MacIsaac is the principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or visit Mike’s blog.

What will Agile look like in 2030?

Photo Credit – Pixabay

It’s been almost twenty years since a group of software developers created the Agile Manifesto. Since then, Agile has changed the way we develop software and taken the business world by storm. Terms like “daily stand-ups”, “MVP” (Minimum Viable Product) and “Sprints” have become common language. Offices used to consist of departments working in silos and large cubicle walls. Now they are filled with cross functional teams and open work spaces.

So, what will the future have in store for Agile? Will the Agile movement continue to gain momentum, or will it become another management fad that fades away?  Will it continue to expand outside the realms of product development? Will we see new frameworks that replace common practices like Scrum, Kanban and SAFe? What about Agile teams, will they look different?

In this post I will tackle some of these questions and provide predictions of what Agile may look like in 2030. I’ll start with the biggest question.

Is Agile a management fad that will fade away?

The short answer is no. The underlying principles of Agile are sound. The fundamental beliefs of Agile were well known long before the Agile Manifesto was written in 2001. Past management gurus like Edward Deming preached the benefits of iterative methods. For whatever reason, it’s taken the rest of the world a long time to catch on. Not only is Agile not a fad, it is mandatory for survival.

While Agile is here to stay, many of the current frameworks and certifications will fade away. Over time they will join the graveyard of past management ideas like MRP, ERP, TQM and JIT.

Will Agile continue to expand into more departments, functions and industries?

Yes. Today Agile is still thought of a something used for software development. Over the next decade, we will see a big push in Agile adoption for HR, marketing, sales and every other department and function.  Don’t be surprised if soon you see your accounting team holding a daily stand-up.

We will also see a much wider spread of Agile adoption across industries. This includes construction, logistics and automotive. The largest industry to go all in on Agile will be financial services. Large financial services companies will have to fend off pressure from non-traditional competitors. Many of the big financial services companies already started Agile transformations, but they are just beginning.

What will Agile teams look like in 2030?

We will still have cross functional, self-organizing teams, but there will be one major difference. Agile teams will have a new team member, and that member won’t be human. Interactive artificial intelligence will be a crucial part of Agile teams. In the future, we will wonder how teams ever operated without it.

I’m not saying we will have a robot walking into our meetings. I am saying teams will use a voice activated AI feature like amazon’s Alexa to provide quick response to questions like “how many large stories are in the backlog?”. But that’s just the easy stuff. It will also perform tasks, help teams make decisions and write code.

Think of the character data from star trek. Data was an invaluable resource to the crew. The same will be true of the AI used by future Agile teams, and it will be super cool. I mean, come on, who doesn’t want a robot on their team?

What will be the training needs be in 2030?

The Agile training needs in the future will be less about frameworks and two-day certifications. They will be more about developing emotional intelligence. Team members and managers alike will need to practice mindfulness to deal with the tidal wave of distractions, pressure and stress the next decade will bring. Self-awareness and empathy already are crucial components to work in an Agile environment but in the future, the need for these skills will be multiplied.

Conclusion

In 2030, we will see some big differences in Agile. Agile is not a fad. It will not fade away, but a lot of today’s popular certifications and frameworks will. Agile will continue to expand across industries, departments and functions. The financial services industries could be the largest industry completely changed by Agile. AI will become an invaluable component of future Agile teams. Emotional intelligence will be the critical skill set. Training will be more focused on EQ to improve collaboration, and less on frameworks.

These are my predictions for Agile changes to come in the future. What are yours?

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. MacIsaac Consulting provides Agile Consulting, Agile Coaching and Agile Training. Follow Mike on Twitter@MikeMacIsaac or visit Mike’s blog.

Why Trust Is the Rocket Fuel of The Agile Organization

Trust is the rocket fuel that propels agile organizations forward. Without it, bureaucracy and rigid management can grind things to a halt. For companies to be fast and flexible, leaders must break down the barriers that hinder trust. In this article I will describe how executives, managers and team members can foster a culture of trust to improve agility.

Executives

Executives of large companies often do not grasp what it takes to be agile. To their defense, they have a lot going on. It’s easy for them to stay on the sidelines when it comes to improving agility. Let Jim, the VP of IT go work on that whole “agile” thing says the CEO. What the CEO fails to realize is that agility is critical to the survival of the company and it goes beyond IT. Agility must be part of the enterprise strategy, and it all starts with trust.

The first thing executives can do is assure middle managers that their jobs are safe. In agile organizations, managers don’t command and control. Instead, they empower and coach. If managers trust their jobs are not in jeopardy, it will be easier for them to empower teams.

Second, executives should let the organization know that it’s okay to make mistakes. Often you will hear in agile companies the term “fail fast”. What it means is that it’s better to deliver iterating on fast failures than trying to build perfect solutions. By promoting a fail fast culture, executives will help reduce fear for employees and encourage trust.

Last, executives must get engaged in agile adoption. They can’t talk the talk, they must walk the walk. The best way for them to do this is by clearing bureaucracy and clutter that impede agility. By having skin in the game, executives send a message to the company that they can be trusted.

Managers

The inability for management to empower teams is often a major roadblock to agility. To understand why, there are many layers of the onion that need to be peeled away. At the core of the issue is lack of trust, and fear. They don’t trust teams to operate without their control, and they fear for their job security. Managers also may not know how to coach.

One of the best ways to address this problem is through enterprise agile training. Most companies make the mistake of focusing agile training only on teams. They embed agile coaches within teams, while managers receive no training.

Agile training will help managers understand their role in an agile organization. They will learn how to let go of control and start coaching. Sir John Whitmore, author of coaching for performance, defines coaching as “unlocking people’s potential to maximize their own performance” (Whitmore, J, 2017). By coaching and empowering self-organizing teams, management will help improve trust and agility. 

Team members

Agile teams are self-organizing. This means they don’t have a manager who is telling everyone what to do. For many organizations this is a paradigm shift. Employees might be used to a project manager who detailed everyone’s task in a Gantt chart. I’ve found that many employees who are new to agile, at first are uncomfortable with the vulnerability it requires.

Team members decide what they will work on in agile teams. They volunteer and rely upon one another to get work done. Trust is the absolute cornerstone to this way of collaborating. Team members must believe that each member of the team will carry their load. If team members feel that someone is slacking, trust will erode, as well as team performance.

Agile teams are also transparent. They expose their work on a task board, also called an information radiator. To do this, employees must trust that leadership will not misuse the task board. The task board is meant to provide transparency, not as a means for managers to micro manage teams.

Conclusion

Lack of trust is a killer to organizational agility. It is the responsibility of all employees to foster a culture of trust. Executives can help by getting engaged and promoting a fail fast culture. Managers must replace command and control with coaching and empowerment. Managers need agile training as much, if not more, than team members.  Last, team members need to be vulnerable so they can trust working with others in a transparent environment.

When trust levels are high, it will take your speed and agility to new heights like rocket fuel.


About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. MacIsaac Consulting provides Agile Consulting, Agile Coaching and Agile Training. Follow Mike on Twitter@MikeMacIsaac or visit Mike’s blog.

Agile Pitfalls – How to avoid 3 common mistakes in an agile transformation

Agile transformation

I’m grateful to PM Network Magazine for publishing my article on Agile pitfalls. You can view the article in the December version of the magazine here

The article published by PM Network was a shortened version of my original white paper. Below is the paper in its entirety.

Three Common Pitfalls of Agile Transformation, and How to Avoid Them: By Mike MacIsaac

Agile transformation is becoming an increasingly high priority for companies. Everybody wants to be Agile, from start-ups to large enterprises. In today’s competitive global market, agility is critical for managing changing priorities. As an Agile delivery consultant, I’ve seen the struggles companies face when they set out to become Agile.

For the past ten years I’ve worked with a range of companies, across various industries. Their Agile transformation struggles tend to be similar. In this article I will discuss three common pitfalls I see, and advise on how to avoid them.

Before we can talk about transformation, we first have to answer the question: What does it mean to be Agile? Most people think of Agile as a way of developing software, but it is much more. Agile is a mindset. Agile is a different way of thinking and behaving from traditional management. Agile is putting client needs first. Agile is delivering value early, and often through the use of an iterative, experimental process.  Agile is innovating through self-organizing teams. Agile is all these things—and to better understand why companies need transformation, it helps to understand some history.

A Brief History of Agile

While Agile is the hot buzzword today, understandings of Agile benefits are not new. In fact, we can trace Agile roots back to the 1600s. Francis Bacon, an English scientist, developed a scientific method in 1620 which would later become the basis for the PDCA (Plan-Do-Check-Act) cycle. The PDCA cycle was used by Walter Shewhart and it was made popular by Dr. W. Edwards Deming. The concept was an iterative approach for improving products and processes. The continuous cycle of short iterations allowed for agility by adapting for change after each iteration. The PDCA cycle had a huge influence on Japan after WWII, as it helped improve production quality and automotive operations.

The most relevant step to agility in the PDCA cycle is step four, “Check.” The idea is to inspect and adapt. In Deming’s Out of the Crisis he writes, “Step 4 of the Shewhart cycle (study the results; what did we learn from the change?) will lead (a) to improvement of any state, and (b) to better satisfaction of the customer of that stage.” (Deming, 1986)  Notice that Deming puts emphasis on satisfying the customer. Customer satisfaction is at the heart of what Agile is all about.

Although Deming advocated Agile concepts throughout the 20th century, Frederick Taylor’s scientific management theory (referred to as Taylorism) was predominant in American business. Taylor’s approach was all about following rigid processes, with a top-down, command-and-control style of management. Managers told workers what to do, and workers followed orders. Taylor’s management theory helped propel the industrial revolution.

Taylorism ran into problems towards the end of the 20th century. The economy had changed and a new workforce emerged. Knowledge workers became the majority, replacing semiskilled workers. Knowledge workers couldn’t be managed the same way as the factory workers. Well renowned Austrian-born American management consultant Peter Drucker once said, “Workers through history could be ‘supervised.’ They could be told what to do, how to do it, how fast to do it, and so on. Knowledge workers cannot, in effect, be supervised.” (Drucker, 1993)

Taylorism worked well for workers on the factory floor, but not for knowledge workers who dealt with complex problems. In 1986, things changed when Hirotaka Takeuchi and Ikujiro Nonaka published a paper on a new way for product development (see “The New NewProduct Development Game,” HBR, Jan 1986). The paper was instrumental in kick-starting the modern Agile movement. Takeuchi and Nonaka described a new product development approach that looked more like rugby. Teams would pass the ball back and forth as they headed towards their goal. This was different from the traditional sequential approach to product development. This new rugby-like approach, made up of self-organizing teams, allowed for speed and flexibility. It enabled change throughout the product development process.

Fast forward to 2001, and a group of software developers got together at a ski lodge and created the Agile Manifesto. This was a declaration of guiding principles aimed at finding better ways to develop software. After 2001, the Agile delivery movement took off on a global scale.

Today, Agile practices are common, but many organizations still operate in the old world of Taylorism. Knowing they need to change, companies are trying hard to become Agile, but many still struggle. Here are three common pitfalls I see when companies set out for Agile transformation—and how to avoid them.

Pitfall 1, Not Having Goals

It’s amazing how many companies set off on a mission to become Agile without have any clear goals. If you ask their executives what their goals are, they’ll respond with something like “to be better at delivering software.” This response provides no specifics on what they are trying to achieve. It also doesn’t provide any sort of inspiration for the employees who will be in the trenches of the transformation.

One client I worked for made this mistake. Without clear goals, they couldn’t tell if they were improving. Employees became frustrated because they didn’t understand what they were trying to accomplish. This caused an unhealthy culture, contention among teams and gave Agile a bad rap. After about two years of little progress, the client finally realized they lacked goals.

Leaders need to take the time to define specific goals that align with the strategy of the company. They need to understand the value generated by an Agile transformation. An example might be something like the following:

“We need to double our production releases from four a year to eight. This will allow us to get new innovative products to market faster. It will also help us meet customer demands and increase market share by x.”

The example above gives a specific goal, with a clear end state. Once goals are defined, alignment needs to be created throughout the organization. A plan can then be put in place, putting the company in a much greater position for transformation.

Pitfall 2, Lack of Prioritization and Executive Sponsorship

I’m not going to sugarcoat it. If leadership is not on board, it’s going to be tough sledding.Leaders often underestimate what it takes for a successful Agile transformation.In a recent report by KPMG, lack of executive sponsorship was a top reason companies struggle with Agile transformation (see AchievingGreater Agility, PMI, Nov 2017). 

In another one of my client experiences, middle management continued to govern delivery teams with tight control. They did so because a) executives weren’t on board with change and b) management was afraid to give up control. Every important decision and process went through a board review and approval process. This of course did not promote a culture of empowerment and trust. It only frustrated and confused delivery teams. It wasn’t long before employees started to leave the company in search for more autonomy.  

Agile transformation is about changing culture. It’s going to take more than forming Agile teams and bringing in Agile coaches. Teams alone cannot change bureaucracy and culture. Leaders need to help remove impediments and promote a new culture built on openness and trust. “Senior executives need to communicate early and often at all levels of the organization to let their people know that the Agile journey will benefit all, and that it is OK for mistakes to be made as long as lessons are learned.” (Cullum, Bagg, Trivedi, Nov 2017)

Target Corp is a great example of the benefits of executive sponsorship. Target executives set out to transform the organization to Agile back in 2015, after the company took a big hit with a data breach. They’ve had great success. In 2017, Target’s CIO Mike McNamara gave a keynote at National Retail Federation (NRF)’s annual Big Show in New York. McNamara said, “What I’m perhaps most proud of is how our new way of working is taking root in other parts of Target, beyond technology teams.Agile sets us up for more innovation and for becoming a leader in how technology and data science can (and will) enhance the retail experience” (see “MikeMcNamara:Technology Transformation on Tap at NRF’s Big Show,”Target, Jan 2017).

Executives also need ensure the transformation a top priority for the company. Lack of prioritization is a common problem with transformations. McKinsey recently published an article in which they wrote “While it is completely OK to start the agile transformation within, say, a small part of the organization,it is important not to stop there and to treat it as a strategic priority for the enterprise. Taking agile beyond small experiments is where the real benefits arise” (see “How to Mess Up Your Agile Transformation in Seven Easy(Mis)steps,” McKinsey, April 2018).  

Pitfall 3, Putting Process over Behavior

Companies are usually quick to put Agile processes in place. If you walk around their offices, you will see task boards with sticky notes and teams having stand ups. They use popular software tools like VersionOne or Jira. From the outside they have all the appearances of being Agile. But if you look deeper, you may find that their behaviors and mindset have not changed. The common reason for this is fear. People are afraid they will be punished for making mistakes. They also don’t trust others enough to be transparent.

Agile values individuals and interactions over processes and tools. This is the first principle outlined in the Agile Manifesto. This is a human element in Agile that is so important, yet often overlooked. To be Agile, people need to talk to each other, and they need to be open and honest.

The best way to drive out fear is through leadership. Managers need to shift their mindset from command and control to coaching and mentoring. Companies need leaders who have strong emotional and social intelligence. With empathy, leaders can foster an environment where people feel safe to make mistakes.

There are various ways to improve emotional and social intelligence. There are learning and development programs available. Google uses a widely popular course called “Search Inside Yourself”. Daniel Goleman is an author and science journalist who offers a framework with coaching certifications.  Aside from development programs, companies should recruit for emotional and social intelligence. Many top business schools are now developing emotionally and socially intelligent leaders. Harvard Business School, for example, offers a program on authentic leadership. The program was started by Bill George, the ex Medtronic CEO and author of True North.

Conclusion

Agile is a different way of thinking and behaving. For companies attempting transformation, the following are three key areas to address: (1) There needs to be specific goals in place. The goals need to be a top priority in the company, and they need to align with the overall strategy. (2) Executive sponsorship is crucial for a successful transformation. (3)  In Agile, individuals and interactions are valued more than processes and tools. To drive out fear, you need leaders who have strong emotional and social intelligence to foster a culture of safety and trust.  


About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. MacIsaac Consulting provides Agile Consulting, Agile Coaching and Agile Training. Follow Mike on Twitter@MikeMacIsaac or visit Mike’s blog.

What Is Agile Transformation?

Check out my latest video on Agile Transformation. In this short video, I touch on the advantages of Agile Transformation. I also discuss the challenges and what leadership can do to help.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or visit Mike’s blog.

Page 1 of 6

Powered by WordPress & Theme by Anders Norén