WATCH the Board (Redux 2015)

Agile & lean teams perform a daily stand up meeting to bring energy and coordination to the day's work.  During this short meeting, an agile leader (ScrumMaster, Project Manager, Tech lead, Coach, etc.) should ensure the team highlights the important points around the current work—but it is often difficult to articulate and probe every aspect to every card in flight on the team board.

Programs and projects in enterprise portfolios place leads over multiple teams or work streams and those leads have a similar need to decide a confidence over their areas of responsibility during quick conversations with other team leads.  

While all team sizes, % of their involvement, and project complexity levels are not ideal, how can leads possibly be quick on their feet to consider the critical aspects of each card, team, or project? When I was in these situations, I needed a mnemonic acronym to make me quick on my feet.

The search for the right acronym started in practices I use with my teams:  information radiating, continuous improvement, and collaboration.  The resulting technique emphasizes good practices, process, collaboration, and accountability.  The result is something I call the WATCH the Board technique.  (For the first vision of this technique, see the 2013 post of WATCH The Board)

Described below, the technique can be used during a team's daily stand-up, conversation with project leads or team members, or observation of project information radiators.

The WATCH the Board Technique

The technique follows two steps:

1. Preparation (optional)
2.  WATCH the board (consider the questions)

1.  Preparation

This optional step prepares you for the stand-up or other project meeting where you consider the questions to ask before the conversation starts.  While not always possible (hallway conversations do occur), preparing for a conversation greatly increases your ability to be fast on your feet.

For a stand-up meeting, prepare by WATCHing each card on the board and noting which areas to ensure are covered during the stand-up.  You will find noting the specific statements you should hear from individuals helps with accountability and quickly articulating important aspects to keep the project on track. Preparing before a stand-up also reduces stress or tension between the need to quickly end the meeting and getting the highest priority issues raised.

2. WATCH the Board

WATCHing the board steps you through a series of questions in priority order using the word, watch as a guide.  Each letter in WATCH represents valuable components to a development project and can be expanded upon as needed.  As the conversation starts, the lead can internally cycle through the letters of WATCH one after another to look for answers or spark critical questions (occurring in a matter of seconds).  Externally, the lead can call out the questions individually as needed.  Each card (work package on a team board or project of work in an enterprise portfolio) can be watched at its own applicable level.  Note:  If WATCHing a daily stand-up, the preparation step helps greatly.

W
Who, What, When, Where, WIP.
Who is working on the card? Where is the card? Where should it be? Where did it come from? What is the WIP limit?

Detail
These clarifying questions let us blend agile and lean techniques and practices by considering both people and process.  Who begins a people thread and narrows in on responsibility.  Where begins a process thread and identifies a state the card is in—and allows discussion of where the card is or where it should be (based on the process).  Cards should come from a prioritized list and represent part of the highest priority set of work.  Noting a card in process that came from a lower set of priority may be a concern a lead should question more.

Questioning the WIP limit makes sure the person, team, or project adheres to its process flow policy and priority.  Leads should ensure the team has the capacity and predictability to perform work at the right quality level, and can respond timely to changes as necessary.

A

Average time & Accountability
A card this size should take how long?

Detail
Work should relatively match against previous work completed or planned (either individually, as a team, or at an organization level).  If the card is under or over the typical effort required from relative cards, the lead can update internal confidence levels and probe for additional detail as necessary.  Practices to determine the relative effort and duration of cards vary, and this question can ensure the appropriate practices for the card are in place.

In parallel to the relative effort required, accountability for the card becomes visible and options and decisions on priority and changes needed (performance, process, etc.) become the topic of the conversation.

T

Technology & Test
Build ready? Environments ready? Access available? Integration complete? Automation working? Testing started? Testing issues resolved?

Detail
Proving it with working software is a corner stone of software projects, and healthy technology and test practices deliver working software quickly.  The competitive advantage of quickly learning from working software allows the team to focus on the unique business problems and differentiators and less on the common challenges with software development.

With a healthy technology state, the solution can be iterated until the learning and results meet the business need.  Leads can question practices and process that aim toward facilitating iterative development.  Examples include integration environment planning & implementation, access request impediments, capacity, automation, etc. For each card, a build should be available soon.  The people should have access to that build.  The build should be reproducible and confidence in iterative updates to the build should be high. The build should be executable by the team and customer when necessary.

With a healthy test state, the solution is understood, documented, and confidence in the quality level of the build is high.  Leads can question practices and process that aim toward defining the knowledge level of the solution.  Is the individual, team, or project able to define the unique business problem or differentiator goals?  The state of that answer can be determined in parallel by the ability to collaborate on the quality of the solution, find details on required features and if those features are healthy and in which location.

A development line effortlessly collaborating on business needs, with high learning throughput are the goals technology and test can aim toward.

C

Card, Conversation, Confirmation
Are the card details complete? Who are on the tasks? Who was in the conversation? Dates identified? Criteria identified? Does conversation occur as needed?  Are we confirming the solution?  How?  Who is?

Detail
Administrative and process details should remain transparent and minimal enough to escape the need for questioning.  However, when the admin work or process is not acting transparent, we may lose focus time on the solution.  The three Cs questions (inspired by Ron Jefferies’ critical aspects of user stories) will help with process visibility for the card and guide the card back into a good state.

The card represents the requirement and reminds everyone what the work is.  The administrative part of the card likely links to a repository of further information about the work (or may well be noted on the card itself).  Information critical to the process should be complete on the card so that it is crystal clear the work has followed the necessary process and those responsible for the work have committed to its completion.  Examples of critical information:  ID, relative size, category, dates, tasks, assignments, dependencies, acceptance, etc.

The conversation represents the collaboration health of the work.  For example, agile practices emphasize face to face, verbal communication, and critical people left out of that communication could potentially surface as an issue during the next solution demonstration.  Leads should ensure the right parties are involved in solution discussion throughout the card’s progression, and that the conversations can and are happening.

The confirmation represents the completion of the work and its acceptance and approvals.  For example, a solution could be complete & demonstrated but is it sufficient to all relevant areas of the enterprise—has it been formally approved (where is it captured)?  Who needs to approve the work?  Aside from the approvals, acceptance criteria of the solution should be crystal clear.  How is the solution being verified?  Where?  Who is verifying?  What do they need?  Is the goal understood—do we know what has been deprioritized?  Depending on the organization, the confirmation may have fewer or greater parts. 

