Jeff Howey, cPrime’s Agile Coach, presented at the first LA Agile MeetUp at Ozumo Restaurant in Santa Monica. We had about 30 guests in an intimate room with saki, beer and Japanese appetizers. Attendees listened to Jeff’s presentation on why Agile is gaining momentum in software development communities. He spoke about how to uncover the about the Scrum and Kanban frameworks, where they fit, how they work and how they differ. He explained how to define metrics and goals that measure successful project delivery and team performance.

We asked people at the beginning of the session to write responses to two questions we have: Why they attended the meet up and what are their challenges in their companies?

A few attendees answers below:

Why You Came?

• “learn about Kanban”
• “finding a scrum master role”
• “meet other people who work in Agile software development environments”
• “we’re here to meet other agile practitioners and build a network to turn to with questions
• “meet other scrum masters and share challenges and find a coach!”
• “to learn more!”
• “meet other people and hear good ideas”
• “professional networking”
• “learn more about agile and scrum!”

What Are Your Challenges?

• “managing infrastructure projects and story estimation”
• “scrum meetings not turning into status meetings”
• “incorporating agile practices into matrixed support/infrastructure departments”
• “how agile is being used at different companies and the challenges and you over come them”
• “how to know if Im doing agile right”
• “implementing a PMO for CRM”
• “convincing clients to use agile / scrum”
• how quickly ramp up new team members with in scrum context”
• “incorporating UX people into scrum teams and work flows”
• “scrum is too popular! and they want me to implement for every department”
• “finding the right people to train as scrum masters”

To get your questions answered, come to our next LA Agile Meet Up! http://www.meetup.com/LA-Agile-MeetUp/

I would like to thank everyone who joined us!! A special thank you to Jeff who gave a spectacular presentation on understanding Agile and it’s momentum in the software communities. Ozumo’s food and drinks were delicious and the accommodations were remarkable. We are excited for more La Agile Meet Ups to come! We had more guests than expected and the excitement in the room was definitely felt.

Set Up:

The Beginning!

Agile, Saki, Beer and yummy food!

This sprint, the team has finished planning and has committed to delivering five stories, totaling 25 story points (sized 8, 8, 5, 2 and 2). Based on their velocity from the past few sprints, this seems like a reasonable commitment.

Shortly after the beginning of the Sprint, without talking to anyone else, Doug goes and talks to Product Owner Sue about a great idea he has. He’s come up with a way to find the user’s location via IP address, turn that into a street address and pre-populate the shipping address when they buy a book. (We will ignore the shocking privacy implications). He pushes hard and convinces Sue that this will be great addition for the product and promises her it will only take a week to do. Sue says “sure, go for it”. At this stage neither Sue nor Doug has said anything to the rest of the team.

During the next few days, Doug doesn’t attend the Daily Scrum, nor does he appear to have committed to any tasks on the tasks wall. Four days into this, he comes to the Daily Scrum but when he answers the question about “What did you complete yesterday?” he’s evasive. Nobody can really understand what he says he’s working on. ScrumMaster John is confused. After standup he digs through the Source Code Control logs to see if Doug has checked anything in since he disappeared. Then he asks Martin and Ian if they know what Doug is working on. Everyone draws a blank.

John asks Doug if they could have a chat saying: “I can’t see from the story board what you’re working on right now can you help me understand?”. Doug says I’m working on something important right now and I’m really too busy to talk.

What are John’s options?

Analysis

At its heart, Scrum helps to build collaborative high performance teams. While he’s well intentioned, Doug is not modeling the Scrum values. He’s not being open/transparent nor is really focused on business value.

Doug’s actions have several affects:

