Search Inside Yourself To Unlock Your Full Potential

Search Inside Yourself

Heather Wray-Isquierdo, Tere MacIsaac, Mike MacIsaac

Last night my wife Tere and I attended a great event by the Minnesota High Tech Association (MHTA) and Women Leading in Technology (WLiT) program. The keynote speaker was executive coach Heather Wray-Isquierdo. Heather did a wonderful job! She explained the benefits of practicing mindfulness and emotional intelligence. She also provided easy to put in place techniques. You can learn more about Heather at her website.

“Search Inside Yourself” is a training program first developed at Google. The program aims at teaching mindfulness and emotional intelligence. The training has become popular and is now used in 30 countries around and the world and companies like Ford, LinkedIn and The New York Times. For more on the training, check out the Search Inside Yourself Leadership Institute.

With all the distractions and stress we face today, it’s becoming more important we learn how to quiet our minds. It’s ironic, the more technology advances, the more we see a need for basic human connection skills. Working in IT, I’ve been saying for a long time that we have a gap in emotionally and socially intelligent leadership. The notion that IT people only need to use left brain and analytical thinking is flawed. Technical knowledge and IQ are still important, but they are not enough.

Thank you to MHTA, WliT and Heather Wray-Isquierdo for putting on such a great event! Below are some pictures.

Tere and Mike MacIsaac

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.

3 Things You Can Count On The Best Project Managers To Do

Leadership

I’ve always had a great deal of respect for project managers. Managing projects, especially IT projects, is challenging. It requires skilled individuals who are strong communicators and cool under pressure. They juggle competing priorities while managing personality conflicts and keeping stakeholders happy.

I’ve been fortunate enough to have worked with some great project managers. Over time I’ve learned there are three things you can count on them to do. Here they are:

1.   They provide clear communication – They keep stakeholders updated through easy to understand written and verbal communication. A lot of project managers struggle in this area, and for good reason. It’s difficult to provide an easy to understand update when managing complex projects. The tendency for project managers is to rush and write up a long email that gets down into the weeds. They think they’re doing a good job because they provided a lot of information. In fact, they leave people confused and frustrated. People don’t want to read a long email and figure out what it means.

2.   They take full ownership and drive the work – Projects are challenging and messy. If they weren’t, there wouldn’t be a need for project managers. Great project managers take stress of their bosses’ plate by taking full ownership. They will drive the project to completion. Yes, sometimes project managers will need help from leadership. When those times come, it’s important they ask for help. But most of the time, great project managers do whatever it takes to lead the project to success.

3.   They stay positive – If the project manager starts to get down and negative, the whole team will follow. It’s so important as a project manager to stay positive, even when the going gets tough. And, it will get tough. I’ve yet to experience any IT project that didn’t come with some level of stress or issues. Problems will come, but the project manager needs to stay positive. This is the essence of leadership. Collin Powell once provided a great lesson he learned on this from infantry school. They taught him: “no matter how cold it is, lieutenant, you must never look cold. No matter how hungry you all are, lieutenant, you must never appear hungry. No matter how terrified you are, lieutenant, you must never look terrified. Because if you are scared, tried, hungry and cold….they will be scared, tired, hungry and cold.”

Summary

Project management is difficult. If it wasn’t, there wouldn’t be such a large demand for project managers. If you are a project manager and you want to stand out from the crowd, focus on these three things. First, take the time to provide clear written and verbal communication. Second, take full responsibility to drive the project. Lastly, be positive, especially when things get tough.

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.

What Is Agile Transformation?

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

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

Fall’s Reminder That Change is Necessary

Living in Minnesota, fall is my favorite season. The crisp air, leaves changing colors and smells of chimney’s. It brings back cherished childhood memories. I remember the excitement of playing outside with friends after school. The closer it got to Halloween, the pinnacle of childhood bliss, the more fun we had.

Today, fall reminds me that change is necessary. As the leaves drop, it’s a good time to reflect inward. What changes do I need to make?  Leadership is about change, and often the most important thing to change, is ourselves.

 

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.

 

 

 

A Realistic Look at the Agile Manager

