Category: Agile Page 3 of 5

Why I Love Agile (And You Should, Too!)

After recently starting a new consulting engagement as an IT program manager, I’m reminded why I love Agile.

I love Agile

 

For most companies, sticking with a Waterfall software delivery model is like being in a bad relationship. No matter how much you know and feel something is wrong, you keep going back to it.

It could be due to the comfort of the familiar. Sometimes the idea of changing to something unfamiliar is too frightening, even when we know we should.

One of the major problems I see with Waterfall is that it sets the stage for people to work against each other. Each phase in Waterfall provides the perfect recipe for friction among people who are afraid. What are they afraid of? They’re afraid of being blamed if things go wrong.

What if the project fails and they blame it on my requirements? What if they blame it on my software design? What if they blame it on my development or testing? The result of this fear is people working against each other.

In Agile you break down the barriers of fear and distrust by bringing people together into cross functional teams. When we bring the different phases and groups together into one unified process, we can achieve great things.

Agile is about people collaborating and connecting with empathy, while creating synergy to achieve a common goal. In my humble opinion, the greatest benefit of Agile is that it brings people together. That is why I love Agile.

About the Author: Mike MacIsaac is the president 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.

12 Ways Management Can Empower Teams And Create Agility

empower teams

Mike MacIsaac – President at MacIsaac Consulting Inc

With the advance of technology and globalization, organizations today must have agility. It doesn’t matter the industry, companies need to be able to adapt to change. As a consultant, I’ve seen this need first hand throughout the tech, retail, and financial industries.

Gone are the days when different departments within a company worked in silos. Companies who still do this, and use a static organization structure, will struggle to survive. They will fall to the competitive advantage of the agile organization.

The problems faced by companies today are too complex to not be agile.  The pressure put on from external forces demand a new way of thinking and collaborating.

One way to create agility is through the use of decentralized cross-functional teams (CFTs).  A CFT is a team made up of people from different functional areas within the company. These experts work together to achieve a common goal. Over time the team develops synergy, and becomes high performing. Team synergy vastly exceeds the productivity of individual efforts.

When management empowers CFTs to make decisions and self-organize, the teams move fast, really fast. Team autonomy and empowerment promotes an atmosphere of trust, creativity, and worker satisfaction.

One of the greatest benefits of empowered CFTs is their ability to manage chaos. This phenomenon is counter intuitive to our natural reaction to manage chaos. Most of what we learn in business school aligns with the carrot and stick style of management. The more things get out of control, the more we tighten up our grip on the team. As managers, we have to let go of this notion of command and control. We can empower teams while still holding them accountable.

In a recent HBR article, Michael Mankins and Eric Garton describe how Spotify balances employee autonomy and accountability. They write “Companies that take the approach of empowering autonomous teams must find ways to ensure that coordination and connectivity happen among those teams without relying on controlling managers. Again, it’s a matter of managerial art as well as science to achieve alignment without excessive control.”

If you assemble a CFT with people new to such an environment, there will be a learning curve. You can’t expect people to self-organize and make decisions when they are used to being controlled.  The key is for CFTs and management to learn a new way of thinking, but this takes time.

Ken Schwaber, who formed the Agile Scrum framework along with Jeff Sutherland, writes “A team requires concrete experience before it can truly understand how to manage itself and take the responsibility and authority for planning and conducting its own activities.”

