Voices of Agile – My Name is Anu

I have lived on this planet for nearly 52 years, the first 21 in India and the past 30 here in the United States. I have experienced my share of racism.  

Even in India I am considered a “Darkie” or a “Kalu” when compared to others in my family. My grandmother was among the people who made me feel “less than”. She would put powder on my face to make me look fairer or less dark. My mom would wipe off all the powder and tell me I was beautiful as is. My mom – my hero!

In the US, things are same but different – I went from being called Darkie to brown. The past few years I have been traveling with my US passport so I can prove I am American. When I travel with my white stepdaughters, I get the LOOK.  The usual assumption is I am the nanny or the help. 

The micro aggressions are equivalent to a death by a 1000 paper cuts.  

To my Indian friends – I am not Indian enough – I am too American.

To my American Friends – I am too Indian – I am not American enough. 

To my colored friends – I am not doing enough as a colored woman

To my non colored friends – I have never been seen as a colored woman

My name is Anu – I am a mom, a wife, a daughter, a sister, an aunt, a niece, a friend, a trainer, a coach, a human…

My name is Anu – I love the beach, sunshine, jasmine flowers and scent, music and dance….

My name is Anu – I am scared of bugs of any kinds even the little lady bugs…

My name is Anu – why does the color of my skin matter?

Planning For Your First Potentially Shippable Increment – Part 2

Written by Anu M. Smalley and William F. Nazzaro

In Planning For Your First Potentially Shippable Increment – Part 1 we recommended that organizations should properly plan for their first PSI.  For simplicity, we will refer to this planning as preparatory activities for your first PSI.

What is the goal or purpose of these preparatory activities?

The goal is to be ready and able to delivery business value in the form of potentially shippable features at the end the release train.

How long should one spend on these preparatory activities?

As a benchmark, we found it useful to have this timebox be the same length as the upcoming Agile Release Train (ART).  If you are planning a 12-week ART, we recommend 12 weeks for the preparatory work.  It may seem like a lot of time, but there is a good deal of work to get ready for your first Potentially Shippable Increment (PSI). [1]  Keep in mind, this is recommendation, not a rule, and the preparatory needs will vary based on your organization’s agile maturity.

Below is a collection of six preparatory activities we refer to as “Form Program & Leadership”.  We recommend that these activities occur 10 to 12 weeks prior to the launch of your first Agile Release Train.

1.     Validate Value Stream

A successful agile transformation or a scaling implementation needs to happen bi-directionally – top down and bottom up.  Validation of the value stream brings together everyone in the value stream to ensure that all teams, leaders, and support services are dedicated and willing to meet the commitment to deliver on the value streams objectives, which is providing business value.  This helps the process of identifying and disseminating the vision of the value stream.

This is ideally done with executives from IT and the business.  This is to ensure that the value stream or the “kidney” is valid and complete.  With an incomplete value stream the rest of the effort to stand up a release train is at severe risk. With the value stream identified and validated we are now ready to form and train the leadership of the Agile Release Train.

2.     Form and Train ART Leadership Team

When considering membership for this team we will look at both the business and IT that make up the value stream.  In larger organizations we will consider senior leaders that are business stakeholders, value stream champion, IT leadership, and those managers making decisions on what personnel will be part of the Agile Release Train team.

The ART Leadership need to understand what the SAFe™ framework is, how its implementation will impact their teams and the commitment to delivering business value.

While it’s recommended that we provide the ART Leadership Team with the 2-Day Leading SAFe class.  We prefer to provide a shorter 1-day version that includes the following topics like Agile Manifesto & Principles, SAFe Big Picture Overview, SAFe Roles & Responsibilities, What to Expect During Your First PSI, and What Changes with Agile and What Doesn’t.

This enables them to know what they are committing to, how a release train works, and what they must do to help assure SAFe is implemented correctly.

This class is only held for the ART Leadership which will often have very different questions from the ART team members.

3.     Identify Program’s Key Players & Teams

Bringing together a 100+ people within a defined value stream together for 2 days to plan for the next 12 weeks is a huge endeavor and requires some level of responsible planning.  We need to ensure the correct people have been identified and are prepared to talk to the business value of the features being discussed as well as managing risks across the train.

