Can you recommend a virtual task board?

The participants of my last course had a lot of questions about working with distributed teams. What tools do you need to work with distributed teams?

I developed echobravo with a team from Brazil. As product owner, I was located (mostly) in Zurich. My team was in Maringa.

One aspect which encouraged the trust between myself and my supplier was the use of a cloud-based source code repository like bitbucket. Knowing that I had access to the source code in the event a dispute took a lot of the worry away from the collaboration.

We found "Web 2.0" tools like Google Docs, Google Hangout, Dropbox and Skype to be essential for collaboration. You can communicate with each other, share screens and access common files, e.g. definition of done. I liked Skype better than hangout for convenience, especially the ability easily recall old chats, but Google Hangout has better video and screen sharing (an extra cost feature on Skype).

In my experience, proprietary tools introduce cost which is a hurdle to using them, and more importantly, they introduce arguments over who will pay for them which can be an even bigger hurdle! Beware of proprietary video conference solutions. Make sure that it is possible for people to call in from home without proprietary hardware.

I find an online spreadsheet is an excellent, collaborative tool for distributed teams to maintain story maps and backlogs, and for holding a distributed retrospective. A wiki is also good for documenting stories, sprints, and acceptance criteria. You can also record the state of the task board every day by taking a picture and uploading it to the wiki, a capability which is, AFAIK, unmatched by any virtual task board.

I would only recommend a virtual task board if the development team is not co-located. (And I would not recommend a development team which is not co-located!). My Brazilian team and I used a Target Process to manage the backlog and the flow of stories (not tasks!) from waiting to working to done in the Sprint, but they used a physical task board to manage their actual tasks.

Target Process is dear to my heart for a number of nonfunctional reasons (ask me about "my" feature!). Greenhopper/Jira is quite widely used, because of its integration into the other Atlassian products, as are Rally and VersionOne. I don't have any strong preference for or against any of them. Most products have an online version which is free for five users, so you can try it out and figure it out before you actually pay money.

The main drawback of virtual tools are twofold: First, a virtual tool doesn't function well as an information radiator -- people have to actively look at the appropriate web page to see the status (if they even have access). With a physical board, anybody walking by can take look.

Second, Products must appeal to a wide spectrum of users, so they can do far more than you actually need. They often support practices which are not really recommended any more (like estimating tasks in hours). Wading through this excess can be confusing and cause you to waste time forever on unnecessary process.

I would therefore recommend, before you pick a product, start on paper. Then maybe move to an online spreadsheet. These are both very flexible tools. Figure out what your requirements and workflow really are. Then you are well positioned to pick a tool that suits you needs.

XM Principle 10: Partner Patterns

Deliveries often rely on third party suppliers, and often they are not yet able to deliver a new product that meets our new specification within a single sprint. So what can we do in order to go from an idea to a new product or service in a customer’s hands in less than 7 days?

WIKISPEED first designs a wrapper, usually a plate of aluminum with pre-defined bolt patterns, around the third party supplied part to create a known “interface” that won’t change, even if that third party part changes. You might see how this is enforced by principle 2: Object-Oriented, Modular Architecture and 4: Contract-First Design, and then sped up by principle 6: Agile Hardware Design Patterns.

Once each third party part is wrapped in a known interface, you can iterate between suppliers and in-house prototypes or volume parts at very low cost. The only marginal cost is that of changing the wrapper itself.

Then, to expedite suppliers, ask them to deliver a certain set of performance characteristics as opposed to an engineering specification. "Do you have a transmission suitable for 100hp motor?", not "Here is our design for a transmission, can you build it?" Why should you wait months for a supplier to build a device to your specifications when they have a device that will satisfy your needs already in the catalog or in stock?

Many engineers are quick to design their own solution, which works to the team’s advantage when the design team is also the volume manufacturing team. But in cases where some production is outsourced, sending a list of values and tests to the outsourced vendor and not sending an engineering specification gives the supplier the most room to innovate. This allows the vendor to do what they do best, that part, which is why you are partnering with them in the first place. Team WIKISPEED finds they get higher quality parts faster, often from within the vendor’s existing stock.

