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

Why Your Scrum Team Needs a Release Plan

Scrum Release Plan Sets Expectations with Management

When teams transition to Agile Scrum, they may decide the only required planning is Sprint Planning. These teams feel that because they are Agile, they don’t have to plan beyond the next Sprint boundary.

Most of us work in a corporate world, where upper management wants to know when the project is expected to finish and the estimated completion dates for major features and interim deliverables. Since these managers’ budgets pay our salaries, we need to find Agile ways to plan projects and deliver them using Scrum.

Teams that plan for Feature releases can still remain true to Scrum. Both the Scrum Alliance and Agile Alliance mention release planning, but they don’t provide a process to accomplish the task.

For this reason, several methodologies have sprung up to fill the gap and put a project management wrapper around Scrum. The biggest players are Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) and Large Scale Scrum (LeSS).

To be honest, when I look at those websites, I get dizzy trying to read their process diagrams. The processes don’t feel very Agile at all.

At GSD Mindset, we are big proponents for creating a Release Plan, but we advocate an approach that more closely aligns with Agile and Scrum.The top half of the GSD Scrum Funnel© illustrates our approach.

GSD Agile Scrum Funnel

GSD Scrum Funnel

Simplify the Release Plan Process

  • Divide the application into logical Feature Sets or Epics (in Scrum terms)
  • Break down each Epic into completed deliverable Components
  • Prioritize the Components
  • Organize the Components into a Quarterly Release Plan
  • Start writing Stories for 1st Sprint
  • Release Component functionality and pivot as customers use the product

Most people get the concept of identifying the high-level Features or Epics. From here, Scrum expects the Product Owner to start writing Stories about tiny slices of functionality required to build the Epic. Most new Product Owners find it difficult start with the concept of a completed Feature and immediately know what Stories to write. The intermediate step of breaking down an Epic into its Component deliverables fills the gap.

Prioritize Component Deliverables for Each Epic Before Writing Stories

Once every Epic has been broken down into Components, you can group those Components into Quarterly Releases. There are many prioritization techniques. My personal favorite is defining the Minimum Viable Product (MVP) or Minimum Marketable Feature set (MMF). Think as if you could lose funding if version 1 of the product does not meet customer needs by the end of the first quarter.

If you only have one quarter to prove the value of the product, then what must be delivered? This is a very real concern if you work at a startup or a company with budget constraints. Going through this exercise helps ensure your team delivers the highest value Components first.

Once you know the highest value Components, it’s much easier to write Stories and plan for the first Sprint.

Status Report Against Release Plan

Now, even without knowing your team’s Velocity, you can provide upper management with a Quarterly Release Plan or the list of Components your team plans to deliver each quarter. The team can status report against the plan. Once you know your Velocity, you can size the Components and begin reporting percent complete.

For more details on the GSD Mindset simplified approach to developing a Release Plan, check out:

I’d love to hear about your team’s approach to planning.
Do comment.

 

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

We are Agile. We are Not Perfect.

Every Team Practices Agile Differently

People take time off. I’m an Agile Scrum Master and Coach to a new team in their third sprint. Newbies. I fretted when I realized that I had a mandatory 2-day class scheduled on the same days as my upcoming Retrospective and Sprint Planning sessions.

At the first Retrospective, the team agreed that they really liked Scrum. At the second Retrospective, they felt like they were getting the hang of it. So, I asked the team if they wanted to run Retrospective on their own, because I knew they would not want to give up two days of their Sprint.

After a short discussion, the team decided to handle it themselves. Canceling Retrospective and holding Sprint Planning on Day 1 of the next Sprint was not even discussed as an option.

I got a little teary-eyed when I realized that sometime in the last 6 weeks my team became self-managing.

For the third Retrospective, they truly own it!

Do I think the team will conduct Retrospective and Sprint Planning with the same rigor as when I run it? Not really, but I am excited to see the result anyway.

Teams Learn by Doing

As you know, shifting from more traditional methods to Scrum and adopting an Agile Mindset takes practice. Scrum is a different routine and requires a higher level of commitment than many teams are used to. The change in habits and thought processes comes from experiencing what it’s like to Sprint, accepting mistakes as inevitable and reinforcing through example.

In the beginning:

  • My team didn’t even know what Stories to write.
  • The team’s first Stories were not really Stories and they required extensive grooming. (They still require grooming.)
  • A couple team members’ Standup attendance was spotty, until they began to see the results of daily focus on getting work done.
  • Not all Stories closed, because the process was new and the team needed to understand about relative sizing, Story Points and Velocity through their involvement in actual Sprints.

Experience provides context. Reinforcement creates good habits.  

Every Team Practices Scrum in their Own Way

As Scrum Masters and Coaches, we not only need to understand Scrum and how to effectively communicate its principles, we need to recognize the team needs the freedom to practice Scrum in the way that produces the best results.

Scrum prescribes 4 formal events for inspection and adaptation:

  1. Sprint Planning
  2. Daily Scrum (Standup)
  3. Sprint Review (Demos)
  4. Sprint Retrospective

As a professional with experience on multiple Scrum teams, I have seen teams within the same company practice Scrum differently. This happens even if all the teams receive training and coaching from the same Coach. Even timing of events can vary.

It’s a good thing for the team to take ownership of the way they practice Scrum. Ownership enforces accountability.

