Requirements Tree: Focusing your efforts on the highest value work

Requirement is a nebulous term.  It can mean something large like a strategy, to smaller items like features, user stories, or tasks. People often throw around the word requirement without a strong sense of the type of requirement it is or the level it belongs. It is important for clarity and common understanding across organizations and teams. Otherwise, it can be quite confusing as to which level people are discussing. 

To gain this common understand of the various levels of requirement, I recommend starting by establishing a requirements tree.  It is a structure that represents the relative hierarchy amongst various requirements elements within your enterprise. It makes it clear how requirements levels are connected. For example, a feature is a requirements element that is at the larger than a user story, so I would expect to find multiple children (aka, user stories) to the build a feature.  Think of it as your requirements lineage. 

What are advantages of creating a requirements tree? First, it ensures that requirements elements at the lower level (aka., the children) are aligned to higher level and presumably high value requirements elements. This ensures that you are putting all of your company’s effort on the highest value work. Second, it helps you determine if there are random requirements that made their way in through a back door.  Third, the requirements tree provides context of the level of requirement being discussed and traceability in the hierarchy.  

What are the various requirements elements and hierarchy? There is no industry standard group in either and they can vary from enterprise to enterprise. The key is to establish yours.  I like to start with corporate strategy and end with tasks as illustrated in the figure. 

Once you establish the levels of your requirements tree, it is important to craft a definition to describe each level.  Using the requirement levels from the figure, here is how I describe each level.  A strategy sets  direction for the enterprise.  An idea is a high customer value and outcome-based opportunity.  An increment is an end-to-end slice of the idea to provide value and validate of the idea.  An epic is a function or feature.  A user story is a requirement that fits into a sprint of a week or two and has one persona.  A task is a very small unit of work that incrementally builds the user story. 

In addition, when you have the requirements tree and definitions of each level, you can align roles of who should be working on those levels with expectations and outcomes of each level. 

You may notice that instead of putting the strategy on top, I place it on the bottom.  I do this to represent the strategy as the trunk of the tree as this should provide guidance for how the smaller requirements elements (e.g., ideas, increments, epics, user stories, and tasks) should grow. While your strategy may adapt over time based on customer feedback and the changing marketplace, it should guide the type of work you may consider working on. 

The key to your requirements tree is for you to establish one that makes sense for the type of work you do.  For example, if you only have one division in your company, then a division strategy isn’t necessary.  You may also work with business requirements so place them in the right level for your tree. Those that may consider creating a requirements tree are a combination of executives, portfolio, product owners, and team members.  Once crafted, it should be shared with everyone for a common understanding and a way to validate that the work at the team level is aligned with the highest value work.

Note: For more information on the Requirements Tree, read Chapter 15 of the book "The Agile Enterprise". 

 

Rose Retrospective - A Rose by any other Name

Many Retrospectives in the Agile world tend to follow the “what went well”, “what problems did we encounter”, followed by actions for improvement. I call this the WWW (what went well) retrospective. While this serves as a practical retrospective, did you know that there is no one specific retrospective practice expected by Agile? The Agile principle only asks that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  Even Scrum is not specific.  Per the Scrum Guide, it suggests that a retrospective “is to plan ways to increase quality and effectiveness”.

If you are applying the “what went well” type of retrospective, would you like to experience something new, a more adventurous retrospective? Allow me to introduce you to “A Rose by any other Name” Retrospective or Rose Retrospective.  

This is a botanical approach that uses the parts of the rose to explore how things are going and what you can do to improve. The parts of the rose that we explore during this retrospective are the Flower, the, Thorn, and Bud. To put some color to these parts, here are some definitions:

• Flower: This highlights the positives, what you're happy about or what is going well for you or the team.
• Thorn: These are negative things that are impacting your work or life. It may be something that didn’t go your way, causing stress, impediments to success, or something that you’re not proud of. 
• Bud:  These are areas that have a potential to bloom or improve if we nurture and put some focus onto them. They have the potential of becoming a flower. 

How might you implement a Rose Retrospective?  Let’s step through the preparation and steps through conducting a retrospective. 

Prepare the space 

Whether a physical room or a virtual room, create a space to (e.g., white boards, etc.) to add Flower, Thorn, and Bud. 

Determine what cohort of people will participate. It is best to invite those that were actually engaged in the topic (e.g., the team that did the work).

Conduct the session 

Start by explaining the process of the Rose Retrospective and the meaning of the flower, thorn, and bud. Advise them on what they will be reflecting on (the recent sprint, project, time period, etc.). 