The 10 Principles of Extreme Manufacturing

XM Principle 9: Scaling Patterns

XM scales as Scrum scales, by adding teams. Coordination can occur through the Product Owners, Scrum Masters or Team Members, depending on the scope of the issues involved.

When multiple teams work on the same module, they each own a sub-module, which will require another finer pass of Contract-First Design to create interfaces for sub-modules before those teams can be created. For example, within the engine module there is the fuel system module, the engine electronics module, the exhaust system module. Each module has an interface that loosely couples it the other modules and clear tests of their value and technical excellence.

Creating Teams

Applied at WIKISPEED, the first design decision is the fundamental architecture of the product being created, in their case a car. What are the main modules, e.g. engine, body, drive train, cockpit, etc., and what are the interfaces between them? Once the modules have been identified and the contacts between them created (see XM Principle 4: Contract-First Design), sub-teams can be created on each side of an interface to develop that module.

If capacity allows and velocity and quality metrics indicate adding more teams per module will improve velocity and quality, then multiple teams can work in parallel per module.

Each team owns their own integration and tests, no team is “done” with an increment of their module until all tests pass, including tests that it complies with their module’s interface and no additional connections have been introduced.

Team Coordination

In XM Scrum of Scrums, teams consist of 4 to 5 people, including a Product Owner and Scrum Master. Each product owner is responsible for pulling stories from the Portfolio Product Backlog (or simply "Backlog"), and getting clarity when their team needs it on the customer visible value and Net Present Value each story is intended to deliver.

This clarity comes from the Chief Product Owner (CPO) who sequences and refines the Portfolio Product Backlog continuously. The CPO is not a senior role in pay or experience, but is simply the person available enough to keep backlog ready for the teams, answer questions, and have the most clear understanding of the customer visible value the Portfolio Product Backlog is aiming to produce. Ideally, the CPO is the customer, and the one paying for the product or service the backlog is aiming to produce.

On each team, each Scrum Master is responsible for accelerating the velocity of the team, i.e. the amount of work sustainably delivered each sprint. Sustainible implies that the teams are happy and that all work completed satisfies the quality metric called the Definition of Done. Scrum Masters have an additional job here, too: they collaborate with the Scrum Masters of other teams to negotiate the shared resources like space, tools, and modules, across teams.

In this way, a team of 5 has clear expectations for themselves on how to resolve the most common types of impediments: lack of clarity is handled ASAP by the product owner, lack of backlog is handled ASAP by the product owner, lack of visibility into team delivery trend/quality/happiness is handled as a matter of course each week by the Scrum Master, and resource constraints and coordination are handled ASAP by the Scrum Master."

Next: XM Principle 10: Partner Patterns

The 10 Principles of Extreme Manufacturing

XM Principle 8: Continuously Deployed Development

Extreme Manufacturing requires going from an idea to a deliverable, working product or service in 7 days or less. How do you produce a new design in volume in such a compressed timeline?

Let's look at how traditional companies address the problem of new product creation: When a traditional car manufacturer designs a new transmission, they build a new factory.  Step one is to negotiate with various political districts for optimal conditions, e.g. access to roads & power, conditions for taxation, etc. Then they acquire the land, build the facility, hire and train the workforce, and configure the line. After many years of preparation, their customers can finally order a product for delivery.

How do you compress years of lead time down to a one week delivery cycle?

This Principle involves making the mass-manufacturing line flexible, so it can produce different products within a 7 day sprint. These products might be existing products, modified products or completely new products.

Achieving this operational flexibility might mean additive or subtractive rapid prototyping machines, or both. It might mean some machines or lean cells are placed on lockable casters so they can be wheeled in or out of the flow depending on the sprint goal. This often means that the team reconfigures the machinery following daily Scrum each morning. And this always means test fixtures connected to andon lights at all stages of the line.

R&D belongs at the head of the line. If the new product design team is within earshot of the volume manufacturing line, bi-directional communication occurs. If the R&D group deploys to the production line every sprint, both teams can work together to reconfigure the line to test and produce the new product. As cross functional skill grows, any separation between the R&D and manufacturing team dissolves and we simply have the cross-functional product team. Each individual has specializations, welding certifications for example, but through pairing they work on every aspect of the product flow from idea to customer delivery and support.

