This is the title of an email presumably sent to all people with an account.

Dear Yahoo! Mash member, Thank you for trying out our Mash Beta service. We hope you had fun with it. Please note that we will shut down Mash on September 29, 2008. As a result, your current profile on Mash will no longer be available. We strongly recommend that you return to http://mash.yahoo.com and copy the content that you wish to save onto a separate document. For a list of FAQs, please refer to the Mash Help Page. Thanks for trying out Mash! Matt Warburton Yahoo! Community Manager

Please do not reply to this message. This is a service email related to your use of Yahoo!. To learn more about Yahoo!’s use of personal information, including the use of web beacons in HTML-based email, please read our Privacy Policy. Yahoo! is located at 701 First Avenue, Sunnyvale, CA 94089. RefID: lp-1017654

There is also a blog post with mostly the same content. When I first saw the subject of the email, it really did not surprise me. The only people it may affect are the 360 loyalists, who would snicker behind their hands, was one of the first thoughts. Turns out, they’re getting shut down, too. It makes sense, and feeds in to the overall universal profile strategy.

After VYC2.0 launched, I was asked who were the heroes in the group. The one or two people who deserved recognition for all of their hard work. I was hunting around for the email chain, but I’m pretty diligent about deleting emails. I wish sometimes I wasn’t so relentless at that, but I don’t have it. Essentially, I responded that calling out a couple of people creates competition, that everyone stepped up and deserves to be recognized. Management agreed, and everyone involved wound up with a Flip, and I was asked how we may be able to codify some whole team incentive.

My answer was pretty short in coming, as I have wanted to establish the proposed incentive program written about in the ground rules for one team I was working with doing kanban stuff.

The following is what was agreed upon by our senior management. Some things were changed, and quite drastically. For starters, credit will only be given for features/stories completed in one Sprint. When asked my opinion, I suggested this may lead to technical debt. It was also decided to have a showdown at the end of the year, and to recognize the team with the most redeemed tokens. I am afraid this is against the whole-team incentive, and once again fosters competition.

Here it is:

“Video Tokens” rewards

Team collects tokens (1) for every MMF/story that is developed & tested in 1 sprint

Eligibility:

All Video Platform Teams

Selection criteria:

MMF/Story must meet acceptance criteria from Product Owner, must be tested and bug-free

Selection process:

At the end of each Sprint, Scrum Master will review Sprint deliverables and compliance w/ selection criteria. Tokens are awarded to a team.

Timelines:

End of each sprint

Rewards:

Finished features can be collected by the team and redeemed for rewards. Team can decide to either redeem their collected points or wait to accumulate more points for a higher reward

• 10 = Beer and snacks for the next Review & Retrospective
• 25 = Team Lunch
• 50 = Movie passes
• 100 = Day off

ALL tokens collected and/or redeemed are counted annually when team enters into Annual Token Standoff.

Program Facilitator

Scrum Master or Program Manager

The following was written by myself and edited by my manager to help define roles in our group. Modifications have consisted of removing any reference to the specific group. This is largely influenced in the writing by David Anderson‘s book Agile Management. Most of the wording for the roles of Product Owner and Scrum Master come from the Scrum Alliance, with specific cites on the role’s title. Influences in the editing have a decidedly more traditional feel to the statements, and leaves one feeling they are behind the steering wheel of some analogous car.

Agile Team Members – Roles & Responsibilities

The key to successful team building is creating unity while celebrating the individuality of each team member => Common purpose supported by unique contributions

• Team is held responsible for a release, individuals are held accountable to their commitments
• Each team member has one or more roles on a project
• When a team member has more than one role on a project, potential conflicts may occur. Always think checks & balances before signing up for multiple roles

---

• Team Members – Roles & Responsibilities
  
  • Program/Release/Project TEAMS
    • Program/Release/Project CORE Team consists of:
      • Representing multiple TEAMS as a Core Team member
      • Scrum Of Scrums
      • Representing multiple ROLES in a Core Team
    • Scrum Team consists of:
  • DESCRIPTION of Roles & Responsibilities
    • Product Manager aka Product Owner
    • Program Manager
    • Architect
    • Engineering Manager
    • Product Developer
    • QA
    • UED
    • Operations
  • Role comparisons
    • Program Manager vs. Product Manager Comparison
    • Advantages to PMs and EMs having a Program Mgr on a project