Below are 12 principles that can help management develop high performing cross-functional teams:

  1. Create stable cross-functional teams – Creating stable CFTs, dedicated to long-term goals, is necessary for high performance, quality and innovation. To do this you must dedicate resources and provide constant training. Each team member must have knowledge and expertise in a certain functional area. Changing team resources and not allocating for long-term planning is a killer to team performance.
  2. Provide a clear and compelling purpose – People suffer when they lack purpose. It is the responsibility of management to provide a purpose. People need a purpose because it creates intrinsic motivation. If employees are assigned tasks that have no meaning to them, they will lack motivation. Management should communicate how the goals of the team align with the long-term goals of the company.
  3. Protect the teams – Run interference and protect CFTs from distractions and skeptics. Management must be committed to the overall purpose of the organization and the CFT. There are always skeptics and people who are resistant to change. It is well advised for management to not include these types on change efforts and new CFTs. Skeptics will cause more harm than good. Staff CFTs with people with positive attitudes who will champion the goals of the team and organization.
  4. Give teams the help they ask for – With the high performing CFT model, managers don’t tell the team how to do their job. Instead, the teams tell management what they need to be successful. It is the job of management to listen to these requests and do their best to provide the teams with the help they ask for. Again, just because management is not telling teams what to do, it doesn’t mean they shouldn’t hold teams accountable.
  5. Empower teams to make decisions – Management can hold teams accountable for results, but they need to empower teams to make decisions. The decentralization of authority allows teams and organizations to produce results fast while responding to change. Management is still responsible for telling teams what needs to be done, but the teams are responsible for how it will be done.
  6. Allow mistakes to be made – Encourage teams to accomplish stretch goals, but do not punish if everything is not achieved. It’s important for management to help drive out fear. When employees are afraid of being punished for mistakes, it kills innovation. The important thing is learning from mistakes. Teams should continually take inventory on how they can improve.
  7. Use information radiators – On CFTs, everyone needs to see what’s going on and what needs to be done. Having a board that displays visual controls enables and promotes teams to self-direct. Information radiators also let management and outside stakeholders view how the team is doing and how much work is in progress.
  8. Deliver as fast as possible – Fast product delivery results in increased business flexibility and happy customers. Short value streams eliminate waste and they allow decisions to be delayed. Management should promote the idea of delivering valuable products fast. Often time’s people think that you can’t deliver fast without compromising quality. This is not the case when you build quality and integrity into product development. The fast delivery system does not compromise on quality; in fact it improves quality because consumers get the product faster. This enables consumers to provide feedback sooner which can go back into the design of the product, improving quality.
  9. Analyze and improve throughput – The best way to optimize an organization is to focus on throughput. The theory of constraints teaches us to find bottlenecks in the system and fix them. Teams should continue analyzing the system, identifying bottlenecks, and removing them. When teams focus on improving non bottleneck areas of the system, it doesn’t help improve throughput. Following the theory of constraints principle, teams can delivery fast.
  10. Promote quality built into products – In Edward Deming’s book “Out of the Crisis” he writes “Quality comes not from inspection but from improvement of the production process. Inspection, scrap, downgrading and rework are not corrective action on the process”. This means for software development, we need to get away from this notion that QA is this separate process that happens after software development. We should not be inspecting quality into the software through QA. Instead, QA should be happening as part of software development through the use of test driven development and automation. This enables quality to be built up front, instead of through inspection.
  11. Improve quality by learning from the consumer – In the Agile software development “Scrum” we do product reviews continually with the consumer. This same principle can be implemented throughout the organization. The goal is to feed the consumer reactions and feedback back into the design of the product to improve quality.
  12. Provide servant leadership – In Scrum, the Scrum Master acts a servant leader. The Scrum Master job is to remove impediments and help the team. This servant leadership practice is a great example for management to emulate. By supporting and helping teams, you foster at atmosphere of empowerment and trust.

For many organizations, the points I listed may be a significant change from their current reality. It’s not easy to put in place all these changes. Even for the modern agile company, agility is an ongoing learning process. If your organization needs guidance, at MacIsaac Consulting we are here to help. From advising leadership, to providing resources, we can guide you on your agile transformation journey.

About the Author: Mike MacIsaac is the president 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.

References

Deming, E. (1982). Out Of The Crisis. Cambridge, MA: MIT.

Mankins, M & Garton, E (2017). How Spotify Balances Employee Autonomy And Accountability. https://hbr.org/2017/02/how-spotify-balances-employee-autonomy-and-accountability

Poppendieck, M. (2003). Lean Software Development. Upper Saddle River, NJ: Pearson Education.