• Commitment – By doing unplanned work, he makes less likely that the team will meet their commitment for the sprint
• By doing work that wasn’t part of the Product Backlog, we don’t really know if this feature has value to the business
• Estimates – The estimation wasn’t done with his teammates so no one was there to question his assumptions
• Quality/Fit – We’ve no idea of what he’s working on is a good fit for the rest of the product, both in terms of the UI and also the shape of the code
• Code review – his code has not been peer reviewed (either pair programming or code review)
• Trust – By hiding from his teammates, he has effectively said he doesn’t trust them
• He signals that being closed is ok on this team
• Regulatory risk – if team has to comply with SOX or other regulatory framework, this code can’t be tied back to meaningful requirement

Doug has become a cowboy or rogue.

What options does John have?

• Confront Doug right away
• Invite him out for coffee and ask him what’s going on
• Find a way to bring the issue up with the whole team right away, without turning it into a blame and shame
• Let the rest of sprint take its course and let the team struggle to make the commitment – then discuss in the retrospective.

Side note: My Reccomendations

I never find confrontation solves any problems and as Doug has already said that he doesn’t have time to talk, I prefer the last option – let the team discover the problem on their own. We want to grow their self-organizing muscle. This is a good way to start.

I think the key for John is to have a good retrospective agenda ready so the team can delve into the issue without making it personal. This would be one of those occasions I would ask a team member to read and remind us of what the Retrospective Prime Directive says: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”. I would have several activities available to me and choose which one to use depending on what the team is discovering. In situations where we have things to discover, I find the Retrospective Timeline a good start: Patrick Kua has a great summary and Simon Baker has another example. In this case the activity seems like a good fit because it will not only reveal what Doug did, but also what happened with the rest of the Sprint. This way it won’t seem like Doug is being picked on.

Back to the Story

John decides to let it ride until the end of the Sprint and see what happens.

Doug hardly engages for the remainder of the Sprints and the team gets visibly more frustrated. The 2nd to last day of the Sprint, Doug checks in a large batch of code for his “feature”. However the code lacks unit tests, hasn’t been peer reviewed nor is it well tested. During the Sprint Review Doug demonstrates his feature and its clear it has some bugs. The rest of the team has struggled and just missed the original Sprint commitment delivering 21 of the 25 points.

Before the Sprint Review, John has surveyed team members to see if they would be comfortable with Product Owner Sue attending the Retrospective. Everyone said yes. John started with the EVSP (Explorer, Shopper, Vacationer & Prisoner) warm up activity and then launched into the timeline. Populating the timeline, Doug added his work on the location feature. When it came time to label emotions Doug put lots happy marks for the times corresponding to his feature while the rest of the team noted either surprise or sadness. This lead to a discussion about why team members had made the notes they did and Doug started to realize how the rest of the team perceived his actions. By the end of the Retrospective the team had agreed that in future if special projects were warranted, they had to be discussed with the team first and placed on the Storyboard so they would always be aware of what the others were working on.

What other options do you see John as having? How would you have handled it?

Part of an ongoing series called Scrum Master Tales. The series covers ScrumMaster John and his team as they develop an online bookstore.

Atlassian’s fourth annual San Francisco user conference, Summit, held on May 30^th through June 1^st 2012, will bring together hundreds of customers, partners and experts to explore what makes a technical team work together artfully. cPrime’s training track will help bring understanding to Atlassian’s users on Agile best practices and how to implement Atlassian’s Agile project management tools, such as GreenHopper for JIRA, within Scrum and Kanban environments.

cPrime is pleased to be announced as the Agile tool training provider for this year’s Summit which will host over 1000 people at the Design Center Concourse in downtown San Francisco. The Summit gives product and service teams a chance to learn about team efficiency and creativity in seven distinct tracks about the product and service development life cycle, case studies and how-to’s, and eight training work-shops for users. Attendees, including technical teams, agile developers, project managers, advanced users and plugin developers will spend three days together, collaborating, exploring and networking.

cPrime’s Agile Practice Lead, Kevin Thompson, is hosting the Agile training track on Scrum and Kanban with GreenHopper.  The class will give users an introduction to Agile best practices and how to use Atlassian tools to implement them. Topics include planning feature development for a Scrum team, applying Kanban for maintenance releases or queue based teams, and scaling Agile in an Enterprise. Users will learn how to interpret reports and drive continuous improvement within their teams. The intended audiences are ScrumMasters, Product Owners, Project Managers or anyone in a queue-based role such as Operations. The training does not require any prior knowledge of GreenHopper.

