Scale agile to the enterprise with distributed teams

Here is a podcast that might help managers and senior individuals managing multiple projects to better managing resources and planning projects.

The Project Management Podcast:Episode 231: Agile, Coffee, Tea and Trains

http://www.project-management-podcast.com/index.php/podcast-episodes/episode-details/481-episode-231-agile-coffee-tea-and-trains

Scrum Training (2/2)

User Stories

• A story typically describes “what”. Here is a simple template: “As a [user role], I want to [goal] so that [benefit]“. The “so that [benefit]” clause is optional depending on how obvious the benefit is.
• Tools: XPlanner, Rally, Scrumworks Pro, Thoughtworks Mingle, and Card Meeting. The instructor said non of the tools handles hierarchical backlogs. See also Rally vs Scrumworks.
• Architectural considerations: If your project has a horizontal architectural. You may need to build the underlying infrastructure and plug-in new features. Practically, you may need to re-factor to add new modules. Another approach is to build features vertically. The risk of this model is that specific infrastructure build for a feature may need to be changed when adding a new feature. This vertical approach can enable a team to focus only on work that is needed to move forward faster in the near-term. XP demands vertical approach. The team should balance between these approaches depending on individual situation.
• How do you work with customers who only ask for bare minimum and often time ask for more later? For such customers unwilling to prioritize or accept the expectation, they may be asking the team to incur technical debt
• Building a common glossary is important at the beginning of the project to ensure everyone have a common understanding of terms that are in-use by the team. To handle overloaded terms, use qualification to provide a context.

User and User Roles

• Gaining access to users is important. Often times, only user proxies are possible.
• When defining user roles, a guiding question is “Does the team has to do any work to support that role?”
• As a brainstorm exercise, the whole team can do a “silent grouping exercise” to quickly generating ideas. Each member write their ideas on a sticky notes and post his/her notes on a wall. If there is a redundancy, just overlay the sticky notes. If one identified a misplacement, he/she can just relocate it. This exercise should be done silently.
• Translate “As a student, I should not do…” story into something similar to “As a student, I should …”.
• A non-human system can have a role. A programmer can be a user of feature of the system. For example, “As a programmer, I want an API for deleting widgets from the database.”
• Persona is an imaginary role that usually require research and typically a team only spend the time to write a few. This can be an effective way to target the team to build the system for specific type of users.
• A good story has the following properties: Idependent, Negotiable, Valuable, Estimatable, Sized appropriately, and Testable. Not all stories will have all these properties. A story should be at least valuable or the team should ask “why keep it?”.
• If stories has dependencies or may have variable cost due to the order of implementation, the team can annotate the story.
• A comment on independence: Extract technical commonalities among stories: Sometimes necessary to break down the work but not ideal because the the customer do not receive an independent feature by the completion of the the technical commonalities.
• Perhaps writing technical stories that product owners can understand. For example: Change from “All error handling and logging is done through a set of common classes” to “As a user, I awant all errors presented and logged in a consistent manner”
• A story that says “Refactor the payroll process code” because it will give the customer 10% performance gain. This story is not a very good one because it’s not testable at end of this story’s completion. An approach to this is to embed it into a related story and be transparent with the customers rather than have an independent story. In some cases, people might not even notify the customers. This approach may cause the following situation: The team might invest time and energy to do the refactor work without letting the product owner know. After the fact, the product owner might say that why did the team invest the time when that code base might be expected to retire in six months.
• If a story is too big and you don’t have to work on it, it’s okay. If you have to work on it and it takes weeks (i.e. longer than one iteration/sprint), you might want to break it down. Sometimes if multiple members need to work on the story, you might want to break it down. For example, the story may require legal review, you might create a new story for a separate team to handle the story.
• For some stories, a team might spend some time to acquire knowledge before estimate the work.
• Some people may attach a quality template with a story that define a test, scale of the test, minimally acceptable limit on the scale, a planned taqrget, best-ever/engineering limit, and current status. This will show the product owner that if the story is done or not.

Other guidelines on stories

• Closed Stories: A story that finishes with the achievement of a meaningful goal.
• Non-functional Requirements: performance, availability and other qualities. Testable characteristic is desired for stories on these topics. Identify system level non-functional requirements as early as possible and decide when to focus on these.