H

Help.
Who is available to help? What help is needed? Are we stuck? Should this card be returned so team members can help elsewhere?

Detail
There may be a spectrum of collaboration levels required to complete work on projects.  Team members should be able to work independently on tasks (or projects) as well as work with the surrounding and supporting teams and delivery model in place.  For example, team policy may be to attempt to join work on another card before pulling a new card.  Or, a team member may need to engage an expert to help design a component of the solution.

The final letter of WATCH is meant to determine if the current people, process, and technology in place for the card is sufficient or if one or more changes need to occur. 

This is where the team or project works together to find a resolution.  For example, should the team swarm on this highest priority user story so that it will complete in this Sprint?  Do we need a technology expert to assist with this task?  Should we escalate to a supporting team? 

For each question, leads or other team members can search for more specific detail as necessary.  Since WATCH is a guide to help leads articulate additional questions, make sure questioning tracks closely to the guide so as to not stray too far from the critical answers needed.

At the end, you have WATCHED the board!

When the card or project is over, you may have Enhanced Domain knowledge in the business or technology area to which your project contributed and can use this knowledge for future project success

Agile Software Requirements Comic

The software requirements comic musing about pitfalls of software delivery through various images of a tire swing on a tree has been around in one incarnation or another for perhaps 40 years. 

Classic Software Requirements Comic

While acknowledging the comic depicts what can happen in software delivery (this even applies to other industries as well), I think we are here to acknowledge that we need to prevent these pitfalls and enhance our ability to deliver what the customer really needed (the last panel in the comic).

In the right cases, Agile values and practices can move us in a step in the right direction.  Below, I've rearranged the classic comic into one with a slant toward an Agile delivery approach intending to bring out the customer’s right solution.

Agile Software Requirements Comic

In an Agile version, the customer’s initial vision is truly only known to the customer or product management team.  A delivery team is assembled and project approvals are generated to start the refinement of the vision in the second panel.  Panels three through five depict the solution going through an iteration—starting with nothing, failing fast, and ending with a small or minimal slice of the solution as a base, foundation, or minimal feature in line with the vision.

The second row of panels continues iterating over the product with each iteration producing feedback and a better alignment to the vision.  The third panel in the second row shows a completed tree at the end of an iteration with the rope ready to accept the final piece of the solution. 

The end of the comic delivers what the customer really needed.  The customer interacted with the delivery team throughout the solution development, and was able to refine and prioritize the features to arrive at an optimal solution.

WATCH The Board

Agile teams should perform a daily stand up meeting to bring energy and coordination to the day's work.

During this short meeting, an Agile Project Manager (ScrumMaster, Coach, etc.) should ensure the team highlights the important points around the current work--but it is often difficult to articulate and probe every aspect to every card in flight on the team board.

How can I possibly be quick to consider all the aspects of each card?  I needed a mnemonic acronym to make me quick on my feet.


I bring you the WATCH The Board technique.
(See the updated version of WATCH the Board containing more detail)

WATCH The Board

Agile Project Managers can enable their teams by WATCH'ing the board during the daily standup, interaction with team members, or casual observation of a team's board.

W

Where, Where, What, WIP.
Who is working on the card?  Where is the card?  Where should it be? Where did it come from? What is the WIP limit?

A

Average time.
A card this size should take how long?

T

Technology & Test
Build ready?  Environments ready?  Access available?  Integration complete?  Automation working?  Testing started?  Testing issues resolved?

C

Card, Conversation, Confirmation
Are the card details complete?  Who are on the tasks?  Who was in the conversation?  Dates identified?  Criteria identified?

H

Help.
Who is available to help?  What help is needed?  Should this card be returned so team members can help elsewhere?


I'm really excited about bringing innovation to the acronym space :)  Hope this helps you daily!

ScrumMasters Remove Only The Real Impediments

Impediments to the team can be disastrous if left alone, or they could give life to the team's success.  Coaches and leaders of ScrumMasters can assist these team leaders by helping them navigate their teams' true impediments and which of those are best suited for removal by the ScrumMaster.

ScrumMasters Are In A Paradox
One of the core responsibilities of a ScrumMaster is to foresee and remove impediments to the team.  So naturally, any time an impediment is raised, a good ScrumMaster's first thought is to remove that impediment.

One of the main practices of a ScrumMaster is that of servant leadership.  So naturally, any time something comes up, a good ScrumMaster wants to step in and assist the team themselves.

Discussion and literature about agile typically discuss alternatives to agile as command and control (in terms of big up front or phase based planning).  The command and control nature of these alternatives contrasts with the intent of the more enabling ScrumMaster role.

Technology companies build and promote tools allowing "developers to focus on development."  So technical ScrumMasters may follow that same course.

Combine removing impediments, servant leadership, and reducing command and control practices; and ScrumMasters are inclined to serve the team by removing the impediments themselves.

But what happens when the team becomes reliant on the ScrumMaster?  The servant leader has just become the impediment.

ScrumMasters Are In A Paradox--But Who Isn't?
The ScrumMaster should always first look to see what can help the team complete their commitment.  At times, the ScrumMaster will themselves remove impediments, complete tasks, and coach the team.  At other times, the ScrumMaster will ignore the impediments, let tasks go uncompleted, and let the team work it out.

Similar to other leadership roles, the ScrumMaster's role is to guide and protect the team.  A team navigating a project needs to gain the experience and skills to support itself for the life of that project.  Therefore, a ScrumMaster needs to determine when to remove an impediment, and when to leave the team to remove it themselves.

Teaching People To Fish Is Nothing New
Part of removing impediments is to enable the team to complete their current Sprint.  More of removing impediments is to continually improve the team to allow them to remove the impediments themselves and then prevent the impediments from occurring.

The Real Impediments
So what are the real impediments?  Which impediments should ScrumMasters remove themselves?  How does the ScrumMaster balance servant leadership with helping the team succeed?

Let's look at each of these questions:

The real impediments are those that don't happen often.  They are the ones that are looming ahead.  They are the ones caused by specific individuals at specific times.  The real impediments are not the work that people don't want to do.  They are not the manual work that the team has not yet automated.  They are not the compliance or regulatory administrative work the team faces.

