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

Why Every Story should have Acceptance Criteria

Better Understand the Purpose of Story and Acceptance Criteria

Some who practice scrum believe that acceptance criteria are optional. Others only write a one sentence summary and don’t even bother writing story requirements. These practices could be a recipe for disaster, because developers may not understand what to develop and testers may not know what to test.

At GSD Mindset, we teach that acceptance criteria are mandatory, and we spend lots of time helping those new to scrum learn how to write stories. The story describes the requirement for that next slice of functionality the team needs to build. The acceptance criteria describe how the product owner and team know that the functionality works; they also describe what happens when something goes wrong.

If story content so profoundly impacts the team’s ability to produce quality work, then why do so many teams write crappy stories? We get that it takes time to think through and document the specific functional requirement, plus also to think through how to tell that the function works. We get it that most teams write their stories the night before or the morning of Story Grooming. We get it: your team is busy.

How much busier does the team become when stories take too long to close? How much busier does the team become after they build the wrong functionality and they have to rewrite it? How much busier does the team become when the project gets behind schedule?

After high level design and Epic breakdown, writing good stories is one of the most important activities the team performs. Taking the time to write a clear, concise story with clear, concise acceptance criteria can be one of the most important predictors of green project status and excellent quality.

How Do You Write a Good Story?

The Story format is simple:

As a <user role>
I want <to perform some function>
So that I can <achieve some goal/benefit/value>

When you sit down to write a story, think about who will be using the functionality, even if the user is another automated process. From the user perspective, visualize what function the user will be performing and why this slice of functionality is important.

For example, think about the customer of a shopping website. If the requirement is to build the first slice of a search tool, think about how the customer wants to search. Suppose research shows that most customers are brand conscious. Then write the first slice to search by brand:

As a customer of this shopping site,
I want to enter my favorite brand name
So I can see easily see all the products available for sale and quickly browse the list.

The requirement for this slice of functionality is clear. The reader understands what the customer wants to do and why: Because they came to the website with a specific brand in mind.

Yes, there are other ways customers search: by price or clothing type or gender, etc. But agile scrum stories only describe a slice of functionality. Every one of those other search parameters should be described in separate stories.

The acceptance criteria format is simple too:

Given that <I am able to perform the new function>
When <I complete the function>
Then <something happens to show success/failure>

How does the tester know that the brand search is working?

Given that the customer enters a brand name,
When the customer clicks to search,
Then the website returns the list of clothing in stock for that brand and displays a list that includes: small image, product name and price.

What does the website do if there is no clothing in stock for the brand?

Given that the customer enters a brand name,
When the customer clicks to search,
If there is nothing in stock for the brand, the website returns a message that includes the search parameter and offers the customer options to search for similar brands (e.g., people who search for A also search for B).

The effort to write a complete story that clearly describes required functionality and what to look for when testing does not really take much more time than writing a crappy, incomplete story. If your team is not writing stories complete with acceptance criteria, I urge you to try writing complete stories for at least 3 sprints.

I’ll bet you love the results!

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Techniques to Increase Sprint Velocity

Try Applying these 3 Techniques to Increase Sprint Velocity

In agile scrum, we only count closed stories when we calculate velocity. Stories have only 2 statuses at the end of the sprint: 0% or 100% complete. No partial credit for incomplete stories.

Many teams refuse to accept this fact. Scrum does not give partial credit for the simple reason that incomplete stories cannot be delivered to the customer, so they have no value. Because priorities can change at the speed of business, incomplete stories may not rank high enough to be prioritized for the next sprint. If that code was checked in, the code changes for those partially finished stories have to be backed out, which causes even more work that adds no value.

We have found the following 3 techniques help the team close more stories, which improves burndown and results in increased velocity:

  1. Write smaller stories
  2. Ask when story will close
  3. Adopt shared test mindset

Write Smaller Stories

Do your developers pick up stories at the beginning of the sprint and work on the same set of stories for the entire sprint? Does your burndown chart look more like a plateau with a cliff at the end? If this frequently happens with your scrum team, then your stories are probably too large.

Look at your backlog. How many 1 and 2 point stories has your team written? None? Are they all 3 or 5 or even 8 points? If you answered yes, then streamline your approach to story writing.

Remember that a story performs a single function. Take a serious look the slice of functionality defined in your larger story requirements. If your stories describe requirements for multiple, yet related functions, then divide and conquer.

Ask When Story Will Close

At daily standup, the development team answers the following questions:

  • What did I do yesterday?
  • What will I do today to meet the sprint goal?
  • Do I have any impediments?

