Category: Project Management Page 2 of 4

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.

 

 

 

 

 

Every IT project is a unique composition

IT Project

A musical composition tells a story. Take for example, Mozart’s Requiem: Lacrimosa. As the music begins, the sounds of the soft strings and chorus provide a sense of mystery. The sounds fill you with wonder as you chart off into the unknown. The story has begun.

As the sounds and tempo begin to intensify, you go on an emotional ride consisting of high peaks and low valleys. The music eventually softens and the piece concludes. The story comes to an end.

In the same way, each IT project delivered is a unique composition that tells a story. Like Mozart’s Requiem: Lacrimosa, projects often begin with a sense of wonder. As you discover the project scope, it’s like the beginning of roller coaster ride. You slowly climb high into the sky. Filled with excitement and nervousness, you look around and realize you are in for a wild ride.

Suddenly, whoosh! You hit max speed into your first steep drop. The orchestra is playing at a pulsating high volume. The story has changed. No longer are you in the beginning of a discovery phase accompanied by soft strings and chorus, you are now surrounded by danger and chaos. Hold on because it’s going to be a wild ride.

Delivering the scope of your IT project will be as intense as Beethoven’s 5th symphony. Up until this point you only had a plan, but now you are in execution, where things get real.

Coming at you all at once are change requests, deadlines, defects and personality conflicts. These are just a few of the components that make up the challenges of the project story. On the flip side, team work, achievements, and feelings of accomplishment provide the high points.

The cast of the story usually includes a range of characters. Business executives, managers, team members and stakeholders all have a role to play. The main protagonists of the story are the project team members. For the story to come together like a great musical composition, everyone on the team needs to be in sync.

The leader of the team needs to be passionate, like an orchestra conductor. An orchestra conductor can hear the music so clearly that he or she can direct changes simply by waving their baton.

The project leader must do the same to keep the team on track. They need to direct the story and guide it to completion. If anyone is out of tune or out of sync, the project lead must correct it immediately.

In the end, all IT projects will complete. Whether they are successful or not, the music will fade away and the project team will move on. The story will come to an end.

The team then moves onto another project, where a new story will begin.

 

For more content like this, subscribe to the MacIsaac Consulting Blog.

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.

Going from Software QA to IT Project Management

Software QA

My journey in the world of IT began as a quality assurance analyst. For UPS, I would test and certify applications used in operations. I spent most of my time in the test lab with the rest of the lab rats. Testing software back then was the easy part, the hard part was building the right platform. Performing a ground up install of MS Windows Pro could take almost half a day and if it failed, you’d have to start over again. If you were lucky you got to use a ghost OS image, but even those presented their own challenges.
 
Later in my career I would go on to focus less on hardware and more on testing software. With Accenture I worked along side large testing teams on huge multi year waterfall software projects. We would create test plans consisting of hundreds of test scenarios. We then charged off to complete all the testing in a matter of weeks. Anyone who worked in QA (or dev) can attest to the agony of the waterfall project death march experience. Pressure from management, late nights in war rooms, and working weekends combined to make the QA role a nightmare.
 
Fast forward to the arrival of Agile and my role in QA became tolerable again. Instead of having a mountain of code dumped on me for testing, now I could test small chunks of software in two week sprints. The only problem was (and still is) that many organizations struggle building shippable software in sprints. This results in companies that are waterfall masked as Agile.
 
After almost a decade working in QA I decided I to get into project management. I always enjoyed connecting with people and I felt project management better fit my strengths. Through the guidance of mentors, lots of studying and hard work, I was able to become an associate project manager. After time I was able to work on larger projects, consulting for large companies.
 
Making the transition into project management was a great career choice for me. Project management much better aligns with who I am. For you it may be different. Your passion might be in QA and there’s nothing wrong with that.
 
If you are someone who works in QA and you’re considering get into project management, my advice is to go for it. Software QA analysts make great project managers because they are battle tested. I discussed this more in my last post “The identity crisis of the IT project manager“.
One thing’s for sure, if you’re not happy in your current role, don’t settle!

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 identity crisis of the IT project manager

The IT project manager role is one of the most in demand and sought after positions in technology. Ask any hiring manager and they will tell you that finding a good IT project manager is difficult. I’ve seen people with the most impressive credentials crash and burn trying to manage IT projects.

So what exactly is an IT project manager, and what makes a good one? The IT project manager used to be the person accountable for managing scope, schedule, and budget for IT projects. Today, that’s still true, for the most part, but the role has a bit of an identity crisis