ScrumMasters should remove these real impediments.  Big items affecting the team's agility should be attacked by the ScrumMaster to bring change.  A ScrumMaster should facilitate the onboarding of an automation team member and framework as removing a foreseen impediment.  A ScrumMaster should not typically make all the security requests or do all the administrative work disliked by team members.  A ScrumMaster should instead coach the team on the best way to streamline the security request.

A ScrumMaster should have no problem performing the smallest or largest of tasks to help the team.  Learning all the processes, all the policies, and all the practices of the team should be on the ScrumMaster's short list.  But where there is pain, let the team feel it--they will want to automate the pain away over time.  Where there are lessons to be learned and improvements to be made, ScrumMasters should step in and show the team members which tasks are designed to help them grow.


My favorite fake impediment:
Team Member:  "I sent the email and haven't heard back yet.  So I'm blocked."
ScrumMaster:  "What did he say when you called him to ask?"
Team Member:  "Well, I didn't call yet."
ScrumMaster:  << Walked over to the next building, up the stairs, down the hall, and asked for the answer.  Then walked back to the team member.>>
ScrumMaster:  "He didn't see the email, but your answer is ..."

In this case, the ScrumMaster should take the team member along and show how simple it is to get an answer.


Next Steps
ScrumMasters' next steps are to return to their teams and take a second look at the global and task impediments they're working on.  Which ones are pain that no one wants to do?  Give those back to the team and let them improve upon them.  Which ones are good opportunities for learning or growth?  Identify some specific team members that could benefit and walk them through the process--let them shadow the process of removing that block.  Which ones are not on your impediment board?  ScrumMasters, go find those and work on them yourselves.

Winning with Scrum Under a Phase-Based Program

Which one of these guys is agile?  Which one is waterfall?

OK, that's not what this is about.

Scrum teams may become connected to a program delivering a new suite of products.  The program and its other projects may follow a different delivery method than the Scrum teams, and it is up to the people in both the program and teams to inspect and adapt their models—bridging the impedance mismatch brought by incongruent methods.

Program and architecture governance may require specific steps, approvals, and engagement with specific partners.  These program requirements may not lock in step with the project start and development cycle of the Scrum team.  The reverse is the same—the Scrum team cadence may not match the start and end of a phased based project.

While Agile and Waterfall or phase-based methods need to coexist (just the state of the times in your organization, for example), we need to make the best of it.  Both processes can operate fine independently, but the Agile team has an interest in making it work where the two methods meet.

Agile teams need to ride the Waterfall to make it work

One of the top reasons for failed Agile projects 

is external pressure to follow a traditional waterfall process

PROCESS MISMATCH
The mismatch starts with the differences in process:  When waterfall has completed planning, Scrum is setting up a development environment.  When waterfall is gathering requirements, Scrum is testing working software.  When waterfall has completed requirements and architecture reviews, Scrum is adapting the plan and getting more requirements.  A waterfall, or phase-based program's specific steps, approvals, and engagement requirements with specific partners may not match the Scrum team's cadence and practices.

Waterfall and Scrum have a process mismatch

INTEGRATING THE SCRUM TEAM, STAKEHOLDERS, AND PARTNERS

Mixed in with these planning and delivery mismatches, partners and the people themselves are potentially mismatched based on mindset, experience, and motivation.  Phase-based team members are possibly not comfortable with limited information.  Scrum team members want to get started with little up front information so that they can get feedback.  Mismatches involving people’s understanding of the process, techniques, values, and principles should be assessed prior to the project start and resolved throughout the project by continuous coaching (at the team level and then at the individual level as well).

Some specific challenges to resolve through coaching are:  The change in roles and responsibilities; making inappropriate comparisons; hesitancy about or hindering delivery by blocking, or building in waste to a Scrum team's processes or practices; controlling team commitments or focusing on lower priorities; misunderstanding the value of an informative workspace (wanting everything electronic); locking down scope, limiting scope flexibility, using change control; incorrectly measuring progress; wanting a Scrum team to use phase-based methods (estimates, requirements gathering, etc.); unaligned business and customer partners, and Scrum team communication and reporting with program stakeholders.

Before starting a project, train, coach, and involve people.  Ensure the delivery team and stakeholders are brought along and value the Agile mindset.

The delivery team and stakeholders should train before the project

INTEGRATING THE SCRUM TEAM AND ARCHITECTURE FUNCTION

Another mismatch occurs while planning the first release of the project.  The Scrum team may recommend a feature-driven development approach.  Architects may recommend a component-driven approach.  The feature-driven approach uses all layers (possibly tiers) of the architecture and produces value to the customer in the form of a potential production-ready feature.  The component-driven approach shows the architects progress on the architecture up front.

Specific architecture domains are also put in the same situation.  In large architecture functions and programs, each domain may have its own governance.  Business, application, information, integration, infrastructure, and security architecture domains may require up front, approved solutions before functional development begins.  These architecture domains may raise issues or identify risks to the program if as User Stories are placed into a Sprint before, for example, the data model is finalized and approved.  Architects or technical Scrum team members may try to encourage the Product Owner to place component-driven backlog items into the Sprint backlog, or to put documentation-driven work ahead of working software (valuing full business context, or non-functional requirements documentation over a risk adjusted backlog of User Stories).

A solution to this mismatch is to ensure the architecture is defined using the correct process for the product, project, and people involved.  Typically, candidate architectures are crafted from the architecturally significant requirements.  Any development framework or methodology can determine the architecturally significant requirements.  As those requirements are identified, the mismatch can be solved.  In this example, the Scrum team can map User Stories to architectural significances and progress of the architecture can be measured against completion of those User Stories.  Since Product Owners consider architecture significance and risk in prioritizing, these User Stories should be completed early in the project.  The Scrum team will follow and implement architecture guidelines and standards during feature development and update necessary documentation and repositories incrementally. 

To support this solution, an embedded solution or delegate architect can perform periodic or ongoing reviews of the architecture to ensure the visibility of architecturally significant decisions and leveragable work.

The product can be driven by features, while prioritizing the architecture components for those features

INTEGRATING PROJECT AND PROGRAM MANAGEMENT WITH AGILE DELIVERY

1.  Charter and Funding