To keep the eye on the prize and focus on closing the story, we suggest you ask an additional question every day when you discuss the status of every story:

  • When do I think this story will close?

The answer to this question provides insight into the true status of the story. If you don’t like the answer, immediately follow up with: Why? The answer to these two questions help identify the proper next steps, which could include clarify requirements, get help from tech lead or pair the developer with another programmer.

One of the pillars of scrum is transparency. Be honest with each other. Ensure stories that languish get the attention that they need to close.

Adopt Shared Test Mindset

To produce quality products, we recommend scrum teams take a 3-pronged approach to testing:

  • Test driven development
  • Write QA tests when the Story is picked up
  • It’s everyone’s responsibility to test  

If your development team does not have automated testing goals, add them to your team’s contract. Every time you add new functionality to a program, apply the iterative concept of Test Driven Development (TDD): write a failing automated test first, then write the code so the test passes.  

We recommend getting testers immediately involved when the story is picked up for development. Early involvement by testers, who write test cases based on the acceptance criteria, avoids having those resources sitting around for half the sprint waiting to test. It also ensures the team is ready to test immediately after the story is code complete.    

Agile scrum holds the entire team responsible for completing the story. That means testing is everyone’s responsibility. If stories get backed up waiting for testers to test, other members of the team must pick up the slack to get all stuff done on time.

If your team successfully applies these techniques or other techniques that result in a smooth burndown and increased velocity, we’d love to hear them.
Do share.

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Help Your Product Owner Prioritize Stories

Two Winning Techniques that Help Product Owners Set Priorities

We’ve all seen it.  The business provides a list of enhancements to a Product Owner. You, as Scrum Master, call a meeting to walk through the enhancements and try to facilitate prioritization.  What happens?  The Product Owner ranks all of the enhancements as high priority or must-haves.  And of course, if every priority is Number 1, there’s actually no priority at all.

I’ve tried a lot of techniques on the various teams I’ve worked on and have found these two work the best: Quadrant Chart and Story Mapping.

Quadrant Chart

My favorite quick-and-dirty prioritization method is the Quadrant Chart.  

It looks like this:

Notice how the Priority on the vertical axis is ranked Low to High, but the Complexity/Size on the horizontal axis is ranked High to Low.

This method is most useful when you have a long list of items you want to sort quickly and efficiently. You begin by stepping through your list of whatever it is you want to prioritize. In our case, Epics, Components, or Stories.  Start with the first item and work to the last.  Assign each two ranks.  For Priority, assign 1, 2, 3, 4 with 1 representing the least important and 4 having the highest priority. After you assign the priority repeat the ranking for the item on the basis of Complexity or Size. Again, use a scale of 1-2-3-4 with 1 representing the smallest/least complex and 4 representing the largest/most complex.

Now you have a list of Stories with two rankings each that you can plot on the quadrant.

It’s very easy to see that any Story that falls in the upper-right quadrant, High Priority and Low Complexity, is your best place to start.  This enables you to bring the highest value with the least amount of effort.  Who doesn’t like that?

Story Mapping

If you to try using a technique that requires more analysis, I suggest Story Mapping. This is similar to the old waterfall method of sequencing tasks, but with the added dimension of priority.  This method was introduced by Jeff Patton in 2005 and I highly recommend that you read his discussion on his Jeff Patton and Associates website.

Write your Epics on sticky notes and place them on the top of a decision box.

Now break the Epics into Components and write the Components on sticky notes. Place them in your decision box from left to right in order of use case sequence.

Finally, break the Components into Stories and place them in your decision box from left to right in order of use case sequence.  Here comes the cool part. At the same time, arrange the Stories from top to bottom based on importance. You can use the Quadrant Chart method to rank importance if you like.

When you finish, you’ll have a map of features that you can use to plan your Sprints. You move from left to right over time for your Sprints. Because the map also provides a top to bottom order of importance, you also have a lovely map of releases that provide increasing sophistication with each delivery. This is Alistair Cockburn’s concept of the Walking Skeleton.

So there you have it. Prioritizing is really pretty simple. All you need are a couple of tools and you can organize anything. If you want to investigate some other prioritizing methods there’s a great blog written by Daniel Zacarias who’s based in Lisbon. He describes 20 Product Prioritization Techniques. It’s a great resource.

Combine this with the GSD method for project planning and you can’t lose. See Chapter 2: GSD Gold Project Planning.

Gerri Slama Grove

 

Gerri Slama Grove
GerriG@gsd.guru

read more