Identifying key Agile Release Train (ART) players early on in the process is a critical step to the success of a SAFe QuickStart.  Some of the key players needed early on are:

  • Product Management
  • Architect
  • Release Train Engineer (RTE)
  • Release Management Team
  • Business Owners
  • System Team
  • Dev Ops
  • Scrum Masters

4.     Program Team Kick-Off

From the outset it should be clear what the purpose of the Program Team is, their roles and what’s expected of them and how agile may influence their behaviors.  During this time of “forming” we’ve found it advantageous to have the Program Team also establish a Working Agreement.  This working agreement should outline how they plan on working together to handle prioritizations, coordination, escalations, and impediments.

5.     Review Readiness Checklist

We should have the Release Train Engineer and his/her key people identified above actively work through the PSI Readiness Checklist.  While SAFe’s Readiness Checklist[2] is a good place to start you may want to adapt this checklist for your organization. Some things to consider are:

  • Are all the teams on the train in place
  • Is training available for these teams on agile concepts as well as any tools and processes that are part of the organization
  • Has a coach been identified and engaged to assist with the teams as well as the groups on the program level
  • Is the tool to be used by the train for their PSI ready and set up
  • Are all support services available and committed to the release train
  • Are the engineering practices to be used understood and in place

This is not an exhaustive or exact list; rather, these are ideas to guide your activities and provide you with an awareness of the amount of preparation required to work to ensure a successful QuickStart.

6.     Establish Program Team Backlog

A common Program Team Backlog contains the stories the Program Team needs to keep the train on the tracks.  It’s important to note that the Program Team Backlog is different from the Program Backlog.  The Program Backlog contains the prioritized features.  The Program Team Backlog contains the stories that:

  • Remove impediments for the agile release train,
  • Establish, maintain and track program-level metrics,
  • Manage critical value stream relationships that are external to business or organization,
  • Represent the communication to and for the agile release train,
  • Drive a continuous improvement culture.

The Program Team Backlog takes time to build and these stories can impact the scrum teams’ abilities once we start the ART.  Having these items identified and potentially being worked on prior to the PSI Quick Start will ensure the train is effectively moving forward on the tracks.

Conclusion

In Part 3 of this article we’ll discuss the “Build Vision and Backlog” preparatory activities we recommend to address 6 to 10 weeks prior to launch.  In Part 4 of this article we’ll discuss the “Conduct QuickStart” preparatory activities we recommend to address 1 to 2 prior to launching your first Agile Release Train.

[1] Note: Not all individuals will be working full-time on the preparatory activities

[2] Agile Software Requirements, by Dean Leffingwell, p 485.

Sprint Team Kickoff or Reset

As agile transformations continue and grow one of the things we do as coaches is stand up scrum teams or sometimes reset an existing team.  Bringing 7 +_2 people together and informing them that they are now a team and should start sprinting tomorrow is one way to do this, but often not successfully.

There has been a lot of conversation in the industry on this – some call it Sprint 0, some call it pre Project work, others call it preparing for the scrum team.  Regardless of what it is called, there are something’s that need to be put in place prior to a team starting to sprint. These might include – obtaining hardware, licensing software, getting environments, etc.

Once all this pre work has been done, the people who have been identified to be part of this scrum team need to do some work to start forming as a team.

I have conducted a Scrum team kickoff or a team reset with all the teams I have coached and am coaching.  I have listed out 6 things I always do and some outcomes for each activity.

# 1 – Agile/Scrum refresher

  • Refresh the team’s knowledge on agile/scrum

Expected OUTCOME

  • Get the team on the same page with agile terms

#2 – Team Identity

  • Pick a team name,
  • Pick a team logo
  • Create team norms
  • Identify which ceremonies the team will use and setting up the cadence for them
  • Identify which BVIR’s (Big Visible Information Radiators) the team want to use

Expected OUTCOME

  • Brings the team together; help them create their team energy or “BA”