How are you going to get a truly marketable product, if you only have seven days to create a new product? See XM Principle 5: Iterate the Design. The objective is to create a first version within a week. Then iterate on the design to improve it as needed. Use the intermediate results to get feedback from customers, users and other stakeholders. Early designs will be big and clunky, making use of off-the-shelf components, but as you iterate the design and get feedback on it, you will zero in on your target.

For services, the story is exactly analogous. Ideally the service providers are the advanced marketers and innovators of new services, and within a sprint they interact with customers to improve the service and make the improvements available to the customers.

Next: XM Principle 9: Scaling Patterns

The 10 Principles of Extreme Manufacturing

This article was written by Joe Justice and Peter Stevens.

XM Principle 7: Continuous Integration Development.

WIKISPEED has team members contributing in 20+ different countries, any time of the day, with variable availability. How does they produce a cohesive, salient product? The answer has two parts, the first part is about engineering practices, and the second about how to scale.

At the engineering level, Extreme Manufacturing employs Continuous Integration Development (CID) to run their test suite frequently (see principle 3, Test Driven Development). Continuously Deployed Development (see principle 8) ensures a tight collaboration between product creation and product manufacturing, so the goal of never being more than 7 days from releasing an improved product can be achieved.

Continuous Integration Development (CID)  ensures that the test suite is automated as much as practical, so that every time a team member sends in an updated design, an extensive test suite is run automatically.

Every time a team member uploads a new 3d drawing to DropBox, Box.net, Windows SkyDrive, or any of the file sharing technologies in use, WIKISPEED run tests. WIKISPEED can simulate crash tests and stress tests on the part using FEA (Finite Element Analysis) and a software package like LS Dyna or AMPStech. WIKISPEED can simulate airflow, aerodynamics, fluid flow, heat transfer, and electrical propagation using CFD (Computational Fluid Dynamics).

These tests can be run automatically whenever a new CAD shows up, and write out a 1 page report with a list of red or green lights. Green lights mean the test is same or better than the current version, or passes an explicit test for that part or module.

In this way, team members from all over the world can simultaneously contribute in parallel with very different ideas for improvements to each module. And it’s easy to know what the current best part is; the version of record is whatever part in CAD has passed all tests with the most green lights.

WIKISPEED includes tests for simplicity and low cost, along with user ergonomics, maintainability, manufacturability, and conformance to interface(s) of the module they are a part of.

Next: XM Principle 8: Continuously Deployed Development

The 10 Principles of Extreme Manufacturing

After an unexpectedly long break, I am now finishing up the series on Extreme Manufacturing! This post was written by Joe Justice and Peter Stevens.

Call for Participation: Product Owner Camp Switzerland #POCampCH

Following the fantastic Swiss Agile Coach Camp, I thought it would be cool to organize a similar event around of Product Ownership. I put out a tweet and got some good resonance (so much that it is now difficult to keep track of everyone who responded),

The Product Owner Camp in Switzerland #POCampCH will be a 2 day open space event. It is a non-profit community event and this will be reflected in the prices.

I expect it will be held during the first or second quarter of 2015, that it will be in some nice location in the mountains, or at least away from a city, and I expect there will be one or more some optional workshops on Product Ownership around the event.

With this call for participation, I am looking to confirm these expectations, find out who wants to come, who is willing to contribute, and get some guidance for key decisions about the venue and possible non-open space program (workshops or courses).

Are you interested in participating in or organizing the open space Product Owner Camp Switzerland? Sign up below!

Scrum Framework, or how do you do Scrum?

Last post I wrote, "Scrum is a simple, team-based framework for solving complex problems." How does the Scrum framework actually work?

Scrum is modelled on successful patterns for product development. The classic phase-driven approach, or "relay-race model" was found to be less effective than the team-oriented, "rugby model", in which an interdisciplinary team solves the whole problem together, without explicit phases or formal leadership roles. (See "The New, New Product Development Game" at HBR for the research which inspired Scrum).

