The debate over the best Agile development tools rages on. Tools like JIRA, VersionOne, and Trello all offer different benefits. Some people love the lightweight team focused flexibility of JIRA, while others prefer VersionOne for its program management capabilities.
Long before the popularity of Agile, organizations struggled to find the right software delivery tools. Teams need tools for things like version control, defect management, test cases, reports and requirements/user stories.
It’s not uncommon to find companies using different tools to manage the different aspects of software delivery. For example, they might use Rational ClearQuest to manage defects while using HP ALM to manage test cases. Or they may use SharePoint to maintain documents while using JIRA to manage User Stories and Sprints.
Here’s the thing. There is no right or wrong combination of tools that works for your team or organization. Some teams prefer not to use any tools, and that’s okay. The real goal of self-organized teams is to produce good flow. Good flow means producing quality software that provides value to the business. It should be up to the teams to decide which tools, or lack of tools, works best for them.
Value stream mapping is a powerful tool. It’s used to identify and remove bottlenecks in your organizations value stream. Before going further about the mapping, let me first touch on what a value stream is. I’ll also describe the theory of constraints.
Your organizations value stream is the end to end process used to deliver a product to the customer. For example, it may begin as a request from a customer, and end once the customer has the finished product. The stream contains all the activities it takes to get the customer the finished product. Each activity contains a work time, and a wait time.
The theory of constraints says that the best way to optimize an organization is to focus on throughput. Throughput is the key to generating profitable revenue. The way to increase throughput is to look for the current bottleneck that is slowing things down and fix it. Once removed, find the next bottleneck and fix that. Keep this up and you will have a fast-moving value stream (Goldratt, E 1984).
Creating a value stream map – “Mapping your value stream is a good way to start discovering waste in your software development process. In industry after industry, the process of mapping the value stream has invariably led to deeper insights about how internal processes work or don’t work to meet customer needs” (Poppendieck, 2003).
An easy way to create a value stream map is to have a project team gather around the whiteboard. The process shouldn’t take long. You should be able to do this in an hour or less. Write out all key activities in your value stream. For each activity, write down how much work time it takes, and how much wait time there is.
For example, you may find it takes on average 2 weeks to code for a project, but it takes an extra 3 weeks to move the code to test. This extra 3 weeks is wait time that doesn’t provide any value to the customer. It is waste.
After creating the value stream, identify the biggest bottlenecks in your process. The goal is to increase flow and value added time in the system. Focus on the fixing the biggest bottleneck, then continue to fix the next bottleneck.
In software development, it is common to find that the biggest bottlenecks occur after development and testing are complete. This is why it’s so important for organizations to be moving towards a lean software development model.
Below is a picture of a value stream map from the book Lean Thinking, by James Womack and Daniel Jones.
For more content like this, subscribe to the MacIsaac Consulting Blog.
As a practitioner and student of Agile software development, I am fascinated by those who have influenced the Agile movement.
For fun, I have decided to put together my personal top 10 list of those who I believe have influenced what we refer to as Agile software development. Not only have they influenced Agile, most of them have put out bodies of work that will continue to educate future generations.
For all you Agile gurus out there, don’t freak out about who’s not on my list. You may have your own list which looks completely different. I know every time the the NFL puts out a top ten players list, I’m usually in disagreement 🙂
Here we go…
10 -Kent Beck
Currently working for Facebook, Beck is the creator of Extreme Programming. He was one of the original contributors to the Agile Manifesto in 2001. He is a leading advocate for test driven development (TDD). Beck has published over 8 books on software development.
9 – Mary and Tom Poppendieck
Mary and Tom are a package deal. I was fortunate enough to attend one of their workshops several years ago. Minnesota locals, the two have written together several books on lean software delivery. They helped bring lean production techniques to software development. Together they have had a big influence on the Agile movement.
8 – Jeff Sutherland
One of my personal favorites, Sutherland is the co-creator of Scrum. A West Point graduate and pilot, Jeff flew over a hundred missions in Vietnam. After his military carrer, Jeff got into software development. He was a doctor at the University of Colorodo school of medicine, and he helped write the Agile manifesto in 2001.
7 – Eliyahu Goldratt
Although his name may not be synonymous with software development, Goldratt has influenced the way we think about systems. Goldratt’s book “The Goal” is a required reading in almost every business school. He’s is known for his teachings on the theory of constraints (TOC) and the critical chain method.
6 – Ken Schwaber
The co-inventor of Scrum along with Sutherland, Schwaber is a prominent leader of the Agile movement. Ken has authored many books on Agile and Scrum. Ken founded Agile Alliance and Scrum Alliance, which created the Scrum master certification programs. Ken helped write the Agile manifesto in 2001.
5 – Jim Highsmith
Jim has authored books on software development and Agile project management. He created the adaptive software development model. Jim is respected as a leader in the Agile software development movement. Jim won the Jolt award in 2000, and the Stevens award in 2005.
4 – Frederick Brooks
Brooks is an American computer scientists widely known for his book “The Mythical Man-Month”. In his book he describes the lessons he learned while managing the development of IBMs System/360 family of computers. Brooks law states: “adding manpower to a late software project makes it later”.
3 – Taiichi Ohno
The father of the Toyota production system, Taiichi Ohno was the originator what we now refer to as lean. The processes and principles he put in place at Toyota had a huge influence on lean software development and Agile. Ohno claimed that he modeled the Toyota Production system after Ford, only he removed the waste.
2 – Henry Ford
Ford is a fascinating American icon. He founded the ford motor company and helped create the assembly line production process. Not only did his assembly line process change the auto industry, it changed the world. Manufacturing would never be the same. What I admire the most about Ford was that he accomplished so much, and he did it all through sheer determination. Ford had little formal education, he didn’t graduate from High School.
1 – Edwards Deming
My favorite quality guru, W. Edwards Deming. What I like the most about Deming was that he cared for the line worker. He championed pride in workmanship. He put the responsiblity on management to focus on the system. Along with a 14 point process for quality improvement, he created the PDCA (Plan, Do, Check, Act) method. The PDCA method is exactly what takes place during Scrum sprints (iterations). His processes and statistical control methods also revolutionized the Japanese auto industry.
For more content like this, subscribe to the MacIsaac Consulting Blog.
Trust and empowerment are the fuel that drives high performing technology teams. Companies like Facebook, Amazon and Spotify have realized this. They all use lean software development principles. They are cutting edge Agile. They have achieved a continuous delivery framework. They deliver quality software to production almost every 11 seconds.
So what does lean software delivery have to do with trust and empowerment? You can’t adopt a lean software development framework without empowering and trusting the teams. Using lean, management tells the team the problem, but lets the team decide how to solve it. Using lean, management let’s teams deploy software to production. This means there is no wait for a release date or a release management team to deploy software.
Can you imagine, as soon as software has passed testing, it’s deployed to production? It sounds like a fantasy, but it is not. Companies like Spotify have been doing this for years. If you want to stay competitive, you need to be moving towards a lean continuous delivery model too.
Most companies are the opposite of lean. They have long release cycles, maybe delivering new software to the customer on a monthly or quarterly basis. They follow a strict release management schedule, riddled with controls. The whole process is filled with waste that slows down the delivery of working software.
An underlying principle of lean software development is to cut waste. Waste is considered anything that doesn’t add value to the customer. If you take a good look at the software development system within your organization, odds are you will find a lot of waste. Waste only delays the delivery of working software to the customer.
This is why management needs to let go of control. They need to empower and trust their teams. The real strength of high performing software companies comes from the teams. Marry Poppendick, author and expert on lean software development, writes: “Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work” (Poppendieck, 2003).
Trust and empowerment are the foundation of great teams. They are the fuel that propels the team’s forward. Trust and empowerment enable lean software development in an Agile framework. The result of lean software development is satisfied customers. Satisfied customers are the most important aspect of the software development process. When you have satisfied customers, you have achieved quality.
For more content like this, subscribe to the MacIsaac Consulting Blog.
“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.
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.
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.
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.
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.
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
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
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.
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
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
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
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
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.
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
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.
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.
In our current age of digital disruptions and continuous market changes, C-level executives must prepare to achieve greater agility. This is true across all industries and sectors, not only in technology. Enterprise wide flexibility has far reaching advantages, including revenue and profit increase and faster speed to market.
Achieving greater agility is not only about software development and engineering methods. It’s also about culture change, which often is the biggest road block to agility. Changing culture requires commitment from the C-level. In a recent report by PMI and Forbes Insights (Achieving Greater Agility), they surveyed C-level executives across the globe. Only 27 percent of executives surveyed considered themselves highly agile. “In fact, culture emerges as one of the biggest hurdles to adapting to higher levels of agility, with 50 percent of respondents calling it challenging. In this light, it is troubling that only a quarter of all executives find their cultures to be strong enablers of agility.”
Below are four steps for the C-suite to drive culture change towards greater agility. These are the steps that Walmart and other large companies successfully used:
Start small – For large organizations, start by using a small piecemeal approach. By creating small pockets of cultural change, you will have more success scaling. Structure small teams that are empowered and autonomous. Your odds of transformation success increase even more if you have people who will embrace agile values. Enable them to make decisions, and get out of their way. Most of all let them have fun!
Teach your leaders – Management needs to learn a new way of doing things. Agility is about empowering and coaching teams. Command and control needs to go to the wayside. This is a mindset change for management that is so critical for success. Teach management to let go of control. If they don’t, it will be an absolute killer to agility.
Set expectations – The Company needs to be clear about expectations for a new way of working and expect some attrition. Agile is not for everyone, and it’s best to be up front with people. If anyone wants to move on and not be part of an agile culture, that’s fine. Be clear and set expectations up front.
Invest in training – You have to invest in the training so people can learn how to work in an agile environment. The key is driving out fear so smaller teams feel safe making decisions on their own. Sending people to a two day course is helpful, but not enough. Embed training and learning as part of the culture that is ongoing. Create practice groups and promote learning.
Whether you are a small company or a large enterprise, agility is the key to survival. The C-suite has a responsibility to engage and promote agility. With their efforts, driving culture change can be accomplished.
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.
The role of SM (Scrum Master) is challenging. It takes a certain type of person to succeed. As per the Scrum Guide, the SM serves the product owner, development team and the organization. The SM is a servant leader. Nobody reports to the SM.
Without formal authority, the SM relies on their natural abilities to provide leadership. People who shine as SM’s, tend to be those with high levels of social and emotional intelligence. In short, they are great with people. They build meaningful relationships and promote trust.
In no particular order, here are five unique qualities that make up a great Scrum Master:
Empathy – Empathy is one of the competencies that make up emotional intelligence. It is the ability to feel the emotions of others. It creates a sense of rapport which is necessary for servant leadership. Empathy gives SM’s the ability to hone in on team members who may be frustrated or having difficulties, and help them. With empathy, the SM can see and feel someone’s struggles, without having to hear it. Great SM’s use empathy every day to gauge how the team is doing.
Courage – There are two key reasons why SM’s need courage. The first is having the courage to admit mistakes. When the SM admits to a mistake and takes accountability, it sets the right example for the team. In Scrum, the team needs to understand that it’s okay to try new things and make mistakes. This promotes trust and helps to improve team performance and innovation. The second reason SM’s need courage is to protect the team. When someone interferes with the Scrum team, the SM has to confront that person. Often this can be challenging for the SM, because it could be someone with position power who is affecting the Scrum team. An example would be a manager who requests the Scrum team to do something outside of their Sprint goals. The SM needs to have the courage to confront the manager and shield the team.
Coaching – The SM is a coach, and coaching is an art form. In Scrum, coaching is about asking the right questions and helping people learn. It is not about telling people what to do. Great SM’s are passionate about helping people to unlock their potential through coaching. The SM coaches the team on self-organization, cross-functionality and any areas in which Scrum is not understood. For a great book on coaching, see Coaching for Performance by John Whitmore.
Discipline – Scrum is a straightforward framework. The practice of Scrum and the Scrum events are easy to understand, but difficult to master. The SM must ensure the team stays disciplined to the Scrum events. For example, great SM’s don’t blow off Sprint retrospectives or any other Scrum event. SM’s need to ensure that team members are showing up and contributing to all the Scrum events. It all starts with the SM. Great SMs lead by example, and they show up early and prepared to all the Scrum events. They never cancel events unless there’s a good reason.
Facilitation – The importance of facilitation is often over looked or minimized. Have you ever attended a meeting that completely went off course due to poor facilitation? Or you had to wait 15 minutes for the meeting to start because the facilitator couldn’t get the conference bridge to work? We all have. A great SM is polished in their facilitation skills. They ensure that all Scrum events and meetings take place without a hitch. They do this by being well prepared in advance. They also use their social and communication skills to keep meetings on track, and on time. Crisp facilitation is crucial for SM’s.
Some people are fit to be a Scrum Master, and some are not. When managers are looking to fill a Scrum Master role, I tell them to not try and fit a person to the role. Instead, fit the role to the person. What I mean is, try to place someone who you already know is good with people. If you know someone is terrible with people, they’re not cut out to be a Scrum Master. It doesn’t matter how many certifications someone has, the SM must have emotional and social intelligence. If you can identify someone who has the five qualities I listed in this post, rest assured they have potential to be a great Scrum Master.
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 subscribe to Mike’s blog.