#3 – Definitions

  • Definition of Ready
  • Definition of Done
  • Definition of Impediment – This is something I do with my teams. Any roadblock that threatens completion of team commitment. See previous article at                                                                                                             https://agilemethis.wordpress.com/2013/08/16/test/

Expected OUTCOME

  • Help the team understand what they will work on, when they will know their work is complete and when to call out impediments

#4 – Initial Product Backlog

  • Understanding the work the team will be doing
  • Understand the priority of the work
  • Story mapping exercise

Expected OUTCOME

  • Helps the team figure out WHAT they will be working on

#5 – Simulation

  • Plan the next two-week window
  • Conduct, understand and experience all ceremonies

Expected OUTCOME

  • Give the team an opportunity to experience SCRUM before Sprint 1

#6 – Agreement with the coach

  • Build the coaches backlog
  • Agree on coaching engagement model

Expected OUTCOME

  • Creates a clear understanding on the  role and expectations of a coach

I have used this format with all my teams and have found it to be successful.  This initial foundation helps the teams SCRUM together and hopefully be on their way to becoming hyper productive teams.

Planning For Your First Potentially Shippable Increment – Part 1

Written by Anu M. Smalley and William F. Nazzaro

In 2013 the Scaled Agile Framework (SAFe) appears to be the de facto standard for those organizations seeking to go beyond team agile and truly bring distributed, scaled agile adoption to their enterprise.  While SAFe has made quite the splash and many companies are seeking to adopt it, we would like to share some of our experiences both pro and con with assisting our clients in implemeting SAFe.

One area of SAFe that is incredibly powerful is the concept of a Potentially Shippable Increment (PSI) and the metaphor of an Agile Release Train (ART).

What is a PSI?

PSI provides the Program or Enterprise with a timebox in which iterations are then conducted.  The PSI offers the following: “a routine and continuous planning cycle, an aggregation of iterations value into larger piles of newsworthy value and a quantum unit of thinking, roadmapping, implementing and measuring.” [1]

What is an ART?

“The Framework’s primary scaling mechanism, the Agile Release Train (ART), is to the program what iteration is to the team. It follows the same pattern—plan, commit, execute, demo, and reflect—but at the Program Level (see Figure 1) where it produces system-level working software every two weeks, and full, potentially shippable increments of software every 4-5 iterations.” [2]

safe

Figure 1 – Agile Release Train

Although the PSI and Agile Release Train are very helpful for teams to focus the delivery of business value to their stakeholders the one concern we have with the current version of SAFe [3] is little to no mention on planning for your first PSI.  While this may be an oversight or intentional (and we acknowledge that SAFe is meant to be a framework and not a prescriptive process), we feel this lack of detail may actually catch those new to SAFe off-guard as they embark on their first Agile Release Train.

Why do I need to plan for my first PSI?

Many organizations new to SAFe are likely to conduct an Agile Release Train Quickstart.  This 5-day immersion program will bring together anywhere from 50 to 100 people into a single location with the sole purpose of identifying PSI 1’s features and objectives.  If the Quickstart is the first time that a company is thinking about teams, governance, value streams and features it could be quite costly and disappointing for those in attendance.

Therefore, we recommend planning for your first PSI and allow a Program and Enterprise the time to ask and answer these hard questions prior to bringing all of these people together.

Now that we’ve framed the problem, in our upcoming blog posts we will discuss and share what should be done prior to launching your first PSI.

Individuation!!! What the heck is that?

A big part of building trust in a team is to get the team to know each other.  Focus your team on individuation.

According to the Merriam-Webster dictionary:

Definition of INDIVIDUATION

1:  the act or process of individuating: as

a (1) :  the development of the individual from the universal (2) :  the determination of the individual in the general

b :  the process by which individuals in society become differentiated from one another

c :  regional differentiation along a primary embryonic axis

2:  the state of being individuated; specifically :  individuality

Individuation is the process by which people differentiate themselves from others.  Without Individuation, your view of people will be based on what you have heard and not on what you know.  The only way to trust a person is to get to know them better.

It is important for a team to get to know each other.  What does each member bring to the team?  How does each member contribute to the team? What are the differentiators for the team members?

