Contents

• Make Something from Nothing
• Justify the Expense
  • Project Charter Format
  • Create the Charter
• Find the Folks
  • Self-Organize from the Start
  • Create New Teams
  • Connect Existing Teams to New Work
• Kick Off the Project
  • Prerequisites
  • Kick it Off
  • Ramp Up
• Create a Template Program
  • Build from Reality
  • Phase Deliverables if Needed

---

Make Something from Nothing

When starting a new project, Agile or waterfall, you need to ensure sufficient value for the effort, organize resources, and kick things off in a way that will maximize efficiency. The team-level and release sections of the Full Scale agile™ site assume you are working with existing teams and programs. (As defined before, I am using “program” as a collective term for a related group of work comprising one or more projects, and the people involved.) This section assumes that assumption was wrong. Whether you are starting a new project with existing teams, or starting from scratch, this topic is for you!

According to the Project Management Institute, there are five major project management processes[2]:

• Initiating
• Planning
• Executing
• Monitoring and Controlling
• Closing

Agile’s strength is the middle three. How you initiate and close a project will essentially be the same regardless of how you plan, execute, monitor, and control it. You can buy standard project management books that detail the “Initiating” process, but I will cover the fundamentals and Agile considerations here.

When starting a brand new project, invest time to reach a basic understanding about it among its stakeholders. Think of project initiation as making vacation plans. Some basic decisions are required before setting out. You need to know what direction you are headed in, if not a specific destination; the means of transportation; obstacles you need to overcome in advance (like requesting time off from work); and how much you would like to spend. All this can be done without planning the driving route or plane flights or hotels in advance. You can buy a last-minute flight to Geneva, but you have to know you are flying… now… to Geneva. Or instead that you are taking a road trip in a few weeks to the American West.

The Initiating Process in FuSca answers very fundamental questions about what problem the project is meant to solve, the basic approach, what that will require, and what problems the project might run into. The output is a simple two- or three-page “Project Charter” that captures this information to focus backlog creation and Sprint Planning. Although you will have backup documentation you can share in raw form, if asked to explain how you calculated numbers, there’s no need for a more comprehensive document. This is not due to the Agile Manifesto point about documentation, by the way: I was trained to do a two-page charter when earning my certification as a waterfall project manager.

Justify the Expense

Project Charter Format

You need to justify the expense of starting the work to whoever pays the bills. These sections should suffice for most executives who understand project management:

• Description—A one-sentence summary of the project, often a statement of a problem the project will solve.
• Business Justification—Two to three sentences explaining why this project is worth investing in. Potential revenues are the best justification in profit-making enterprises, of course. Nonprofits should come up with how many people can be helped and how. Cost savings, whether direct costs or labor costs saved through efficiency, are valid as well. In any case, specific numbers are required.
• Goal—An over-arching SMART goal[3] for the project, perhaps in the form of: “The (team name) will (create this measurable result) using an iterative process until the customer declares it done.” In waterfall projects, a planned end date is added, and per “The Waterfall Myth” is a lie. In FuSca we refuse to lie.
• Milestones or Objectives—Three to five steps or subgoals toward achieving the project goal. A critical difference between waterfall and FuSca project charters is that waterfall versions will include dates in the Milestones section. For R&D projects these are always spurious, given that you have no data to base them on and face significant “unknown unknowns.” Don’t waste your time on that.
• Key Individuals—At minimum, list by name the:
  • Customer(s)—Who are you doing the project for, whether in or outside of the enterprise?
  • Program/Program Sponsor—Who within your larger organization would be supplying the budget and strategic decisions?
    Note: For internal projects, this person may also be the Customer as defined in FuSca.
  • Facilitator, if different from the Sponsor—The person leading the project initiation, and thus the author of the charter (Agile Release Manager, program/project manager, etc.).
  • Stakeholders—Other managers or groups outside of the team impacted by the project.
