Core Project Management Functions must Continue after Transition to Scrum

Who on your Scrum Team should Perform these Core Project Management Functions?

You’ve convinced your bosses to let you introduce Agile Scrum into your company and you’ve picked your pilot project. You gathered your team, trained them, you’ve enlisted an enthusiastic Product Owner, and now you are ready to rock.

As you get a couple of Sprints under your belt, you begin to realize some Project Management functions that were performed by a PM in the waterfall world may still be needed. What are they and who performs them now that you’re Agile?

  • Financial Reporting: How much will this feature set cost?
  • Risk Management: Who tracks risks and issues?
  • Documentation: Do we still need documentation and if so, who writes it?

Here at GSD Mindset, we have some practical ideas on how to approach this.

Financial Reporting

There are very few organizations that give you a pile of money and tell you to go have fun. Today, most companies want an accounting of how funds have been allocated. In the waterfall world, Project Managers report out the status of the monthly budget, using techniques like Earned Value to calculate where you are in relation to money spent.

Now that you’re Agile, good Project Management dictates that you still need to keep a financial accounting. In fact, many companies require careful accounting as a legal requirement. It’s not so hard to track and forecast expenses when you transition to Scrum.

After a few Sprints, you use Velocity to determine how many Story Points you can complete in a Sprint. If you know your monthly team budget, you can also calculate the average cost per Story Point. Multiply that cost to the estimated Story Points for the remaining Stories in your backlog for each Feature or Epic and now you have a rough idea of the amount of funding required to complete the remainder of the project.

Keeping on top of the financials will go a long way toward keeping management happy.

Who should track financials? Since calculating cost is similar to calculating Velocity, we believe this is a task best performed by the Scrum Master.

Risk Management

With Scrum, you should have less risk, because you deliver more frequently to customers, but that does not mean you can quit tracking and analyzing risk when you transition to Scrum. There are many ways to identify and track risks now that you are Agile. I find MindTools article on Risk Analysis and Risk Management helpful. 

Risk analysis and assessment should be a team effort. The Scrum Master should lead the discussion during Sprint Planning and conduct a quick checkup at Standup half-way through the Sprint.

Check out our blog post Reduce Risk on a Scrum Team for more ideas.

Documentation

Most software folks are loathe to create documentation. This goes for writing User Guides and Specs all the way down to including Comments in lines of code. Documentation is an important tool to help future users understand what it’s all about. Documentation is a necessary Evil for those of us who remain in a world where our projects are audited. Even in Scrum, we follow a process and our implementation of that process may be audited.

The level of documentation should be decided at the beginning of the project. There are many tools to help you decide and document the minimal amount of documentation your project should require. Many companies today have Project Management Offices (PMOs), and they provide either written guidance or a tool for capturing this list. The final list of necessary documentation should be a part of your Definition of Done.

Once you’ve determined what needs to be written, you need to figure out who’s going to write it. Writing documentation is the responsibility of the entire team. The task to write or update documents should be included as part of the the Story. Because Stories are small changes to functionality, the level of documentation for each Story will be small compared to the size of documents completed at the end of large waterfall projects.

Hopefully, these ideas will help you figure out how best to tackle other traditional project management tasks that may be missing from your Scrum Team practices. Remember, it’s all about teamwork, team empowerment, and team accountability, so figure this out together as a team.

For more advice on how to transition more traditional project management roles, I recommend our blog post Agile Teams Still Need Traditional Support.

 

 

Gerri Slama Grove

Gerri Slama Grove

 

Gerri Slama Grove
GerriG@gsd.guru

read more

Don’t Hate Me Because I’m Agile

Why Do Traditional Project Managers Hate Agile?

I recently hired into a project management group of mostly traditional lifecycle project managers. The group has a directive to transition the team to become agile. That’s why I’m here.

I’m also here to apply agile to the Phase III of a problem project, where Phase I and Phase II were mismanaged and the application is unstable. So much for traditional project management methods.

In the first month since I started: I setup JIRA, formally kicked off the project with the Steering Committee (we can still be agile in a waterfall world), provided 2 half day workshops for my business product owner and business team members, planned feature deliverables for six Epics over the next three quarters, planned and executed my first sprint. We are not in “Exploring,” we are in “Doing.”

I attend all the project manager team meetings. I participate in discussion. I even offered to train or coach any project manager interested in becoming more agile.

Last week, my boss tells me that another project manager needs help with an agile project, and he asked me if I’d be open to coaching him. Of course! Next day, my boss sends out an email giving him the green light to reach out. Nothing. A few days later, my boss asks me if that project manager contacted me, and I had to admit that I had not heard from him.