Program/Release/Project TEAMS

Program/Release/Project CORE Team consists of:

• Product Owner (aka Product Manager)
• Engineering Manager
• Architect
• QA Manager
• Program Manager (aka Project Manager, Scrum Master)

Representing multiple TEAMS as a Core Team member

• Cannot attend multiple stand ups
  1. Scrum team too large and being split
  2. New teams being formed
  3. One core team member on multiple Scrum teams
• Stagger daily stand ups
• Attend one stand up and send a proxy to the other

Scrum Of Scrums

• Starts ON TIME
• Attendees
  1. Core team members
  2. VP of the group
  3. All other VP direct reports
• Scrum Master is the Director of Program Management
• Product Owner is the Director of Product Management
• Program or Project Manager (Scrum Master) for the project answers the following
  1. What was accomplished on the project yesterday?
  2. What is happening today on the project?
  3. What is blocking the project from progressing to deployment?
  4. What are other projects with which this one is being integrated?
• A proxy of another core team member who attended the daily stand up can answer if needed
• Product Owner provides business and domain answers for clarification of project direction
• Side conversations are parked and follow-up meetings arranged
• Scrum Master records all blockers and follow-up arrangements
• Scrum Master lists out existing blockers and follow-ups made
• VP prioritizes blockers
• NOTE: Every attempt is made to resolve all blockers in the day they are raised.

Representing multiple ROLES in a Core Team

A core team member might have for example, both the roles of Product Manager and Architect; or a team member may be Scrum Master and Engineering Manager. In some cases, there can be a potential conflict of interest. In the first case, this could be a person with great, wide vision for a product. In the latter, this is a coalescing of authority and responsibility. The person responsible for protecting the team from interrupts with outside work now has great influence to interrupt someone working. Please use due diligence in volunteering for, or assigning people, multiple roles.

Scrum Team consists of:

• Scrum Master role – usually Project or Program Manager but can be anyone on the team
• Product Owner role – usually Product Manager but can be anyone on the team
• The Team of 7 people, +/- 2, Responsible for Task Completion :: Development, QA, Architect, OPS, UED Engineers, etc
• Core Team

DESCRIPTION of Roles & Responsibilities

Product Manager aka Product Owner

Role definition

• “CEO” of the product
• Vertical – focus on long and short term product vision of a product line
• Represents customer’s interest
• Represents the product to the outside world (Customer)

Responsibilities Responsible for market, business case, and competitive analysis Responsible for long and short term product vision Responsible for ROI and Net Profit Prioritizes features for releases based upon expected ROI Writes Acceptance Criteria Writes user stories Makes tradeoff decisions between scope(value in Expected ROI) and schedule(higher operating expense in longer release cycles)

Challenges Resisting the temptation to “manage” the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself. Resisting the temptation to add more work Being willing to make hard choices during a planning meeting. Balancing the interests of competing stakeholders.

Program Manager

Program Managers can perform both Project & Program Manager roles. On a Scrum team, Program Managers usually perform both Program Manager & Scrum Master roles unless another team member is assigned to be Scrum Master.

Role definition

• Horizontal (Across the product lines, projects, x-functional teams)
• A rational voice to drive the cross-functional core team to solve problems and make decisions
• Impartial – not biased to Product, nor to Engineering, nor any other group

Responsibilities

Program Management responsibilities Manages planning process Manages overall program schedule Drives multiple releases/projects Facilitates Release Planning & Retrospective Provides access to tools and people Owns all action items for the project until he/she finds the right owner Owns reporting on project status, to all directions Coordinates other release support Responsible for risk assessment & mitigation The Role is a peer to the Product Manager and the Engineering Manager on the release/project Educates/Enforces agreed upon processes & methodology rules Educates/Enforces roles and responsibilities