Schwaber, K. (2004). Agile Project Management With Scrum. Redmond, WA: Microsoft Press.

 

Kanban vs Scrum – What You Need To Know

Kanban vs Scrum

If you are familiar with Agile you know about Scrum and Kanban. While these two Agile frameworks have similarities, they are also very different. Their differences go way beyond stickies on boards. In this post I’ll describe the two frameworks and their history, as well as their benefits and differences.

Scrum OverviewScrum is by far the most used Agile framework. Credit for the framework goes to Jeff Sutherland and Ken Schwaber. Scrum got under way back in 2001 after the creation of the Agile manifesto.

Scrum is great for complex software delivery projects. In Scrum, there are defined team roles which are Product Owner, Scrum Master, and development team. The Product Owner creates a backlog of user stories that define the scope of a project. The team then completes the stories in short iterations called “sprints”. Sprints usually last 2-4 weeks. Sutherland was influenced by his days as an Air Force pilot. He relates the team sprints process to coming back from short missions and landing the plane on time.

The goal is to have working software, approved by the Product Owner, at the end of each sprint. The stories worked on in the Sprint should be done (all testing completed..etc). The key metric used in Scrum is Velocity. Velocity is the average amount of points a team can complete in a Sprint. Within Sprints, change to work is discouraged.

The stories completed in each sprint represent part of the total project scope. The team repeats this cycle of sprints until all stories in the backlog are done, in which case the project ends.

Kanban Overview  – “Kanban” get’s its origins from the Toyota Production System. Back in the 1950s, Taiichi Ohno created a pull system for Toyota. The idea was first sparked by his experience in American supermarkets. He was fascinated by how shoppers would walk down the ails pulling only what they needed from the shelves and putting it into their shopping carts. Shoppers usually had a list they carried which told them what they needed.

In Toyota plants, “Kanban” are instructions in clear plastic that communicate information needed at work stations. In a sense, a Kanban is like a grocery list. When an order comes in, a Kanban would be used to pull the whole car creation process together. Each item needed for the Kanban is ready just in time (JIT). This enables minimal build up of inventory. In a lean system, the goal is to reduce waste. The build up of inventory is the worst form of waste according to Taiichi Ohno.

The principles of the Toyota Production system were emulated in lean software development when Kent Beck created XP (Extreme Programming). The goal was to use the JIT principles and limit work in progress to the teams capacity. Beck also implemented a test driven development (TDD) process that improved quality. XP can be considered a different Agile framework from Scrum and Kanban. In my view, XP has more of relation to Kanban, since Beck based most of the practice off of Ohno’s Kanban method.

Unlike Scrum, Kanban is usually not the framework of choice for software delivery projects. Projects have a clear beginning and end, as well as a defined scope. Kanban works well for support teams, where work will be ongoing.

Teams will use a Kanban board, like the board a Scrum team would use for their Sprint. There are no Sprints in Kanban, the work is a continuous flow. There are also no defined roles in Kanban, like there is in Scrum. Cycle time is the key metric used and unlike the Sprints in Scrum, in Kanban change can happen at anytime.

Some of the benefits of Kanban include flexibility in planning, increased throughput, fewer bottlenecks and visual metrics. Kanban also compliments continuous delivery.

Below is a grid that Dan Radigan from Atlasssian put together, which displays the differences between Kanban and Scrum.

                                          Scrum                                                             Kanban

Cadence Regular fixed length sprints (ie, 2 weeks) Continuous flow
Release methodology At the end of each sprint if approved by the product owner Continuous delivery or at the team’s discretion
Roles Product owner, scrum master, development team No existing roles. Some teams enlist the help of an agile coach.
Key metrics Velocity Cycle time
Change philosophy Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. Change can happen at any time

Summary