GreenHopper adds Agile project management to any JIRA project for software development teams practicing Scrum or Kanban. GreenHopper helps users with Scrum and Kanban planning, visualizing and managing workflow, estimating and planning sprints, and monitoring and reporting burndown charts. The tool allows for a simple integration and set up with universal JIRA plugins.

Kevin Thompson has been working with and training Agile development teams for over five years and has thorough understanding of the GreenHopper tool along with the pain points of Agile tool adoption. His training will bring practical knowledge to users through exercises and activities to show how to overcome pains such as distributed teams, hybrid projects and agile planning. Unlike conventional feature-based training, Kevin’s students will work through real-life scenarios to define requirements, plan work, and track progress, across all roles in the project.

Kevin Thompson is the Agile Practice Lead at cPrime, a project management and Agile services company. cPrime has helped over forty enterprises adopt Agile methodologies through Agile training, coaching and assessments.  Included in cPrime’s Agile training curriculum for organizations is an Agile Lifecycle Management (ALM) tool training which includes Atlassian’s GreenHopper. cPrime will continue to provide organizations with Agile tool training in GreenHopper and guide companies through successful Agile adoption.

cPrime is pleased to be invited  as Atlassian’s GreenHopper tool training provider for this year’s Summit and is excited to see their partnership grow.  For more information on the Summit and how you and your team can attend please visit summit.atlassian.com.

The Scale of Professional Responisbility is a simplified version of the PMI’s Professional Code that cPrime uses to help project managers decipher best practices with regard to business ethics and the Professional Code. It is a great tool to help project managers gauge the best way to respond to questions on the PMP Exam that may pertain to the Professional Code because information on the scale is greatly condensed and visually laid out in a way that is easy to understand and absorb.

One side of the scale is classified as “Always Do”, actions laying closest to this end should be utilized as often as possible. The other side is classified as “Never Do”, actions laying closest to this end should be avoided as often as possible. There are some actions that are questionable, and lie some where between the two sides. Actions that fall below the center divide are technically classified as “Never Do’s”, so when considering one of those actions, do so carefully, and thoughtfully. These “gray” actions, for example,  understanding, taking action and deferring require more consideration of the surrounding circumstances, however, knowing which action trumps another on the scale will help you decide what is best to do. By knowing where certain actions lie in the scale and being able to translate one from another will help out on many PMP Exam questions.

How to these translate to day-to-day tasks

• Obey The Law – Pretty straight forward, do not do anything illegal
• Follow Company Policies – These differ among companies, so be sure to find where they are explicitly written
• Adhere to PMI Processes – You MUST Know these!
• Transparent – You want to be open, upfront, communicative and clear
• Understand – Assessing, researching, asking, discovering, listening etc.
• Take Action – Actively doing something, making any changes
• Defer – Postponement of any kind
• Confidential – Hiding details of a situation with any party
• Escape – Canceling, quitting, resigning, etc.
• Report False Data – Any type of falsification, twisting information, etc.

Below is the Scale of Professional Responsibility:

The Scale of Professional Responsibility

Paul’s educational background is a PHD in EE from UC Irvine and he is PMP and CSM certified professional.

Here is what Paul’s manager had to say about him – “Paul has been a great addition to the team and has really adapted to our environment quite well.  He recently took over the financials for our program and has impressed the finance team with his detailed analysis of our program finances.  The running joke with me and Paul is – “ I told you so…” because there have been several occasions where he has called out something that I didn’t heed – to only have him come back to say – “ I told you so…” J. Paul has always preached and lived up to the themes of – Adaptively , flexibility, and accountability.  I am happy to see he is being recognized for his outstanding efforts.”

Learn more about cPrime’s consultants and Program Management Services.