This morning, I’m sitting at my desk and another project manager comes up to me and says, “Yesterday, I was sitting at my desk and I was surprised to hear you talk dirty.” I smiled and asked him to explain. His reply saddened me and inspired me to write this post: “You know, I heard words like agile and scrum in your conversation.”

Whaaaaat?!

I get it. Everyone’s a little scared of change. People ignore or belittle things they don’t understand.

I get it. Agile is not only a new method of application development, it’s a new way of thinking.

But, as technical professionals, we must learn new things all the time to remain relevant in our jobs.

What makes learning and adopting agile different from everything else?

I don’t have one best answer, but my observations lead me to believe that if you really want your team to become more agile:

  • The desire to change must come from upper management and it must be embraced throughout the organization.
  • Everyone must be trained. Get good training, even coaching. It’s worth the money.
  • Rip off the bandaid and do it right. If you want to practice scrum, practice scrum. Every aspect. Don’t hybrid a method unless you’ve mastered it.
  • Start small, with teams that want to transition first. Find the early adopters. Use them as poster children for how amazing agile can be.
  • Integrate change management principles into the transition. I attended a webinar on this topic the other day, and it opened my eyes to new ideas about how to implement agile (topic for another blog post).

I can hear you thinking: That’s all fine and good, Cynthia, but what am I supposed to do? I’m just an individual contributor, the Scrum Master / Product Owner / Member of the Development Team.

I say: Walk your talk. Seek to understand. Lead by example.

  • Meet individually with those who resist and ask them how they feel about agile. Elicit honest feedback. Listen. Don’t judge or try to change their minds at this meeting. Afterwards, use that valuable feedback to figure out how to address concerns.
  • Ask those who are struggling if they’d like to observe you work with your scrum team.
  • Offer to coach those who have trouble shifting their mindset, writing stories, grooming stories and sprinting.
  • Help your team meet their sprint commitments, even if it means working outside your job description.
  • Deliver quality product to the customer more quickly than before, even if it means helping with testing.

Agile is a journey.

Retrospective ensures continuous improvement.
We can always make it better if we work together as a team.

Is that so different from anything else we do?

Don’t let negative experiences like the ones I describe sidetrack you.

Smile big and be the change you want to see in others.

I wrote this post to spark a discussion.
What are some techniques you employ to reduce resistance to adopting agile?

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Agile Teams Still Need Traditional Support

Scrum is an Agile Development Method Not a Product Management Framework

When I talk about agile for business, I’m talking about the need for businesses to apply agile concepts, so they can better meet the needs of an ever-changing worldwide landscape. As you know, I dedicated an entire post to how Business Must Become Agile or Be Left Behind.

When I talk about an agile team, I’m talking about how development teams apply scrum in product or software development departments within a business. The biggest misconception about scrum is that when you convert to scrum, you no longer need traditional program or product management.

The role of program manager, product manager, project manager and scrum master are all very different. All four roles are important, but you don’t necessarily need four people to fulfill them. How many people you need to manage the development organization depends on the size of your business, the number of projects and/or products, and the skill set of the resources assigned.

The Need for Program and Product Management are still Required

That’s right folks:

  • Someone still needs to develop and manage the product and/or program roadmap
  • Someone still needs to decide what new products, product enhancements and/or projects the development team works on
  • Someone still needs to decide what milestones to track
  • Someone still needs to organize the workload and ensure the team delivers to committed milestones
  • Someone still needs to report status against milestones to upper management

This sounds a lot like traditional product and program management, you say? Well, that’s because scrum is a development methodology, not a program or product management methodology.

Don’t Mess with the Development Team

The practice of scrum and applying the agile mindset to software development is radically different from traditional software development. As part of transition planning, decide how the development team will work with and report to the rest of the organization. Then, once the team commits to scrum, rip off that bandaid and allow the team to truly become agile.

Program and Product Managers Guide the Development Team

Think of program and product managers as wrappers around scrum development teams. These managers guide the team’s high-level priorities and ensure they deliver according to the business roadmap.

I suggest splitting the project manager role between the program manager and the scrum master.  Program and product managers set the roadmap and report to upper management or the PMO. Scrum masters work with the development team to determine if delivering to the roadmap is possible, work with the Product Owner to ensure the right stories are brought into each sprint and work with the program manager to reports status against roadmap milestones. Most importantly, the scrum master helps the team remain agile and efficiently practice scrum.