Begin with Flowers. Give everyone 5 minutes to brainstorm their flower(s). Everyone shares their flowers. This may include recent successes in delivery, relationships, and progress. You may use data as an input. The intent is boost morale and make people feel proud of their activities and progress. The result is to visualize as a bouquet of flowers on a rose bush.

Continue with Thorns. Give everyone 5 minutes to brainstorm their thorn(s).  Everyone shares their thorns with the intent is to share challenges. The result is to visualize the thorns of a rose bush. 

Finally, the group discusses the buds. Reviewing the Thorns, consider what can be improved and actions for improvement. Provide time to consider the root cause, brainstorm new ideas, and suggesting solutions. Also consider other ideas that may need a boost in areas that are ripe with infusing extra effort to turn the bud into a flower. Prioritize ideas and solutions and focus on the top 2 or 3 actions. The result is to visualize a group of buds that may blossom with some extra effort. 

Work on the actions 

Once the session is over, the next steps are to add the actions to your backlog of work, marking them as high priority. Then work on the actions to turn the buds into bouquets of flower. 

Exploring Five Pair Programming Techniques

A collaboration by Antonio González Sanchis and Mario Moreira

Extreme Programming (XP) introduced a programming technique that’s been famous since its early days: pair programming. It sounds simple, two people working together with the same computer. However, what people don’t know is that there are many ways in which you can approach this technique. Let’s explore a few:

Driver-navigator: This is the best known style of pairing. It consists of one person ‘driving’, taking the keyboard and coding or doing the work, while the other one is ‘navigating’. The Navigator’s job is to pay attention to the work being done by the driver while keeping the big picture in mind.  They should guide the driver in the right direction. It is very important that driver explains every decision they make, otherwise the navigator might lose interest and may stop paying attention. It’s healthy to switch roles every now and then.

Ping-Pong: For this approach you might need two keyboards connected to the same computer. In contrast to the driver-navigator mode, in ping-pong both people can be driving at any point in time. A good strategy for this approach is to have one person writing the tests while the other one tries to pass them. As in the previous approach, you should be switching roles often.

Backseat navigator: A typical approach when there’s a new team member in the group or a junior colleague. The navigator (usually the more senior team member) tells the driver, who has the keyboard, what to do to solve a problem with every little detail. The navigator should provide insights on how to solve the problem but also on why that’s the best solution in mind. It’s a good way to ramp up new members in your team as they build relationships with other people in the team while learning about the working style.

Tour: If there is an even number of team members or someone who you used to pair with went on holidays, you are not going to stop working. However, when those people return or you start pairing with someone, you don’t want them to start right away. Therefore, a good way to start would be to do a ‘tour’ through the code or work you did in their absence. The person who doesn’t know the most about the work takes the keyboard and the mouse and starts driving through the code while the ‘expert’ acts as a navigator and explains every detail.

Distributed pairing: Often people tend to think pairing is for collocated teams but that’s not entirely true. While pairing face-to-face is definitely much more effective than remotely, there are many tools and ways colleagues can pair. A good suggestion would be to use a videoconference messaging tool with a screen sharing app that allows the navigator to see in real time what the driver is doing.

These are not the only pairing styles that you might encounter but they are the best known.  They are also the easier techniques to try when you want to start pair programming. Also, examples seem to focus on software development but pairing is applicable to almost every field.  For example if you are in marketing and are launching an email campaign, you can pair with someone to navigate through the email while you write it, etc.

There might be anti-patterns when pairing. For example, you might find cases when the navigator is ‘sleeping’. This means the navigator can be checking emails, texting or even coding in parallel without paying much attention to the driver. Try to identify the root causes of this behaviour before you jump in into action. Usually it might be because the driver is not explaining properly the reasons why he is doing a specific task in a particular way.

Lastly, keep in mind that while pair programming may work in every role or department, it might not be suitable for every work. There will be times when you just want to discuss the approach with the team and go do it by yourself. That’s also a way of getting feedback, which in the end is the main purpose of pair programming: getting feedback early.  

If you are interested in trying pair programming, the first thing to do is review the list of possible techniques (above) and select one that you will experiment with.  Then identify your pair.  Brainstorm on how you might approach pair programming, specify how long you will try your experiment, and begin.  

------------

Learn more about Antonio González Sanchis at https://www.linkedin.com/in/antoniogonzalezsanchis/

Read more of Mario's article at: http://cmforagile.blogspot.com 

Building an AI and Agile Culture of Learning

