Don’t Let Setbacks Derail Your Agile Project

Take Advantage of these 3 Techniques to Get Your Agile Project Back on Track

We’re all learning new ways to live and work in a virtual world. Many have published articles and delivered webinars explaining how to use available web tools so everything functions more smoothly. These tools may make facilitating meetings and classroom training easier, but without changing your practices, they may not be enough to keep your agile on project schedule.

When my agile project needs some love and attention, I have successfully used these 3 techniques to get back on track:

  1. Add optional 15 minute meeting after Daily Standup
  2. Take advantage of Retrospective 
  3. Rethink Velocity

Add Optional 15 Minute Meeting After Daily Standup

I’ve always tried to stick to the 10 minute max Daily Standup rule. In fact, I often tell my teams that “Daily Standup is the best 10 minutes of your day.” Why? Because that’s the only time each day when everyone is together in 1 place. 

Daily Standup is the best time for the Product Owner and Scrum Master to ensure everyone is focusing on the right stuff. It’s also the best time for the Development Team to gain clarification and resolution to open issues and burning questions.

If the team has issues that cannot be resolved in the 10 minute time box, Scrum implies that plans should be made to continue the discussion at some other point in the day. With virtual teams, it’s easier to get distracted. So, at the next Daily Standup, we often hear that those involved did not meet and the affected Stories have not progressed. As this happens with more and more Stories in the Sprint Backlog, the Sprint (and therefore project schedule) may get derailed.

We all have a tendency to work on the easy stuff and ignore the tough stuff when we’re isolated at home. When I work with virtual teams, I often add an optional 15 minute meeting after Daily Standup, so the Scrum Master and Product Owner can ensure the necessary conversations take place with the Development Team. 

By creating a separate meeting, you don’t disrespect the intent of Daily Standup. By making the meeting optional, you limit attendance to only required team members. 

The caveat: Just because you schedule the meeting doesn’t mean you must use the time every day. Only take advantage of the time box when the team really has an issue to discuss. The additional meeting is NOT an excuse to extend standup to 25 minutes.

Take Advantage of Retrospective

Relationships change when teams become virtual, because we communicate differently. Conversations happen less frequently, and most of those conversations are messages rather than video or phone calls. It’s easier to ignore each other when uncomfortable issues arise. 

Retrospective is the best time to talk about what’s working, what’s not working and to brainstorm better ways to work together. At the end of every Sprint, use Retrospective time to openly and honestly reflect on what’s affecting team productivity. 

If your team does not conduct Retrospective at the end of every Sprint, reinstate the practice now. Address small issues before they become big ones and further derail your agile project.

Rethink Velocity

New virtual teams must overcome many obstacles. In addition to the issues I’ve already discussed, your team may be faced with network issues, VPN issues, access issues, environment issues and problems with new tools. It’s naive to think that Velocity won’t be affected.

It’s been a few Sprints since we all became virtual, so you probably can see a new normal Velocity emerging. If this new Velocity is significantly lower than before, you need to reset expectations with your management and other stakeholders.

Recalculate estimated time to completion and project status. Help your organization understand exactly where your project stands in relation to where you’re supposed to be. That way, you can negotiate more realistic timelines. Maybe reducing scope or redefining the MVP could be the answer, so your customers can still get what they need.

The Key is Communication

To remain a productive team, open and honest and constructive communication between members is required. Address important issues as soon as possible. Extend Daily Standup for those who need additional help with requirements and technology. Take advantage of Retrospective and find creative ways to work together. If Velocity is affected, reset expectations and scope right away.

What agile techniques is your team using to remain happy and productive?

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru
503.799.5500

read more

Why Your Team is Not Agile

Maybe Your Team is not Agile because They Don’t Know How to Be Agile

Many Scrum Masters feel frustrated when their team is not agile enough or they don’t practice scrum the “right way.” Probably every Scrum Master feels this way at some time in their career.

So, why is this happening?

We could list an infinite number of reasons for this, but if you look past the symptoms, we can group the team’s lack of commitment or poor performance to 3 root causes: 1) Inadequate training, 2) No consequences and 3) We forget that we are servant leaders.