• Assumptions—A short bullet list of facts that will have to remain true to meet the goal, such as, “People and tools assigned to the project at its start remain assigned full time.” The desired agreements are a good source for others.
• Risks—Another short bullet list of issues specific to this project that could prevent the goal from being met, perhaps with a mention of the possible approach to each (e.g., Avoid, Transfer, Mitigate, or Accept). Refer to the discussion of risk management under “Projects are a Risky Business.”
• Staffing—A list of the roles and number of people needed in each, such as:
  • Marketing Analyst
  • Product Designer (2)
  • Design Engineers (3)
  • Manufacturing Dept. representative
  • Tester (with the assumption this role will eventually blur with the Design Engineers’)
• Initial Run Rate or Budget—The amount of money you will invest up front, either per period of time or total. Under any agile method more money will likely be needed than the initial total, but it will be vetted against other possible expenditures when that amount is running out. If required to provide a figure, see “Budgeting an Agile Project.”

Even an internal project can benefit greatly from this process. I have found that putting a charter on an intranet page or wiki cuts down greatly on the amount of time I spend answering those questions from inside and outside of the team. It also supports the “Simplification” principle by helping to fend off gold-plating requests. “That sounds great, I’ll say, but it is outside the scope of the project charter,” referring them to the document.

Create the Charter

Creating the charter starts with a conversation with the Project Sponsor, unless that is you! I’m guessing you are the person who was asked to lead the program/project or the Full Scale agile conversion. I’ll refer to you as the “facilitator” (lower-case “f”) in these sections on initiation. The sponsor should be able to provide most of the information. One who can’t hasn’t really thought through what they want. Help them do so, or you are going to waste a lot of labor time (and money) as you and the people you talk with wander about in search of a destination.

By the way, it is perfectly acceptable in Agile for the sponsor to impose a budget figure. This is no different from an external customer saying how much they have to spend (which may be how the sponsor comes up with the number). This will drive refinement of the “Staffing” section of the charter because the size of the team determines cost per sprint. Once under way, the team delivers as much work as it can each sprint. FuSca proves they are working as hard as they can while maintaining a sustainable pace, and data to predict as much as four months ahead what will be delivered for the money. That is plenty of time for the company or customer to decide whether to add budget and keep going.

Get as far as you can with the sponsor, and then gather the people the sponsor named as “Key Individuals” to fill in the gaps. You do not need to build consensus among everyone at this stage, but asking for it will both identify problems as early as possible and increase support for the project if approved. When working with existing teams, I run the draft by them as well. This is a fantastic way to build a sense of empowerment and ownership.

In organizations that have a formal project approval process, you will of course need to modify my charter suggestions to meet its guidelines. Fight to minimize any other information that process requires. In larger non-agile enterprises, you will have to do some educating on why there is no project plan, architectural or technical specifications, completion date, and so on. Refer to “Making Gates Agile” for more on that.

Regardless of what you have to provide, build consensus on the charter and any other required documentation among the customer(s) and “Key Individuals” before proceeding to request funding. Jump the gun, and you risk wasting everybody’s time.

⇒ Steps: Create the Project Charter

Find the Folks

Self-Organize from the Start

I explain elsewhere on the site my concept of “Extreme Self-Organizing,” based on the Agile Manifesto and research-backed best practices into self-directed work teams. With new teams, you can apply this approach as soon as you have two members. With existing teams, it begins when the program kicks off. The following section deals with each of these scenarios, implementing research on team hiring practices and development in the Agile context. Those not hiring anyone for the new program can skip to “Connect Existing Teams to New Work.”

Create New Teams

Hire Initial Members

The hiring process in the self-organizing approach starts the way it always should have according to small group psychology, but often doesn’t. The “Staffing” section of the charter tells you the needed skill sets. Your job descriptions (JDs) must include the minimum technical needs.

That’s the point at which typical practices diverge from research-backed practices, unfortunately. Most JDs add some fairly meaningless generalities about the type of job, and go on to list increasingly detailed additional technical skills that could be learned.

What cannot be easily learned are the people skills that speed self-organizing teams to success. For empowered teams, therefore, a greater emphasis should be on teamwork behaviors. Here is part of a JD I wrote for a technical writer position in 2000, before the Agile Manifesto existed:

Together this was almost as many lines as there were for technical skills.