Scrum Master responsibilities Manages 1 sprint at a time Facilitates Sprint Planning, Review & Retrospective Finds and works to remove roadblocks Helps to motivate the team and keep them excited Protects team from outside distractions Facilitates communication between roles for every aspect of the project Responsible for keeping release/project information consolidated, organized and up to date Drives the cross-functional team at all levels Responsible for throughput (team velocity) Drives the execution of sprint items

Architect

Role definition

• Leads the technical direction of overall system

Responsibilities

• Responsible for end-to-end cross functional system design and communication
• Works with the PM to group features based upon the Architectural Elements which support them, an influence on priorities
• Tests Architectural Elements with executable and testable design (abstract interfaces, aka the contract)
• Facilitates technical decision; incorporates feedback and emergent patterns from the team back in to the overall design
• Produces alternate Design Concepts & detailed approach
• Ensures the Design goals – Performance, Modularity, Reliability, Maintainability, Reusability, Internationalization and Accessibility – are met
• Ensures technical cohesion and helps write the technical contract in interfaces and other abstract objects and data entities
• Leads design review & provides feedback

Engineering Manager

Role definition

• Ensures the successful completion of Work-in-progress (WIP)
• Understands the process of product creation

Responsibilities

• Responsible for rate of production and lead time (what each engineer needs to fulfill their commitment)
• Responsible for initial high level sizing
• Works with the architect and the team to prove technical integrity
• Responsible for conducting forward leaning technology investigations (spikes)
• Negotiating with architect on technical approaches
• Removes most bottlenecks
• Enforces engineering best practices
• Ensures motivation of their team
• Assists career development of team members
• Conducts focals

Product Developer

Role definition

• Responsible for creation of product

Responsibilities

• Estimates size of backlog items
• Translation of backlog items into engineering design and logical units of work (tasks)
• Evaluation of technical feasibility
• Implementation of backlog items
• Writes unit tests first to the contract of the interface and other abstract classes
• Writes and verifies code which adheres to the acceptance criteria
• Application of product development best practices

QA

Role definition

• Prevents defects from entering the system, as opposed to finding them at the end
• Facilitates building integrity into the software product and development process

Responsibilities

• Writes test plans which enforce the acceptance criteria of features
• Keeps all test plans and cases updated to changing requirements
• Continually integrates the code base with automated builds and functional-level regression tests
• Notifies when production is blocked due to errors in development
• Measuring Quality
• Defining Quality
• Improving Quality
• Enforces QA Best Practices
• Provides visibility into end-to-end product quality
• Owns QA Health status of releases/projects in SM dashboard

UED

Role definition

• Integrating the human factor in to features

Responsibilities

• Responsible for overall UI consistency across interaction models and visual styles
• Upfront user research (to help inform features/direction)
• Interaction Design specs (wireframes, user flows) which conform to acceptance criteria of the features
• Works with the PM on analysis of features conform to user’s needs and provide a consistent experience
• Ensures features are implemented as designed, and design modified to reflect implemented features
• Visual Design
• Prototyping
• Usability testing

Operations

Role definition

• Keep products running in production

Responsibilities

• Design hardware configurations for BCP, security, monitoring, availability during product design stage
• Responsible for getting the required hardware using the “HRC” process
• Set up staging, production environments (and in some cases the QA environment)
• Post production monitoring, and troubleshooting of product/services
• Owns OPS Health Status of releases/projects in SM dashboard

Role comparisons

Program Manager vs. Product Manager Comparison

• Product Manager: owns the decisions on the project tradeoffs
• Program Manager: owns the execution of the project based on those tradeoffs
• Product Manager: owns the product vision: overall and per-project
• Program Manager: owns the execution of the vision for each project

Advantages to PMs and EMs having a Program Mgr on a project

• Both are freed from doing all the program/project work!
• The Product Managers can focus on their true mission:
  • finding the most value in the smallest scope (maximizing ROI)
• The Engineering Managers can focus on their area of expertise:
  • developing the best engineering design
  • solving technical issues
  • building products in accordance w/ best eng. practices
  • improving performance and stability

Alex, Jason and Joey are developers in our group attending the internal Hack Day going on today. The next one is coming soon. They have figured a way to fight the leeching of feeds.