Inadequate Training

Maybe the team doesn’t know how to be agile.

It never ceases to amaze me how many companies transition to agile without training everyone involved: management, the engineering staff and (oh yes) the business team members too. Agile methods are more than ceremony. To be agile, you must change the way you think. To truly transition, everyone involved must understand not only how to practice, but also the theory behind why the practice works.

Companies that train their staff may only train the Scrum Masters and maybe the engineering staff. I’ve never understood why management feels exempt from training too. If their entire staff is transitioning to a new approach to application development, won’t their approach to managing their staff need to change too? How can anyone manage and support what they do not truly understand?

One of the major benefits of scrum is Product Owner membership on the team. This precious customer representative influences timing and impacts quality. Their vision has direct impact on customer satisfaction. If the Product Owner is an integral part of the team’s ability to deliver, then why is it that the Product Owner rarely receives training before joining the team? How can we expect someone to write stories when they do not understand the concept and they haven’t been trained how to plan or how to write story requirements and acceptance criteria?

If your team does not know how to be agile, as the Scrum Master, remove this blocker by requesting training for those who need it.

No Consequences

What happens when the team misses their commitment?

Many scrum teams operate without a team contract. Agile is about self-managing teams. Self-management is an awesome responsibility. As the first step, the team needs to define how they want to work together. If the team skips this step, then there is no commitment to practice scrum and it’s no surprise that anarchy ensues.

The team contract should acknowledge mandatory attendance at ceremonies like Daily Standup, Story Grooming, Sprint Planning and Retrospective. The contract should also include expectations when a team member cannot attend. The team contract should be prominently displayed on wiki or SharePoint pages. Consistent disregard for aspects of the contract should be escalated to management by the Scrum Master in the same manner as any blocker to team success. For more information about team contracts, check out Chapter 1 of the GSD Scrum Handbook.

Many teams cannot seem to time box their sprints or meet their story commitments. This common problem has roots in many different aspects of practice. As Scrum Master, do not let these problems languish. Discuss them at Retrospective. Let the team identify the root cause and then let them decide how to change their behavior. At the beginning of every Retrospective, review practice changes from prior Retrospectives to see if the team has actually changed. Holding the team accountable for walking their talk is an important aspect that is often overlooked.

We Forget that We are Servant Leaders

Servant leaders are not task masters.

In the age of agile, many project managers have transitioned to Scrum Masters. In our past waterfall world, the project manager works with the team to create a work breakdown structure and then creates a plan with tasks that must be completed to complete the project.

In scrum, the Scrum Master must know scrum, but the Product Owner decides what the team works on and when the work is complete. The Development Team decides what they can commit to. Everyone decides how they want to work together. Then, the Scrum Master clears the path and removes roadblocks.

For many Scrum Masters, it’s hard to give up control. When your team is not agile enough, first look inward. Are you part of the problem? Scrum Theory prescribes 4 events: Sprint Planning, Daily Scrum (Standup), Sprint Review (and Demos) and Sprint Retrospective. If your team practices these events, they practice scrum.

Coach your team and arm them with knowledge about best practices, yet give them freedom to practice scrum in the way that works for them. If it’s not working, review at Retrospective and let them decide how to change.

Providing team training, allowing the team to define their own rules and consequences, and ensuring the team has freedom to practice within the boundaries of scrum are the recipe for self-managing teams that are most likely to meet their commitments.

Do you have any experiences that you’d like to share?

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru 503.799.5500

read more

Ensure Project Success by Getting Formal Commitment from your Extended Team

Get Commitment from all Extended Team Resources at Start of your Next Project

In today’s business, organization boundaries blur. When you form a new scrum team, you may not get all the desired resources assigned to your Development Team. This is quite common in today’s business, where budgets are tight and resources are stretched thinly across the organization. At GSD Mindset, we propose that when you organize a new scrum team, in addition to identifying and gaining commitment from the Product Owner, Scrum Master and members of the Development Team, you also gain a level of commitment from what we refer to as the GSD Extended Team.