The Project Management Institute, with their PMP certification, says the role is all about planning and control. If you’ve taken the PMP exam, you know PMI teaches you to create a large project plan. Within that plan are many sub plans for each area of the project.

The PMI has come under scrutiny in recent years by the technology community, and for good reason. With the rapid advancement of technology and globalization, organizations need to be agile. Planning is important, but responding to change may be even more important. Our systems and organizations have become too complex for the PMI plan and control model. This need to adapt to change is what has fueled the Agile software development movement.

With the increase of self-organizing agile teams, it brings us back to the question, what is the role of the IT project manager? Is it an Agile project manager? Is it a project leader? Is it a servant leader? Is it a Scrum Master? Is it a tech lead?

The answer depends, but the role may consist of a combination of all these things. One thing we know for sure is that the IT project manager is a change agent and a leader.

To succeed in this role, one needs to have both hard and soft skills. Good IT project managers use both the left and right hemispheres of their brain. The right side of the brain used for cognitive thinking, the left side for emotional intelligence and relationships. This enables them to be both technical, and emotionally intelligent. Project management is both a science and an art form.

If you are looking to get into IT Project management, you better be able to deal with chaos while keeping your cool. If you currently work as an IT business analyst, tester, or developer, you are well prepped for IT project management. I began my career in QA, and my experience in testing has been invaluable to my role as an IT project manager.

The reason people in these roles make good IT project managers is because they are battle tested. They know what it’s like to be in the trenches of IT projects, and to come out on the other side.

Let’s face it, delivering IT projects is tough. Business executives often don’t realize how tough it is. They are like patrons in a restaurant ordering a four-course meal. As they sit in the dining hall waiting for their meal, agitated by any delay, they don’t see the chaos in the kitchen.

It’s the job of the IT project manager to manage the chaos while portraying calmness and confidence to the team and business. Managing the chaos and leading the project to completion is what makes the IT project manager so valuable.

For me, I enjoy the chaos that comes with delivering IT projects. I particularly like the areas of development and testing. If you love technology, working with others, and solving complex problems, the IT project manager role may be a great fit.

So although the identity of the IT project manager is hard to define, it’s an exciting time for the field. With the rapid advancement in technology and globalization, the demand for good IT project managers will continue to go up.

We have only begun to scratch the surface of the digital world. AI, IoT, and big data technologies are in their infancy. As we chart a course into unknown territories of the digital world, we need good IT project managers to lead the way!

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.

Is your project worth the investment?

return on investment

Return on investment, or ROI, is a term you often here in the corporate world. ROI is not an actual financial metric, like ROA (Return on Assets). When you are talking about ROI, you want to know how much you will get back if you invest in something.

If an athlete invests a lot of time in the gym he will most likely perform better in his sport, which is the return. It’s the same with business. Companies invest in a new product, piece of equipment or project only if they expect a good ROI.

They spend cash they have now in hopes of realizing a return at some future date.

Sometimes managers have to fight with competing projects to receive funding for their project. If they can forecast a good ROI it will help them get the funding.

To determine ROI, you need to understand the time value of money. Over time the value of a dollar one year from now will be less than it is today. Three concepts used in analyzing investments are future value, present value, and required rate of return.

Future Value

Future value is what a given amount of cash will be worth in the future if it is loaned out or invested. Being able to predict the future value, especially for security investors, is crucial.  It can tell you whether your investment is a good one. If a stock is selling for $200.00 and is estimated to increase 20% over the next year, the future value of the stock in one year would be $240.00

Present Value

Present value is the opposite of future value. If the future value is worth $240.00 in 1 year with a 20% interest rate or increase, then the current value is $200.00

Required Rate of Return

If an investments value expects to increase 20% in three years, the increase percentage is rate of return. Before making an investment decision, investors will have determined a required rate of return. Say if a rate of return is only 3% over the next three years the decision might be to not make the investment.

Calculating ROI

The fancy term investors use when putting a value on a company is DCF (discounted cash flow analysis). For now, let’s look at the three popular methods for calculating ROI. These can be used to forecast a projects ROI. They are the Payback Method, Net Present Value method, and the Internal Rate of return method. The payback method is a simple calculation to determine how long it will take to get back the original investment. The Net Present Value method is more complicated but also more powerful because if factors in the time value of money. Net Present Value is the present value minus the initial cash outlay. The Internal Rate of Return (IRR) method is like except it calculates the actual return provided by projected cash flows.

For more content like this, subscribe to the MacIsaac Consulting Blog.