Estimation

• Every estimates comes with a probability. Estimate should be relative size. This enables velocity to calculate using the same unit and enable further statistical calculations.
• To ensure similar estimations, the team should define the size, scale, and 2 reference points.
• Story points or ideal days for the story estimation? Either one can work depending on a team’s preference. Task estimation usually done with ideal days. Ideal day estimation sometimes lead to unreasonable expectation. A story with 5 days estimation, does not automatically mean it will be done in 5 days. For story point estimation, some people may feel uncomfortable understand what it means.
• For stories that you don’t know, you may break it into two pieces: 1. uncertain part 2. learning/investigation part.
• A team should not do story point driven planning. i.e. pick the top x number of points for the next iteration. This is fast and dangerous way to plan. Initially, the team might be new to a particular technology may have a lower velocity than after working on it for six months.
• Estimates at task level may not match the associated story. Task estimation is at much higher precision than story estimation. Story estimation is used as a roiugh number for prioritizing the iteration/sprint.
• Estimate by Analogy: Avoid use a single standard. Instead, compare to multiple known stories.
• Some use the following scale: 1, 2, 3, 5, 8, 13. While some use the following: S, M, L, XL, XXL, X, infinity, pi (I am hungry and want to eat some pie). Everyone vote at the same time to avoid influence. If there are different votes, members can explain why they gave the vote. Next, people vote again. The goal is to reach consensus. See: planning poker
• Any time when the relative size change due to new information/understanding, re-estimate associated stories.

Sprint Planning

• For a 4 week Sprint, the Sprint planning may take half-a-day. Adding retrospective and sprint review meetings, the remaining development period maybe only 19 days. Sprint review meeting will be harder to schedule because it involves a lot of people not on the team. Therefore this meeting should be scheduled first. For wide time zone differences, some teams may choose to do sprint planning before sprint review and retrospective meetings.
• The goal of a sprint planning is commitment. The product owner runs sprint planning meeting.
• In part one of the planning meeting, product owner presents the stories, answer some questions, and leave. In part two of the planning meeting, the team break down the stories into taks. Product owner returns and everyone completes the planning meeting. The instructor recommend to have the product owner to be stand-by while the team break down the stories so product owner is available if the team encounters a question.
• A team should give consideration to capacity (i.e. how much time each member can allocate per-day – time spent on meetings – un-planned task – personal vacations). Watch out if one of the team members becomes is on critical path and does not run out of spare hours to work on stories.
• If a team completed all tasks, the team may start on the next story from the backlog. Make sure there are three times as many stories estimated in the backlog. The team may choose to address the technical debts or various pending issues. All these are typically done with negotiation.

Scrum Training (1/2)

Here are some of my notes from “Working on a Scrum Team” training by Kenny Rubin.

The Agile Manifesto

• Individual and interations over process and tools
• Working software over Comprehensive documentation
• Customer collaboration over contract negotiation. (note: avoid hostile situations and the negotiation overhead)
• Responding to change over following a plan

Three most important words in Agile is “inspect and adapt”.
See also Agile Manifesto

Lean Principles

• Eliminate Waste
• Amplified Learning
• Leave option open as long as possible (note: This is motivated by the expectation that we will have more and better information at the last moment and it is the best tie to make a decision.)
• Deliver as fast as possible
• Empower the Team
• Build integrity in (note: testing during development.)
• See the whole (note: An example of approach this is to bring a documentation person into a beginning phase of a project to write user documenation on high level over view. If the team can do this, this shows that the team has a good understanding of of the whole project.)

An Agile Iteration

• In an iteration, the team attampt to deliver what customer(s) asked for. What customer(s) asked for may or may not be what they want. If the customer(s) do not want what the team delivered at end of an iteration, the customer(s) can re-prioritize the re-work for the next iteration.
• In the training room, some people expressed that they received high level requirements. The team often needs to break-down the reqirements into sub-projects or individual stories for Agile iterations.
• For teams that work on multiple projects at the same time, see notes at a later section.

Scrum