The required commitment to attend Daily Standup, Story Grooming, Sprint Planning and Retrospective may be too much for Subject Matter Experts (SMEs), Database Administrators (DBAs), Architects and others whose expertise is required by multiple teams across the organization. Just because these experts cannot commit to membership on your Development Team, doesn’t mean they cannot or will not participate on your project. They probably already do participate in some capacity.

The GSD Extended Team Contract

How do you ensure your team gets your fair share of the expert’s time, when you need it?

First, start with a Release Plan. When you know what your deliverable commitment is, you then have a better understanding of how much time you need from each extended team member.

Then, meet with each resource, negotiate the required commitment and document it as part of your Team Contract. If you have a project Kickoff, invite them, because they are a valued member of your team.

Provide Status to the GSD Extended Team

We are agile, so requirements can change, which means desired commitments can change too. Keep your extended team updated, so they can plan for and be available in the Sprint where their expertise is needed.

Keep in mind that even though they agreed to participate as an extended team member, your team priority is not always their priority:

  • Confirm availability before bringing in Story that requires their expertise
  • Escalate if the required team member is not available within reasonable timeframe
  • Provide regular status updates to keep your team’s needs on the experts’ roadmap.

Invite Extended Team Members to your Scrum of Scrums

If your project is large enough to warrant a Scrum of Scrums, invite the extended team to that meeting along with your partner Development Teams. If you keep to the intent of Scrum of Scrums by only focusing on upcoming cross-team commitments, all project teams have a better chance of bringing the right Stores into the next Sprint and having the right resources available to work on them.

Remember, your extended team members probably overlap with your partner Development Teams. Scrum of Scrums offers visibility into all the teams on your project. Openly discuss upcoming dependencies, honestly review priority and negotiate use of scarce resources in good faith to ensure those resources are used wisely.

Even if you do not practice Scrum of Scrums, regular communication across all project players ensures all Development Teams have access to the GSD Extended Team’s expertise when most needed.

I’d be interested to learn how your scrum team manages shared resources.

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Story Identification for Newbies

Event Modeling is Easy Story Identification Technique

For those new to Scrum, Story identification can seem intimidating. Even if you follow our guidelines in Chapter 3 – GSD Gold Approach to Story Writing, you may still have writer’s block. Event modeling is one of my favorite go to methods that get my Story writing juices flowing.

Every Story has a beginning, middle and ending. The Event kicks off the beginning of the process we want implemented, the Story Description outlines the what’s and why’s of the process, and the Acceptance Criteria instructs the reader how to tell if the Story has a happy or sad ending.

Simple.

It all starts with the Event.

Once you know the highest priority Epics and Component deliverables that must be implemented first, then brainstorm and list all the reasons why the Customer accesses the online portion of your application. Because I’ve previously written about the Customer Account Maintenance Component of an Online Banking app in my post Write Better Stories, I’ll use that same example, but approach Story identification from an Event Modeling perspective.

Here are just a few Customer Account Maintenance Online Events:

  • Customer receives Welcome Letter and wants to setup Online Access
  • Customer wants to setup Mobile Access
  • Customer wants to update personal information, such as physical addresses, email addresses, phone numbers, etc.
  • Customer cannot remember password
  • Customer wants to change password

Each one of these Events represents at least one Story that starts with “As an online banking customer, I want to…so that I can…”

Once you’ve exhausted all the Events that describe reasons why the Customer wants access the application, then brainstorm all back-end processes needed to support the online ones.

Some back-end Events could include:

  • New Customer application approval generates Welcome Letter to access new account
  • Customer account password expires
  • Customer incorrect password attempts triggers online account lock
  • By viewing the application from the Customer perspective, isn’t it easier to identify what Stories to write?

What tips and techniques do you use to get your Story writing juices flowing? Do share!

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

How Big is Too Big for a Scrum Team?

You May Need to Divide Your Project into More than One Scrum Team

In Chapter 1 of the GSD Scrum Handbook, we talk about the size of the GSD Gold scrum team. What is the right number of team members? The Scrum Alliance recommends a scrum team size of no more than 9 members. At GSD Mindset, we also recommend organizing a scrum team with all the skills to complete quality work valued by the customer: Product Owner, Scrum Master, Tech Lead or Architect, Business Analyst (to help Product Owner write Stories), Programmers and Quality Assurance (QA) testers.