A first mismatch occurs during the program’s project charter and funding.  The Scrum team may recommend a small funding of the determined team for a small number of sprints in order to gain a better understanding of the project, and produce some working software from which immediate feedback can be gained from the customer.  The program and architects may recommend a full requirements and architecture phase to determine the complete scope up front, and then request approval and funding for the entire project.

A solution to this mismatch is to sell the Scrum team’s recommendation to the program and architects.  Having successful delivery in the past will help the Scrum team with the sell, but if a new Scrum team is assembled, the arguments for assembling the Scrum team can be directly used to the program for a small initial funding of the project.

2.  Release Approval & Estimates

Another mismatch also occurs while planning the first release of the project.  The funding and approval process of the program may take significant time relative to the Sprint cadence of the Scrum team.  Two or more Sprints can go by while the next release is socialized with the program governance.  In the first release, the governance may need to review the Scrum team’s velocity in order to gauge completion of later releases.  However, if the Scrum team has not been provided sufficient time to stabilize a velocity, the approval for the next release may not occur based on accurate information. 

A solution to this mismatch is to allow appropriate time to gain accurate information.  If the first release is only four sprints, the approval for the following release may occur after two sprints—not sufficient time for a stabilized velocity.  The Scrum team may recommend a longer first release or a shortened approval cycle.  An alternate solution is to complete the full release (all sprints) and hold the team while the approval is gained for a next release.

Stabilize velocity, backlog, and architecture before seeking long-term approvals 

Estimating with Scrum typically uses story points or ideal days at times when the entire architecture and design of the product is unknown.  Program stakeholders may find a higher level of comfort with the phase-based approach of defining the entire scope up front, and estimating that entire scope based on components.

A solution to this mismatch is to coach the stakeholders on the problems with estimating an entire scope and how using points or ideal days allows the team to start working quickly on refining the estimate by producing and basing measurements on the construction of a working product.  Allow stakeholders to compare the Scrum team’s estimate with any estimating model they can produce in parallel to show how the estimate of the Scrum team is within a similar magnitude.

During the project, a dependent team or customer may ask the Scrum team for feature estimates in financial terms.  A point or ideal day estimate would not satisfy the request.  A solution to this estimate mismatch is to the estimate in the following terms: 

• Duration:  Number of Sprints (based on velocity and the Scrum team’s estimate of the effort in points or ideal days)
• Cost:  Burn rate of the Scrum team (or a portion thereof) for that number of Sprints

Integrate cost planning with other teams by using portions of your velocity to determine costs of features

3.  Planning, Monitoring, and Controlling

Another mismatch occurs in monitoring and controlling project execution.  Program and project managers may naturally want a project plan containing all activities, durations, and start dates.  The Scrum team may recommend Sprint and release burndown charts to track progress.  However, the program manager can point to another dependent team that needs a specific feature or component completed by a specific date.

A solution to this mismatch is to categorize those stories needed to fulfill that dependency.  Then, similar to a Sprint or release burndown, the Scrum team will burn down that story category, and track its completion to the date.  Stories from this category can be planned into sprints as necessary (starting backward from the delivery date).

Categorize work to meet dependencies and burn down that work each Sprint

A Scrum team previously not involved in a program could potentially not have experience with complex delivery dependencies.  Backlog items for developing the product may not incorporate post-development activities such as deployment, operational readiness, etc.  Project management supported by the program can plan these activities, and the Scrum team can look to the program’s expertise for this portion of the delivery.

A phased based project plan typically uses contingency time equating to some percentage of the estimate to account for unknowns.  A Scrum team avoids contingency using an empirical process, customer collaboration, and allowing the people doing the work to do the estimating.  If the program requires the project manager to add contingency to the delivery plan, a percentage of the release points could be added and a suitable duration extension based on velocity could be added to the project plan.  The Scrum team members are not affected by this contingency, but the ScrumMaster must ensure the Product Owner or customer remains involved with the current progress and scope so that transparency remains.

Utilize complex delivery expertise of project and program management

From a project management perspective, communicating updates to scope and release schedule may occur more frequently than if Scrum were not employed.  Project managers can view this as intentionally over communicating to program leadership, but also a necessary part of the process.

A ScrumMaster could protect the team by letting the project manager interface with external requests to the team.  Dependency coordination can be handled by the project manager, while the Scrum team focuses on the current release.  The project manager would have to ensure the Scrum process is followed by involving the Product Owner for dependency information affecting priority.

CONCLUSION

To win the mismatch, both sides need to evolve

To fit Scrum and phase-based programs together, both sides need to evolve.  Gains toward a lean organization that sends prioritized project work to agile teams focused on their product are desirable.  To make gains, champion Scrum and agile values and principles; and demonstrate to project managers a high confidence level throughout the project, a team building the right product, and competitive advantage delivered to the customer.

Agile Inside Waterfall Impedance Mismatch

Agile teams may become connected to a program delivering a new suite of products.  The program may follow a different delivery method than the agile teams, and it is up to the people in both the program and teams to inspect and adapt to a new model—bridging the impedance mismatch brought by incongruent methods.

In this example, consider an agile Scrum team with proven delivery success and a new program following a waterfall methodology.  The program governance will require specific steps, approvals, and engagement with specific partners.  These program requirements will not lock in step with the typical project start and development cycle of the Scrum team.  The reverse is the same—the Scrum team cadence will not match the heavy start and end of a waterfall project.

1.  Charter and Funding

A first mismatch occurs during the program’s project charter and funding.  The Scrum team will recommend a small funding of the determined team for a small number of sprints in order to gain a better understanding of the project, and produce some working software from which immediate feedback can be gained by the customer.  The program and selected architects will recommend a full requirements and architecture phase to determine the complete scope up front, and then request approval and funding for the entire project.

A solution to this mismatch is to sell the Scrum team’s recommendation to the program and architects.  Having successful delivery in the past will help the Scrum team with the sell, but if a new Scrum team is assembled, the arguments for assembling the Scrum team can be directly used to the program for a small initial funding of the project.

2.  Feature-driven and Component-driven

Another mismatch occurs while planning the first release of the project.  The Scrum team will recommend a feature-driven development approach.  The program or architects may recommend a component-driven approach.  The feature-driven approach uses the whole technology stack and produces value to the customer in the form of a production-ready feature.  The component-driven approach shows the architects progress on the architecture up front.