• See also Yahoo Groups
• Product backlog: Owned by product owner. Eac requirement are sized, prioritized by value, cost, knowledge and risk.
• Sprint planning meeting: Product owner and team produce sprint backlog together.
• Sprint backlog: Contains tasks for the sprint
• Sprint: The team commits to delivering some amount of functionality. Product is potentially shippable after every sprint. The product owner/customers commits to leave priorities alone during the sprint.
• Requirement can be incomplete and our understanding of them is refined during the sprint. So the team will have to judge on case-by-case basis to accept changes during a sprint or not.
• Sometimes, if the team expects a constant stream of unexpected urgent tasks, the team can pre-allocate a certain amount of time for this type of activities into the scrum estimation.
• In extreme circumstance, a sprint might abnormally terminated if change can not be kept out of a sprint or if there is no value to continue a sprint.
• Supplement written documentation with conversations.

Product owner and srum master should be two different people, at least the role should not be on the same person.

The ScrumMaster

• Alternate names: Servant Leader, Sheepdog
• Some teams may have a ScrumMaster that has a secondary role of both ScrumMaster and an individual contributor on the same team. This arragement can work in some situations.

The Team

• Self organizing and self managing
• After several months, most team feel the Scrum practice is getting easier. At around 9th month, the team may encounter new challenges such as seeding Scrum practices to other teams.

Team Size

• The sweet spot is 5-7 people

Fungible Resource

• Definition
• Team cross pollination can help knowledge transfer at the cost of time/energy for the team into performing stage. Historical velocity data will be nullified and need to be re-established.

Agile Planning

• For feature driven release, which can be done by establishing a cut-off on the backlog. This means release date becomes variable or estimated with a range.
• For date driven release, the features becomes variable.
• If there are dependencies among stories, additional planning needed, specifically rolling lookahead planning. It basically assist planning on when stories can start i.e. place in which iteration’s backlog.
• Sprint/iteration 0 – Some teams starts with 0 to setup infrastructure or create the initial backlog.
• Some teams has a finalization sprint/iteration in preparation for a release.
• During sprint/iteration 1, the team may plan and estimate tasks for the next sprint/iteration.
• Work unit accounting should not use a partial credit technique to keep the planning/management simple. Although this might impact velocity for a particular sprint/iteration, it will not have a significant impact in the long run on average velocity.
• “it’s better to be roughly right than precisely wrong.” — John Maynard Keynes
• Precision on product backlog’s estimation doesn’t need to be as precise as sprint backlog.
• Avoid task buffering. Instead, use schedule buffering. i.e. perhaps add a buffer iteration before the major release.

Release Planning

• Theme is a collection of stories. For the next release, what is the theme the product owner want to focus on?
• Priority poker is an exercise that allows each participants to priortize themes by voting with poker chips. Re-votes might be necessary if there are themes/stories that are unpopular, required for the next release, and did not receive enough votes in a prior vote.
• Crises work should be consistantly counted or not counted during planning. So velocity calculation stabilize. Velocity should not be an employee performance metric. Teams should not do velocity-driven planning also. See explanation on this topic tomorrow.

Agile Requirements

• Before the first sprint/iteration starts, several things has to happen, such as project inception (story writing, prototyping, etc.).
• A goal is to have the least amount of requirement needed to be successful. (Having the most amount of requirements is equivalent to waterfall model.)
• Not all requirements need to be at the same level details initially. “Strive to describe items as briefly as possible”
• Sometimes requirements were not well written and not testable. Tomorrow’s notes will cover this topic.
• The product owner team should review the work done throughout the sprint/iteration soon after the task done and not wait until end of the iteration.

Notes from Sustainable Software Development

Here are my notes from Kevin Tate’s “Sustainable Software Development: An Agile Perspective”

Introduction

• “Sustainable development is a pace that can be maintained indefinitely.”
• “Sustainable development requires a singular focus on a form of technical excellence that regularly provides useful software to customers while keeping the cost of change low.”
• “Balancing the short and long term requires projects to be more driven by a vision than tracked against a plan.”

Chapter 1

• “Key indicators of sustainable development are an ability to keep the number of defects relatively constant over time while recognizing that the software must be modified to keep the cost of change under control.”
• “Working harder (more hours) results in declining capability over time. Working smarter, with an emphasis on continual improvement, leads to increasing capability”
• “Companies need people who treasure the contribution they make when at work and who are passionate about the success of the company. This has no correlation with the number of hours worked. . . ”

