Dual Track Development

Are you building the right product? Are product discovery team members sharing what they’re learning with the rest of the development team? If you’re not sure, then maybe Dual Track is for you.

So, what is Dual Track? Simply put, Dual Track is about bringing light to product discovery by focusing on generating and validating product ideas for the team’s delivery backlog. It does this by bringing the product Discovery work into visibility.

You may be thinking like me, what’s the big deal? When we practice Scrum, we have the Product Owner work with stakeholders, including UX, to build a backlog. The problem is that they often do this work in a silo and only share their stories with delivery team members at Sprint Planning. If your team sees stories for the first time at Sprint Planning, it’s too late. So, in Dual Track, we have visibility into the work the PO and the discovery team members are doing, and this work is shared on a regular cadence with the rest of the team in refinement, or through team members working together.

Dual Track is nothing new. The original idea was published in 2007 by Desiree Sy, and Marty Cagan wrote about it in 2012. While there are many instances of writings about Dual Track, Jeff Patton and Marty Cagan are two of the most well-known advocates for what Marty has coined Dual Track Scrum. In its simplest form, Dual Track provides visibility and best practices to the discovery work that must occur before a team ever sees a user story. A good article to read more by Jeff Patton can be found here.

While researching Dual Track, I found that it fits nicely with what I believe the Product Owner, Business Analyst, and UX people on the team should be doing anyway. That is working with stakeholders and the team to discover the best product. Dual Track emphasizes team engagement and focuses on not letting people work in silos. It provides guidance and structure to ensure the entire team builds the right products at the right time, together as one team. So here is one of the first things I discovered about Dual Track – the team performs as one team. Read on to see what else I discovered.

One Team, One Backlog, One set of Scrum events

According to Jeff Patton, Dual Track is “just two parts of one process”. It focuses on maximizing the value delivery of your entire team by having discovery team members working a Sprint ahead of the development (delivery) team members and including them in the work.

This approach to embracing one team is important; as Jeff Patton says, “the whole team is responsible for product outcomes, not just on-time delivery”. When we keep the entire team engaged in product discovery, the developers, and testers will have more context, and they may also surprise us in ideation with great problem solutions. Finally, not all ideas in the backlog should be implemented, and developers can help Product Owners see where ideas will be problematic.

Jeff outlines how to incorporate the product design team members into each Scrum event without disruption. The team works as one, from the Daily Standup to the Sprint Retrospective. A benefit of following a Dual Track is better engagement from developers and faster learning.

Below is a good video link I found on how to set up a single backlog in Jira for Dual Track boards that enables teams to visualize the work they are doing in the two tracks:

Progress on both tracks happens simultaneously

The Discovery Track represents teamwork through product ideation via stakeholder interviews, developing personas and stories, and market research. Once complete, the discovery team members share their findings with the rest of the team. The design team members utilize design sprints to make progress on stories for Sprint N+1, while the development team members are working on Sprint N in delivery sprints. The output from product discovery becomes the input for product delivery. At the same time, feedback from product delivery informs product discovery.

Benefits of Dual Track

The Discovery Track is always a few steps ahead of the delivery team. This approach leads to:

• Better Products – Allowing only validated product ideas into the backlog leads to better products for your customers.
• Less Wasted Time – Breaking the barrier between product design and development means the whole team better understands what they are building, reducing the back-and-forth conversations that occur.
• Lower Development Costs- Teams will not pursue product features that haven’t been validated or are well-thought-out.

Summary

Dual Track increases the odds that you will deliver high-quality products that your customers will love.  It does this by bringing visibility to what Product Owners are doing to prepare for a Sprint. It requires high collaboration between the people responsible for ideation and the people responsible for development. If you decide to incorporate Dual Track and design Sprints, you’ll be in good company. Jake Knapp wrote about Google Ventures utilizing design Sprints, and now we have the likes of Uber, Slack, and Facebook embracing this way of working.

I like what I’ve read about Dual Track and hope I have piqued your curiosity.  I would love to hear about your experience with Dual Track if you have tried it.  Please feel free to share in the comments!