Today I would re-use these without hesitation in hiring an agile team. The first bullet point, about customer satisfaction, aligns with the primary goal of any agile team. Three of the middle four speak to how an empowered team member must interact with their teammates. “Problem-solving” is a critical skill in a team, because the team would be slowed down if it had to wait for an expert to jump every hurdle. “Meeting deadlines” may seem odd in an agile context, but we ask people to deliver all of their tasks within a sprint, so it is appropriate. You could change that to “doing what you say will do” if that feels more agile.

Do not hire team leaders, or in any way suggest the need for managerial skills. Such are not appropriate for self-organizing teams. Certainly it makes sense to quickly hire technical experts in those skill areas listed in the charter, if you don’t already have them in the organization. Those people are better placed to assess the technical abilities of later candidates. Neither the experts nor those later candidates should be allowed to think of the initial hires as bosses or even the likely Guidance Roles, however.

Resumes should be judged on the evidence they provide for those teamwork skills, though those are easier to assess in the interview. Part of the interview should be questions specific to each line in the JD. Here is the set I used to cover the teamwork requirements:

• How do you ensure you are satisfying your customers?
• Tell me about a situation in which you took an ethical stand when it would have been easier not to.
• What is your problem-solving process?
• Tell me a specific problem you had to solve and the steps you took to do so.
• Give me an example of some criticism you received and how you responded.
• Give me an example of some criticism you had to give, and how you went about giving it.
• What steps do you take to manage stress productively?
• What process do you use to ensure you meet short-term deadlines?

Notice that these challenge the candidate to come up with historical facts, not giving them room to make pat claims. I would pair these with similar questions for the individual’s references to provide evidence for “demonstrated success.” I would also include the Agile Performance Standards and maybe the other relevant desired agreements in the JD so people know what they are getting into!

Obviously the functional manager(s) have to take the lead in hiring the first couple of people, though I strongly recommend including existing Agilists in your company in your interviews. Once you have two people on board, though, the approach takes a radical turn toward self-organization.

⇒ Steps: Make Initial Hires

Let the Team do the Hiring

When new people are needed for an existing team—even if just hired themselves per the subsection above—self-direction requires they be allowed to do the hiring. Most companies I have worked with believed that a team leader deserved to have the ultimate say on who joins the team, with vetting by technical experts, Human Resources (HR), and the leader’s manager. Since a self-managed team does not have a team leader, final authority over hiring has to be one of the leadership duties the team takes over. This also provides the advantages covered earlier of group decision-making over reliance on experts, and provides better indication of the likely chemistry among the individuals.

The existing team should have authority to customize any standard JDs and/or create them to meet the team’s needs. HR help will be needed to ensure they meet legal standards, but that would be true for a team leader as well. HR should provide all team members with the same training they would provide a team leader on employment law regarding hiring practices.

Then let the team select candidates for and conduct interviews, and select the hiree. They should still involve other roles as described in the first paragraph, and of course must follow company policies about hiring approvals. Within those limitations, the team should be allowed to hire whomever they want to the degree any team leader could in your organization, even if the other roles consider a particular hire a mistake.

⇒ Steps: Conduct Team-Led Hirings

Connect Existing Teams to New Work

In many, probably most cases, an existing set of employees will have little choice but to take on a particular new program. Usually they are the only people with the needed combination of skills and availability, the latter due to prior work getting completed or winding down. Given the luxury of two appropriate teams or sets, and two or more projects, self-organization means a manager does not make the assignment. Gather the teams in a room, have your Program Sponsor(s) or Customer(s) describe each project, hand out the project charters if drafted, and leave the room with instructions to the teams to hash out which projects they will take.

Where that isn’t possible, never break up and re-form teams to match the work, as discussed under “The Power of Stability.” You will lose a host of psychological benefits that take months or years to recreate. Move the work to existing teams, add skill sets through formal training if you can, initiate new hiring by the teams if needed, and get started!