Does your AI and Agile education begin and end with barely a touch of training?  A number of colleagues have told me that in their companies, training ranged from 1 hour to 1 day.  With this limited training, they were expected to implement and master the topic.  AI nor Agile isn’t simply a process or skill that can be memorized and applied. It is a culture shift. Will this suffice for a transformation toward AI and Agile?

Education is an investment in your people.  A shift in culture requires an incremental learning approach that spans time.  What works in one company doesn’t work in another. A learning culture should be an intrinsic part of your transformation that includes skills, roles, process, culture and behavior education with room to experience and experiment.

A transformation requires a shift toward a continuous learning culture which will give you wings to soar!  You need a combination of training, mentoring, coaching, experimenting, reflecting, and giving back. These education elements can help you become a learning enterprise.  Let's take a closer look at each:

Training is applied when an enterprise wants to build employee skills, educate employees in their role, or roll out a process. It is often event driven and a one-way transfer of knowledge. What was learned can be undone when you move back into your existing culture.

Coaching helps a team put the knowledge into action and lays the groundwork for transforming the culture. Coaching provides a two-way communication process so that questions can be asked along the way. A coach can help you course-correct and promote right behaviors for the culture you want.

Mentoring focuses on relationships and building confidence and self-awareness. The mentee invests time by proposing topics to be discussed with the mentor in the relationship. In this two-way communication, deep learning can occur.

Experimenting focuses on trying out the new skills, roles, and mindset in a real world setting.  This allows first-hand knowledge of what you’ve learned and allows for a better understanding of Agile.

Reflecting focuses on taking the time to consider what you learned whether it is a skill, process, role, or culture, and determine what you can do better and what else you need on your learning journey. 

Giving back occurs when the employee has gained enough knowledge, skills, experience, to start giving back to their community to make the learning circle complete. Helping others highlight a feeling of ownership to the transformation and the learning journey.

It takes a repertoire of educational elements to achieve a culture shift and becoming a Learning enterprise. When you have people willing to give back is when the learning enterprise has become full circle and your enterprise can soar.

-------------------

For more Agile related Learning and Education articles, consider reading:

• Agile Education Engine - Bringing power to your Agile Transformation - http://cmforagile.blogspot.com/2014/11/agile-education-engine-bringing-power.html
• There is no Success of Fail, only Learn - http://cmforagile.blogspot.com/2015/12/there-is-no-success-or-fail-only-learn.html
• How a Self-organizing Agile Education Vision can help your Agile Transformation - http://cmforagile.blogspot.com/2014/02/how-self-organizing-education-vision.html

Four Anti-Patterns impacting Customer Value

Value is in the eye of the beholder.  Smart people will say that the beholder is the customer. While in most companies there will be a similar saying to the “customer is king”, some have lost their way and have somehow forgotten the importance of customer and their feedback.  The result is organizational anti-patterns that impede successfully getting to customer value. There are a number of anti-patterns on why this occurs and below are four: 

• Known as Pretend Certainty anti-pattern, this is believing that you can pretend to know with certainty what the customer wants upfront.  The danger: the consequence of limiting options and being blind to customer feedback to shape product direction.  
• Known as No Room at the Innovation Inn anti-pattern, this is focusing primarily on driving efficiencies through cost cutting and high resource utilization.  The danger: the unintended consequence of a lesser focus on the customer with little room to innovate and adapt. 
• Known as Sub-Optimizing for Comfort anti-pattern, this is sub-optimizing for the comfort of having a well-established plan and set of well-defined processes.  The danger: the consequence of restricting change at the expense of adapting to customer needs.  
• Known as The Few and the Missing anti-pattern, this is engaging few to represent the whole.  The danger: the consequence of understanding customer pool, ignoring potential customers, and missing customer feedback to shape product direction. 

When you are a start up, you realize the importance of being customer value driven because if customers don’t buy the product, then your start-up goes under. Because of this and their small size, most start-ups will stay very close to the customer or potential customer.  When companies become larger, there is a greater chance these anti-patterns appear.  More process and more controls are often put into place and unfortunately this leads to restricting change.  A company may sub-optimize for their own processes and plans that distances them from their customers.  

The question is, do you see any of these anti-patterns within your organization that impact your ability to achieve customer value?  Avoid the poor “aim of the anti-pattern’.  Instead, engage with your customers and use their feedback to help you hit the customer value target!

For more information on the topic of Customer Value, consider reading the following articles:

• Dangers of Certainty in Realizing Customer Value
• How an Agile Customer Feedback Vision can lead to Customer Value