In today’s digital business landscape, businesses are looking for solutions to be more competitive. Some digital businesses have found the Scrum Framework to be that competitive edge with its foundation of empiricism. Empiricism uses knowledge based on experience to make decisions. Scrum framework empiricisms reflect in three pillars of transparency, inspection, and adaption. Scrum’s Evidence-Based Management (EBM) is an empirical approach that supports organizations in demonstrating business outcomes, organizational capabilities, and business results. In the simplest terms, the EBM helps organizations navigate through complex problems by intentional small steps and adapting through continuous feedback loops. (For more on complexity, see the Scrum Theory section of the Scrum Guide at https://www.scrumguides.org/scrum-guide.html)

Scrum’s Evidence-Based Measurement approach allows organizations to avoid traps like metrics turning into milestone deliveries or project task activities.  EBM offers an opportunity for the digital organization to experiment and move to their next step to value through these areas:

Key Value Areas – Unrealized value, Current Value, Time to Market, and Ability-to-Innovate.

Scrum.org, 2020

Let’s look at them and see if your organization might benefit from using them.

First Value Area – Current Value

What is the purpose?

The organization reflects on the current value they bring to the customers or stakeholders. It is in its current state. It is not a future state at all.

How does an organization identify it?

EBM shares this value indicating the happiness of customers, stakeholders, and employees.

It can be very simple: measure how happy the customers, stakeholders, and employees are. Is their happiness up or down? The important aspect here is to get a baseline and then, at regular intervals check-in that the current state is moving towards the desired state.

Potential examples:

Second Value Area – Unrealized Value:

What is the purpose?

The organization reflects on what future value they could provide to their customers, stakeholders, or employees. Based on the current value, what is the difference? That difference is the potential unrealized value.

How does an organization identify it?

EBM shares this value is about understanding ALL the desired needs or future state that our customers, stakeholders, and employees would like to have to be very, very happy. It allows the organization to evaluate where finances are being expended.

Potential examples:

Third Value Area – Time to Market:

What is the purpose?

The organization determines how quickly it can deliver something new to its customers or stakeholders.

How does an organization identify it?

EBM shares this value is about understanding how the organization does things, how the organization learns, and how quickly the organization applies what they learned.

Potential examples:

Fourth Value Area – Ability to Innovate:

What is the purpose?

The organization determines how good they are at developing new ideas that might deliver value to meet customer needs.

How does an organization identify it?

EBM shares the ability to innovate the organization by looking for blockers and dependencies and addressing them. What are the “gotchas” that prevent customers from being happy about the delivered solution?

Potential examples:

Gathering the information for EBM’s 4 values provides the organization with a baseline and is a great first step.   However, the biggest secret to success the Scrum’s Evidence-Based Measurement guidance offers is to be intentional with small steps of change to move the needle in each of the four value areas. EBM supports using the PDCA model derived by W. Edwards Deming to accomplish this.

https://deming.org/explore/pdsa/, n.d.

Deming’s approach is built on:

Plan: What is the organization trying to do? (What is the problem they are trying to solve?)

Do: What are the intentional, time-boxed steps the organization will use to solve it?

Check: What are the outcomes?

Act: If the outcomes are great, then continue with that process. If the outcomes are not as expected, what changes does the organization make?

Scrum’s EBM guidance has been applied in various industries.

In one great case study, a Real-Estate Software Provider shared that after one year of using the EBM, the company had its’ largest revenue growth in over 10 years. Its success was also reflected in its EBITDA and Net Promoter score.

Scrum.org, 2018

This case study is only one example. Has your organization used this approach? If so, what were your results?

Appendix:
The sample below shares an approach that might be synthesized from the Scrum Evidence-Based Measurement.

Metrics are vital to a team. They give us a starting point, just like choosing “my location” on your GPS. Then metrics tell us where we are headed. They help us know whether our team is winning at continuous improvement. They tell us how our journey is going, and where we might be off course.

The stability of metrics demonstrates that teams are predictable and can forecast future work. Many times, it is a combination of metrics that give us the real picture though.

One measure that can demonstrate a team’s stability is velocity. A team made up of dedicated members should have a stable velocity over time, which helps them better determine how much work to commit for a given sprint. So, measuring velocity over a number of sprints is a great Scrum metric. You might think that a rising velocity is good. However, a rising velocity along with rising escaped metrics tells us we haven’t reliably sped up at all. In fact, if escaped defects are rising, we need to fix something else in our process. We may need to slow back down. In contrast, a rising velocity and a decreasing or stable number of escaped defects would be a good team goal.

Another metric for a Scrum team is Committed vs Delivered %. Rather than just focusing on velocity, add a measure of Committed vs Delivered for velocity to see how your team is doing at being predictable. Teams that frequently have a low percentage of Committed to Delivered are committing to too much work in the sprint. If this is happening to your team, it is time to figure out why. Sometimes, we will know exactly what has impacted our metrics, while other times we may need to have a retrospective to discuss why. Escaped defects are important to consider, as a high percent Committed to Delivered is good, lots of rework is not.

While Velocity and Committed vs Delivered % are end-of-sprint metrics, throughout the sprint, a team’s burndown gives us a view into progress during the sprint. It’s important to look at a team’s burndown every day to assess whether the team is likely to complete all the work they committed to. Burn-down gives us the point-in-time view of the work to be completed within the sprint. If the remaining work is far above the ideal burndown line, we may need to have a conversation with the Product Owner about stories that won’t be completed. On the other hand, if the burndown is far below the ideal line, we may be able to bring another story into the sprint.

Some teams go a step further and measure Cycle Time for stories. Cycle Time starts when a team member starts work on the story and continues until the story is moved all the way to the team’s done column. Cycle time can help us determine if we are right-sizing our stories. For Scrum, stories are right-sized to just a couple of days of work or less. If Cycle Time for stories is extending well past a couple of days, you may need to try and break your work down into smaller pieces.

Using a combination of metrics and charts for a Scrum team can help the Scrum team spot problems and see if their experiments are working. These internal team metrics are just the start and give an even fuller picture when customer outcome metrics are added, but that is a topic for another post. Do not let your team meander along. Get them metrics to see where they are and where they are heading.

In the first installment of our Product Owner Empowerment series, we talked about the three crucial dimensions of knowledge that a Product Owner’s effectiveness is measured on. We looked at how various aspects of empathy influence a Product Owner’s ability to connect with the team, client and organization in our second post. In our third and final post in this series, we are going to look at the impact that psychological safety has on a Product Owner’s success.

Psychological Safety: Psychological safety is a state of mind and a cultural aspect that is created and fostered by someone or something other than the subject themselves. When people in the organization are afraid to make difficult choices and shy away from having tough conversations, it is generally due to a lack of psychological safety. Various factors contribute to how safe people feel psychologically in an organization. Empathy, as discussed above, at all levels plays a big role in this. If the culture, in general, is more empathetic, there will be a higher level of psychological safety. However, it is not the only factor. Let’s dig a little deeper on this factor and see how PO’s success is tied to psychological safety for themselves and the teams they are working with.

• Psychological Safety for Teams: In the case of teams, it is usually the leaders that are responsible for ensuring that team members feel psychologically safe to work in challenging situations with often unpredictable outcomes. Agile requires teams to be flexible and collaborative in their approach to address the ‘just-in-time’ nature of work. Innovation, exploration, and taking risks is a necessity to succeed in such an environment. This comes with the possibility of teams running into occasional failures that should be treated as learning opportunities. But, if the organizational culture is not forgiving of failures, it leads to teams not feeling safe enough to take the risks and challenges they may need to, to optimize value delivery. Leaders should actively address the topic of psychological safety and ensure that they foster a culture that encourages innovation and taking calculated risks.
• Psychological Safety for the Product Owner: The Product Owner is in a unique position having a tremendous influence on a team’s psychological safety, but in turn, are equally or proportionally affected by the psychological safety afforded to them by their leadership. A Product Owner who is well engaged with the team will need to make decisions regarding priority, scope, and timelines. An empowered Product Owner will be able to make such decisions with appropriate communication, keeping the team working at a sustainable pace. However, we often see organizations where such pivots must go through multiple levels of approvals, often surrounded by process constraints and red tape. This causes the organization to see change as undesirable and anyone bringing the change is viewed as the bearer of bad news.

Having leadership that welcomes change, is key to providing psychological safety to the Product Owner and the team. It is not sufficient for leadership to merely say that they support and welcome change. They need to look at systemic and cultural aspects of the organization that might be working against this mindset and actively work to realign them to an Agile way of working. It may not be the norm in some organizations to have leadership unsupportive of change, but a delay in the ability to pivot can lead to periods of unsustainable workload on the team while the Product Owner is negotiating upwards. To truly support psychological safety, allowing for making difficult choices and having tough conversations, organizations need to embrace decentralization decision making and empower the Product Owner and teams as much as possible.

Conclusion:
I hope you enjoyed this series. Throughout these three posts, we explored various factors that impact the ability of a Product Owner to work effectively in their role and serve the purpose they are meant to. They must be empowered with knowledge of not just the business domain, but also the delivery and process knowledge to successfully operate in the organizational context. Empathy at different levels of the organization and towards the customer, whether they are internal or external, is crucial to move the product in the right direction. Psychological safety is often an unmeasurable and underlying factor that should be proactively managed by leadership and ingrained in the culture and processes of the organization to truly empower their Product Owners.

As a final thought, if you’ve enjoyed this series or have additional questions on how to truly empower your Product Owners, join me for a FREE webinar on Product Owner Empowerment. We have a few seats available (on a first-come basis) and invite you to register today.

The Product Owner plays a crucial role in the success of a team and subsequently the organization. Most organizations consider the Product Owner to be a person with sufficient business knowledge such that they can communicate the business needs to the teams for implementation. While this is an important qualifier for a Product Owner, other factors must be present to have a truly empowered Product Owner.

The following 3 factors have the biggest impact on a Product Owner’s ability to succeed:

1. Knowledge
2. Empathy
3. Psychological Safety

These factors are not just applicable to the Product Owner, but also the surrounding environment. This includes the organization, processes, culture, teams, the product itself, stakeholders, and customers. Let us dig a little deeper.

In this post, we are going to focus on the first influencer: Knowledge. Next week, we’ll take a deeper dive into the impact Empathy has on a Product Owner’s ability to succeed, and we’ll round out the series with defining Psychological Safety and looking at the effect it has on a Product Owner.

Knowledge: The knowledge aspect is the most obvious and widely analyzed and assessed factor to evaluate the effectiveness of a Product Owner. However, there are several dimensions of knowledge that are required.

• Domain Knowledge: This dimension doesn’t need explaining and is probably the most obvious one of all. The Product Owner must have a good understanding of the domain they are working in, to effectively lead product development. While it may seem comfortable to assume that industry-wide it is common practice to have Product Owners with sufficient domain knowledge, some Agile antipatterns have led to the emergence of roles such as proxy Product Owner, or technical Product Owner. The primary culprit for organizations gravitating to this antipattern is a lack of understanding of the Product Owner’s role. Organizations assume that as long as there is a communication path to transfer the business needs to the teams, it is ok to have layers between the customer and the team. This creates dysfunction in Agile teams that are supposed to collaborate with the Product Owner in discovering and delivering value, but don’t have an empowered Product Owner who can make decisions and pivot when needed effectively.
•  Process Knowledge: When it comes to a PO having knowledge and understanding of the Agile approach, best practices, and antipatterns usually takes a back seat. To clarify, we are not talking about just having your PO take a 2-day certification class and call it a day. Yes, it is necessary to have formal learning as part of role development, but, the learning should not remain at this minimal level. An effective Product Owner should have lived the process, learned from the challenges, successes, and failures, so they understand what it takes to deliver the product they are helping build
• Knowledge of PO role across in the organization: We talked about knowledge that a PO should have, but, to have a truly empowered Product Owner, an organization needs to know what to do with such a role. As mentioned before, a Product Owner role is different from a mere subject matter expert. To empower a Product Owner to make decisions, the organizational stakeholders need to understand how the Product Owner role works in an Agile context. Product Owners are not only the primary source of information on business needs for the team but are also one of the key roles influencing the pace of value delivery.

If the organization doesn’t understand what it takes for an Agile team to receive business needs Just-in-Time, iterate on requirements, let design emerge, deliver value and allow for slack time and innovation, It will make a Product Owner’s job quite difficult if they are still held to traditional expectations from leadership. These expectations may include providing inflexible delivery commitments, obtaining buy-in from a myriad of stakeholders before any scope changes are made, or worst of all, ensuring maximized utilization from the team. The organization’s stakeholders must be trained and knowledgeable about the basics of Agile if they are new to this way of working. Additionally, leadership must know the common pitfalls, assumptions, and antipatterns that organizations fall into and actively work to avoid or mitigate them.

If you are a Product Owner or your Agile team struggles with this role, join me for a free webinar on Product Owner Empowerment. This webinar will be held on December 12th and you can register here! Space is limited and on a first-come basis.

In Scrum, the User Story represents the main item in the Product Backlog. However, it is not the only item in the backlog. So let’s take a look at other items in the Product Backlog.

According to the Scrum Guide, “The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.”

For the purpose of simplicity, we group the backlog into four types of items:

1. User Stories
2. Technical Stories
3. Spikes
4. Defects

Let’s take a look at each type of item.

User Story
Written in the format: As a Type of User, I Want to do something, So that why do I want it. User stories are not complete without Acceptance Criteria and a discussion with the team to gain the full requirements of the story. User stories cover features, functions, enhancements, and epics. Typical guidance is that a user story can be completed in 2 days or less, while some experts say the work of the team on a story may last up to a week. Whether you call large User Stories epics, themes, or features may depend on what tool you are using, or how you were trained. User Stories originate from XP where any large story needing to be broken down was called an Epic. As these large stories were broken down, we could actually tear up the Epic as it was being replace with multiple smaller stories. Product Owners may not have the skills to break stories down as small as they need to be for a Sprint. This is where the team comes in during grooming/refinement to help break down stories and discover gaps. Our tools (Version One, Rally, Jira, etc) allow us to maintain a parent child relationship using the labels like Epic, Theme, or Feature.

For tips on writing user stories check out this link.

User Stories can be written by anyone. They are often written during user story workshops where the team and stakeholders are together brainstorming user actions and system needs. The goal of the Product Owner is to thoroughly understand stakeholders needs in order to create and explain the User Stories in the backlog. For me, the PO or their surrogate are the main writers of user stories for end user applications. PO’s are the ones that will typically be engaging stakeholders. So while they may get some help in writing the stories, they are still the ones accountable for ensuring complete understanding, and to accept the story as the work is completed.

Technical Stories
Technical Stories represent any technical work the team must undertake during a sprint. While it is possible to use the typical user story format by identifying ‘the who’ as something that isn’t really a person, like “System X”. However, I ask teams I’m working with: is there any value in writing Technical stories in this format? For me, where there is no benefit, there is no reason to write technical stories in the user story format. A simple statement will work, e.g. “upgrade test tool”. While the format of a user story isn’t needed, it is still important to include acceptance criteria. Team members typically write these stories, and let the PO know where in the backlog they should sit in order to be completed in a timely manner, often as a predecessor to doing other user stories.

For more on writing Technical Stories look here check out what Mike Cohn says about using the FDD format here.

Spikes
Spikes are done for knowledge acquisition. Spikes should be time-boxed, and have specific acceptance criteria. A team member may ask for a spike in order to do some research, proof-of-concept, or prototyping to gain knowledge prior to working on a set of user stories. There is no reason to write spike in user story format. The maximum duration for a Spike is the length of a sprint. Another attribute of Spikes, is that they should be the exception and not the rule.

For more on Spikes see this article.

Defects
As users work with the system, and testers test the system, bugs or other defects may be found. For me, these are not the same as rejecting a current user story because it fails testing. User Stories that fail testing are rejected and reworked within the sprint if time allows. If time doesn’t allow, the PO can decide if the story will be in the next sprint or not, and the team will not get points for the story until it passes test.

As other defects or bugs are found in the system new user stories are written to identify the desired functionality. The PO will stack rank these PBI’s along with all other stories.

Many times I have seen newly formed or new to Agile teams and organizations moving from Scrum and/or Kanban to eventually settling for Scrumban as they mature. As I reflect on these teams that I have worked with, I feel that their ultimate form of Scrumban is probably their own kind of Shu-Ha-Ri progression.

Shu Ha Ri is a Japanese martial art concept, and describes the stages of learning to mastery.

Shu – the student copies the teacher’s moves as perfectly as possible. The teacher corrects the student if the movement is imperfect, inefficient, or ineffectively performed.

Ha – In this stage, the student understands the principles well enough to depart from rigid practices. The student experiments and makes observations of the new techniques. The newly emerged techniques become his own.

Ri – stage, the student has reached a point of mastery and is able to teach and to adapt to new situations easily.

Shu – the journey begins
Teams and organizations new to Agile and in infant stages of Agile transformation start off as being Scrum .They start following all the Scrum practices, conforming to the roles of the Scrum and they kind of follow the prescriptive form of Agile, or Scrum which makes sense. Installing a basic set of proven Agile practices by force can start yielding quick benefits for the organizations, letting them see how the new methodology leads to working faster and delivering the value out to the customer quicker. It kind of builds confidence at the team level too. The teams and the organization are both at the Shu level.

The team keeps having the daily scrums, planning sessions, locking the sprint, reviews and retrospectives in a prescribed manner till it becomes muscle memory.

When a team produces consistent results using rigid methods, they have completed their Shu stage.

As an Organization, these successful practices are also replicated to other areas to see the benefits in the other parts of organization.

Ha – adjusting the sails
With each retrospective and in the spirit of constant improvement, they change the practices to what make sense for their own unique solution. Teams start to feel maybe Scrum isn’t the right way for what they are doing.

Some teams don’t want to be restricted by the lock down of sprint commitment and want to be able to pull their work. Some of the teams want to move away from the planning session or role demarcation but still like the way certain things worked in Scrum and start to work on what is the “Ha’ phase. In the Ha stage, teams often will start to innovate their processes and the way they design their software. They may adopt new methods and tools in dealing with each other. Retrospectives are the key in the Ha stage to gauge the effect of the newly formed processes: are they helping the team or taking them back into the post Scrum era.

The Ha stage will include some successes and some failures, but it will be a learning experiment and the team will be wiser and mature with each of these experiments.

As an Organization starts doing Scrum in various teams and divisions, it becomes clear that one size doesn’t work for all aspects of the software development, and some prescriptive processes which work for majority of teams clearly need more refinement or customization to work for the other teams. This is the organization getting into the ‘HA’ phase. This can be extremely useful for existing Scrum teams looking to improve their scale or capability.

What the discovery leads to is Scrumban, an Agile management methodology that is hybrid of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban.

Scrumban is a pull-based system, where the team no longer plans out the work that is committed to during the planning, instead continuously grooming the backlog. The same Scrum meetings (planning, review, and retrospective) can still take place, but the cadence of them can be more context-driven. The main emphasis is on limiting the work in progress (WIP).

With Scrumban, a team benefits from the prescriptive nature of Scrum while the process improvement of Kanban allows their process capability to continuously improve (kaizen) , reducing the waste and simplifying the way they work. In all of this they develop something new and unique to the team and hence get to the “Ri’ stage.

Ri – losing sight of the shore
At the Ri stage of an Agile transition, the team becomes capable of abandoning rules and strict forms while increasing the productivity and customer experience. They can produce quality work, with the rule or methodology of their own.

As an Organization, it might be a new flavor of Methodology which works best for the company itself.

When an organization decides they want to “Go Agile”, they usually go through a multitude of changes before they get into a rhythm of the method(s) they have decided to use.  Once a team gets into a rhythm of ‘going’, or just doing, they will most likely be so engrossed that they forget to look up and see where they are.  However, it is important that they stop at some point to examine how things are going overall in their Agile journey and whether or not their method(s) are working for them.

The most popular framework that teams choose when first moving toward being Agile is Scrum.  In order for a team to really grasp the idea of sprints and incremental development, they will need to do a number of sprints before stopping to examine themselves; one sprint does not give the full feel for the changes and mindset shift that occurs.  Whether they stop after 4 sprints or after 10 sprints, the team will usually feel one of two ways:  “Scrum seems to be working for us; let’s keep it up, using continuous improvement to get better, and examine again in another few sprints” or “this doesn’t seem to be working; let’s forget Scrum and just do the work”.

When a team feels that Scrum is working for them, they have usually tweaked the framework a bit to allow for their team to feel they are abiding by the Agile Manifesto the best they can to ensure value.  As teams work together, they will tend to work toward continuous improvement and look for ways to work with the customer to ensure their satisfaction.  They will strive to continue to tweak their process to be successful in being Agile.  This type of team is most likely tightknit and feels good in the rhythm they have gotten into—so much so that they may not want to stop to examine, but realize they need to.

The other feeling that comes out is the aforementioned “this doesn’t seem to be working; let’s forget Scrum and just do the work”.  When a team has been doing Scrum for a while and they take stock of where they are, they sometimes conclude that Scrum is more work than they want to expend.  They can see the ceremonies as too much time wasted or that the timebox simply doesn’t fit their needs.  When this happens, they typically chose to abandon the framework and simply ‘work’.  They could just leave Scrum behind and choose a different method to become more Agile, but usually that is not the case because they have come to believe that the road to Agile is the problem; not its implementation of the method or framework.  When the team abandons Scrum, they don’t just abandon the sessions, like sprint planning or retrospectives, they tend to abandon the mindset that being Agile instills.  As they move away from Scrum, they also are likely to shy away from concentrating on the customer and the value they can provide to the customer, which is the core of the ‘Agile way’.  They see the ‘failure of Scrum’ as ‘failure of Agile’ because somewhere along the way, they have equated the two: Scrum = Agile and Agile = Scrum.

As the team ‘does what they want’ and does not follow any Agile methodology, they can easily fall into the trap of ignoring the customer’s wants and needs to the point of missing the mark.  When this happens, we have to examine why the team chose to move toward Agile in the first place:  to deliver what is really needed/wanted and not just what is listed.  If they don’t feel Scrum is working, the team will have a tendency to focus on what they want to do and stuff they find easy. In the end, the product is not what the customer is looking for; there tends to be wasted effort and time.  This wasted effort then results in many other issues with the project/product like not meeting dates, going over budget, risking the cancellation of the project/product, etc.

With all this said, it is not every team that reverts to ‘just working the list’; some simply find other avenues to be Agile other than that of Scrum.  These are the teams that understand that Scrum is maybe not for them, but understand that their attempt to be Agile is not the problem.  These teams usually find a way to move to other methods more suitable, such as Feature Driven Development, Extreme Programming, or even Kanban.

It’s important to remember that the point is to take time and examine what it is that is working, or not working, overall.  Most teams do this at the retrospective, but that should be focused on the team and the sprint.  There should be a time when teams do a more encompassing retrospective that looks at the process as a whole, which would look at things like release planning and working with other teams in the organization.  It is crucial that they take stock of what is working and what is not so they feel empowered to make changes to be as Agile as they can be!

I get this question a lot. And I ask back “What business problems are you trying to solve?” Each method has great potential when applied within the right context. If you are already using one of them, it doesn’t mean that you can’t use practices from the other. You should adopt any practice that enhances your current toolset for solving business challenges.

Here is a good article that takes a pragmatic approach on how each one of the methods can be used based on what is best for your customers: What is Best, Scrum or Kanban? – http://www.agileconnection.com/article/what-best-scrum-or-kanban

CC Pace provides a variety of Agile services, and we can help you build your toolset as your business needs change. This blog site is a great forum to ask methodology related questions. What do you want to learn more about?

When our yacht club saw membership dropping and was looking for a change, I called our Chairmen of the Board and suggested… a Kanban board.

Lucky for me, our Chairmen works in software for a well know online travel site. He knew just what I was talking about. After a short discussion, we decided to introduce the ideas of Scrum to the board. At our next Board of Directors (BoD) meeting I turned up, white board and 3 x 5 cards in hand.

Together we introduced the BoD to the idea of using a Scrum board to track our work. We started by brainstorming ideas in two key categories supporting the club’s 2015 goal of Membership retention and growth. Our two categories are membership activities and building improvements. After creating quite a backlog for the club, we discussed priority, and arrived at a commitment to working on a subset of the backlog for the upcoming sprint. Our sprint cycle was easy to determine as there are two meetings a month at the club, providing approximately 2 weeks in between each meeting. Board members signed up for stories listed in the backlog to get us off and running. At our general membership meeting, the visual board with our sprint and “product” backlog were introduced to the club.

Being “Agile” is a way of thinking. Core ideas like transparency, prioritizing, and collaboration can be incorporated into our everyday lives. I often suggest using a visual board for household chores when I’m doing training. No more nagging your partner, or kids. Just keep a board with 3×5 cards or post-its to identify upcoming work. Identify priority, acceptance criteria, and limit your work in progress by identifying a sprint length (one – two weeks work well). This helps to keep from feeling overwhelmed. Everyone is happier knowing what is expected. I’ve tried this at home with good success which is what led me to suggesting this for our club.

In taking these same principles and applying them to our club, we’re able to benefit from being Agile. The club members are our customers. They get visibility and input into the work being done. Members can make suggestions for new work, and volunteer to help. The club’s budget helps identify what can be afforded, and expected ROI helps us prioritize. Our initial work is underway, and I look forward to seeing our long-term projects lead us to sustaining and even growing our membership.

Have you ever wondered exactly what types of things a team does during a Sprint or what they should be doing? A team usually has one thing on their mind during a Sprint: “complete our commitment”! However, there is a bit more wrapped in that commitment getting completed which the team needs to consider.

Something teams use to know if they complete their commitment is a Definition of Done. As a team develops their Definition of Done, they assume certain things, which frequently center on the most obvious like coding and testing, will be completed during the Sprint and base the Definition of Done on those. Nevertheless, there is much more that should be considered for the Sprint. By using what I call “The Sprint Bubble” as a guide, a team can construct their Definition of Done to ensure they do everything they need to do in order to complete their commitment.

In addition, by using the Definition of Done as a guide, the team will be much more comfortable with what they expect to complete during the Sprint and will identify things which should not be done. It is worth reviewing those as the team builds the Definition of Done as well.

A lot of teams think the Sprint is nothing more than a ‘mini-waterfall’-type timebox; which is not the case at all! While there are many things which go on during the Sprint, they are absolutely not done in a ‘mini-waterfall’ style. Using “The Sprint Bubble” (shown below), you can more easily identify the things that have a place, or not, in the Sprint. I like using the MoSCoW-based categories—“Musts”, “Shoulds”, “Coulds”, and “Won’ts”—to explain. These things, regardless of category, are simply a way to construct the Definition of Done. There are times when you may have a bit of order to be followed, but these things just need to be completed.

First, let’s look at the “Musts” that belong in “The Sprint Bubble”. The most obvious things are develop and test code. However, given that testing is usually broken out into multiple different types—unit, integration, functional, story, system integration, performance, user acceptance, and so on—there will be some that may fall into other categories. With that in mind, the unit testing and functional testing would be a must because they help to ensure the stories are completed and functioning correctly. Also, many teams are moving more toward story testing (also referred to as acceptance testing), which is defined as testing around each and every story to ensure it meets the acceptance criteria of that story. When teams are doing this style of testing, it is also considered a must. Another must is integration testing; teams need to ensure their pieces work together and integrate well in order to make sure the entire product works well.

What about things like design or user interface components? These would be categorized as “Shoulds”. Before we talk about what things are categorized as shoulds, what does it mean to be a should—well, it means that it is something that belongs in the Sprint, but will not necessarily cause a ‘break’ in the application that’s being built or overall Scrum framework if it’s not. A lot of what you find categorized as shoulds are designated as other teams’, or organizations’, responsibilities in larger companies but would be musts in companies that don’t have these other teams or organizations. When you have a company without these other types of teams, design or user interface components should be done inside the Sprint and be part of the team’s Definition of Done. When a company has a different team or organization that does these types of things, they may decide these things are to be done and approved prior to the story being put into a Sprint. The one thing that many teams seem to forget is documentation. Documentation is a should, and therefore belongs in the Sprint, which helps to ensure it never gets overlooked. Another thing that would count as a should is that of system integration testing. System integration testing is very important to the overall product and is required to ensure the newly created product plays well with what the organization already has in place.

That brings us to “Coulds”. There is some easy stuff that could be put into a Sprint based on the company and the ability to do it in the timebox. Coulds are things that some may argue belong in the shoulds, but the way the organization is organized or the way the environments are set up may more appropriately put them in could. Probably the most popular detail that falls into coulds is user acceptance testing. This is something that seems to have the most problem being put into a Sprint due to the amount of time that the UA testers can lend to the Sprint timeframe or environment setup. If you have none of these kinds of restrictions, the user acceptance testing can most definitely go into the Sprint and therefore will allow for a release to production after the Sprint. Performance testing is another could, but will also be done in bits as other types of testing are performed (another topic for another day). I try to have performance testing be more a should than a could, but again relies on how the organization and its environments are set up.

Well, now we are at the “Won’ts”. A few things definitely do not belong inside a Sprint and need to be defined as such. One of these is defining acceptance criteria for the stories already in the Sprint. If you do not have acceptance criteria on a story, then the story is not eligible to be put into the Sprint in the first place. Another is defining a story to work in the current Sprint. If a story is not well understood, it cannot be accurately estimated, which also means it cannot be worked properly and cannot be put into the current Sprint.

Hopefully by better understanding what work is part of a Sprint, a team’s Definition of Done can be better constructed and followed. By using “The Sprint Bubble” as a guide, it helps the team solidify what should be part of their Definition of Done based on their environment and company policies. Having a solid Definition of Done means the team can ensure they are producing the highest quality of a valued product at the end of each Sprint.

In a previous blog, “The Reality of T.E.A.M”, I talked about Agile teams being dedicated, or part of a ‘permanent’ team that focuses on a single solution and remains together over time.  Another big factor of an Agile team is that they are cross-functional in nature.

What is a Cross Functional Team?    
When the topic of cross-functional teams comes up, there seems to be varying opinions that come out.  What does it mean when I refer to teams being cross-functional?  Does everyone on the team have to be able to do every job?  Do all team members have to know every detail of everything that goes on inside the team?  Does the team have to ensure that they can complete their solution?  Let’s look at what cross-functional means for Agile teams that I work with.

If you want to define it, you will most likely find that it means something like “a group of people with different functional specialties or multidisciplinary skills, responsible for carrying out all phases of a program or project from start to finish.”[1]  If you stick with this definition, you may find that you do not have to have a team where everyone on the team knows how to do every job on a team, but more that it is meant to keep members focused more on their role in moving the product forward than on their title.

Now that you’re on a Cross Functional Team
When the members of a team hear they are to be cross-functional, I’ve seen them get a little uneasy thinking they have to become something they may not want to be or learn to do things they don’t want to do.  I call this their ‘mini identity crisis’ because these team members are so centered around their title defining what they are supposed to do, they lose sight of what it means to be a team.

Team members will hopefully come to understand that becoming part of a cross-functional team means they will be focusing more on their role as a team member than on what their title is on their HR file.  Being a cross-functional team member is about ensuring you chip in whenever necessary and do as much as you can to ensure the solution is complete, and as good and valuable as it can be.

It’s not necessarily important that all team members know how to do everything, but it is important they work together, embracing common Agile principles from the Agile Manifesto and Principles, as well as principles that are found in Agile methods, such as “’Collective Code Ownership’ in Extreme Programming, which ensures the entire team owns the code and ‘Self-Organization’ in Scrum, where the team organizes themselves to get the job done.

Where does an Agile Coach fit in?
When coaching cross functional teams, I try to support and help them understand they won’t be losing their identity, but they are going to become part of a larger solution.  I emphasize that they’re not ‘against each other’, or ‘apart from each other’, but ‘for each other’.  I’ve found it’s important for team members to communicate and collaborate so they feel like part of a team instead of a pool of resources thrown together and asked to feel and behave like a team.

For all you sports fans—A Sports Analogy
Cross-functional teams remind me of football teams.  In football, there are multiple positions, both on the offense and on the defense.  While each member of a football team is most likely drafted onto the team to play a specific position, such as protecting the quarterback, the skills they possess for that position may also translate to other positions on the team.  For example, the player that protects the quarterback can use those same skills to get around the protection of the other team’s quarterback and sack him.  Just like a football team has players who are able to move to different positions in order to win the game, Agile teams use the same idea to produce the best possible solution!

Have you ever wanted to learn a new sport? Cricket, Golf or Rugby?

Where would you start? You may say, well I would find a coach. Maybe, you would consider reading a book, or watching a video, i.e. training!

So You want to learn a New Skill
Let’s use golf as an example.

If you’ve never seen a set of golf clubs, reviewed the rules of play, or know what a golf course really looks like, how will you learn to play? If you haven’t had any training, and you hire a coach, they will give you training. Coaches can’t help you improve your game until you understand the basics. If you’ve had training, a coach can help you incorporate what you’ve learned and give you pointers to help your game.

Training Lays the Foundation
Let’s introduce you to the course. It is played over 9 or 18 holes (sprints). The goal is to have the lowest number of swings possible (inverse velocity) while trying to get the golf ball from the tee into the hole. Holes differ from par 3’s to par 5’s. To move the ball from the tee to the hole, clubs are used. Clubs are grouped together by their primary use. There are drivers, irons, wedges, and putters. Once you’ve been trained on the basics of maneuvering through the course and using clubs, you can get out on the course. You practice, and practice, but your score is not what you want. You need “continuous improvement” to improve your score. This is where coaching comes in.

As Agile trainers, we like to get to know your organization. What are your goals and objectives of training? Are we introducing something new to your teams? Through learning about your organization, we can tailor our training specifically to your teams. Trainers can better provide a pragmatic approach by learning the big picture (how big and what type of golf course are we working with). Spend a little time up front with trainers to determine exactly what your needs are. Then rather than having them provide “out-of-the-box” or “by-the-book” training, you will get a customized approach that enables your teams to get the most out of training. Your teams will be introduced to Agile (the big golf course), its various roles (clubs) and ceremonies (swings). Together the organization will engage on a journey to establish best practices to enable organizational success through Agile methods.

Coaching Helps You Improve
Coaches look at what you are doing. Do you have the right clubs? Are you selecting the right course for your play? Are you holding the clubs correctly? Coaches can help make sure you do not fall into bad habits. They can also help you to avoid or get out of sand traps. Coaches point out if you’re lifting your head during a swing, if your feet are positioned too close together, or if you are using the wrong club. They give you suggestions to try, and let you practice a bit more. If you don’t take any of their “suggestions”, improvement may only come from you working harder and harder to get to the hole. If you take their suggestions, your score will undoubtedly improve. In fact, the objective is to show continuous improvement. A golf coach may not only watch your swings at a range, but may play a few rounds with you. This helps them see the big picture of your play rather than just how you approach a par 3, specific lie or a long put. If gaps in your knowledge appear during full play, a coach may have to act as a trainer or suggest training.

As Agile coaches begin an engagement, they often want to assess where everyone is at in their use of their chosen Agile method. How much training has the team/organization participated in? How is practice going? Coaches do this by observing, asking questions, and participating with teams throughout a given time period. Within Scrum, a coach will follow you through sprints. Within the sprints, Scrum has many ceremonies to navigate where a coach’s impact can be seen. Observing how the team works together, and how well the team executes each ceremony allows a coach to provide feedback for improvement. An Agile coach may encourage the team to step out of their comfort zone trying something new. They may suggest teams engage roles a bit differently both inside the team and across other parts of the organization. A coach can help you review your results, and pick something to improve each iteration. Coaches work with specific individuals on improvements they can make, as well as working with the team as a whole. Some basics outputs of coaching will likely include:

• Establishing a cadence
• Standardizing Agendas for Scrum Ceremonies
• Clarifying roles, and helping team members perform within those roles
• Identifying and improving your velocity
• Establishing an environment for continuous improvement

Use Both to be Your Best
Just as in golf, where training and coaching gives you the foundations for play and then helps you reduce your overall score, Agile training and coaching gives you the foundations for Agile and then helps you increase your velocity. So invite your trainers and coaches on your journey to improving your Agile game. Your organization will thank you with more frequent delivery of working software.

As discussed in the first post in this series Agile in the Federal Government – Going, Going, Gone Beyond Scrum, the history of Agile adoption in industry took the path of usage of Extreme Programming (XP) followed by the combination of Scrum and XP. In the government, the adoption of Scrum alone has become the de facto method of Agile adoption with the use of the term Agile and Scrum even becoming synonymous in some agencies. In our latest white paper we discuss why we believe the use of Agile Engineering Practices such as XP is crucial to the success of Scrum projects for the Federal government and that the government can again benefit by combining Scrum with XP as is already in use by industry. We believe this is because Agile Engineering Practices enhance the empirical process control (Inspection, Adaptation, and Transparency) of Scrum.

According to the latest State of Agile Survey by VersionOne, the top three XP techniques in practice are Continuous Integration, Test-First Programming, and Shared Code. What XP practices are you using at your agency? Is the use of them improving quality?

About a year ago, I co-authored with Bruce Yang a whitepaper entitled “Agile in the Federal Government – Moving Beyond Scrum.”  In that whitepaper, we predicted that the government would follow the lead of the private sector to adopt Agile solutions beyond Scrum to gain broader benefits.  Specifically, the private sector had learned that Scrum by itself would not effectively support scalability to replicate the success of one project across the entire organizational structure and adopted scaling frameworks such SAFe.  Similarly, it realized that the Scrum methodology was not necessarily appropriate for all types of work and looked for alternatives, most notably Kanban.

I am happy to report that the federal sector has in fact followed this anticipated pattern.  Some examples:

• DHS – Using SAFe at USCIS  to enable more rapid, high quality software delivery 

• DOL – “Why, yes, we Kanban” at DOL’s Office of the Solicitor 

• NGA –  SAFe becomes part of NGA’s School for Agile

• GSA – XP techniques adopted along with SAFe
  

We’re trying to compile a more comprehensive list of agencies that have adopted Agile techniques beyond Scrum and how well they have been working.   Would you mind sharing any non-confidential examples that you might be aware of?