A solution to this mismatch is to ensure the architecture is defined using the correct process for the product, project, and people involved.  Typically, a candidate architecture is crafted from the architecturally significant requirements.  Any development framework or methodology can determine the architecturally significant requirements.  Once those requirements are identified, the mismatch can be solved.  In this example, the Scrum team will recommend the user stories are mapped to architectural significances and progress of the architecture can be measured against completion of those user stories.  Since Product Owners consider architecture significance in prioritizing, these user stories should be completed early in the project. 

3.  Release Approval

Another mismatch also occurs while planning the first release of the project.  The funding and approval process of the program takes significant time relative to the sprint cadence of the Scrum team.  Two or more sprints can go by while the next release is socialized with the program governance.  In the first release, the governance will need to review the Scrum team’s velocity in order to gauge completion of later releases.  However, if the Scrum team has not been provided sufficient time to stabilize a velocity, the approval for the next release may not occur based on accurate information. 

A solution to this mismatch is to allow sufficient time to gain the most accurate information possible.  If the first release is only four sprints, the approval for the following release would occur after two sprints—not sufficient time for a stabilized velocity.  The Scrum team will recommend a longer first release or a shortened approval cycle.  An alternate solution is to complete the full release (all sprints) and hold the team while the approval is gained for a next release.

4.  Monitoring and Controlling

Another mismatch occurs in the monitoring and controlling project execution.  Program and project managers will naturally want a project plan containing all activities, durations, and start dates—the standard command and control nature agilists are well aware of.  The Scrum team will recommend sprint and release burndown charts to track progress.  However, the program manager can point to another dependent team—not working with agile—that needs a specific feature or component completed by a specific date.

A solution to this mismatch is to categorize those stories needed to fulfill that dependency.  Then, similar to a sprint or release burndown, the Scrum team will burndown that story category, and track its completion to the date.  Stories from this category can be planned into sprints as necessary (starting backward from the delivery date).

5.  People

Mixed in with these planning and delivery mismatches, the people themselves are mismatched based on mindset, experience, and motivation.  Waterfall team members are not comfortable up front with such limited information.  Scrum team members need to get started with little up front information so that they can get feedback.  Mismatches involving people’s understanding of the process, techniques, values, and principles should be resolved throughout the project by continuous coaching (at the team level and then at the individual level as well).

To fit agile and waterfall together, both sides need to change.  Agilists hope each instance will allow more agile remains each time.  The complete fix is to make gains toward a lean organization that sends prioritized project work to agile teams focused on their product. 

Introducing Scrumban To A Scrum Team

Scrum is a great development framework for teams focused on developing a product.  If the framework is followed, the product owner will see clarified requirements, a production-ready implementation, and have a stable velocity with which to plan, at the end of the sprint.  However, if the framework is not followed, and if the framework is not congruent with the actual workload and organizational environment, it may be beneficial to consider other framework options (after attempts to right the issues under Scrum have been unsuccessful). 

A typical set of problems with the Scrum framework arises when the product transitions to a maintenance phase in the context of a large organization.  The problem includes issues such as priority changes mid-sprint, incongruent processes between teams, unfocused work, and sprints not completing.

Priority changes can affect a Scrum team's velocity, ability to complete a sprint, and planning.  Production issues may change the team's plan and incomplete work may accumulate.  Organization-wide objectives or mandates may also affect the team's plan once the product has been coupled with other dependent products in the larger organization.  Once the sprints become harder to complete, planning is affected because the team's velocity is unstable. 

Once a team transitions to a maintenance phase, the team may have turned over support or deployments to another group.  Environment changes may also be handled differently.  Often, different groups within an organization are not yet operating with compatible development processes.  The Scrum team may need to wait for or artificially break down a story in ways that affect the story's ability to complete within the sprint.

The Scrum team may experience a shift in the type of work required, and notice the focus of their team is not as narrow as it once was.  Once a product is introduced to a larger integration of other products, the focus may broaden, other groups may introduce priorities, and the potential for interruptions in the sprint increases.

These issues can compound and make it difficult for a Scrum team to complete sprints.  While there may be solutions to remain with Scrum (protecting the team and plan from interruptions, prioritizing better, pull from a good ScrumMaster notebook, etc.), these solutions won't always solve the problem completely.

An alternative approach may be to modify the Scrum team's use of the Scrum framework.  While the major goals of agile and lean development still apply, and while Scrum still applies, a slight change can be made to introduce the ability for allowing more frequent changes, allowing for incongruent processes, and allowing for a broad focus of work.

Scrumban is a combination of the Scrum framework and Kanban.  Information on Scrum, Kanban, and Scrumban is readily available and can prove why the approaches are successful. 

If Scrumban has been identified as an option for your team, consider the following approach for transitioning your Scrum team to Scrumban.

Sell Scrumban
The first win is to get your leadership team familiar with and set up for an approval of the new framework.  There are differences with a framework that incorporates Kanban practices, and the leadership team will need to feel comfortable with the changes. 

During your pitch, cover the following topics to help influence the decision:  Current problems team faces with Scrum, solution options, pulling work, the value stream, Kanban, and lastly Scrumban.  Lean principles should also be incorporated throughout the discussion.

The current problems should be identified as areas with which Scrum has difficulty helping.  A team often facing priority changes during a sprint, incongruent processes between the Scrum team and external teams in the organization, broad objectives, and incomplete sprints are typical issues maintenance teams face under Scrum.  These problems may be solved by protecting the team, or with a more influential Product Owner, but these issues can go beyond the reach of the ScrumMaster and Product Owner.

The options should include ideas shuch as allowing for more frequent changes during the sprint, allowing for incongruent processes in the near term, and allowing for unfocused and broad objectives.

Once the problems and their potential solutions are identified, ensure the team understands the subtle difference between pulling work and pushing work.  Highlight that pushing work task by task onto the team only allows the team to focus on those individual tasks.  Pulling work gives the team more ability to view their work in the context of the larger system, and where it can make improvements.  Pulling work is a basic lean software development principle and a fundamental practice in Kanban.

The value stream is not a focus in Scrum.  However, Kanban allows you to easily see the value stream.  Ensure the leadership team understands the concept of the value stream, and the importance of optimizing it.  Visual control over the value stream is the lean principle the team should understand the most.  Show how to identify ways of optimizing the value stream by using examples.