By: Kendrick Burson, Agile Coach at cPrime

cPrime’s production pre-printed task and story post-it notes is the next generation to help new teams to organized their data in a standardized way on the post-it pads.

Every team I have ever worked with uses post it notes for planning, and most use these notes for a physical sprint task board that they reference in their daily standup.  The physical notes provide a more tactile, visceral connection with the stories and tasks throughout the sprint.  These post-its are generally only used for sprint planning and this sprint task board, not for general product backlog work.

Story cards contain a header band at the top that allow the story id (from online tool such as Rally or VersionOne), a story name, owner priority and team estimate.  The rest of the card is given to the story narrative, and maybe the acceptance criteria (which are often put on a separate note, paper or on the back of the card).

The task card that teams I have used usually have a similar header [Story ID] [Task ID] [Estimate in Hours].  The rest of the card is used for a brief description of the task.  These cards are always the smaller 3×5 or 3×3 cards to limit the information put on the card (avoid analysis paralysis).

When used in Sprint planning, the Scrum Master will have the story cards pre-printed or filled in with all the information from the sprint backlog and attached to the wall, laid out for easy viewing. The team reviews each story and discusses the design details with some Q&A with the product owner or Subject Matter Expert.  This process often involves modification to the story or acceptance criteria (especially if the story was not previously groomed). Once they are comfortable they vote on an estimate; often they accept the pre-existing estimate from backlog grooming or affinity estimation exercises that occurred earlier.   After they have reviewed established estimates for enough stories to fill their sprint (according to team velocity or capacity) they then turn to task break-downs.

For the task-break down, they return to the top story and discuss what tasks would be necessary to accomplish the story as specified.  This usually involves deep discussions on design and architecture.  The Scrum Master is often challenged to hold the team back from diving too deep and getting lost in analysis paralysis. Mature teams will break out into sub groups, pairs or individuals to do task breakdowns on multiple stories in parallel (one sub-group per story).  After the stories all have guestimated task breakdowns the team reviews each story with their task breakdown and makes modifications as seen necessary by the team as a whole.  In the end each task is ratified for appropriateness and communication of intent as well as estimated in hours to complete.  These task estimates are then rolled up and compared to the story estimate (in story points) and reviewed if adjustments in the story estimates are necessary.

After sprint planning, the story cards and task cards are often placed on a sprint task board. This sprint task board is used to communicate, track and manage the sprint backlog throughout the sprint progress. Developers will move individual task stickies from a pending or ‘to-do’ state through ‘in-progress’ to a ‘done’ state.  Finally, after all tasks for a story are completed the story is reviewed by the product owner and the story card is moved to ‘accepted’, or new tasks are created to finish the story to the product owners satisfaction.

At the end of the sprint, all the task and story post-its are thrown away and sprint planning begins anew with new stories pulled from the top of the product backlog. In order to maintain historical reference data, and for broad communication, the product backlog and tasks are maintained in parallel in an online tool such as rally or versionOne. In many teams, the Scrum Master volunteers to maintain the online tool to free up the developers to write code.

Post-it notes have been used for the past decade to manage iteration work details.  Online tools have been appearing to help organize, manage and mine this data as well as make it accessible to people located outside the team area.

Get your own cPrime Story and Task Template Set

Discussions about project planning and project management tend to focus mostly on understanding requirements and creating schedules. These things are important, but it is also important to understand that the work of a project is done by people. If we have a fixed set of people available for the project (often, if not always, the case), we need to understand how much work they can do, in order to understand the scope that can be delivered in a schedule, or to estimate a schedule derived from the scope.

A common approach to scheduling for plan-driven projects defines tasks and their dependencies, estimates the effort per task, assigns individuals to tasks, specifies each person’s availability, performs resource leveling, and produces a schedule for the project. This process can be laborious and require many iterations to get an adequate result.