So (some) sites (…) have been leaching our music video feeds for a while and we have been in a “cat & mouse” game with them. This morning at 3:40am CST… i think we won. See Video at V.Y.C

Jason had the following to tell me in a chat:

this was ~ 3:40 am
it was good times
it was a massive viral rick roll
as alot of myspacers use our leached feeds
they took down anything pointing to us
for now
we had it rolling for 3+ hours
it hit about 6-7 other leaching sites
it was epic

I’ve always been under the impression that Scrum and Sprints can only go as well as the shape of the product backlog. Having Continuous Integration in place is essential to move effectively through this good backlog. Recently, I realize I’ve been making an assumption, that there are already well-formed teams in place.

During a recent visit to one of our offices, I observed the following:

Some people are segregated to a functional unit of a manger and a couple of directs. Collections of individuals are resourced to one or more projects. These groupings create many integration points and external dependencies to other functionally segregated individuals.

With shared resourcing, whatever high-priority projects are being worked upon becomes the moniker for the “team”. Individuals then complain about the high overhead of Scrum, which I now understand when one person is on several of these project “teams”, and in multiple Scrums, with multiple standups, planning and the like. It is out of the control of the individual to select what team to work on, or what work to do. The divide and conquer approach allows people at higher positions to move these “resources” around at will.

The manager that someone works for should not determine the team they work with. Dedicated cross-functional teams of larger size need to be formed. People come together on dedicated teams. The established and dedicated teams consume backlog items of features. Dedicated teams have less hand-offs and therefore less churn. Problems do not languish for long as collaboration in these groups is tighter. These teams should be somewhat self-selecting, with guidance from leaders but an allowance for the team to include who the team wants and maybe more importantly, that people who do not want to be on a team or are not wanted by a team, are not forced to do be on a certain one.

We are now coming up with a proposal for stakeholders to sponsor piloting a dedicated, cross-functional and enabled group of individuals, and see if we can have one of the only teams in the group ready for consuming a well-formed backlog, once it is ready to be worked on.

At one of our Program Management meetings, I was asked what was absolutely necessary to do for Scrum and Sprints. I was very reticent to write up a check-list of what is needed as it will always have a prescribed, controlling feel to enforce how to work. Using a cheat-sheet like this can leave short that full understanding, of being able to grok Agile. There is so much more to it, and so very much that has been left out, or could be misinterpreted. Yet I wound up writing it. Our group is so distributed and the team was asking for this to help them. I wrote up a draft, reviewed with the team and refined, and wound up with the following:

Recipe for Scrum Basics

• Before Sprinting you need:
• To begin a sprint you need:
• While in a sprint:
• After a sprint:
• Caveats:
• What to do when trend lines go flat:
• Visual information radiators:

Necessary team size

Team additions to ensure bar is met

• Video Hub

Recipe for Scrum Basics

All of this work is required before a team is considered to be in a Scrum and Sprinting.

Before Sprinting you need:

1. Forced-ranked backlog of features
2. Backlog sized for release plan
3. Automated builds
4. Regression testing
5. End-to-end environment
   1. dev
   2. stage
   3. test
   4. CI
6. Agreement from team on sustainable working hours
   1. Between 4-6 hours a day
   2. Heads-down, uninterrupted work hours
   3. What is not included in sustaining hours
      1. All meetings
      2. Reading email or other documents
      3. Other breaks

To begin a sprint you need:

1. Enough features sized for more than one sprint
2. Enough items on backlog force-ranked for more than one sprint
3. Product Owner states goal of sprint
4. Current estimate of team velocity for calculating sprint capacity
   1. Story points finished per sprint
   2. When there is no historical data, use the first planned sprint. Combine that with just finished sprints until enough history for more accurate trends.
5. Acceptance criteria written by Prod Mgr for each feature taken in to sprint
6. Capacity in hours of the team for the sprint
   1. sustainable hours multiplied by days in sprint per person
   2. subtract out time for looking ahead to the next sprint, operations, production and other support