Scrum and Kanban are two different Agile frameworks, but both have many benefits. In my view, Kanban is more aligned with lean development than Scrum. The area where Scrum gets into trouble with lean is the idea of having a team create and work on a large backlog. Lean experts, like Mary Poppendieck, cringe when they hear the word backlog. This is because it goes against the principles of JIT and low inventory. At Toyota, I’m sure the plant manager would freak if they had a large backlog of orders piling up. They want to have low inventory and good throughput. While Kanban works great for a repeatable process, my view is that Scrum is the best framework for complex software delivery projects.

If you enjoyed this post, check out The Top 10 Influencers of Agile.

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.

 

The Worst Advice We’ve Ever Heard About Scrum

 

Scrum Master

Currently I’m consulting as a Scrum Master for a couple of Scrum teams. This morning I was running a couple minutes late to one of the daily Scrums. When I arrived, the team had already started going around giving their updates. Seeing that the team already initiated the daily Scrum was music to my ears. The team doesn’t need to wait for me to begin, the daily Scrum is for the team.

I was happy because the team is self-organizing. A lot of teams new to Scrum will treat the Scrum Master like a project manager. In that case, they wouldn’t start any meeting before the project manager arrived. Non-Agile teams look to project managers to run meetings and tell everyone what to do.

With my current teams, I’m not only happy about their daily scrums. I’m also pleased with how well they do in all the Scrum ceremonies. They were a team that was new to Agile, and most of them have non technical roles. Even though there was a steep learning curve, the team now delivers completed work at the end of each sprint. They have a stable velocity.

What my teams are doing is the opposite of advice I once received from a manager about Scrum. It was the worst advice I ever heard about Scrum. He said: “feel free to cancel or reschedule those Scrum meetings whenever you like“.

At the time I heard this, I was new to Scrum, but I sensed it was wrong. The Scrum Master should never cancel any of the Scrum ceremonies.  “Those Scrum meetings” he was referring to were the daily Scrum, the Sprint review, and the Sprint retrospective.

In Scrum, it’s important to have discipline. This means the ceremonies always take place, and the team stays committed. Committed not only to the work in the Sprint, but also to the practice of Scrum.

Remember that in Scrum it’s about the team delivering value. It’s not about a project manager controlling the team. The Scrum Master is only part of a self-organizing team.

My advice is to never cancel or reschedule any of the Scrum ceremonies. Even if the team feels they don’t have much to show in the Sprint review, have it anyway. Stay disciplined and true to the practice of Scrum. The Scrum teams I work with now are doing so well because they’ve stayed discipline to the guidelines of Scrum.

What’s the worst advice you have ever heard about Scrum?

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.

Should a Scrum Master ever crack the whip?

Scrum Master

We know the Scrum Master role is different from a project manager. Scrum Masters are servant leaders, coaches and facilitators. Project managers are more aligned with command and control.

Does this mean that Scrum Masters should never crack the whip on the team?

Well, yes and no.

Just because Agile teams are self-organized, they sometimes still need to be pushed. Ideally the team will push themselves, but if that’s not happening then yes, the Scrum Master should put some pressure on the team. In Scrum, it’s usually the Product Owner who has some authority. Although the Scrum Master doesn’t have authority, they can vocalize the importance of getting work done (aka, crack the whip).

There are some misconceptions about Agile and Scrum when it comes to pressure. Some people think Scrum is a low pressure environment. Not true. In Scrum, they call iterations Sprints because teams are moving fast! There is pressure. There is also more visibility. Everyone can see what everyone else is working on in the Sprint. There is no hiding.

So, while cracking the whip usually aligns with project management, I do think it’s sometimes appropriate for Scrum Masters.

What are you thoughts?

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.

 

 

The one thing you should stop saying to Agile teams

Let’s face it, Agile adoption is difficult. For people new to an Agile team, especially those who spent decades in the waterfall world, it takes time to adjust.

Agile teams

I’ve been on different types of Agile teams. Some were completely new to Agile, while others were advanced. As I’ve written in my post, the problems with SAFe, the real challenge with Agile adoption is the mindset.

It’s not the standups, retros or demos. That’s the easy part. The struggle is in improving collaboration, changing the way you think, and building trust.