The Agile perspective on resources is oriented towards Teams, rather than individuals. It assumes that a Team is a persistent group, which has the combination of skills required to do the project work, and which self-organizes to identify tasks, assign owners, and do the work as quickly as possible. Because of the Team orientation, resource calculations focus on determining how much work the Team can do, rather than on how much work each individual can do. As a result, the effort involved in performing this analysis is much smaller for an Agile project than for a typical plan-driven project.

The basic unit of effort is the person-hour, which represents one hour’s work by one person. This unit is not related directly to duration: Two people who spend a total of four hours each doing some kind of work (say, shoveling sand) expend eight person-hours of effort, whether they do all of this work on one day, or in increments across several days.

Our starting assumption for Agile Teams is that different types of work, involving different skills, can be treated as equivalent for the purposes of estimating the team’s total capacity to get work done in a specific period of time. This assumption is almost never literally true, but the resulting estimate often turns out to be surprisingly effective in practical terms, for reasons we will consider later.

Agile projects typically break the work of implementing and validating requirements into a set of tasks (the task breakdown) associated with each requirement specification (the User Story). Most Agile projects estimate tasks in units of person-hours, so our goal is to determine how many person hours of work a Team can perform in a particular period of time, such as a Sprint or Release. (The Scrum process uses the term Velocity for the amount of work a Team can do in a Sprint.)

Ideally, we would find out which hours in the workday each person will be working on implementation and validation of requirements, over the period of interest, and add up those hours for all people on the Team. Unfortunately, this information is not likely to be available, so we will fall back by building a resource model for the Team.

Our resource model will consider these factors:

• Number of workdays in the period (at five days per week)
• Number of Team members
• Known meetings or activities which involve the whole team, during which no one is doing the hands-on work of the project
• Planned time off for each person in the period
• Fractional availability of each person for work when not in known meetings

The approach is straightforward for anyone who knows how to use a spreadsheet.

1. Multiply the number of workdays in the period by eight (hours per day) to get the total number of “Work Hours” hours in the period.
2. Subtract the total time allocated for whole-team meetings. This result is the “Net Work Hours,” and is smaller than the total “Work Hours.”
3. Get the availability and time off for each person. For each person, subtract time off from Net Work Hours, and multiply the result by his availability to get his individual capacity.
4. Add up the individual capacities to get the Team capacity in person hours, and divide by eight to get the capacity in person-days.
5. Divide the Team capacity in hours by the Work Hours to get the Net Team Resources, which is the effective number of full-time people on the Team.

For example, let’s consider a one-week period, with five working days. We’ll assume that the complete Team has several meetings, which add up to 8 hours, yielding a Net Work Hours of 32.

Next, let the team members have availability and time-off values from the table:

The hours for each person are shown, and sum to 124.16 person-hours (or 15.5 person-days) of capacity for the whole team.

An interesting byproduct of this analysis is the discovery of how severely meetings and other distractions reduce the Team’s ability to do work. The example shows results for a Team of seven people, but the effective number of full-time people is less than half the actual Team membership.

Now, what about the problem of specialization? Doesn’t the fact that some tasks require specialized skills, which only one or two people on the Team may possess, make this result meaninglessly optimistic? Strangely enough, the answer is, “No,” at least much of the time.

Task breakdowns typically consist of a mix of specialized tasks and general tasks, where general tasks can be done by more than one person. As long as the effort of the specialized tasks does not dominate over the remainder, the above approach is effective. (Of course, if the degree of specialization is great enough, more sophisticated analysis is required.)

In conclusion, the agile approach to estimating how much work can be accomplished in a particular period of time is team-oriented, rather than individual-oriented. The team-oriented analysis is effective as long as specialized work does not dominate over general work.

[Try our free template for estimating capacity of Agile Scrum Teams!]

Be sure to follow up this blog by watching our video on “How to Effectively Read Questions on the PMP Exam”.

If you’re preparing for a certification exam, work backwards. At cPrime the focus is on Project Management and especially the PMP, but this method is a sound for any certification exam that uses multiple choice questions.