Next, cover the basics of Kanban.  Walk through a brief scenario.  Show how it covers the solution options identified earlier.  Make sure the leadership team sees the difference between measuring Scrum and measuring Kanban (burn down vs. cycle time).

Lastly, incorporate Kanban into your current Scrum framework.  Show how you would like to start with small changes and leave it to the team when more changes are introduced.  Start with a team board change and tracking cycle time for each backlog item type (or size).

Once the leadership team has agreed to the framework changes, introduce the Scrum team to the idea.  Get their feedback, answer their concerns, and propose to start during the next sprint.  Since Kanban can be used with your current process, it is possible to introduce with little lead time.

Create Board
After the team has agreed to the new framework, create the current value stream on a team board.  For example, use the back of your current Scrum team board and make one column for each step in your SDLC from the start until your definition of done is reached.

Use this board in the final step discussed next.

Walk Through A Sprint
Finally, simulate and walk through a sprint with the Scrum team.  Show how the backlog items appear on the board.  Note the differences in the board, and how the previous tasks in Scrum planning are now left up to the team members to lead themselves.  Give the team the feeling they have already been through a sprint with the new framework to help ease them into the next sprint.

Using the approach discussed here, a team facing situational issues with their Scrum framework can start Scrumban as an ongoing evolution until their product development and organization align.

The ScrumMaster's Notebook

The ScrumMaster's skill set differs from those of roles outside the Scrum framework.  While project managers have the majority of the skills, the ScrumMaster needs more knowledge and current practical experience on the application development side (analysis, implementation, etc.) to help with the lower level of day-to-day details involved with the role.  While application developers and analysts can have the majority of the skills as well, the ScrumMaster needs more knowledge and practical experience in the Scrum framework, influence, agile and lean techniques and principles.

The following describes those topics a ScrumMaster should track and evolve in a notebook for quick reference and continuous improvement. 

The Scrum Framework
While Scrum is only a framework for projects (and not a prescribed methodology), it is important for the ScrumMaster to know how to incorporate agile, lean, and development practices and principles into the framework.  Knowing where the framework stops, and the team's practices begin can help the ScrumMaster pull the team together in times of misunderstanding and in times of value stream optimization.

Notes on good practices for the daily meeting (stand up meeting) can help as a reference when the meetings run long or when the value of the meeting starts to decrease.

Keeping a list of alternative approaches to the retrospective is valuable.  Switching retrospective techniques can help invite new opportunities for team member participation and bring out new ideas not thought of in the previous retro's approach.

The ScrumMaster should also be able to articulate the team's velocity and recent burndown (or hours remaining).  A page should be dedicated to creating a burndown (perhaps even a project burndown to show senior management the team trends).

Scrum Team
Information on the Scrum team should be kept in mind to assist with the team's effectiveness.  Information on the best size of a team, the ability for the team to be cross functional, and how the team works with management can prove valuable when issues, organizational changes, or team questions arise.

It is important to control the team size and to be able to articulate the importance of the team size.  If team members are pulled away or added, then current relationships, velocity, and team effectiveness is affected.

The team should remain cross functional.  As a team moves away from new development and transitions to a maintenance phase, for example, it is common for the team to see organizational changes.  The ScrumMaster must be able to refer to the fundamental principle for cross functional teams and ensure the team is able to maintain the previous effectiveness.

ScrumMasters should understand how management can work for the team.  When to escalate to management, and when to shield the team from management are important things to keep in mind. 

Agile
A ScrumMaster should be well versed in agile principles and practices.  The benefits of the agile manifesto, and how those benefits map to business value are important to keep readily available.  Prioritizing can sometimes be helped with information on why things are done the way they are done, or why the process needs to change. 

Specific examples for ScrumMasters to note include story maps, the roles of team members, how to handle debt, and the benefits of information radiators and team boards (physical task boards vs. virtual task boards).

There are lots of development frameworks out there, and the ScrumMaster needs to know when to evolve the current team's framework.

Lean
Just as agile principles and practices are important, lean principles are also important.  While Scrum doesn't technically require a knowledge of lean principles, a ScrumMaster can shape its team's effectiveness by incorporating lean principles (such as optimization, limiting waste, making small changes at a time, limiting debt, continuous improvement, visual control, simple technology, using just in time, etc.).

Impediment Removal
ScrumMasters have a responsibility to foresee and remove impediments to the team.  However, ScrumMasters should coach the team to proactively remove impediments themselves, so that the ScrumMaster can focus on removing the real impediments.

Pull vs. Push
The ScrumMaster should have an appreciation for the differences between pulling work and pushing work.  The team that pulls work is empowered to produce a quality product and innovate.  The team that has work pushed to them has less opportunity to do so.

Continuous Delivery
Knowledge of and reference to the benefits of continuous integration and delivery is valuable to a ScrumMaster in situations where the Product Owner needs explanation for the priority of work toward these practices.  Mapping the components of automated continuous delivery to business needs is a key skill for a ScrumMaster.  The Scrum team benefits from automation, but the entire organization may need to be influenced to see the benefits.

Engineering Practices
The Scrum framework does not prescribe engineering practices, so the ScrumMaster must ensure the team does not lose sight of good practices.  Notes on these practices and when to utilize them can assist the ScrumMaster in determining if the definition of done is complete, if the right tasks are considered during planning, and if junior team members are collaborating with senior team members for the right reasons.

Technical Skills
A ScrumMaster should acquire at least a minimum skillset in the technologies used by the team.  A background in the team's technologies, processes, and techniques will assist the ScrumMaster in removing impediments, and ensuring team members are working effectively.  A reference to these items can help make quick decisions or improve the effectiveness of the decisions made by the ScrumMaster.

Functional or Domain Knowledge and Skills
The ScrumMaster should also acquire at least a minimum level of knowledge or skills in the business domain or functionality of the product.  Referring to this information will assist the ScrumMaster in leading the team's planning and prioritization.

System Quality Attributes
Occasionally the team identifies areas of difficiency or debt that the product owner or customer has not realized.  The ScrumMaster should be able to assist the team with relaying the relevance of the debt to the product owner.  A tactic to improve the product owner's understanding of the problem is to map the problem to one of the standard system quality attributes (or non functional requirements).  Refrence information on these quality attributes can make this process more effective.