Agile Manager

Often you will hear that the biggest challenge to Agile adoption is management. There is little doubt about this. Adjusting to an Agile mindset for many managers is difficult. This is especially true for managers who only know a command and control environment. It also doesn’t help that most business schools teach outdated management theories. Agile requires a new way of managing based on coaching and empowering others.

It is important though to realize that manager’s still play a key role in Agile. Just because the Scrum Guide and Agile Manifesto pay no mention to managers, it doesn’t mean they aren’t needed. To the contrary, in my experience good managers are crucial to the success of Agile delivery. Management shouldn’t be a bad word!

Let me provide a scenario. An Agile team was on track to a deliver a product to a very important customer. The team misses their promised delivery date and the customer is irate. In a situation like this, should executives look to the entire Agile team to understand why the delivery date was missed? No, they shouldn’t. In this situation, a manager should be the one to explain to the executives what happened, and take the heat. The manager would also provide direction to go forward. It’s the manager’s responsibility to communicate with leadership and, well, to manage.

Agile is about empowerment and trust, but this doesn’t mean we abandon management. If we did, it would be chaos. The notion that managers relinquish all control to delivery teams is naive. It’s also irresponsible. Agile purists envision a Utopian world of people working together in harmony. They long for a workplace where people are never told what to do. The reverse is the old school manager, who wants to make all the decisions. Neither one of these approaches are adequate. The key to management is balance. This brings me to the Agile manager.

The Agile manager empowers teams, but also knows when to step in. They are servant leaders first, but they know when to manage. The idea that managers should never put pressure on teams, or tell anyone what to do, is a fantasy. As Agile continues to evolve, we can’t see management approaches as black or white. Agile managers must be flexible. The best teams evolve from a diverse management approach.

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.

4 Proven Steps For The C-Suite To Drive Greater Agility

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:

  1. 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!
  2. 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.
  3. 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.
  4. 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.

 

 

 

 

 

Leadership Is About Enjoying The Success Of Others

Leadership

I don’t know about you, but I love the feeling I get when I’m able to help someone.  This is especially true in the workplace. Recently I provided an opportunity for someone to give a presentation.  After some resistance, he proceeded and did a great job! Afterward, I gave him well deserved recognition. I also sang his praises to the rest of the leadership team.

Leadership is about helping others and empowering them to lead. It’s also about enjoying the success of other people.

Unfortunately, sometimes people get put into “leadership” positions, when they shouldn’t. Some people don’t enjoy helping others, or seeing others succeed.  That’s okay. This doesn’t make them a bad person, but it does mean they aren’t leaders. If you’ve ever experienced working for someone who never praised you for a good job, you know how terrible it is. Most people, more than anything, want to feel appreciated.

It’s ironic but by helping others, we help ourselves. If you think about the great leaders you admire, they all have something in common. They surrounded themselves with good people, and they empowered them. Steve Jobs once said, “It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”

In your role at work, regardless of your job title, ask yourself, am I helping others? Am I helping to develop and empower people, and am I enjoying their success? If the answer is no, it may be time to reevaluate whether you are in the right role. Or, you may need to realign your core values and priorities.

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.

5 Unique Qualities That Make Up a Great Scrum Master

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Conclusion

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.

 

Leadership Is About Owning Up To Your Mistakes

Elon Musk, the tech billionaire behind Tesla and SpaceX, recently made a huge mistake. When his plan to help a boys soccer team trapped in a cave in Thailand (all were eventually rescued) using a submarine failed, he lashed out in irritation. Musk’s actions of getting into a feud with one of the rescuers and calling him a “pedo” (short for Pedafile) was awful. It appeared Musk was more concerned about the spotlight than the trapped boys.

After the severity of the damage of his actions took hold, Musk did the right thing. He tweeted an apology to the rescuer he insulted, and he took all the blame. I remember reading Musk’s apology tweet and thinking, this was the best thing he could do. He messed up, and he’s taking accountability.

The mishap Musk got himself into is a great reminder that leadership is about owning up to your mistakes. I’m sure Musk’s intentions were good, but when things didn’t work out his way, his frustration got the best of him.