What does “work backwards” mean? When attempting to answer a multiple choice question, read the answers before the question. Therefore, work backwards. This method works well for questions that are a paragraph in length, not a single sentence. To prepare for a certification exam, master reading questions through practice. Deconstructing multiple choice questions is a skill that improves with repetition over time.

Here’s the steps:

1)      Read the question mark (usually the last sentence of the question.)

2)      Read the answers.

3)      Eliminate wrong answers if possible.

4)      Read the question.

5)      Reevaluate the answers eliminated.

6)      Make a selection.

Below is a sample question that we will use as a demonstration. Don’t be tempted to read through the question. Follow along with the instructions and see the usefulness of this technique.

Step 1 – Read the question mark. Scan the paragraph for the last sentence. It asks, “What is the best way to proceed?” The logic here is to read for direction and emphasis. Is it “best,” “least,” “first” or perhaps the thing to “never” do?

Step 2 – Read the answers. Here four choices are presented.

Step 3 – By process of elimination discard answers that are least appropriate in relation to Step 1.

a)      “Ignore…” Eliminate questions that “ignore.” Once something has been revealed it most likely can’t be ignored.

b)      “Disclose…” Acceptable. Keep it for consideration.

c)       “Discuss…” Questionable. “Discussion” is good, but “consensus” is questionable. PMs do not operate in the world of consensus.

d)      “Take…” Eliminate answers that defer authority to senior management. Project Managers should know their level of authority and know how to proceed without checking with senior management.

Step 4 – Read the question. After you have a sense of direction and the answers, read the question from an informed position.

Step 5 – Reevaluate. “A” and “D” remain eliminated. Answer “B” is still acceptable. “C” was questionable and is now eliminated.

Step 6 – Select. “B” is the best choice in this example.

SAMPLE QUESTION 1

Your company is managing a software implementation project for a fortune 500 client and you are the Project Manager. Several months into the year-long project two of your project team members begin debating about how to proceed. One of your team has discovered the client has problems with their procedures and gaps in their processes. This discovery is within the bounds of information the team needs to know to implement the software, but the solution to this discovery is hundreds of hours of additional consulting work that is beyond the statement of work. Another team member is adamant about the need to stick to the statement of work, and that bringing up the discovery could delay the project by months, or even cause the client to cancel the project entirely. What is the best way to proceed?

a)      Ignore the discovery and stay within the bounds of the statement of work.

b)      Disclose the discovery to the client, even though they might believe you are trying to expand the contract.

c)       Discuss the situation with the entire team and come to a consensus how to proceed.

d)      Take the situation to senior management.

Please add a comment if you have any suggestions or find these tips helpful!

Gary has been an outstanding Program Manager that has led major initiatives with two of cPrime’s largest clients for more than 2 years. He is widely recognized by his peers and executive leadership as a “rockstar”! He is well respected by his teams and has delivered on very challenging projects with William Sonoma and Macys.com. cPrime is very lucky to have him on our team!  Congratulations to Gary Goldstone, cPrime’s December 2011 Consultant of the Month!

I’ve rarely run into scenarios where a 2 or 3 week time frame from User Story to Release was seen as a bottleneck – especially with history working on 18-month projects in my (not-distant-enough-to-forget-the-pain) past.  However, during a recent class, I was challenged by a savvy Scrummer with the question, “What if Scrum isn’t Agile enough?”  It took me a moment to grasp the gravity of the question before me.  Scrum?  That which I espouse as an ideal (albeit, not the only) way to deliver customer value frequently and regularly?

After just a few minutes of deeper investigation, it became clear that 3 weeks was not too long for this particular querent’s customers.  In fact, their customers were delighted that they could put forth a request and see it come to fruition within a month (if it was of sufficient priority, of course).   It was the Scrum Team itself that was concerned that they could frequently turn around functionality more quickly if they weren’t bound by a 3 week release schedule.  They, wisely, wanted to avoid Sprints that were much shorter as a majority of their backlog fit nicely into 3 weeks.