Release Management Must Deliver More Often to the Customer

Scrum ensures a quality working product is demoed at the end of every sprint. Whether or not the updated product moves to production or releases to the customer is another process that is outside the boundaries of scrum. Remember that even if your team practices continuous integration with automated tests during sprint development, it does not mean regression testing, automated manual testing and user acceptance testing can be bypassed as part of the release cycle.

Because an updated product is available at the end of the sprint, we hope that management makes the commitment to release more often. Don’t wait. Big band delivery is the old way of thinking. Successful businesses consistently provide value to the customer, those folks that buy your products and provide the income that goes toward your paycheck.

Want to better understand how to successfully practice scrum in the real world?
Then you should read our GSD Scrum Handbook.

Want personalized instruction?
Then come to our next GSD Scrum Training or call us for a consultation.

 

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Overcome Resistance to Agile in Your Organization

A Simple Approach to Overcome Resistance to Agile

The biggest obstacle to successfully transition to agile is resistance to change. People resist change for many reasons, including fear of the unknown and job insecurity. If you are a proponent of agile development, then you need to overcome fear and uncertainty in order to get buy in.

If the desire to become agile begins at the highest levels of the organization, it’s the software development team that must become agile, so that team holds the key. If the desire to become agile begins with development team, management must agree to this new approach. Top to bottom, all levels of the organization must embrace the agile mindset.

How can you overcome fear and uncertainty? Make it easy for everyone to get on board.

  1. Explain how agile fits into the existing structure
  2. Start with 1 team
  3. Educate everyone involved
  4. Commit to working out the kinks
  5. Prove that agile works better

Before you suggest that even 1 team convert to agile, make you truly understand agile and the agile mindset. Get trained on agile scrum. Then test the water by asking your manager to pay for your training as part of your professional development. We recommend you read our post How to Get Your Boss to Pay for Scrum Training.  If your manager won’t pay for it, pay for it yourself. Show your commitment to the cause.

1. Explain How Agile Fits Into the Existing Structure

This seems like a no-brainer, but you’d be surprised to learn most companies that transition to agile do not even think about how agile fits into current business processes. If you want to alleviate fear and uncertainty, figure out:

  • How the new team’s roles and responsibilities map to existing roles and responsibilities.
  • How agile teams plan with and work with traditional teams.
  • How will status reporting occur? The agile teams must be able to report progress in much the same way traditional teams do.
  • How agile teams fit into the existing project management or product development structure.

Put together a proposal. Show that you are prepared and serious about taking action.

2. Start with 1 Team

Agile scrum is a software development method. Only the development team really needs to change. We suggest starting the transition with only one team. This lowers the risk to the organization, gives everyone a chance to get used to the idea, and also gives you a higher chance of success.

But, you must start with the right team. In addition to the Scrum Master, we believe you need a Product Owner, Business Analyst, Tech Lead or Architect, Developers and Quality Assurance.

You need a committed Product Owner, not an Executive Sponsor. Make sure that person is respected by the product team, understands the requirements and can prioritize the work. The Product Owner must be available to attend daily Standup, Story Writing and Grooming, Sprint Planning and Retrospective. That’s a much bigger commitment than that of Executive Sponsor, who periodically attends Steering Committee meetings.

The reason that you need a Business Analyst is because the Product Owner may not understand how to translate business requirements into stories and acceptance criteria. Business Analysts are well suited to team up with the new Product Owner and help out.

The transition to agile does not mean architectural design is no longer needed. Quite the opposite is true. Because the team is delivering functioning application code at a much faster rate, the role of Tech Lead or Architect is critical to team success. The team needs someone who understands the big picture, can build a development framework and ensure all the small pieces of functionality fit together at the end.

Choose the right developers. Yes, make sure you have all the skills to code all aspects of the application on the team. However, don’t pick developers who don’t want to switch. Just like with the Product Owner, pick developers excited to learn something new and who are willing to attend the required meetings: Story Grooming, Sprint Planning, Standup and Retrospective.  

Finally, scrum dictates that you cannot close a story until the acceptance criteria has been validated working as expected by Quality Assurance. Make sure that you have the right number and mix of testers.  

3. Educate Everyone Involved

Now that you have the right team, you need to train them. To minimize risk and to validate management commitment, get everyone on the team the proper training. The team must start with a good understanding of scrum and an agile mindset.

If you cannot get management to provide adequate training for your team, do not attempt the transition. Seriously, don’t even start. Agile scrum is way too different from traditional software development. You at least need enough management commitment to ensure everyone on the team starts with the tools needed to succeed.

