Category: Agile (Page 1 of 5)

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

Agile transformation

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

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

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

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

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

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

A Brief History of Agile

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

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

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

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

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

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

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

Pitfall 1, Not Having Goals

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

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

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

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

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

Pitfall 2, Lack of Prioritization and Executive Sponsorship

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

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

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

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

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

Pitfall 3, Putting Process over Behavior

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

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

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

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

Conclusion

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

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. 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.

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.

 

 

 

 

 

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.

 

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.

 

The Truth About the Limitation of Scrum

limitation of scrum

There is something I’d like to get off my chest. There is this notion in Agile that project management is no longer needed. Some even think that the role of a project manager will soon be extinct. Before we chase away project managers with pitch forks, lets back up a bit. I’m 100% on board with Agile and with Scrum, but I disagree that the need for project management is going away. The reason is that Scrum has a limitation. It is not designed to deliver large scale projects, at least not without help. The complexities of large scale projects demand the need for project management. This may change at some point, but I don’t see it happening any time soon. And, I’m not sure it should.

I can envision the Agile purists as they read this. Project managers needed in Agile? Scrum has limitations? Blasphemy! Hear me out.

When I refer to large scale projects, I mean projects that could have anywhere between 5-30 changed systems. These types of projects usually include complex system dependencies and a lot of coordination. The systems need to integrate and plan their production releases based on their dependencies. Someone needs to oversee that it comes together, and that someone is a project manager.

On Scrum teams, no, there is no need for a project manager. There are only three defined team roles in Scrum. They are Product Owner, Scrum Master, and the Development Team. Scrum is perfect for teams that focus only on one product or component. As an example, a Scrum team may focus on the search feature of a website.

The need for a project manager shows itself when you have large-scale initiatives. When you have a large project that impacts many Scrum teams, someone must coordinate all the dependencies between the teams. Without a project manager, who will do this? I posed this question in a recent advanced Scrum training course. I then proceeded to watch the instructor twist into a pretzel struggling to answer it. I was then referred to a course offered on Scrum@Scale.

Scrum@Scale, along with LeSS, and SAFe are the popular scaled Agile frameworks. While each of these have their benefits, they also have limitations when it comes to large scale projects. The problem is not scaling more Scrum teams, although that poses a different set of challenges. The problem is managing large scale projects.

In a recent HBR article, Agile at Scale, Jeff Sutherland and other experts discussed large scale Agile projects. They said you can establish a “team of teams” (or Scrum of Scrums), and issues that can’t be resolved can be escalated up to leaders. I’m all for that, but it still doesn’t answer the question of who is coordinating the work of all the teams? They go on in the article to reference Saab’s aeronautics business. “Aeronautics also coordinates its teams through a common rhythm of three-week sprints, a project master plan that is treated as a living document”.

I found it interesting that they referenced a company that uses a project plan in an article on scaled Scrum. This further indicates to me that we need to pause on the idea of abandoning project management.

Scrum@Scale is the model Jeff Sutherland advocates for scaling. In Scrum@Scale, there is a Chief Product Owner (CPO) and a Scrum of Scrums Master (SoSM). They are like the team level Scrum Master or Product Owner roles, but at scale. These roles sound like they will help address the challenge of managing large-scale projects, but there is still a gap. While a SoSM focuses on removing impediments and the CPO on prioritization, you still need someone to look at the project from a holistic view. Someone must coordinate team dependencies, not to mention manage risk, schedule and budget. In short, you need a project manager.

The need for project managers on large scale Agile projects has fueled the rise of SAFe. If you’ve read my post on the problem with SAFe, you know that I’m not a huge fan. But, at least SAFe acknowledges that someone needs to coordinate the work of self-organizing teams on large scale projects. They refer to the role as a Release Train Engineer (RTE), but it sounds a lot like a project manager to me.

Why do Agilest cringe when they hear the words project manager, or for that matter, the word project? When I say there is a need for project management in Agile, I am not saying that projects need to move in sequence from phase to phase like waterfall. I’m not referring to a command and control tyrant who manages Gantt charts with an iron first. Project managers today can lead large initiatives and still follow Agile principles. Projects can still use an iterative experimental process.

You may argue that by creating an architecture where each Scrum team works on an autonomous application, you end the need for a project manager. Spotify is a good example. Lightweight autonomous applications are the way to go, but you still can’t get away from dependencies on large scale projects. In most large fortune 500 organizations, legacy applications are dependent on other systems.

In summary, Scrum has a limitation when it comes to large scale projects. Project managers are not needed on Scrum teams, but they are still needed in Agile for large scale projects. What is changing is not that the Project manager role is going away. It is the role itself that is changing to align with Agile values and principles. The Scrum organizations seem to be working hard to address this limitation through their scaled frameworks, but they have a long way to go.

If you have experienced large scale Agile projects where there was no need for a project manager, I would love to hear about it. I’ve worked for many organizations that have adopted Agile and I’ve yet to come across one that had no need for project management.

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.

Delighting Clients Absolutely Needs To Be The Primary Goal

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.

Advanced Scrum Training and Meeting Jeff Sutherland