There are many games and exercises that can help with this; I would like to share a couple of games/exercises that I have used that have helped me help my teams in getting to know each other.

 Team Interviews

This exercise originated from Lencioni’s book, Overcoming the Five Dysfunctions of a Team: a Field Guide.  I have made a few minor modifications to suit my teams.

 Time Required: 15-25 Minutes

Directions:

Pair people in the team and have them interview each other to find three things they did not know about the person they are interviewing

Debrief: Ask team members to share what they learned about one another that they didn’t already know. This reinforces the purpose of the exercise and allows for a natural ending to the conversation.

Learning Points:

  • To help the team focus on individuation – helping them get to know each other based on facts and what they hear from each other, rather than from stereotypes.

Line Up

This exercise originated from Tastycupcakes.org and was posted there by Stefan Nijenhuis .   I have made a few minor modifications to suit my teams.

This is a simple and quick game that can be used as an energizer and get to know each other a little bit. It also gives you hooks to talk about acceptance criteria, self-organizing teams and process improvements

Participants: 4-50

Timings: 15-20 minutes

Materials: none

Instructions:

Round 1:

  • Ask everybody to stand up
  • Assign a ‘manager’ and ask him to make the group stand in a line, ordered by middle name (pick something that may not be common knowledge to all)
  • Wait to see what happens.
  • After everybody is lined up, check the result with them. Is the result ok? How can you do this faster?
  • Thank the ‘manager’ for his/her help.
  • Did the ‘manager’ specify the end result? Or was he/she managing the process?

Round 2:

  • Specify the expected end-result very clearly: “After I say ‘Go’, I want you to line up, ordered by the number of years you have been part of this organization, less than 1 year starting on the left to 5 plus years on the right”
  • Verify if the team understands the expected end result.
  • Say “Go”
  • Wait to see what happens.
  • After everybody is lined up, check the results with them. How can you check this? (E.G. make everybody say their tenure out loud). How can you do this faster?
  • Show that being clear about the end result (acceptance criteria) enables the team to self-organize.

Round 3:

  • Specify the expected end result very clearly: “After I say ‘Go’, I want you to line up, ordered by the month of your birth ascending, January starting on the left to December on the right”
  • Specify that the team is not allowed to speak to each other while doing this
  • Verify if the team understands the expected end result.
  • Say “Go”
  • Wait to see what happens.
  • After everybody is lined up, make everybody say his or her birth month out loud).
  • Show that being clear about the end result (acceptance criteria) enables the team to self-organize.

 Variations

Use some other to line up, like: years with this company, years in this business, travel distance, hometown.

Learning Points

  • Get some energy in the room
  • Get to know each other a little bit and let people speak up to each other
  • Show that if the acceptance criteria of the expected end result are clear to the team, they are able to self-organize
  • Length is an extrinsic value, so this can be used without talking. First name is an intrinsic value, so you have to speak and ask. Finally favorite hobby is an intrinsic value that’s really hard to guess, even in a group that knows each other’s first name.
  • See which roles people take. Who is taking the lead? Who is ‘freezing’? Who is easily led?

Who Dun it/Who is it

Time Required: 30-60 Minutes

Directions:

  • Ask every team member to write three things about themselves on three pieces of paper that they believe no one in the team would believe about them.  Put all the pieces of paper in a box.
  • Ask each team member to walk up to the box, pick a piece of paper, read it out aloud and then look around the room to see if they can figure out Who DUN it or Who is it.
  • They can ask the team members to help them as well.

Debrief: Ask team members to share what they learned about one another that they didn’t already know.

Learning Points:

  • To help the team focus on individuation – helping them get to know each other based on facts and what they hear from each other, rather than from stereotypes.
  • Get to know the team a bit and get them talking to each other.
  • Get some energy in the room

There are many more games and exercises that will fit your team.  You just need to find the right one.  Any activity that helps a team to get to know each other better is a step in building team trust.  You could try the trust game and see if the team is willing to fall backwards on blind faith, but they might be more willing to do that after they know each other better.

This article is a follow up on the previous article  – https://agilemethis.wordpress.com/2013/10/30/building-trust-not-just-a-cliche/.