Lucky for me, the question came only 10 minutes before I planned to tackle training material that started with “Kanban: Where it fits.”  Rather than delay the discussion, we tabled our deep-dive into Scrum and regained the attention of a few audience members by flipping to that section immediately.

Call it Kanban, call it Lean, call it whatever you like (I know this article will ruffle a few feathers with the use of any of these words), but the point is this: Agile itself is meant to be agile – to identify what is needed and to do it.  “We value… working software, customer collaboration and responding to change,” after all.  As an Agilista at heart, the goal is to deliver value as quickly and sufficiently as feasible. (note the period at the end of my last sentence)

This particular team supported a robust reporting platform that crossed multiple data sources and business units.  They worked aggressively to groom their Product Backlog on a regular basis, pointed every Story, crossed every “T” and dotted every “I” in the Scrum Guide.  Scrum was working well for the team and their customers.  But they still felt something could be done more quickly with some of their User Stories.

The stories at issue generally revolved around minor changes to existing features – such as adding additional validation or selection criteria to reports, modifying existing data field structures, incorporating ad-hoc data from external sources into their data warehouse.  During our discussion, the team indicated that initially many of these User Stories were given a point value of 1 because they were so small.  After several Sprints, the team revised their pointing structure to attempt giving more valuable information with their Story Points (a noble effort) and created a new set of criteria to help the myriad “1’s” in the backlog break out into at least something through 5. This did not feel right to the team as it was not very useful to anyone but themselves for identifying effort.  They then discussed combining multiple requests into one larger epic to be sized and tasked; but immediately voted down the idea (rightly so) as it was seen as simply a planning tactic and would cause confusion all around.  The team was left dissatisfied as the Story Points were not incredibly meaningful and the tasking discussion during Sprint Planning often took as long as making the code change would take.

Eliminate waste! The team was ready.  My only question to the team was this: “What if some portion of the team’s time was spent just working down the list of priorities?” Within minutes the team felt validated with ideas they had already discussed – but felt broke the “rules” of Scrum.  They had identified that they could sacrifice one team member per Sprint to focus on these issues.  But, it is not a principle of Agile to sacrifice a teammate to anything, even if the more mundane tasks were rotated.  During our few minutes of brainstorming down the bunny trail, the team identified that they could carve out 10 hours of their Sprint Capacity every Sprint to focus on delivery of these prioritized requests and actually improve their overall velocity by removing the overhead of the Scrum rituals related to these small bits of work.  As an added bonus, nobody had to be sacrificed.

The next steps were quickly evident.  Beginning with their next Sprint, the team would modify their capacity to allow for 10 hours of time on the “Hit List” (as they called it) in a FPIFPO (that’s first “priority” in, first “priority” out) approach.  Following the tenets of Agile, these were not immediately assigned to individuals – which allowed them the freedom to self-organize around WHEN the 10 hours of time would be given to the work.  This also allowed the team to swarm on priority requests and work together when feasible.

The “Hit List” is now a separate piece of the Product Backlog, but is clearly maintained in a visual manner that allows the Scrum Product Owner to see the priorities across the portfolio.  The team has empowered the Product Owner to guide the team’s allotment of time when needed.  If there are more priorities on the “Hit List” than the rest of the Product Backlog, the team may devote more than 10 hours during their next Sprint to the FPIFPO work; or less time, if other priorities are on deck.

The kicker to this article is in the moral of the story.  In the end, the team had the answer.   They had tested different ways to implement the answer.  There was some initial distress in the idea of jumping from the Scrum side of the creek to the Kanban side, understandably wanting to avoid confusion internally and with their customers.  But a little wading into the creek built confidence that it is possible, in many settings, to wade (vs. jump or swim) the waters between Agile processes.  I was happy to nudge them into the water, but through inspecting their progress and adapting to their reality, this team used their own collective knowledge and creativity to answer the question “What if Scrum isn’t Agile enough?”

Are you ready to roll up some pant legs and wade?