Follow Mike on Twitter @MikeMacIsaac

To contact us about our services, click here.

Why Cash is King

Cash Flow

If you work in technology like me, you may not think there’s a need to focus much on finance. It is important though to understand the numbers, especially in project management.  In my next several blog posts I’m going to focus on financial management. To begin, let’s start with the green hard stuff, cash.

When it comes to cash and business, there are three things to know. The first is that cash is not the same as profit. The second is that most companies fail due to a shortage of cash flow. The third is that the cash statement provides valuable insight into a company’s situation. That last point is particularly important if you are planning to buy stock in a company. Warren Buffet might be the world’s greatest investor because he understands cash.

Cash is not the same as profit

Profit is the amount of revenue generated minus all expenses, what you have left is profit. So what is the difference between cash and profit? First cash doesn’t reflect money coming in through earned operating income. The cash may be coming in through loans or investors and that money doesn’t show up on an income statement.

Money from recorded profits isn’t received until some time after the transaction takes place. In an all cash transactions the funds will placed directly into the sellers account.  Small companies that are growing and creating profit, but not receiving the cash needed to keep up with expenses, run into trouble. This leads to the next topic which is that most companies fail due to a shortage of cash flow.

Most companies fail due to a shortage of cash flow

Profitable companies can go out of business if they don’t have enough cash. What happens is that they are continually waiting to receive cash to keep up with their expenses. An example would be as follows: Company A is a startup which over its first several months of business has recorded good revenue gains and large profits. The transactions for the products the company sells take 4-6 weeks for the funds to arrive. Due to the delay in receiving payments, the company does not have enough cash in the bank to cover the costs of operating expenses and growth. This ends up being a continual game of catch up with the actual cash behind the recorded profit. For most companies and startups it won’t be sustainable.

By reviewing a cash statement you can gain valuable insight into a company’s situation and where it might be headed

Income statements are complex and can be deceptive. The numbers can be manipulated by accountants to appear as though company is in better shape than it actually is. Most of the expenses on the statement haven’t been paid during the time of the statement.

Cash statements give an accurate view of how much cash was received and paid within a certain period. The cash flow statement can not be altered by the accountants like the income statement can be. Due to this, the cash statement gives great insights to investors because it paints a clear picture of how the company is doing.

In a sense the cash flow statement is a way of looking into a company’s bank account. The cash flow statement can provide valuable insight into a company’s future. If investment money is coming in, that may be an optimistic sign for the future. It could also mean that the company is selling stock to stay afloat. Looking at the cash flow statement may generate questions, but they are the right ones to be asking.

For more content like this, subscribe to the MacIsaac Consulting Blog.

Follow Mike on Twitter @MikeMacIsaac

To contact us about our services, click here.

Ready, Fire, Aim! Why we need to slow down when tackling complex issues

Leading technology projects

Leading technology projects, I’m often reminded that we need to slow down when tackling complex issues.

When faced with a problem, the tendency for most of us is to immediately act and do what our gut tells us. I call this the ready, fire, aim syndrome. Have you ever worked for a manager who had the team charge down a course of action only to realize after the fact it was a giant mistake? It’s not a good feeling and if you work in business and technology, I’m sure you’ve been there.

Here’s the key, although our instincts may be in the right place, it makes sense to slow down. When we slow down we can then think things through and look at the problem from different angles. Then, we can apply the action that will bring about the best solution.

Slowing down also enables us to get feedback from others. Sometimes there’s nothing more helpful than bringing in a fresh set of eyes for a different perspective and possible solution.

So the next time you’re ready to charge off into the battle, maybe take a step back and pause. Have you thought things through and engaged the right people? Is there even a need to act right away? Amazing things can happen when we sit still for a moment.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

System integration testing, a 6 step survival guide

system integration testing

So you’ve gotten through your planning, design, development and application testing. Everything looks good, the team feels confident, and the project is on track. There’s only one problem. Up until this point you’ve been looking at your code changes with tunnel vision. Application testing is like fixing a bike tire while it’s not connected to the bike. The real testing begins when the wheel gets reconnected to the bike. Once reconnected, then you’ll see the how the fixed tire works with all other parts of the bike.

I’ve been through many large software projects, both as a project manager and as a tester. Often the most difficult part of completing a software project is end to end system integration testing. This is particularly true if you’re not using an Agile model.

System integration testing is where the rubber meets the road. If you work for companies like Facebook, Spotify, or Twitter you are lucky. These companies use modern Agile software delivery methods that make integration testing less painful. Automation, DevOps, and continuous delivery is the way of the future.