Feedback
The ScrumMaster is sometimes called upon to resolve conflicts or deal with difficult situations.  Readily-available notes on how to deal with these situations, and how to give proper feedback are useful.  Sometimes these situations come up unexpectedly and a quick resolution may be required.

Reinvigorating Your Scrum Team
The Scrum team can sometimes get into a rut.  Repetitive types of backlog items, or periods of uninteresting work may take away some of the team's excitement.  The ScrumMaster should have a list of approaches available to apply during these periods to keep the team engaged. 

Leadership
The ScrumMaster is a leadership position.  The team has more interaction with the ScrumMaster than with management.  Therefore, the ScrumMaster should have a set of leadership skills to match the team's needs and information on how to best use these skills.

Optimizing Value
A team's backlog contains items of varying priority, value, and complexity.  The ScrumMaster should understand and have access to the benefits of acting on these items in the way that best optimizes the value added to the product.  The Product Owner owns the priority, but the ScrumMaster can influence priority from the team's perspective.  For example, consider acting on high value with low complexity items first.  When those items are complete, assess the remaining items to determine their remaining value. 

Facilitation & Project Management
The ScrumMaster facilitates the Scrum rituals and various meetings with the team and stakeholders.  Additionally, standard project management skills are used daily to run the development team. Additionally, ScrumMasters need to guide their team and a program if working within a program following a different methodology (see considerations for agile inside waterfall.)

The ScrumMaster also needs to think quickly about each card on the team board during the daily stand up meeting.  Consider the WATCH The Board technique.

While the needs of a ScrumMaster will change with the particular team, notes on the topics identified here will help the ScrumMaster empower and effectively lead the team.

The Analogy Between Construction and IT Application Development Is Still Useful

There is a commonly used analogy in IT to help describe the details of application development where mechanical construction is compared to the construction of an application.  The analogy was more congruent with traditional application engineering, but newer development methods stray more from the analogy (see considerations for the mismatch between agile and waterfall as an example).  However, the analogy is still useful when used correctly.

The Analogy
When application development was heavily focused on big design up front (BDUF) or a large waterfall process, this analogy was a simple method to convey details to external stakeholders and those less involved with the process.  Architects would make statements that compared a building's foundation to constructing a foundation for an application.  Programmers would compare building framing to the application code.  User interface designers would compare paint on the walls to the look and feel of the application.

What is Right, What is Wrong
Taking the analogy literally is wrong.  The right way to use the analogy is to use it as a more familiar way to convey information.  Peers in the IT industry go back and forth on the usefulness of the analogy, but the truth is there is not much of a reason to do so.

An application architect or designer could mention a foundation is needed first in order for the rest of the application to function well.  This idea is true, but peers in IT should understand that the scale may have changed with time.  Perhaps under BDUF the entire foundation would have been created.  Under more iterative processes, a foundation is still created under whatever small functionality is being delivered.

Roles
The roles in both industries can be compared somewhat, but there are some roles that can't.  Architects and engineers can cross over and easily be understood.  Project managers can also compare easily.  Developers in IT mean something different in construction, but a developer in IT can be compared to finish or rough carpentry, or an electrician in construction.  Testers in IT can, perhaps, compare to an inspector in construction.

What roles do we have trouble comparing?  Configuration management doesn't have a direct comparison in construction.

Agile
The analogy is understandably not as easy to apply in all aspects under an agile process.  Building a little at a time, refactoring, and building more is not how you see a house go up.  However, what you didn't see before that house went up across the street were the many prototypes created in AutoCAD or scale models created out of Styrofoam board.  Therefore, the analogy still applies under agile.

Creative Partnerships For Effective Development Teams

Application development teams transforming to a new development methodology, framework, or process are challenged with ensuring their new working relationship and responsibilities have a positive impact on the results of the transformation.  Development managers and leads can enable effective product and feature teams by ensuring the following topics are visible and well understood.

Pull, Don't Push
A basic undercurrent of an effective application development team is its culture of pulling work instead of reacting to work pushed upon it.  Pushing work removes creativity from the process to the point where team members lose the vision of the complete solution and only focus on their current work item.  Managers and leads should ensure the capacities of their teams are not 100% utilized with work that the team was not ready to pull.

Managers and leads can create effective team members by ensuring end to end integration of the entire value stream (using value stream analysis) and ensuring work is pulled just in time (JIT).  Teams enjoy the right to have pride in their workmanship, and barriers to this right should be removed to increase their effectiveness. 

With a pull system in place, an application development team can effectively partner with with other teams (as well as with its own team members).

Scrum Team Roles
In the Scrum framework for application development, the following three roles are identified to perform the work.  These roles have different individual goals and it is important to distinguish the individual goals from the larger team goals. 

• Product Owner - The Scrum Product Owner for the team is responsible for providing the next priority and the answers to any product-related questions.  Individually, this person needs to ensure that the requirements conveyed to the team are correct and what the product minimally needs at that point in time.  At a team level, this person sets planning goals and is there to assist the team with priority.
• ScrumMaster - The ScrumMaster is responsible for coordinating the team.  Individually, this person needs to ensure the team's practices are correct and followed, and that each team member's work flow is going as smoothly as possible.  At a team level, this person ensures the team is only committing to work it has the capacity for.
• Team - The Scrum Team is responsible for completing the work.  Individually, the team is a set of individuals with the right to perform their roles as professionals.  At a team level, the team pulls work from the Product Owner when they have the capacity (see creative examples of how more than the team can work with the Product Owner).

The partnerships between these roles can become constrained if the roles are not fully understood.  If there is not a culture of pulling work, then the Product Owner and ScrumMaster may inadvertently push work on the team for which there is not capacity.  Managers and leads should enable their Scrum teams to partner effectively by clarifying the roles and assisting with implementing a culture of pull.

Project Managers and Teams
Project managers should partner with teams from a high level.  In large organizations, or projects within a program, project managers are needed to monitor, report on, and control dependencies between entities.  Teams are needed to self-organize and complete the work.  At intervals (just in time or regular intervals), the team should connect with the project manager to communicate any risk changes or issues that affect the dependencies the project manager is monitoring.

The project manager does not need to track or plan the individual work items of the team.  However, at intervals when coordinated efforts are required between entities, the project manager can then partner with the team to facilitate scheduling and coordination.