It’s OK if it’s not perfect.
How do you know if good is good enough?

Ask these 2 important questions:

  1. Is the team able to predict and meet it’s time-boxed Sprint commitments?
  2. If team size remains constant, is Velocity averaging out?

These two factors are crucial to delivering projects on time.

If you answered “Yes” or “Most of the time” to both questions, your team is doing well.
If you answered “No” to both questions, brainstorm improvements at Retrospective.

It’s not about perfection.
It’s about Getting Stuff Done (GSD).

What are your experiences?

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

 

read more

Dealing with the Office Saboteur

How to Deal with the Office Saboteur

I have never understood why some co-workers feel compelled to gain the upper-hand by acting like a saboteur. Is it insecurity? Possibly jealousy? Or maybe they’ve been facing challenges at home and need to take it out on someone at work.

I’m not talking about The Arrogant Bore who tries to take over your meeting or The Know-It-All who is all too happy to tell you what to do because they of course know best. I’m talking about the person who creates real havoc in your work life. I’ve come across many types of saboteurs, and I’ve grouped them into the following titles:

  • The Sniper
  • The Passive-Aggressive Disrupter
  • The Smiling Assassin

Before I talk about our 3 featured villains, I want to stress 2 very important concepts:

  1. Most people do not come to work each day with a mission to sabotage your project. So, before you act, make sure that you’re reading the situation correctly.
  2. Most important, do not take things personally. I repeat, do not take things personally. Bad behavior at work is the result of many different factors.

Always address the behavior in a professional and objective manner, citing facts to back up your observations.

Now, on to our bad guys.

The Sniper

This saboteur throws you a curve ball or directly opposes you (out of the blue) at a meeting. The Sniper seems to like striking in public, where they can do the most damage.

In my experience, The Sniper is often motivated by the need to have some control over what is going on or what is being discussed. This saboteur is best diffused by including him in pre-meeting discussions. I ran into one of these guys during a consulting job for the government, where I was a project manager.

At a major status briefing, when I came to a statement concerning his area, he sabotaged my briefing by saying the facts I reported were wrong. I didn’t say anything negative about his area, but he found it necessary to degrade me in the meeting anyway.

The next week, before the status meeting, I met with him and explained what I was going to report. I asked him if my report on his area met with his approval. I also made a point of asking him if I could count on his support at the meeting. He agreed, and I never had further trouble with him.

All he wanted was to be recognized and offered some deference. After I started looping him in prior to meetings, he turned into one of my most effective supporters.

The Passive-Aggressive Disrupter

This saboteur can create quite a bit of havoc when she has a beef with you. The Passive-Aggressive Disrupter comes to you in confidence and tells you something negative that another person said about you.

I’ve found the most effective way of dealing with this behavior is not to act on the information you receive. I worked with a woman several years ago, when I was managing a team of 125 analysts. One day, my co-worker approached me and told me that someone complained to her about one of my team members.

I decided I wasn’t going to play this game. I told my co-worker that if someone has an issue with a member of my team, then that person must come to me and discuss it themselves. I do not engage in watercooler talk and react to hearsay.

After this incident, I never had this sort of problem again, and people started coming directly to me with issues.

The Smiling Assassin

This saboteur can be one of the toughest to deal with, because on the surface, this person is nice to you and in agreement with you. Then, when you least expect it, The Smiling Assassin undermines you with your co–workers when you’re not around.

I have found a couple of ways to deal with this threat without resorting to an HR intervention:

  • Direct confrontation
  • Enlist co-worker help
  • Cultivate your network

Confronting The Smiling Assassin requires cool professionalism on your part. Approach him and tell him that what you heard he said. Give him a chance to explain or discuss the problem directly. Stay calm. Don’t get emotional. Listen objectively. If there some truth to the criticism, own it and work to correct it. If there is no truth, you have effectively shut this back-corner talk down by bringing it out in the open.

Enlisting co-worker help is a less confrontational strategy. Hopefully, you have co-workers that you are comfortable approaching for help. Ask them to shut down the conversation or come to your defense any time The Smiling Assassin speaks ill of you. This shows that negativity falls on deaf ears, and that soon stops the behavior.

Cultivating your network undermines The Smiling Assassin. I faced a situation many years ago where I was in line for a promotion. I found out after the selection meeting that a particular VP who didn’t like me vetoed the promotion. I confronted my Smiling Assassin and asked what I could do to improve his opinion before the next promotional cycle. He hemmed and hawed, and I figured out that there was little chance that he would change his mind.

I made a special effort to engage the Senior VP of that group and to worked to impress him. After the next promotion meeting, my network told me that the Smiling Assassin again tried to derail my promotion. But now, I had the Senior VP on my side and his vote overruled the other. I got the promotion. Afterwards, I avoided The Smiling Assassin as much as I could for the rest of my career at that company.

Closing Thoughts

Many times, workplace challenges are self-inflicted. Learn to honestly assess your own behavior before you blame others’ bad behavior on your negative outcomes. But, if you’ve done your soul-searching and you still think the problem is not yours, don’t become a victim and have faith in your power.

Always remember to stay professional, don’t waste energy taking things personally and try not to go over to the dark side yourself.

If you’ve run into a different type of Saboteur that you’d like to discuss, leave a comment and let’s see if we can add some more coping mechanisms to this post.

 

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