Unfortunately most companies still build software the old fashion way. They create one huge pile of software then throw it over the fence to QA nearing project end. This leaves integration testing only a matter of weeks to complete and meet a tight deadline.

If you don’t do a great job planning for integration testing, you’ll be in for real trouble. If you do a great job planning, you’ll still most likely be in for some pain.

Here are 6 steps to help you survive system integration testing so you can be successful.

  1. Plan enough contingency time – This might be the most important point. Give the team enough time to do the test effort. If you know it takes 1-2 weeks just to get your environment and data working right, plan for that time. In system integration testing, many roadblocks occur. Data, configuration and environment issues can  block testing. Plan for the unexpected.
  2. Create test scenarios with the help of system experts – Once you know all the affected systems, find out who the technical experts are for each system. Then schedule white board meetings to draw out end to end flow test scenarios. The system experts will be invaluable helping you to write end to end scenarios.
  3. Get all your data setup in advance – There’s nothing more frustrating than finding out none of your data works on day 1 of testing. Setup your data in advance and check to see its setup right before you do your testing.
  4. Run connectivity tests – For large projects, take at least 1 week to test environment connections before the start of your SIT. Often companies use shared testing environments and configurations are always being changed. Make sure all your configurations and connections are setup. If you don’t do this, you’ll think you’re running into defects only to discover an application is pointing to the wrong environment.
  5. Use a war room – All throughout system integration testing you should have a room where all key resources sit together, all day. The key players usually consist of developers, testers, a PM, and system and environment experts. As soon as a test runs into an issue, a developer should be there to look into it immediately.
  6. Have a test lead manage the effort – Last but not least is having a good test lead. In my opinion, test leads have one of the most difficult jobs when it comes to managing integration testing. The job requires both testing expertise, project management skills, and tremendous grit. Often test leads have a lot of pressure put on them to meet deadlines. A good test lead will rise to the challenge.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Leadership and tremendous discipline. What’s your 20 mile march?

project leadership

In Jim Collins book, Great By Choice, he sought out to answer the question, why do some companies thrive in uncertainty and chaos while others do not? He and his team performed extensive research to answer this question and they were able to draw some surprising conclusions. They referred to companies that thrived as 10X companies. These companies performed ten times greater than similar companies in their industry.

One of the factors of the 10X companies was that they were fanatically disciplined. They stuck to their strategy that aligned with their mission. While other companies in their industries made risky changes to adjust to the conditions, the 10X companies did not.

A great example of fanatical discipline is the 20 mile march. Collins tells the story of two teams that made a journey in 1911 to the South Pole, one led by Ronald Amundsen, the other by Robert Scott. In this story, Amundsen’s team was successful while Scott’s team failed (all perished).

One of the key differences between the teams was that Amundsen’s team stuck to a 20 mile marching regiment each day. Even through the most brutal weather conditions, they continued to march. They were fanatically disciplined!

The concept of 20 mile march resonates with me as a technical project leader. Whether I’m working on a traditional or Agile project, I’ve seen how important it is to stay disciplined. For Agile projects this means continuing to always have your ceremonies, maintain velocity and hold each other accountable.  In a more waterfall style project, it means continuing to drive towards your milestones and stick to the plan.

So what’s your 20 mile march? Are you providing the leadership to help your teams stay disciplined?

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

 

Start your projects right by focusing on relationships and momentum

As a project manager, it’s important that you start off your new projects the right way. Sometimes you may get a brand new project , other times you may need to take over a project that’s already in flight or has stalled. Either way, there a few recommendations I have to get the ball rolling.

First, focus on relationships and getting the inside scoop. Find out who the key resources and stakeholders are, then talk to them. Talk to them in a comfortable atmosphere so they can relax and give you their honest insight. This is where you will find out what type of project you are dealing with. You’ll discover the good, bad and the ugly. You won’t get this information in formal project meetings. You will also get to know your stakeholders and build trust, which is critical.

Next, focus on building momentum. You start to build momentum when you take action and create a sense of urgency. Set up your project meetings, schedule a kickoff and communicate status to all stakeholders. The key here is communication. Communicate often, the more the better! Update your stakeholders via email, in person updates, and status files. Under communication is a common mistake project managers make. If you bump into a stakeholder in the hall, they should know exactly the state of the project. They should feel the momentum.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Page 2 of 4

Powered by WordPress & Theme by Anders Norén