If you are a manager, Scrum Master or coach, here’s the one thing you should never say to an Agile team: “This isn’t true Agile”.

I’ve heard this statement quite a bit, and I’m guilty of saying it myself.

Let’s take a look at the statement, and why you should never say this to an Agile team. What is “true Agile”? Is “true Agile” some destination that once you reach you’ve accomplished perfection among the eyes of the Agile Gods? Are there some absolute rules that dictate whether a team is “true Agile” or not?

I’ll tell you what “true Agile” is. It’s a unicorn. It doesn’t exist. It’s a mythical place we’ve made up in our mind due to insecurity. There is no true Agile and there are no absolute rules that say you’re either Agile or you’re not.

Here’s the problem. When you tell a team they are not “true Agile”, it sends the wrong message and makes them feel inferior. It’s demeaning and demotivating. Teams that hear they are not “true Agile” get frustrated and their confidence goes down.

Agile adoption is about progress, not perfection. If a team is doing their best to follow the principles, and following a framework, then they are an Agile team. The team should hold their head high and feel proud that they are Agile.

In Agile, it’s always about improving.  It’s the journey, not the destination. Listen to advanced Agile practitioners from places like Spotify or Google. They say that they are learning, changing and improving. They have humility.

Another way to think about it is with music. I’ve played guitar since I was little, and I’ve always loved music (who doesn’t?) If someone was new to learning guitar, and they loved playing but couldn’t play much due to their skill set, I would never say they weren’t a “true guitarist”. It’s not about being a “true guitarist”, it’s about making music. It’s the same with Agile teams, it’s about building valuable software, and continuing to improve.

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.

 

What are the best Agile development tools?

Agile development tools

The debate over the best Agile development tools rages on. Tools like JIRA, VersionOne, and Trello all offer different benefits. Some people love the lightweight team focused flexibility of JIRA, while others prefer VersionOne for its program management capabilities.

Long before the popularity of Agile, organizations struggled to find the right software delivery tools. Teams need tools for things like version control, defect management, test cases, reports and requirements/user stories.

It’s not uncommon to find companies using different tools to manage the different aspects of software delivery. For example, they might use Rational ClearQuest to manage defects while using HP ALM to manage test cases. Or they may use SharePoint to maintain documents while using JIRA to manage User Stories and Sprints.

Here’s the thing. There is no right or wrong combination of tools that works for your team or organization. Some teams prefer not to use any tools, and that’s okay. The real goal of self-organized teams is to produce good flow. Good flow means producing quality software that provides value to the business. It should be up to the teams to decide which tools, or lack of tools, works best for them.

 

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.

 

Adapting to change, the Agile organization

Organizations today must be Agile to deal with the rapid pace of change due to globalization and technology. In software development, we have seen how well cross functional Agile teams can deliver value.

Companies that adopt this same level of agility across their enterprise will be well served. I’m not talking about scaled Agile or some framework. I’m talking about organizations that can change and adapt. They are like clay instead of rocks. Agility provides a level of flexibility and adaptability that gives them a competitive advantage.

Below is a short talk from John Kotter in which he discusses the differences between the network and the hierarchy, and how they can coexist. In my view, organizational structures of the future will look less like hierarchies, and more like solar systems (networks).

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.

 

Self-organizing teams produce the best architectures, requirements, and designs

Self-organizing teams produce the best architectures, requirements, and designs.

self-organized team

The above statement is one of the principles behind the Agile Manifesto. Too many “Agile” teams struggle to get this concept.  They have the Agile ceremonies down, and they may even sit together, but they still work in silos based on waterfall principles.

The following statements are all signs that a team is struggling to adopt the Agile self-organizing team behavior:

  • “I can’t work on the design because the requirements aren’t complete yet.”
  • “I can’t create any test scenarios yet because the design is not complete.”
  • “I can’t start development, I have to complete a design document first. “

In Waterfall, the requirements and design process looks like this:

In Agile, it looks more like this:

It’s a cluster of work that happens together. The process gets messy and entangled, in a good way. There are no long drawn out separate phases of development or QA. All the work is happening together, and cross functional team members collaborate through the whole process.

When the team is self organized, that’s when great ideas and valuable products emerge. Why wait for a long period of time for requirements to be completed by a BA, only to be reviewed by the team at a later date? Or wait for a design or dev to be completed, only to be reviewed later?

As Deming used to say, you don’t inspect quality into a product, quality is built-in up front.  Why not use that same principle for how we treat requirements/stories, designs and tests? Instead of inspect quality into them, let’s build the quality in up front by having all team members contribute to the work.

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.

5 reasons project managers make lousy scrum masters

Lousy Scrum Masters

As the Agile movement continues to grow, the demand for scrum masters has increased. Traditional project managers have caught on and they’re disguising themselves as scrum masters. With a small fudge of the resume, they’re hired as scrum masters. What’s the problem? Project managers make lousy scrum masters.

Now, don’t freak out and get offended. When I first began working as a srum master, coming from an IT project management and QA background, I was lousy. I had a steep learning curve. It’s only after time and working with good Agile coaches that I’ve been able to improve as a scrum master.

The reason we project managers make lousy scrum masters is simple. The two roles are completely different. The original founders of scrum have made it clear that a scrum master is not a project manager. For a description of the scrum master role, check out the Scrum Guide from Scrum Alliance.

Yet, companies continue to hire project managers as scrum masters. Part of the problem is that most business executives don’t understand Agile. I still hear the question from management, “hey can you do that project using Agile”? As if Agile is something you can decide to use like choosing which fuel to pick at the gas station. Agile is a different way of working and thinking. Agile adoption requires commitment and understanding from teams and leadership.

Okay, I’ll get off my soap box. Without further ado, here’s my list of 5 reasons why project managers make lousy scrum masters:

  1. The concept of self-organizing teams doesn’t register with project managers. This may be the most challenging aspect in Scrum for project managers. Project managers are hardwired to tell teams what to do and when to do it. They then expect a full status back in return. In Scrum, the team decides what to work on with guidance from the product owner. The team is then accountable to each other, not to the scrum master. During the daily Scrum, team members should be giving their updates to the team, not to the scrum master. Keeping quiet and letting the team be accountable makes project managers feel like fish out of water.
  1. Project Managers aren’t used to coaching. On traditional projects the project manager is a leader and decision maker. In Scrum, one of the primary roles of the scrum master is to coach the team. They coach in self-organization and cross-functionality. To be able to coach though, one first needs to learn. If the project manager hasn’t learned Scrum, how could they coach the team?
  1. Project Managers struggle to give up being the top dog. On traditional projects, the project manager is the top dog. The buck stops with them. As a project manager, it feels good to have authority and control. In Scrum, you have to let that go. The scrum master does not have authority. The team does not report to the scrum master. The one who has authority on the Scrum team is the product owner. This fact requires project manager to have humility when transitioning to Scrum.
  1. Project managers freak out without a plan. The Project Management Institute teaches project managers to create plans, for everything. If you have your PMP, you know that they expect you to create a giant plan (document) consisting of like 10 sub plans. This plan, the size of the PMBOK, does not change unless there’s some official change request. While Agile still involves planning, this is completely different from Scrum.
  1. Most project managers don’t understand servant leadership. Scrum masters are servant leaders. This means they’re willing to jump in and do whatever it takes to remove impediments and help the team. That might mean helping to dive in and handle low level administrative work. Scrum masters put their ego aside and serve the team. Instead of puffing out their chest and telling everyone what to do, the Scrum Master asks how they can be of service. Most project managers are not used to this style of leadership when they begin in Scrum.

Here’s the good news, it is possible for project managers to become good scrum masters. It takes time and training. It’s like learning to play both guitar and drums well. Yes both instruments create music, but they need different training and skill sets.

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 3 of 5

Powered by WordPress & Theme by Anders Norén