A scrum team size of 9 members may be optimal for Scrum, however your project may need a bigger team to complete all the required work on time. In Agile projects as well as Traditional projects, we face the same Time-Scope-Budget triangle constraints. When Time is fixed, sometimes upper management agrees to add Budget, and then your boss goes out and hires more team members.

How Do You Know When the Team is Too Big?

One indicator that helps determine whether or not a scrum team could be too big is the length of standup. If your team sticks to the constructs of standup and they cannot complete the meeting in less than 15 minutes, the scrum team may be too big.

Large scrum teams developing lots of features that cross multiple business boundaries can be another indicator. If you notice scrum team members stop paying attention half way through standup, retrospective or sprint planning, then dividing the team is a good way to speed up those meetings up and keep everyone engaged.

There are lots of reasons why teams get unwieldy and difficult to manage. If you’ve got 10+ team members on the same scrum team and you feel like the team is becoming inefficient, it probably is inefficient.

How Do We Split the Scrum Team?

Identifying the need to split one team into two teams is easy; deciding how to divide the teams is not always easy. We at GSD Mindset believe all the roles listed above are required to form a competent team. We  want you to continue this practice as you plan for and hire new scrum team resources.

When management wants to get more stuff done, their first thought is to hire more programmers. However, if you double the number of programmers without hiring QA testers, QA becomes a bottleneck. If you don’t hire another Business Analyst to help the Product Owner write Stories, grooming and sprint planning can get delayed.

Yes, you can share the same Product Owner, Scrum Master, Tech Lead and Business Analyst across 2 teams that share the same Backlog when you add 2-3 new programmers. We do encourage you to keep the ratio of programmers to QA testers at 3:1 if possible.

Of course, your application may require a different mix of players. The important takeaway here to remember that as your scrum team grows and splits into more scrum teams, keep in mind: The correct mix of team players ensures maximum throughput.

How Many Scrum Teams Can Pull from One Backlog?

Scrum teams with shared Backlogs continue to share the same grooming sessions, sprint planning and retrospectives. Those meetings may still be unwieldy, because you only really divided the development and QA aspect of completing Stories. Consider this before you decide to divide and still share.

I once worked successfully with 3 scrum teams pulling from a shared Backlog. The combined team supported multiple applications and the Engineering Manager wanted all the programmers to have the knowledge to work on any one of them, depending on the needs of the Product Owner. Keeping Stories written and groomed became challenging, so each scrum team added their own Business Analyst to help write Stories. The burden fell on the Product Owner to ensure the right mix of high-priority Stories were ready for sprint planning. Our original scrum team organically grew from 1 to 3 teams over the course of 2 years, with the same Product Owner and Scrum Master, so they were experienced enough to handle a Backlog with hundreds of Stories.

I would not recommend 3 teams sharing 1 Backlog for those new to Scrum.

I would never attempt to manage 4 teams from a shared Backlog.

How Do We Divide the Backlog?

If you divided your functional requirements into independent feature sets or Epics as described in Chapter 2 of the GSD Scrum Handbook and you include Epic as one of your Story attributes in your agile project management tool (like JIRA or VersionOne), then you can easily start a new project and divide the Backlog. If not, then you need to properly attribute your Stories with an Epic.

If you are dividing 1 scrum team into 2 scrum teams, the Product Owner, Business Analyst and Tech Lead should review the Epics and organize them so the 2 sets of Epics have the least amount of overlap. The 2 scrum teams must be organized so they can independently complete their Stories.

After the split:

  • Each scrum team must be able to close Stories without relying on the other scrum team to complete any work
  • Cross-team knowledge sharing is appropriate.
  • Cross-team pair programming is not appropriate.

How Do We Divide the Team?

Agile is about self-managing teams. As tempting as it may be for the Engineering Manager or Product Owner to divide the scrum teams based on tribal knowledge about the Epics in each Backlog, don’t do it! Let the teams divide themselves and pick their own team members.

Organizing for success is not always easy.

Think about what stuff needs to get done and think outside the box.

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more