To get even more buy in, ask management to attend the training. They more they know about scrum, the less uncertainty they feel about the transition.

If you can hire a coach, even better!

4. Commit to Working Out the Kinks

As they say, “Rome wasn’t built in a day.” The same is true for the transition to scrum. It’s a big change. Before you begin, get assurance from management that you have at least 6 months to get the team fully functioning.

Let’s be clear: We do NOT advocate a slow or partial transition.

What you need to do: Rip off that bandaid and practice every aspect of scrum from Day 1.

Because you are switching cold turkey, you need time to get in the groove. We know. Planning, building a backlog and sprinting are new processes. The team may be a bit awkward in the beginning.

Keep up all scrum practices. Don’t skip a step.

Use Retrospective to improve the way you work together.

5. Prove that Agile Works Better

There is no better way to prove that scrum is better than when the team delivers higher quality products to your customers in a much faster timeframe than before the transition. Agile provides you the opportunity to show off your excellent work at the end of every sprint. So, demo often to your customers. If the customer wants or needs a change, pivot.

Practice scrum, meet your team commitments and deliver high-quality products to your customer.

Walk your talk.

That’s how you prove agile works better.

GSD Scrum Training

Do you need some help with your agile transition?
Then come to our next GSD Scrum Training or call us for a consultation.

 

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Transition from Project Manager to Scrum Master

3 Steps to Become a Scrum Master

Agile and scrum are trending topics. Here you are, a successful project manager, and you want to learn more about scrum. You may even want to become a scrum master. The career transition from project manager to scrum master may seem simple, but it’s not as straightforward as you may think.

Scrum master has a very different role from that of project manager. The agile mindset is a paradigm shift from that of project manager too. To gain a better understanding of just how different, I recommend you read my earlier post: The Difference Between Scrum Master and Project Manager.

When readers contact me and ask me to advise them on how to best transition, I suggest the following:

  1. Learn about scrum from the Scrum Alliance
  2. Study and become a Certified Scrum Master (CSM)
  3. Get a job on an agile team

1. Learn about Scrum from the Scrum Alliance

Many of us organically became project managers through the course of our careers. We learned how to manage projects by working on projects and, eventually, we were promoted to leading projects ourselves. I personally never took a course on project management until the marketplace demanded that project managers have PMP certification.

However, scrum is a specific agile framework that is drastically different from the way you are used to managing traditional projects. If you want to be a scrum master, you need to read about it and study the concepts until they become an integral part of how you think about organizing projects.

The Scrum Alliance is a well-recognized authority on framework. Lucky for us, the Scrum Alliance has a wonderful website with lots of fabulous information.

Start here: https://www.scrumalliance.org/why-scrum

Reading about scrum is a great start, but I recommend you also learn about scrum from someone who already is a scrum master. If your company is transitioning to scrum, you may have the opportunity to learn from an agile coach. Take every advantage of that precious resource. If you are pursuing agile on your own, take a class. Ask for recommendations from friends and colleagues. Classroom learning combined with live exercises help reinforce the agile concepts you’ve been reading about.

2. Study and Become a Certified Scrum Master (CSM)

Just like with traditional project management where you need to become a certified PMP, if you want to be taken seriously, you need to become a CSM. Lucky for us, the CSM exam is straight-forward and much easier than the PMP exam. So, there is no reason not to get certified.

Start here: https://www.scrumalliance.org/certifications/practitioners/certified-scrummaster-csm

3. Get a Job on an Agile Team

If your company is not transitioning to agile, you will have to look outside your company for your first scrum master position. You may ask yourself: How can I get a job as a scrum master if I have no scrum master experience?

You may be able to land a scrum master gig based on your mad interview skills and CSM alone. Then again, you may not. If you are serious about becoming a scrum master, you may need to start as a different member of an agile team.

Depending on your background and what jobs you performed before you became a project manager, you may have a better chance at landing a Product Owner or Business Analyst or Tech Lead gig. Take a serious look at your career history and refactor several versions of your resume.

Take your agile friends and colleagues to coffee. Ask them what companies look for in agile applicants, before you apply anywhere. Then, apply for all agile positions you qualify for. The more you interview, the better you get at answering questions.

Land that first agile gig, whatever it is, and learn how it’s done in the real world.

Then, after that first project is finished, change teams or change jobs. Agile is practiced differently in different organizations, self-organizing teams and all. So, to be the best scrum master you can be, get a broader perspective.

Never stop learning.

Expand your mind.

Change your life.

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

 

Contact Us read more