Project managers and teams need to work together especially when combining differing methodologies and frameworks.

Development Managers and Teams
Development managers should partner with the team with enabling in mind.  The team remains self-organized, while the manager enables the team to succeed in the greater enterprise.  Day to day, the manager assists the team with conflict resolution, providing guidance and objectives, and coaching.  The manager then works to strengthen the team by acting as a catalyst, removing barriers, and optimizing the team's value stream.

The team performs the work to meet the set objectives, and works with the manager to identify the barriers.  It is the manager's responsibility to provide leadership to the team.  The manager can blaze a trail while the team follows up by completing the road.

DevOps
A relationship exists between the application development team and the operations team that runs the application day to day.  Whatever the details are, a relationship does exist.  In some organizations, the teams are completely separate, where in others the teams are one and the same.

Compliance and regulatory requirements may affect the organization's ability to integrate these teams, but an effective practice is to ensure that the development team has a close relationship with and an understanding of the operational side of the application. 

The application development team should partner with the operations team to ensure the execution of and issues for the application are visible and known by each team.  Development team requirements, design, reviews, and showcase sessions should include the operations team.


Application development teams can increase their effectiveness by partnering with other teams.  An understanding of the differences in teams and their roles and requirements can increase the effectiveness of the partnership.  Application development managers and leads can enable teams by leading them into these effective partnerships.

How To Get Your Debt Ready

Application development teams trade costs and benefits, and face prioritization issues daily.  Managers and leads should enable their teams to correctly prioritize their backlogs of work items by ensuring the following topics are applied correctly to their teams.  This is not a process to follow, but rather a set of practices and topics that teams should adhere to in order to facilitate the tackling of debt (quality, configuration, or technical debt)--just as any other item is ready for development.

Debt Identification
Ensure debt is identified and radiated to the team.  The team created the debt (or inherited it), and it is the team that will remove the debt.  The identification should occur as the debt is found or created, and the radiation should be simple and visible. 

Example radiators include big visible displays or pages in a collaboration tool.  Since debt should be removed quickly, the simplest technology works best.  Consider this concrete example:  a big visible chart on the wall of the planning room divided into areas for each application component containing ranked sticky notes representing each debt item for that component.

Craftsmanship and Commitment to Quality
Before debt can be identified or prioritized, the team must confirm its levels of craftsmanship and commitment to quality.  A team divided on the amount of automated coverage or design patterns should first commit to its goals before it can identify debt--the team must know what debt is before it can identify debt.

Faltering engineering practices is a typical problem on new or immature teams when the team is challenged with understanding a new methodology, framework, or process.  Managers and leads need to identify this problem and connect with the team to create a baseline of quality levels and craftsmanship to which the team can commit.

Understand How You Get Debt
Debt is incurred whenever you choose today over tomorrow.  A common example occurs when reacting to fires creates workarounds or short-term solutions that are not refactored later.

Debt also occurs when there is not a common commitment to quality or where a lack of development maturity (do you have version control?) produces low-quality implementations, repeated manual tasks, or a lack of test coverage.

Debt can also come out of value stream analysis.  Identifying waste areas, for example, can lead to the need to prioritize debt items.

Debt also occurs in the following four fashions:

• Deliberately and recklessly where commitment levels are ignored intentionally
• Recklessly and inadvertently where immature decisions are implemented
• Inadvertently and prudently where mature decisions are implemented but with an inadvertent impact
• Prudently and deliberately where mature decisions are implemented with a concrete plan for later refactoring

Add Debt Reduction to Goals
Team goals should include commitments that enable team members to map debt reduction to the goals.  A goal of automated releases allows team members to raise a manual step in the release as debt or in need of technical improvement.  Planning can then consider these goals along with those goals provided in other discovery and capability discussions.

Villages Manage Backlogs
Product owners, managers, or customers should ensure all team roles have input into the preparation of the work item and its impact to the product.  While smaller applications can be understood by a single owner or customer, larger applications in larger organizations typically require an entire team of knowledge.

In the picture shown here, a Scrum Product Owner communicates the priority, vision, and goals of the plan, while the remainder of the team provide input based on their expertise and knowledge area

It is critical to ensure the owner, manager, or customer of the product understands all aspects and points of view when prioritizing.

Definition of Done
A team's definition of done should include references to debt or mottos reflecting their commitments to quality levels and delivery capabilities.  While an exhaustive list is not required, the list should be detailed enough for the team to ensure that norms and accountability is congruent across team members.

Responsibilities
Team responsibilities should be clear and team members should take collective ownership of the application.  Team members should be empowered to raise debt issues during planning or development, and owners, managers, and customers should respond with an updated priority accordingly.  Team members have the responsibility to question a de-prioritization of debt reduction. 

Team Should be Savvy Enough to Communicate Business Impact
The team should provide the business impact of a debt item in order for a product owner, manager, or customer to properly prioritize.  Development managers and leads should provide leadership to the team to ensure that business strategy and current and future needs are understood.  Junior team members can collaborate with more senior members to deliver the impact.

The team can use simple tools to map debt items to system quality attributes or non-functional requirements--where those attributes and requirements are then standardized as requirements for applications under that business strategy.  For example, the availability of a system can be affected by an implementation or release process that reduces the availability.  An enhancement to the release process could meet the availability requirements.

Reward Quality
Debt can be traced to quality at some level--affecting the quality itself, or the ability to reach the quality level faster.  A team rewarded for quality or with a focus on quality can be led to better prioritize resolving debt before tackling another feature that would increase the amount of debt.  While managers and leads must be careful of putting too much emphasis on the reward (the team could then game the system), incentives for matching the team's quality commitment can help the team focus on their responsibilities in this area.

Management Leadership
Managers and leads should remove any barriers that rob the team of their right to craftsmanship and pride in their work.  Team members want to do their best and take pride in their work without the fear of being questioned over their test coverage or automation additions.  Management should identify problems in this area and remove them by having the team commit.

Tackling and managing debt (technical, configuration, or quality) needs daily attention.  Team members need to implement together, identify and radiate the debt, and be responsible for communicating the impact of the debt.  Managers and leads need to provide leadership to ensure roles on the team are adhering to their commitments.

Those managers and leads using the practices covered here will enable their teams to effectively get their debt ready and prioritized for resolution.