Building Trust – Not just a cliché

Trust is the main ingredient in an Agile Transformation. Trust is the building block of team cohesiveness and is what allows people not only to feel but also to be empowered.  Building trust is organic and cannot be rushed, scheduled or forced.

When a team is first put together they might be a reluctance to rely on and trust each other.  Team members who do not know each other often fall back to doing what they know best.  At this stage team members are working as independent people working in their silos and connecting when they need to at the end of the sprint. Every person for oneself is the motto!!!!

One of the biggest factors blocking trust is an unwillingness to be open and vulnerable to your team.  During the forming of a team it is critical to help the team get to know each other.  This is not just what kind of work they do but helping the team to get comfortable with each other, to be open and willing to raise impediments, to work together towards a common goal.

Here are five key attitudes and behaviors for building and maintaining an environment of trust –

1.     Respect – Respect is one of the foundations of trust.  Building on the saying –“treat others as you would like to be treated” – respect others, as you would like them to respect you.
2.     Collective Accountability – There is no one person to blame or to take credit.  The team collectively fails or succeeds.  Finger pointing or hogging the recognition is a sure way of breaking trust.
3.     Assume Positive Intent – As you get to know each other assume that the other team members are always working to the benefit of the team.  This does not suggest that naïveté is needed to build trust, but I would submit that a little naïveté along with positivity would go a long way.
4.     Team First – As clichéd as “there is no I in team” sounds, there must be a spirit of selflessness towards team objectives.  Team members working together responsibly towards a shared goal will immensely help with building the trust in the team.
5.     Communication – Communication is a capstone of the building blocks towards trust.  Open, honest communications is a MUST to develop and maintain trust.

In his book The Speed of Trust, Stephen Covey wrote:

There is one thing that is common to every individual, relationship, team, family, organization, nation, economy, and civilization throughout the world — one thing which, if removed, will destroy the most powerful government, the most successful business, the most thriving economy, the most influential leadership, the greatest friendship, the strongest character, the deepest love.

On the other hand, if developed and leveraged, that one thing has the potential to create unparalleled success and prosperity in every dimension of life. Yet, it is the least understood, most neglected, and most underestimated possibility of our time.

That one thing is trust.

 

Definition of Impediment

As an agile coach,  I have heard often during standup – “I worked on task X yesterday, but was not able to complete it. I plan to work on task X today and hope to complete it.  I have no impediments.”  This went on for 2 days until I asked how long the task was originally estimated for and the response was – 8 hours.  So here we are 16 hours later, we have not yet completed task X and we have no impediments.  Upon further questioning I found out that the reason this task was going over the estimate was because the team member was waiting for someone on a different team to provide a particular access.  So in fact there was an impediment but this team member was hesitant to call out someone else as one.

This is a story we have all heard – right?

In a culture of competency no one wants to call out  another person for not doing their job, so they might not properly identify impediments.  One of the new standup questions in the updated scrum guide might aid this issue –  “Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?” This is one way for team members to call out impediments for the whole team rather than just for themselves.

One thing I did to help my team to more objectively identify impediments –  is create a “Definition of Impediment”.  This was posted just like the Definition of Ready and Done in the team room on the BVIR’s.  The Definition of Impediment is created the same way as the other two definitions – together as a team.  Some of the things we listed on our definition of impediment are:

  • If a task is taking more than estimated and that is due to waiting time on any person other that the team member – it is an impediment.
  • If someone outside the team needed to do something to complete a task and the team had been waiting for over 1 day  –  it is an impediment.
  • …

Each morning during standup,  each team member was asked to look at the Definition of Impediment prior to answering the question – ” Are there any impediments ?”.  Over the course of 2 sprints the team started becoming more accountable to themselves.  They would call out dependencies outside the team that risked becoming an impediments.  They would call  out dependencies that other team members were not willing to call out.  Realizing that estimating is a skill that will improve over time, the team dug into how there were estimating and why their estimates were unrealistic.

The Definition of Impediment helped them see beyond their current agile maturity and identify areas of opportunity to “Be More Agile”!!!