The Scrum Framework

The Scrum Framework ensures the core principle of Inspect and Adapt can take place at regular intervals. To achieve this, Scrum introduces a few constraints on the development process:

1. Time-boxing triggers inspect-and-adapt cycles. So a Sprint is time-boxed to four weeks or less.
2. An interdisciplinary Development Team solves the problem. Outsiders do not tell the Team how to organize or do its work.
3. Work taken on at the beginning of the Sprint must be finished by the end of the Sprint. So the team only takes on what it reasonably believes it can finish on time.
4. No changes to the assignment before the end of sprint. Work that is started but not finished is waste, so this should be avoided.

If you accept and believe in Scrum's principles and constraints, then doing Scrum will come naturally to you.

Roles

"The Scrum Team" refers to an interdisciplinary, self-organizing group of people, who collaborate to define and solve the problem as effectively as possible. Within the Scrum Team, Scrum defines three roles:

• Product Owner - represents the voice of the customer or stakeholder. The Product Owner is responsible for answering the question "Why?" S/he is empowered to cancel a feature or even the development of the product if the answer is not satisfactory. The Product Owner guides development from the first formulation of the Vision to the (final) release of the product. 
• Development Team - solves the problem presented by the Product Owner. The Dev Team has all the skills need to bring an idea to the completion. It is responsible for answering the question "How?" and for creating something potentially valuable to the customer or user at least by the end of each sprint. 
• Scrum Master - represents the voice of common sense and is responsible for the process. The Scrum Master acts as trainer and coach to help the Development Team, Product Owner and indeed, the rest of the organisation, become more effective. The Scrum Master recognizes all kinds of impediments and works to eliminate or at least mitigate them.

There are no hierarchies, further divisions or sub-teams within the Scrum Team.

Activities

Scrum is an iterative, incremental approach to development. So development is broken into a large number of fixed-length "sprints", each of which produces an increment of "potentially shippable" customer visible value, which is integrated with the previously created increment to create a seamless whole.

• Sprint -- the basic feedback cycle Scrum. The Development Team takes on a problem to solve at the beginning of the Sprint and commits to do its best to complete that mandate by the end of the Sprint. A Sprint should strive to achieve a clear business goal, which should be between one and three Sprints in the future.
• Sprint Planning 1 -- The Scrum Team collaborates to decide what problem(s) should be solved in the current sprint. This should represent the best step forward toward the ultimate goal, given the Scrum Teams knowledge at the time of the planning.
• Sprint Planning 2 -- The Development team collaborates to decide how to solve the problem they took on in Sprint Planning 1. The result is usually a technical concept and task planning. Neither needs to be definitive, but should be enough that the development team can start work.
• Daily Scrum -- The Development Team inspects and adapts its own work on a daily basis. The team report to each other: What have I accomplished? What is my goal for today? What is slowing me down? Brief, clarifying questions are allowed, but longer discussion must be postponed to (immediately) after the Daily Scrum.
• Sprint Review -- The Scrum Team inspects the product it created in this sprint so it can better decide how (or even whether) to move forward in the next sprint. A potentially shippable Product Increment should be available at the review, consisting exclusively of "done" functionality.
• Sprint Retrospective -- The Scrum Team inspects and adapts itself, so it can be more effective in the future.
• Backlog Refinement -- This is the process of keeping the backlog up to date and preparing the backlog entries for implementation. This includes ensuring that the Team understands upcoming backlog entries; estimation; "slicing" this stories into small enough pieces; and discarding or de-prioritising unneeded entries.

All activities in Scrum are time-boxed.

The sprint length must always be the same, and should be short compared to the length of the project. Two weeks is common in software development. The maximum length may be limited by the Product Owner's ability to hold his/her word not to change the mandate: fast moving businesses generally require shorter Sprints. Four weeks is the maximum allowed by Scrum, because longer sprints have been shown to lower performance.

The Daily Scrum is time-boxed to 15 minutes. This discourages excessive talk and teams from getting too big. The remaining mandatory meetings are time-boxed to 1 hour per week of Sprint (e.g. 2 hours for a 2 week sprint, 4 hours for a 4 week sprint).

