Category: Agile Page 1 of 5

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.

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. MacIsaac Consulting provides Agile Consulting, Agile Coaching and Agile Training. 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.

Page 1 of 5

Powered by WordPress & Theme by Anders Norén