7. Break down one backlog item
   1. Product Manger answers any domain questions about item
   2. Product manager lists out all acceptance criteria if missing
   3. All tasks listed by team to get a backlog item to DONE and DEPLOYED
   4. Subtract hours of tasks from capacity
   5. Ask team if they have capacity to plan out next backlog item, if yes carry on and if no, stop

While in a sprint:

1. Team works on highest priority backlog items FIRST
2. Add up story points finished and track on a big visible chart
3. Track hourly burn down
4. Update WIP tasks with hours remaining
5. Have a daily stand up for no more that 15 minutes, which starts ON TIME
   1. Required participants
      • Entire team responsible for tasks in the sprint
      • Product Owner
      • Scrum Master
      • Other Core Team Members
   2. Record impediments risen
   3. Have task board in synch with where team really is at
6. After stand up
   1. Update tasks
   2. Prioritize impediments
   3. print out new burn down charts, or plot new point if chart is hand-drawn
      1. hourly burn down
      2. point take off
      3. open vs closed defect rate
7. Any finished backlog items for the day are verified with Product Owner against acceptance criteria

NOTE: Attempt to resolve all impediments in the day they are raised.

After a sprint:

1. Find average of best 3, average of worst 3 and last sprint story point totals
   1. If less than 3 sprints, use average of all and last sprint
2. Calculate trends for release
3. Review finished features now on staging from sprint
4. Retrospect on sprint process
5. Record if sprint was a success
   1. Sprint goal met
   2. All tasks created in Sprint planning are completed
   3. Success also means at least one demo-able feature on staging from sprint
   4. Success/fail determined in retrospective by team
6. Plan next sprint!

Caveats:

1. Story points are only added when a feature is DONE
   1. Meets acceptance criteria
   2. In staging
   3. Test plans executed and all features regressed without error
2. Review only finished features
3. Sprints can be aborted
   1. Know that goal will not be met
   2. Complete change in direction from previous goal
   3. Defects and other blocks to reaching goal have overwhelmed team
4. Decisions are made at the lowest responsible level
   1. Teams self organize to create and accomplish tasks for backlog items
   2. Core team strives to remove impediments to team completing tasks
5. Break down backlog items to tasks of 2-4 hours in length, with no task more than 1.5 days
6. Inestimable backlog items are the only candidates for spikes
7. Spikes are time-boxed at one calendar day (respike next Sprint or have list of new estimable backlog items)
8. The team can choose to skip backlog items
   1. Unclear and vague items
   2. Some part of technology not available for effective development
   3. Any other valid justifications from the team

What to do when trend lines go flat:

1. Do not worry about it until 10-20% in to the sprint
2. Remove lowest rank, and not started work from Sprint and put back to Product Backlog
3. Remove work which does not support Sprint goal

Visual information radiators:

1. Sprint board to show task/feature progress
2. Weekly story point take-off
3. Daily task burn down
4. Cumulative work item flow

Necessary team size

• 7 developers, +/ 2
  • Mix of all roles needed, some suggestions
    • DEV (FE/BE)
    • QA and Automation
    • Configuration and release management
    • UED/IAD
    • OPS and DBA
• 1 Product Owner
  • Represents customer and market needs
  • Answers domain questions for development team
• 1 Scrum Master
  • Protects the team from ANY interruptions
  • Facilitates communication and conflict
• Core Team
  • Product Owner (aka Product Manager)
  • Engineering Manager
  • Architect
  • QA Manager
  • Program Manager
  • Scrum Master (aka Project Manager)

Sitting on another call with a few dozen people talking about an application being developed by one full-time person. It’s one of the few things which actually brings in revenue for the group. Some of the highest priority work. It crosses the boundaries of business units and is a big bet. Seems like we should be collaborating to get out the working software using a group of talented engineers. Instead, managers of every stripe are in meetings-go-round discussing dates and pushing in more scope. The build/fix cycle lengthens and we go through levels of complete, not unlike the circles of hell.

A lot of popular folks come to Yahoo! and hang out. There are experts, authors, musicians, luminaries, – giving talks, running workshops, attending conferences, performing, and being a presence on the campus.

