Author: Mike MacIsaac Page 1 of 14

2019 Year in Review at MacIsaac Consulting

I’m grateful for the opportunities MacIsaac Consulting had in 2019. We had some challenging IT projects to manage and I am proud that we stayed true to our core values of trust, commitment and results. There were two projects this year that stood out.

The first was a DevOps project, led by Ryan Shea, to improve dotcom operational efficiency for one of the nation’s largest big box retailers. Ryan led the initiative to migrate company applications from an internal data center to a cloud platform. The cloud computing technology uses “container” virtualization technology. This helped to drive efficiency, save costs, and increase agility. Ryan also managed a continuous delivery team that automated the deployment process for web applications.

Ryan Shea – Agile Delivery Consultant

The second project was a challenging identity and access management (IAM) initiative I managed for a financial institution. IAM is a specialty discipline within cyber security. It increases productivity while securely enabling access to systems. To deliver the project, a cross-functional Agile team was used. The team used a Kanban process to integrate 30 legacy financial systems into one centralized IAM platform (SailPoint IIQ).

Looking Forward

In 2020 we plan to grow our talent and focus on our core competency of delivering Agile IT projects. We are also looking to do more work in the business analytics space, as well as help private equity backed companies deliver IT projects.

I’m excited about the changes and opportunities to come, especially in our local area. Minnesota has a thriving business community and a great talent pool! If your company needs help delivering IT projects, or if you’re interested in joining MacIsaac Consulting, give us a shout!

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.

Gratitude

Thanksgiving is here. It is time for gratitude and reflection. A time to take a step back from work and focus on what is important.

Today I am grateful for my family, having food on the table and a roof over our head. I’m also grateful for turkey and football!

Wishing you and your family a Happy Thanksgiving filled with gratitude!

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.

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.

Identity and Access Management (IAM) Is More Important Than Ever

It’s a company’s worst nightmare. A data breach or cyber-attack. Cyber-attacks continue to be a growing threat, but not all data breaches are caused by outside hackers. Ask Morgan Stanley. In 2015, the financial services firm revealed that an employee had stolen data from more than 350,000 accounts. Forrester estimates that 80% of data breaches have a connection to compromised privileged credentials, such as passwords, tokens, keys, and certificates.

To avoid a data breach nightmare, company’s must ensure only the right people can access appropriate systems, data, and resources, for the right reasons. This is accomplished through Identity and access management (IAM). IAM is a specialty discipline within cyber-security. It helps companies increase productivity while securely enabling access to applications and systems.

IAM has to be an essential part of your IT toolkit. The typical business user has dozens (even hundreds) of applications they must access to do their jobs. These applications span cloud, mobile and on-premise solutions, and all can hold confidential, sensitive and regulated information.

To address the access management problem, there are many different IAM products on the market. I’m currently finishing a project to put SailPoint IIQ in place for a large financial institution. SailPoint is a Java based web application that integrates with legacy systems and Active Directory (AD) enabled applications. Auto-provisioning, native change detection, reporting and access certifications are some of the features SailPoint IIQ offers. Some of the other popular IAM products include Oracle Identity Management (OIM), Microsoft Identity Manager and Microsoft Azure Active Directory.

Regardless of the product you choose, having the right IAM strategy in place is key. The implementation of IAM can be very challenging. It takes strong collaboration between business, IT and operational teams. It also takes prioritization from leadership. Without executive sponsorship, business system owners and stakeholders may be reluctant to assist.

If you are in early stages of IAM or if you are already into delivery, MacIsaac Consulting can help. We provide services to help you put the right IAM strategy in place and we provide delivery resources.

Below are pictures of the cross-functional IAM team in action from my current project which is winding down. The work is very challenging, as most IAM projects are. Yet, the project will be successful because the client made IAM a top priority. They made the investment and provided the support to get the job done. That’s what it takes.

If your company is ready to deliver IAM, or if you need help on your current journey, let’s talk!

We used a Kanban board to track each Application going through the IAM integration process
Cross-functional team made up of IAM engineers and business members
Expert SailPoint IAM engineers working hard in the team War Room

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.

The one trait that the greatest leaders have in common


Throughout my career, I’ve had the benefit of learning from different types of leaders. I have found that the greatest of them, all have one thing in common. They all strive to help others succeed. They enjoy helping people. It gives them sense of fulfillment that goes beyond personal gains.

We often here people in leadership positions speak about their commitment to service. They tout “servant leadership” as their motto, yet their words often ring hollow. Too often we learn that self-interest is their true motivation. These people are leadership impostors.

True leaders are different. What is it about them that makes them enjoy helping others? Are they some sort of special breed, predisposed to become servant leaders? Or is caring about the success of others a skill they developed over time? The answer may be, both.

First, caring for others is a skill that we can develop. By receiving honest feedback from our peers, we can improve our emotional intelligence. Studies have shown that we can develop empathy. Second, we know that each of our brains are wired in a certain way. For example, the brain areas necessary for remorse, do not function for sociopaths. So, there is a genetic predisposition factor.

Great leaders may have a generosity gene, but most also developed their skills. They did this throughout their life. Many have lived through difficult experiences, some going back to their childhood. At some point, someone helped them. It could have been a teacher, coach, manager or friend. These experiences taught them the importance of helping others to succeed.

You may say, all this talk about helping others is great, but isn’t leadership about results? That’s a good question, and here’s my answer. Leadership is about achieving results through others, so why wouldn’t you want others to succeed?

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.

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.

Merry Christmas and Happy New Year!


Thank you for your support in 2018. Wishing you and your family a Merry Christmas and a Happy New Year!

“Cultivate the habit of being grateful for every good thing that comes to you, and to give thanks continuously. And because all things have contributed to your advancement, you should include all things in your gratitude.” – RALPH WALDO EMERSON

Page 1 of 14

Powered by WordPress & Theme by Anders Norén