If you are in a position of leadership, you will make some mistakes. When they happen, don’t pass blame or make excuses. Instead, show vulnerability and accountability by owning up to your mistake. Not only will it help defuse the situation, it also provides a great example for those you are leading. We are all human, and none of us are perfect.

 

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.

 

Hours vs Story Points – Demystifying Sizing

I’ve worked with many different Agile teams from different organizations. Story points are a common topic of confusion and frustration on teams, particularly new teams. I hear questions like, should we use points or hours? Should we use T-shirt sizes? Should we use Fibonacci? Should we estimate the tasks or the stories?

In this post I’m going to explain how we use story points in Scrum. It is important to note that Scrum does not require any particular sizing or estimating technique. I’m going to explain Story points because it’s one of the most adopted techniques in Agile. The method I’m going to explain is a best practice.

Story points are a number assigned to a story, or PBI (product backlog item), to give it a relative size compared to other items in the product backlog. Before I go any further, let me explain something about “Stories”. User stories are a technique from eXtreme programming which expresses the need from the user perspective. A PBI doesn’t have to be in a user story format. In fact, if the item is not related to a user, don’t waste your time putting into a user story format. Creating a story that says something like “As a BA I need to write requirements so…” is bad. Often we refer to all the PBIs as stories, even though they all may not be in a user story format.

Back to story points. The story points do not equal hours, days or weeks. When estimating story points, the team is trying to figure out how big a story is compared to other stories. The team, those who will actually do the work, estimates the points.

For simplicity, let’s go through a basic example. The Product Owner created a Story which says “As an Admin User, I need the ability to disable other user accounts”. The team then during a backlog planning/sizing session looks at the story and asks the Product Owner questions. After the questions are answered, it becomes clear that the work is small. The team agrees to assign the story with 2 points, using a rough order of size scale like Fibonacci (1, 2, 3, 5, 8, 13, 21). The team then moves on to estimate the next story. The next story reads “As an Admin user, I need the ability to perform batch updates in the system and run real-time reports”. The team has many questions for the product owner about this story. There a lot of unknowns and potential complexity. The team then decides that due to the complexities, the story is much bigger than the previous story. After some back and forth, the team agrees to assign the story with 8 points.

The basic example I provided is how story points are used in Scrum. The points give a relative size to stories in the product backlog. That’s it. It’s not complicated.

Things get a little more interesting with Sprints. Before Sprints start, teams conduct a Sprint Planning Session. This is when the team determines what stories (which are already sized with points) will be completed in the Sprint. For 2 week sprints, it’s advised the planning session should be 4 hours or less.

During the Sprint planning session, the team breaks down the stories into tasks. The tasks are estimated in hours, one day or less per task. Once the time for the tasks is estimated, the team has a good idea of the work they can commit to in the Sprint. They can compare the estimated time of the tasks against their capacity. If they know one team member is on vacation for example, using the task estimates they can better plan for the Sprint.

When the Sprint is in progress, the team updates how much time is left to complete the tasks at the end of each day. This provides the data needed for the Sprint Burn down chart. The Sprint burn down chart shows the time remaining to complete the tasks. The Sprint burn down doesn’t measure completed story points, it measures completed hours of the tasks. Below is an example of a Sprint burn down chart:

Now, up until this point I’ve referred to story points only for relative sizing, with no relation between time and points. Yet, once teams establish a stable velocity (average amount of points they complete in a Sprint), they can use points to forecast release planning and a product roadmap. Although release planning is not a core Scrum event, it is widely used. When teams plan for a release, which may be several sprints in the future, they track using a Release burn down chart. Unlike the Sprint burn down chart, the Release burn down measures the completed story points. The release burn down tracks how many story points remain to be completed to meet the release.

Below is an example of a Release burn down chart:

To recap, Stories are estimated in points using relative sizing, and tasks are estimated in hours, no longer than one day. The Sprint burn down chart relates to time left to complete the tasks in the Sprint. The Release burn down chart relates to points left to complete the release.

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.

 

Page 1 of 13

Powered by WordPress & Theme by Anders Norén