Our own group has had people in. I’m not sure who they all are. I hear there was Mary Poppendieck, who’s suggestion of eliminating waste may have been interpreted by a few as meaning some roles could be considered redundant. Seems a shame.

Since I’ve been around, there has been two people we’ve brought in. The first was Jim Coplien, who shook things up a bit. People are still referring to his presentation on agile architecture. We have it on video some where. I wonder if I can make it public? Worth finding out and better than me writing about it now.

Today David Anderson came in, and talked about industrial-strength, agile complimentary, product development system. This system is based in the Theory of Constraints (TOC), where customers pull value through the system. It takes advantage of mathematical fact and scientific backing in queuing theory and Little’s Law. The system is monitored real-time with an ever-changing visual board of all work in progress. Product is developed in a cadence, where success happens with enthusiasm. David calls it a Kanban System for Sustaining Engineering, and with a subtle change, it is a system for software engineering.

David Anderson Presentation Part1

David Anderson Presentation Part2

Slide Deck in the video

We have a few people here that blog, and some are listed in the blogging guidelines as experts. I sent a note out to ask see if they thought I was within the guidelines. Here’s what I got back from JR Conlin:

Hey Aaron,
The fact that you’re asking puts you in a reasonably small group of folks. The fact that you read the guidelines puts you into a smaller one.

You’re doing the right thing.

Looking at the posts on your blog, i don’t see anything that’s a red flag. (heck, I don’t see anything that’s even lightly yellow or a lovely shade of chartreuse.) Even the most recent work related post at:

http://aaron.sanders.name/lean/finding-and-releasing-a-product-development-bottleneck

discusses things from a methodology rather than “Bob was a total idiot”.

* You’re thinking about what you’re posting.
* You’re not posting up something that will come back and haunt you (my boss, the head of YDN, can tell you a nice horror story about that sort of thing and how the news folks can completely goof up regardless of your best efforts to fix it.)
* You’re not posting up something that you shouldn’t (e.g. Jerry was talking the other day about how much PropertyX sucks and is going to be shut down next month…)

I’m happy to keep an eye on things, but for the most part, i wouldn’t sweat it too bad. There are folks here that are doing far worse things than you are.

Still, if you have any questions, don’t hesitate to ask.

Oh yeah, and have fun.

With iterative software, we talk about doing all the necessary functions, such as Design, Develop, Inspect, and Release, within each cycle to increment the value of available software to the customer. Our team divides the things in progress in to these categories, and has a finite amount of slots available to each category.

Friday after the daily stand-up found me, the Product Owner (PO) and the Lead Developer discussing a constraint to work. The Design category is done with its work, but the ready slot for Development is full. The team cannot pull any work in to this area.

The Product Owner wants to give more work to the Designers. I point out this is a push and we really want to refrain from dispatching work out to individuals. Staying focused in on the Designer area, the PO wants to know why we cannot just add more ready slots for Design to put finished work in to, and allow more work to be pulled in. We discuss how the system is designed at limiting the amount of things in process, and this may not be the best idea.

Suggesting we pull back and look at the whole board, we noticed that it is Development that cannot pull more work in to their area, because they are completely filled up with work that is not finished. There is one gnarly task to fix all high-priority defects. It is a worthwhile goal, but perhaps too costly to try and battle them all.

The Lead Developer is watching our discussion and chimes in with something another senior developer has brought up before, batching up the top 5 and parking the rest. These are lower priority than other queued-up feature work. It is pointed out that really, not everybody is working at fixing defects as wanted. There is other work in progress in the Development area.

This is completely agreeable to the PO and so the work is now to enumerate those top 5, which will also help with the Inspection and Release areas to deal with a manageable batch size, too. Soon this should relieve the constraint and allow Development to pull in the Design ready work, freeing Design to concentrate on pulling in new features to work on.

It was so easy then to point out local optimization. Now with some humor and looks relieved of their tension we can chuckle about optimizing one person in Design, instead of dealing with what is really slowing things down at the moment. We part ways with a better understanding of what is going on. Happy to help in making an improvement, we know throughput will soon be on the rise.