When it comes to software quality assurance, most people think of phase at the end of a project. This testing phase is usually performed by “quality assurance” testers. The traditional project delivery model is to blame for this. As someone who worked as a software tester for years, I know about the pains of doing all testing at the end.
The problem of course is that when testing happens at the end, after a development phase, it is too late. What you are doing is trying to inspect quality in, instead of building quality in.
Lean manufacturing and lean software development is about building quality in. This was one of W. Edwards Deming’s, a pioneer in the lean and quality movement, motto’s . To build quality in, testing should take place all throughout the project. Testing early reduces the cost of defects because the earlier you catch defects, the cheaper they are to fix.
For this reason, it is well advised for software delivery teams to apply lean principles and automate as much as possible. Automation shouldn’t only be a set of regression tests that run at the end. Automation should take place all throughout the entire software development and release process.
After TDD, automation can be applied from build and deploy to acceptance tests.
This brings us to the process of Continuous Delivery. Continuous delivery is all about creating reliable software releases through build, test, and deployment automation. Today, more software organizations are reaping the benefits of continuous delivery, yet for most it’s still a pipe dream.
People think the idea of automating everything is too daunting, or can’t be done for their application. More and more we are now seeing that continuous delivery can be done, for any application or organization, no matter the size. A good way to start is by looking at your current release process, and finding the biggest bottlenecks. You can then start to automate over time, targeting the bottlenecks first.
By automating the whole software release process, you build quality in. This makes everybody on the delivery team responsible for quality, not just a “QA” team who tests at the end. For manual software testers, continuous delivery enables them to focus on exploratory testing.
There are many other benefits to TDD and continuous delivery, but perhaps the greatest is the reduction of stress for delivery teams. If you’ve gone through a production deployment process, using manual processes and ad-hoc configuration techniques, you know what I’m talking about.
For those who already use lean development techniques this information shouldn’t be news to you. If you still work in an environment that uses SDLC processes with little to no automation, the topics I’ve covered only scratch the surface.
Some great books I recommend on lean software development and continuous delivery:
“A ‘no’ uttered from the deepest conviction is better than a ‘yes’ merely uttered to please, or worse, to avoid trouble.” – Mahatma Gandhi
Authenticity is one of the most important traits for quality leadership. The tendency for a lot of us is to put on a persona at work, and not be ourselves. The problem with this is that people can see through us in a minute, and all trust goes out the window. People need to count on their leaders for the truth.
Living and working in Minnesota, I see first hand the problems that go along with people not speaking their mind. “Minnesota nice” is the term. People are reserved and polite in meetings, then voice their true feelings at the water cooler.
I ask teams I work with to drop the Minnesota nice. I tell them that if you disagree with me, I encourage you to speak your mind. Being a New Jersey native, disagreement will not hurt my feelings.
Healthy debate is good for teams, and we need people who will challenge our ideas and positions. At first people are uncomfortable being candid, but after time they open up as you build trust.
Building trust is an exercise that all leaders can and must do. They do it by aligning their actions with what they say. If a leader tells the team they will do something and then doesn’t deliver, the leader immediately cut all trust from the team.
I strive to be as authentic as possible in both my personal and professional life. I want people to know that what they see is what they get. Whether we’re in a meeting at work or running into each other at the grocery store, I’m the same person.
Being authentic is not always easy though, especially at work. Let’s face it, we do have to deal with politics and we need to be somewhat mindful about how we express ourselves. Being candid doesn’t mean shouting out whatever comes to mind, with no filter. If you are tactful, you can still express your thoughts, feelings, and ideas without fear.
From an organizational standpoint, it’s crucial for leaders to foster a culture of honesty and openness. It starts at the top, and this behavior should align with the core values of the company.
For more content like this, subscribe to the MacIsaac Consulting Blog.
Quality control, defined by the 5th edition PMBOK, is “The process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes.” Quality control is important and valuable, especially for IT projects. Managers need to have a clear understanding of where things stand. If your project is nearing deployment, you would want to know if any critical defects were still open or if any tests remained.
Here’s the problem, a lot of organizations mistake quality control as quality improvement. Metrics are just like a thermometer. A thermometer can tell you the temperature, but it cannot change the temperature. Managers love to look at metrics and graphs, only to put more pressure on teams when they don’t like what they see.
I used to generate a defect slip rate report each month for management. The defect slip rate was calculated by dividing the number of defects found in production by the total number of defects found in prod and test. We defined a target of 20% so anytime we are over 20%, our slip rate was over our targeted threshold.
While the defect slip rate report helped give us a view into our software quality, it never improved it. Throughout the year the defect slip rate percentage on average would stay about the same.
When it comes to quality, organizations not only need to measure, they need to improve. This is part of the reason Agile and Scrum have become so popular for technology delivery. Using Scrum, project teams perform retrospectives, always looking for ways to improve.
The continuous improvement process goes back to the Toyota Production System and Deming’s Plan Do Check Act model. In Japan, the continuous improvement philosophy is called Kaizen.
The point is this, metrics are important, but what’s more important is improving quality. If you’re stuck in a pattern of putting out fires, you’re not improving quality. Fixing production issues is not improving quality. Running defect and metrics reports is not improving quality. Quality comes from improving the system as a whole, and building a quality product up front.
For more content like this, subscribe to the MacIsaac Consulting Blog.
Defining what quality means is difficult. On this subject, the great statistician Walter Stewart stated: “The difficulty in defining quality is to translate future needs of the user into measurable characteriscts, so that a product can be designed and turned out to give satisfaction at a price that the suer will pay” (Shewhart, 1931).
In software development, we tend to focus on a series of defined tests. If all our tests pass, we have developed a quality product ready to be shipped. If the product is shipped and the result is a high volume of production defects, the product was not of good quality.
The challenge with the old way of Waterfall software delivery, and only relying on our tests, is that the consumer of the product is involved too late in the product development process. The consumer is perhaps the most important aspect of developing quality software.
For this reason, we need to involve the consumer all throughout the development process. This way, we build quality up front.
The below figure shows the three corners of quality model put forth by Edwards Deming.
What we have learned with the application of Agile, is the importance of learning from the customer. Deming talked about this back in the 1970s, but it wasn’t until the early 1990s that it was applied for software development.
On learning from the consumer, Deming writes: “The main use of consumer research should be to feed consumer reactions back into the design of the product, so that management can anticipate changing demands and requirements and set economical production levels. Consumer research takes the pulse of the consumer’s reactions and demands, and seeks explanations for the findings” (Deming, 1982).
What Deming describes is exactly what takes place during the Scrum sprint reviews. During the sprint review, we show production ready software to the consumer. The consumer can then give immediate feedback. This allows us to make changes to the design of the product.
The old way of delivering software looked like this:
The new way of delivering software using Agile ensures we build quality into the product up front. We build production ready software in short iterations, then review it with the customer. The new way of delivering software looks like this:
For more content like this, subscribe to the MacIsaac Consulting Blog.
W. Edwards Deming was a quality theorist, statistician, author and management consultant. He was influential in the practice of quality management. Deming’s most urgent message was for management. He stressed that management create a system where each worker could do a good job and take pride in their work.
What is quality? The International Organization for Standardization (ISO9000) defines quality as “The degree to which a set of inherent characteristics fulfills requirements” (Project Management Institute, 2013, p.228). Quality is one of the most important factors for any business to be successful.
“Quality is more than just a statistical analysis tool for manufacturing lines. When done right, quality should encompass the entire enterprise” (Stevenson, 2009, p.406). An increase in quality results in better productivity, higher morale, and increased customer satisfaction.
Edwards Deming was a visionary who understood the importance of quality management. His concepts helped Japan rise to become a world economic power.
Like most of the major contributors in the area of quality, Deming studied engineering. He would go on to get a PhD in mathematical physics from Yale in 1928. Deming was a professor of statistics at New York University’s graduate school of business. He later went to Japan after WWII to help improve their quality and productivity. He used statistical analysis and a systems approach towards quality.
Deming’s teachings and models were successful in Japan. To this day the Japanese give out an award for quality named the Deming prize. One of the causes for Deming’s popularity was his list of 14 points for quality. He was also an advocate of the Plan-Do-Check-Act (PDCA) cycle.
Deming lived from 1900 – 1993. His theories had great success in Japan, but he didn’t have much popularity in the US until the 1980s. In the 80s he worked with American Automobile companies to help improve their quality.
Management and the system
One of Deming’s key messages was that the cause for poor quality was not the employees, it was the system. He emphasized that it was management’s responsibility to fix the system. “According to Deming, 85 percent of the quality problems on a project are attributable to the management environment and the system in which the team works” (Mulcahy, 2013, p. 297).
Appreciation for the system refers to everyone within a company working to achieve optimization. “Deming believed that knowledge comes from theory, and that learning cannot occur within an organization without a theory of knowledge” (Stevenson 2009, p 409).
Deming was an adversary of the annual performance review process within companies. He thought the arbitrary annual review process was managing by fear. He believed it robbed employees of their internal motivation. Deming believed managements greatest challenge was motivating workers to achieve a common goal.
The Plan Do Study Act (PDSA) Cycle
The concept of the PDSA cycle was introduced to Deming by Walter Shewhart of Bell Laboratories in New York. The first step in the process is to put together a plan by formulating a theory and creating success metrics. Next comes the execution of that plan (the Do step). Following execution is studying the results. The last step is to act based on the results found and put in place adjustments if needed.
The Five Deadly Diseases of Management
Edwards Deming recognized five deadly diseases of management which impede quality improvements. The five disease are as follows:
1. Lack of constancy of purpose. This means that leadership needs to understand exactly why they are in business. They must have a clear mission that has a market for the future and is understood throughout the organization. Firms need to plan for the future and have a long term definition of goals.
2. Short term thinking and emphasis on short term profits. Too much focus on quarterly dividends and raising the company stock. Not enough focus on quality and long term planning.
3. The annual system of rating/performance review. The yearly employee review has a negative effect on long term planning as well as team work. Employees get bitter when they do not receive high performance ratings. The system is arbitrary, unjust and demoralizing to employees.
4. Management that has no roots in the company. They lack knowledge and understanding of operational problems.
5. Use of visible figures only for management. Management needs to understand there are unknowable figures. Understand the importance of the multiplying effect of a happy or unhappy customer (Deming, 1984).
14 Points for Quality
Perhaps the most well know of Edwards Deming’s teachings were his 14 points for management. Below are the 14 points as stated from the Deming Institute (https://www.deming.org):
1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.
2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.
5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
6. Institute training on the job.
7. Institute leadership (see Point 12 and Ch. 8). The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.
8. Drive out fear, so that everyone may work effectively for the company (see Ch. 3).
9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
Eliminate work standards (quotas) on the factory floor. Substitute leadership.
Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
11. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
12. Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objective.
13. Institute a vigorous program of education and self-improvement.
14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody’s job.
For more content like this, subscribe to the MacIsaac Consulting 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. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or visit Mike’s blog.
In 2011, my wife and I went on a vacation of a lifetime. We went to the island of Maui, and we were fortunate to stay in the Ritz Carlton hotel. The trip was a wedding gift from a very generous family member. Had it not been for the gift, my wife and I would have not been able to take such an extravagant vacation.
Staying at the Ritz, surrounded by the beautiful blue ocean and breathtaking Maui views, was an experience we will never forget. Yet, when I look back upon the experience staying at the Ritz, there’s something else that I am reminded of. It wasn’t only the radiant sunshine and palm trees that delighted us. The customer service provided by Ritz Carlton employees was fantastic!
By far, the customer service at the Ritz was the highest quality we had ever experienced. Whether checking in, asking for advice, or saying hello, the staff treated us as though we were royalty. They did this for good reason. They understood that an underlying principle for successful business is to delight clients.
In 1954, in his book The Practice of Management, Peter Drucker said that the purpose of a business is to create a customer. Well, times have changed. While Drucker may have been right that creating a customer was the purpose for business in the 20th century, it’s not good enough today. Increased competition and the advance of technology and globalization have demanded a new way of doing business. The marketplace has changed. Today, businesses need to not only create a customer, they need to delight them.
In Stephen Denning’s book, The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century, he emphasizes the importance of delighting customers. He puts forth principles aimed at moving away from Fredrick Taylor’s outdated command and control style of management. Setting a goal to delight clients is Denning’s number one principle. “The purpose of work is to delight clients, not merely to produce goods or services or make money for shareholders”, writes Denning.
By having client delight be the company goal, it achieves several things. First, clients will promote a product or service if they are delighted by it. Dr. W. Edwards Deming used to harp on this. Dr. Deming said that a happy customer will generate new customers through word of mouth. This effect poses a dilemma for management because it’s hard to put figures around it. It’s hard to measure. Dr. Deming said: “The most important figures that one needs for management are unknown or unknowable”.
Second, delighting clients will inspire continuous innovation. Employees don’t get inspired to produce goods or to increase shareholder value. Employees get inspired to improve people’s lives. Starbucks gets this. Their mission is not about coffee, it’s about inspiring and nurturing the human spirit.
Third, delighting clients fosters a company culture that enriches job satisfaction. Companies that put client satisfaction first, use self-organizing teams. If you haven’t experienced working within a self-organizing team, where you are free to innovate, be yourself and have fun, you are missing out.
The Agile software delivery movement has been leading the way for a new customer focused style of management. Regardless if your business creates software or not, there is much to learn from the Agile movement. It’s the modern way of doing business, with focus not on systems and things, but on people. In Scrum, self-organized and empowered teams build products in short iterations. After each iteration, the product goes to the client for immediate feedback. Shorter feedback loops increase both the product quality and client satisfaction.
The market place today demands a new way of doing work. Our workplace is now made up of knowledge workers, and we must inspire and empower them. Fredrick Taylor’s model of management is not suitable anymore.
Going back to the 2011 vacation my wife and I took in Maui. The experience we had staying at the Ritz Carlton will forever be ingrained in our minds. We learned what it is like to be delighted as customers. For me, I want to emulate that feeling into the clients I serve. At the end of the day, business is about people, not about numbers. If we make client delight the top priority, shareholder value and profits will follow.
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.
It’s that time of the year again. Office Christmas party’s and holiday happy hours are in full effect. Most people are scrambling to get last-minute gifts and prepping for time off. Soon the offices will be empty and most of us will be enjoying time over the Holidays with family.
At this point, most organizations should have a good idea what their IT roadmaps look like for 2018. Businesses usually rank projects based on need and return on investment. This process usually takes place in Q4 as teams prep to get funding for their roadmaps.
Non-IT management of the business typically handle the prioritization process. The idea is, let the business folks decide on what to do, then let the IT folks decide on how to do it. There’s a lot of logic to this train of thought, and for some companies this works well, but I would tell companies to take caution when using this approach.
The idea that the business should focus on the IT roadmap, without IT involved, is prone for trouble. Yes, the business should be accountable for prioritizing work that provides the most value, but IT should be in the discussion.
When prioritizing an IT roadmap, there are other factors to consider other than financial benefits. Looking only through the short-term lens of return on investment, you lose sight of the following questions:
Which projects are best aligned to the long-term IT strategy for the company?
How will the projects affect the IT teams? Are the team’s setup to be successful?
How will employees feel about the work? Will those who are doing the work find it engaging, or are you setting yourself up for a mass exodus?
How will quality be affected? Are you planning to take on too much work, which could jeopardize quality?
If your company is using or moving towards Agile delivery (which it should), how will that affect your roadmap?
Above are a few questions to consider, but you can see why IT leadership should be in the discussion when it comes to prioritizing work for the year.
Aside from IT being involved in the prioritization process, the business should also have a voice in technical solutions. Yes IT is ultimately accountable, but this doesn’t mean the business shouldn’t be in the discussion. When solving technical problems, it’s usually those who work in operations that have the best understanding of the issues. Their’ insights are invaluable.
The need for agile organizations demands that business and IT leadership come together. We can’t afford to have areas of our organizations working in silos. As we begin a new year, isn’t it time we find creative ways for our “business” and “IT” resources and leadership to come together?
At MacIsaac Consulting, we build relationships based on trust, commitment, and results. Based on these core values, we provide the very best IT delivery services to our clients. Our goal is to help companies improve the quality of their software products.
We are big on Agile delivery, but it’s clear to us that many organizations still have an Agile delivery problem. The problem is that companies rush into Agile adoption too soon. In short, they lack strategy! The results are high Agile training/coaching fees and little results. For those organizations who have felt this pain, we hear you!
To address this problem, we help companies create an Agile strategy. We do this through the following three-step approach:
Detailed assessment of your current state IT delivery capabilities (where you currently are).
Strategic recommendations and goals for your Agile adoption (where you need to be).
Partnership options to help you meet your goals (how we can help you get there).
Together we will create an Agile adoption strategy that’s tailored for your organization. Whether you are a large or small company, when it comes to Agile adoption, there is no one size fits all.
We are agnostic to any particular brand or framework of Agile. Our approach includes all aspects of how you delivery software. This includes both business and IT. Too many companies make the mistake of only focusing on their IT teams, but business and IT must work together as one.
We insist that business leadership understands the principles behind Agile delivery. This is so important to a successful Agile delivery transformation.
For more on our Agile advisory services, I encourage you to reach out to us. We are a small team of seasoned IT delivery and Agile experts. All our consultations are at no cost to you. Our ultimate goal is to set you on the right path.
We want to hear from you! We are here to be your trusted Agile strategy advisors.
For an intro to MacIsaac Consulting, see my short video below:
About the Author: Mike MacIsaac is the owner and principal consultant forMacIsaac 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
If you work in a business that has anything to do with technology, you are familiar with Agile. You know the Agile I’m talking about. The kind where teams sit together and deliver software in increments. Seems everywhere you turn these days you hear about Agile. Along with Agile’s popularity has come a title wave of services. These services include coaching, training and certifications.
Consultancies have jumped on the Agile bandwagon big time. The other day I noticed a local consulting firm completely re-branded themselves. They are now the Agile experts. I was like wait, what? Like a year ago, they didn’t even provide IT consulting. Anyway, you get the point, Agile is the flavor of the moment and it’s everywhere.
Along with the over promotion and saturation of Agile, there has also been a mass influx of Agile gurus. These gurus scour the internet to prove their Agile knowledge is second to none. Agile to them has become a religion. They are quick to scold anyone blasphemous enough to challenge their Agile expertise. If you follow any Agile groups on LinkedIn, you’ve seen the ridiculous feuds. For sure the gurus will comment on this post to teach me the error of my ways. Dealing with these gurus online is bad, but if you’ve had to work with them, it’s even worse.
So, between the obnoxious gurus and the commodification, I must ask, have people had enough of Agile? Is Agile software delivery like the glam hair metal of the 80s, and we’re at the point of Nirvana and grunge breaking onto the scene? Keep in mind that as I ask this question, I’m a pro Agile guy. For many years, I studied and worked in both the Agile and traditional SDLC worlds, and today Agile is my preference. Although I’m a pro Agile, I’m concerned about what Agile has become.
To back up a bit, I started my career back in 2000 as a manual software tester, long before Agile exploded onto the scene. For years, I tested software for various organizations. Around 2008, I got introduced to Agile when I worked as a QA analyst on Scrum team. After time, I started working as an IT Project Manager and an Agile Scrum Master.
I studied everything I could on project management and on Agile delivery. I got my PMP and in business school I studied systems thinking and the theory of constraints. I attended Agile training, got a CSM (Certified Scrum Master) certification, and read every book I could on Agile.
Today, I still consult as an IT project/program manager or Agile Scrum Master. Although my preference is Agile, I’ll perform whatever the client role requires. Usually this means being a traditional project manager, an Agile Scrum Master, or a hybrid of both.
I have a real appreciation for Agile delivery. I found that the Scrum Master role coincides with two of my other passions, leadership and emotional intelligence. I love how Agile delivery is not only about writing code, but also about relationships and working together as a team.
As much as I’m a fan of Agile, I still think there is value in traditional project management. There are disciplines and processes that are tried and true in project management. We need to be careful not to write them off. Not all organizations are ready for Agile adoption, and that’s okay. I know that may sound odd coming from someone who is pro Agile, but if we are honest, Agile adoption is not easy. It isn’t as simple as attending a training. There are some great training services available, but often they have little effect.
All this leads me back to question, have people had enough of Agile? Am I, and pro Agile people like myself, part of the problem? Have we lost sight of the Agile Manifesto and become too dogmatic in our views, turning others off?
Soon Agile will morph into something else. New delivery frameworks will emerge, and so will new gurus. Whatever happens, it’s important we open ourselves up to not having all the answers, and we remain teachable. The main goal is that we continue to improve how we develop software and work together. To me, the Agile movement is a part of something bigger than certifications and gurus. It’s about working together to build quality products that provide value. What say you?
About the Author: Mike MacIsaac is the owner and principal consultant forMacIsaac 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.