The third option is that you are reorganizing waterfall teams into agile teams. Once in my career, I had the luxury of converting a group of roughly 80 people who had served on different global teams to FuSca at the same time that they started a new program. We traveled from different countries to meet for a week in Bengaluru, India, where most of them were based. Although managers had done some preassignments into functional teams, I proposed the group reorganize into full-stack cross-functional teams, and they voted 3:1 to do so. To form the teams, I asked the product managers (Customers) to list a set of initial epics across the top of a huge whiteboard. We brought the entire group, including all Guidance Roles, to the board and had the Customers describe each requirement until the group acknowledged understanding. I believe the company later won an award for the platform that program created.

Then we listed each skill set in the room down the side of the board, and drew a table. The group agreed on which skill sets were needed for each epic, and the Customer and architect(s) responsible for each. After sending the group home for the day, I used patterns of skill sets to identify logical team groupings based on the epic(s) they would work on.

The next day, I handed out sticky notes to everyone, had them write their names on them, and put those names on whichever team they wanted to be on. We ended up with a couple of teams that were too large, and a couple with too many or too few people in a particular skill set. The people who volunteered for those teams split them and reassigned themselves until everyone was satisfied. Now that is self-organizing! Teams concerned they might need occasional help on a skill or two were reminded they would be free to request help from another team with those skills on the relevant epics.

You may never get the opportunity for that level of self-organization, but as much as possible, teams should be allowed to form themselves, to the maximum degree possible.

⇒ Steps: Allow Existing Teams to Choose Projects

Kick Off the Project

Prerequisites

The project kickoff meeting is a standard tool of project management to ensure everyone is on the same page. It remains useful in FuSca with some modifications. Most importantly, you need to have:

• The finalized Project Charter.
• The Product Backlog populated per “Create User Stories,” with enough stories to likely keep the teams busy through two sprints (or epics per the last bullet).
• The architectural runway.
• If using releases, at least one epic per team groomed through Phase 2 by the Release Planners, in which case the first thing the teams will do is break those down into stories.

This list is no different, and indeed far less burdensome, than the complete requirements list and architectural specification document called for prior to waterfall kickoffs.

For teams that are not collocated, try your hardest to get the budget to bring people together face-to-face for the kickoff (assuming the covid pandemic is over or everyone is vaccinated, that is.) The scientific evidence on virtual teams suggests strongly such teams perform better and with less conflict when members have a chance to develop personal bonds. As discussed earlier, this is much more difficult when nonverbal communication cues are removed from the equation. Plus the sheer amount of time spent together per day is higher during in-person meetings, and they provide opportunities for social interaction through meals and fun activities.

When programs are new, or new to FuSca, hold a multi-day meeting during which teams and the Release Planners hold the kickoff and get started on the relevant sections of this site.

Kick it Off

Include at least these agenda items:

1. Welcome—The Customer and Program Sponsor talk about why the project is important.
2. Overview of the Project—The Agile Release Manager (ARM) reviews the charter.
3. Introduction to Agile and Full Scale agile—For programs that have not used FuSca already, the ARM covers the basics using the “The Agile Difference” and “Gain Buy-in.”
4. Overview of the Product Backlog—Without going into every item, the Customer summarizes the types of stories/epics with an emphasis on why they are in the order they are.
5. Overview of the Architectural Runway—The architects show the top-level architecture blueprint or model and next level down, even if some parts are still “known unknowns.”
6. Questions and Answers—An open discussion to clarify team member understanding and take input on the charter and backlog.
7. Decisions—Make joint decisions about:
   1. Sprint lengths.
   2. The starting date for the first sprint, allowing time beforehand for:
      1. Sprint 1 exercises, in this case done before Sprint 1.
      2. Grooming to 150% of known or guessed velocity.
   3. When to hold the Joint Demonstration ceremonies.

Ramp Up

Ideally, take a couple extra days after completing the agenda above for team self-organization and initial planning such as grooming described in other sections. Their questions for each other will be answered more quickly and the host of decisions made faster, and the mealtime discussions will bear fruit in the rapid sharing of good ideas. I prefer to get this far by the end of the kickoff when allowed:

• Teams that haven’t already done so create team charters.
  Note: This is the preferred way for Facilitators and Team Guides to be identified.
• If using release planning, all teams perform a Sprint 1 exercise on their chosen epic(s) and begin grooming.