Chapter 2

• “Technical debt is caused by an accumulation of poor decisions over timedecisions that often seem right at the time but are usually made in the interests of a short-term quick fix to the software.”

Chapter 3

• “The most common response to flailing around is to apply bureaucracy, to define a set of strict rules and milestones that cannot be deviated from. But bureaucracy stifles innovation and is most often misguided, leading to unintended side effects. It is also inflexible and change-intolerant.”
• Great teams recognize that what they are trying to achieve is more important than how they achieve it
• Three elements of sustainable development:
  • A vision
  • “Practices that are consistent with the principles.”
  • A feedback loop that leads to enhances to practices.
• Sustainable software development principles:
  • “Continual refinement of the product and project practices.”
  • “A working product at all times.”
  • “A continual investment in and emphasis on design.”
  • “Valuing defect prevention over defect detection.”
• “Effective teams strive for the optimal balance between being visionary (thinking about the long term) and tactical (focusing on today’s problems), and this balance changes over the course of the project.”
• “Great cultures recognize talents and skills as separate from each other. Too many companies are focused on skill alone and recruit only for skills. But skills can be taught, whereas talent can’t.”

Chapter 4: Working Product

• Practice 1; No “Broken Windows” — “no hacks or ugly workarounds”
• Practice 2: Be Uncompromising about Defects — Preventing and addressing defects and put a closure (fix it or close it with a reason) before moving on.
• Practice 3: “Barely Sufficient” Documentation
• Practice 4: Continuous Integration
• Practice 5: Nightly Builds
• Practice 6: Prototyping — In addition to the traditional concept of prototyping with code, a “whiteboard and paper” approach is another quick way to gain insights from the customer(s).
• Practice 7: Don’t Neglect Performance
• Practice 8: Zero Tolerance for Memory and Resource Leaks
• Practice 9: Coding Standards and Guidelines
• Practice 10: Adopt Standards (Concentrate on Your Value-Add)
• Practice 11: Internationalize from Day One
• Practice 12: Isolate Platform Dependencies

Chapter 5
• Practice 1: Ruthless Testing — Use unit tests, mock objects, integration testing (when using 3rd party libraries), system testing (that simulate real user loads), performance testing, Resource-usage testing,
• Practice 2: Use Available Tools — Source code analyzer such as PMD.
• Practice 3: Pair Programming and Code Reviews
• Practice 4: Lightweight Root-Cause Analysis — 1. What cause the defect? 2. What would have caught this defect? 3. How can we prevent this from happening again?

Chapter 6

• Practice 1: Design Vision
• Practice 2: Guiding Principles
• Practice 3: Simple Design – If you see an opportunity to design for a future need, do it and make that architecture work visible to users. The goal is to avoid costly refactor work.
• Practice 4: Refactoring
• Practice 5: Design Patterns — Watch out potential over use of patterns that could be solved with simipler implementations. Sometimes pattern implementations might vary greatly or even have different behaviors.
• Practice 6: Frequent Rapid Design Meetings
• Practice 7: Commitment to Rearchitecture – Use existing tests to check for regression.
• Practice 8: Design for Reuse

Chapter 7

• “the challenge with agile methods is to rely on both adaptability and anticipation and to have a team that knows when and how to apply each, and in what measure.”
• Practice 1: Iterative Development
• Practice 2: Release Planning
  “as with any project, you can either change the date, the feature set, or the resources. You can’t expect to fix all three.”
• Practice 3: Daily Standup Meetings — What you did? What are you doing? What is stopping you?
• Practice 4: Retrospectives — “What worked well?” “What needs to be improved?” “What should we do differently?”
• Practice 5: Coaching and Team Development — It’s important that developers understand what’s important to the customers, which will infer how the customers use the product. Note that how the customers use the product (i.e. what they really asking for) maybe differ from what they asking for. “If the only value you provide to an organization is writing code, then your job can be outsourced (i.e., worked on by cheaper labor).”
• Practice 6: Make Key Metrics Visible

Chapter 8

• Required Change factors: Leadership, a sense of urgency, and executive support
• Change enablers: persistence, training, continual wins, positive reinforcement of desired behaviors, communication, vision, and strategy.