Note: the authoritative literature often combines the time-boxes for Sprint Planning 1 and 2 into one time-box of two hours per week of Sprint. I have found that the time-boxes for Sprint Planning 1 and the Sprint Review are critical. If you cannot finish Sprint Planning 1 in the allotted time, you need to invest more effort in Backlog Refinement. If you cannot finish the Sprint Review in the allotted time, your Team is probably finishing most backlog items at the last minute, and/or the items are not really Done.  

Artifacts

I don't like the term 'Artifact' very much. To me, this implies objects that were created by people who died thousands of years ago and were dug up by archaeologists.  The so-called artifacts in Scrum are living entities to guide and direct the project.

Scrum defines three artifacts: the Product Backlog, the Sprint Backlog, and the Product Increment:

• Product Backlog -- this is the single list of ideas for the product under construction. The Product Backlog consists of entries which represent some value to the customer or user. Each entry is:
• Sequenced - a strong form of prioritization in which each backlog item has a unique sequence number: 1, 2, 3, 4.... Sequencing is most important for the items at the top of backlog, which may be implemented in the next 2 or 3 Sprints.
• Estimated - not all Scrum Teams estimate, but if you do estimate, the Development Team does the estimating.
• Emergent - the product backlog is not a binding definition of the product, just the current best understanding of what the product should be.
• Sprint Backlog -- the Team's detailed plan on how to solve the problem. It consists of the selected backlog items from the Sprint Planning, a solution concept (how to solve the problem) and a task planning (the steps needed to complete the work involved). The task planning is often represented on a task board.
• Product Increment -- Scrum achieves results incrementally, that is one slice at a time. Each backlog item defines a slice. At least once per Sprint, but possibly more often, the team must integrate all the slices of the current sprint into the previous Increment to create a new Increment. This increment and each slice in the increment must be "done" according to the Definition of Done. Should the Product Owner wish to release the Increment, there should be no impediments to doing so.

Agreements

Core Scrum introduced the notion that the Definition of Done is an Agreement, not an Artifact. At first I found this a bit strange, because the DoD was usually posted on our Wiki somewhere. But now I find the notion quite powerful, and believe that Agreements are the basis for many context specific enhancements to Scrum.

Planning in Scrum is commitment based. There is no hierarchical command authority in Scrum. Scrum defines explicitly one agreement, the Definition of Done implies a second agreement, which I call the Sprint Contract, which govern the expectations during a Sprint.

• Definition of Done. The constraint that a feature be done before it can be included in the Increment and that the Increment be potentially shippable requires that everybody mean the same thing when they call something "Done." Generally, the Definition of Done ensures that the Team has built the right thing, that they have built in right, and if something was Done in a previous Sprint stays Done in this Sprint.

The Sprint Contract is implied by Scrum, but not explicitly named. I have found it useful to give it a name, discuss its conditions, and secure agreement among the concerned parties.

• Sprint Contract -- An agreement between Product Owner and Development Team covering the current Sprint: scope (forecast), quality (Definition of Done), cost (Effort), and time (Sprint Length). The team commits to do its best to achieve the forecast. Product Owner and Development Team commit to support each other during the Sprint. Time, cost and quality remain fixed, so if the team overestimates its capacity, it will deliver less functionality than forecast. When that is the case, it should leave low-priority stories unstarted. To prevent wasted effort and unfinished work, the Sprint Contact cannot be changed unilaterally (though it can be cancelled in an emergency). The entire Scrum Team and the rest of the organisation must respect the Sprint Contract.

The following is not defined in the authoritative Scrum literature but I have found additional agreements useful in many contexts:

• Team Working Agreement -- An agreement among the (Development) Team members to enable them to work together more effectively. This often covers core hours, punctuality at meetings, whether reading email is allowed during a meeting, when to update the task board, and anything else the team finds useful. 
• Additional agreements -- As development teams work with their Product Owners they learn to work together effectively. This know-how is reflected in the agreements. One such agreement is the "Definition of Ready" when is a backlog item ready for execution. How often does the Scrum Team get together to do Backlog Refinement?