When it comes to Agile delivery, I’m a big advocate for Scrum. Scrum offers an easy to understand and lightweight framework for developing products.

Scrum is great, but it by no means is a silver bullet.  Scrum does not solve problems, it exposes them. It is like shining a big flashlight on your product development team, exposing the good, the bad, and the ugly. Scrum is an adaptive framework, not a methodology.

For most organizations, Scrum is an effective Agile framework. This is particularly true for companies new to Agile. Scrum offers a set of guide posts and rules that make it easier for organizations to get out of their own way. The rules are simple, but not easy. Anyone can get a get good understanding of Scrum by referencing the Scrum Guide.

Last week I got a great refresher on Scrum by taking the Scrum Alliance Advanced Certified Scrum Master (A-CSM) training led by Angela Johnson. Angela is passionate about Scrum, and her and her company, Collaborative Leadership Team, does a great job.

The training was a great reminder that Scrum is about people working together to deliver the highest possible value early and often.

During the training, I had the privilege of meeting and chatting with Dr  Jeff Sutherland . He was teaching a course next door on Scaled Scrum and during a break we met. While we were discussing the challenges of Agile adoption, he gave me some good insight. He told me that sometimes all it takes is one person to start an Agile movement within on organization. He said it’s like someone pulls a lever.

Dr Sutherland relates Agile transformation to the Blue Pill/Red Pill scene from the Matrix. “Take the blue pill, and go back to sleep and continue to use waterfall. Take the red pill, and stay in Agile Wonderland, and see how deep the rabbit hole goes”.

Below is a picture I took with Dr Sutherland.

 

Jeff Sutherland and Mike MacIsaac

Jeff Sutherland 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 subscribe to Mike’s blog.

Embracing Change and Dotcom Operations

“The Only Thing That Is Constant Is Change” – Heraclitus

Change is necessary in business, technology, and in our personal lives. For me, these past couple of months I have had a lot of change in my life. From moving to a new home to starting a new consulting assignment, change has been abundant. While change can be unsettling, it’s necessary for growth. This brings me to latest consulting role, working in Dotcom Operations.

The picture above shows the monitoring screens located across from where I sit. As you can tell, it’s no small deal. Keeping a live production website running which handles thousands of transactions per second is no small ordeal. To do so, while also adding changes and enhancements, requires talented operations teams.

In my view, operations teams don’t get the credit they deserve. The people I’m working with in web operations are some of the most technical folks I’ve worked with. They are also good people. They are infrastructure engineers, coders, and they work with the latest DevOps technology.

It’s fun learning about the latest technology they’re using in Web Operations. Infrastructure built in the cloud using tools like Jenkins, Chef and Splunk has given me a broader perspective on IT. It’s taken me back to my days testing software in QA, but things have changed. The technical systems for web operations are more advanced than they were five years ago.

Technical systems are always challenging to manage, but what’s more challenging, are the human systems. People need to collaborate and communicate with each other, and this is where I come in to help. The effectiveness of operations teams relies heavily on communication.

To help with communication and the constant influx of work coming in, the teams use Kanban. Kanban uses a pull system to make process better. Below is an example of what you may have seen with a Kanban board.

The core practices of Kanban are as follows:

  • Visualize Workflow – Using Kanban, teams can see the whole visual representation of their workflow.
  • Limit WIP (work in progress/process) – Teams should experiment with WIP limits, which will help improve focus and increase throughput.
  • Manage Flow – By paying attention to how quickly work is getting through the process, teams can begin to improve flow management.
  • Make Process Policies Explicit – Teams should set their own policies on how they can best do their work and improve flow.
  • Implement Feedback Loops – This is about continuous improvement. Just like in Scrum, Kanban teams need to measure their effectiveness and continuously improve.
  • Improve Collaboratively, Evolve Experimentally

Kanban comes from manufacturing and the TPS (Toyota Production System). The below quote is from Taiichi Ohno, creator of the TPS:

“There is no magic method. Rather, a total management system is needed that develops human ability to its fullest capacity to best enhance creativity and fruitfulness, to utilize facilities and machines well, and to eliminate all waste.”

Eliminating waste was a major rule of the original TPS. TPS identified seven types of waste in manufacturing. They are Transportation, Waiting, Motion, Defects, Inventory, Overproduction and Extra Processing.

Years later, Mary and Tom Poppendieck defined the following seven categories for waste in software development.

  • Partially done work
  • Extra processes
  • Extra features
  • Task switching
  • Waiting
  • Motion
  • Defects

An effective way of identifying waste for is through creating Value Stream Maps. Often the biggest bottlenecks occur after development and testing are complete.

Summary

Over the past few years I’ve managed a broad range of IT projects. From working in the insurance industry, to reverse logistics programs, to Web Operations. While this work has commonalities, Web Operations is different. Tackling a constant flow of work is a change for me, and change is good. The change to Web Operations has provided me with two key opportunities. The first and most important, is to provide value and help a talented team of engineers. The second is to learn a different aspect of IT and business.

Are you embracing change in your business and in your life? If you work in software development, are you continually trying to reduce waste and follow lean principles?

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

 

 

 

 

 

 

 

 

Page 1 of 5

Powered by WordPress & Theme by Anders Norén