Guidance roles should sit in on Sprint 1 and Grooming Sessions as much as possible. Besides the likelihood more high-level questions will arise in this first dive that they are best suited to answer, it will create a greater understanding of the process on their part, and thus help communications in the future.

Regardless of when it happens, the goal we’ve discussed in a couple of places holds true: Have more than enough stories to keep each team busy groomed in time for the first Planning Ceremony… in this case, of the entire project!

⇒ Steps: Conduct Project Kickoff Meeting

Create a Template Program

Build from Reality

When I was describing requirements, I talked about the impact on waterfall projects of technical and business needs people didn’t think about until too late. Many companies try to overcome this by creating a comprehensive list of all of those requirements and checking them off, usually as part of a phase/gate model. This violates the Agile Manifesto mandate against “comprehensive documentation.” An agile compromise to the issue is a “template program,” a set of typical projects and/or epics required in any program of a particular type your organization often tackles. The template ensures people don’t have to keep re-creating these, wasting time and possibly missing some requirements. However, the technique emphasizes critical dependencies and risks only, because Agile Liaisons can identify other needs as they arise, rather than trying to predict them all up front.

It is much less labor-intensive and more accurate to let reality guide you. Complete (or at least make significant progress on) a program, during which the release planners will organically create needed projects and epics based on real-world demands. Then the ARM can lead an effort to create a template program from experience. As this is another “one-off” effort, I will list the steps for the ARM here instead of creating a separate step set:

1. Make a copy of the completed program in your Agile Tracker, down to the epic level.
   Note: If there is no obvious way, check with the provider of your tracker to see if there is a tool for a “deep” or “nested” copy, moving all parents and children at once.
2. Remove portfolio items (for example, projects and/or epics) that do not apply to most programs.
3. Modify remaining items to use generic terms or placeholders for those specific to a future program.
4. Schedule a meeting more than a sprint length in the future with the following roles, as many as you can get across programs and teams:
   • Architects
   • Agile Liaisons
   • Customers
   • Team Guides
     Tip: Put a link to the template in your invitation and ask them to review it beforehand.
5. Facilitate the meeting to add, revise, or delete portfolio items.
   Tip: Only cover the items applicable to 80% of your programs.
6. Notify all stakeholders about the program.
7. Modify the template as you identify items that are or are not needed in most programs.

Phase Deliverables if Needed

Often these project lists look waterfall-ish. At one company that designed complex products for later manufacturing, we ended up with nine projects rank-ordered by the chronology inherent in creating something that requires a significant investment just to get to a trial run. That said, this company did not use agile manufacturing or invest in 3-D printers; had it done so, I think the phases could have been cut down to a list of projects like this:

1. Initiation—Conduct due diligence to justify the program (or next project within the program), by creating the project charter, initial epics, etc.
2. BOM and Cost Estimate—Create a prototype that allows drafting of a parts list (“bill of materials”) and estimated manufacturing costs, usually required to gain approval for development.
3. Revision [Letter]—A project that gets repeated as often as needed through revisions ending in updated prototypes (“Rev. B,” “Rev. C,” etc.).
4. Manufacturing Pilot—Work with plant and supply chain groups to build or configure a line for producing test units and do pilot runs.
   Note: Certification efforts, if any, could be in this or the next project.
5. Qualification Testing—Run “qual” tests and address defects until the product design, line configuration, and supply chain are finalized.
6. Close—Transition the design to production and support teams.

Recall that under FuSca, a team can work on different projects at once. Thus if the program was in the last Planning Release of the “Rev C Project” (for example), and knew it would be ready for the pilot after that, it could begin the “Manufacturing Pilot Project” in the same release.

Going forward, when a new program is proposed, the Project Sponsor or ARM simply creates a copy of the template program and revises the first project (like “Initiation” above) to reflect the language and needs of the new program. This may require deleting or adding epics in consultation with stakeholders, but most of your work is already done. Future projects in the program get modified one at a time as you get ready to start on them.

↑ System | ← Run the Release | → Customize FuSca

---

[1] (Removed.)

[2] Project Management Body of Knowledge (Project Management Institute 2013).

[3] Discussed under “The Power of Acceptance.”