Project Selection

Quick reference

• 00:03 Hi, this is Ray Sheen.
• 00:05 I've talked about how senior management must align the organizational systems for
• 00:09 Agile/Scrum and how the business and product line strategy can be used for
• 00:14 identifying potential Agile/Scrum projects.
• 00:18 Let's now look at the project selection process.
• 00:20 There are some ground rules management should consider when selecting
• 00:25 Agile/SCRUM projects.
• 00:26 First, let's be clear, management's goal is to select the right project.
• 00:32 These need to be right for both the business objective and right for
• 00:35 use with the Agile/SCRUM methodology.
• 00:38 And of course, the implication of selecting the right project is to cancel
• 00:41 the wrong project.
• 00:43 Now let me be clear.
• 00:44 We're saying to cancel it as an Agile/SCRUM project,
• 00:47 it still may be right for the business, but not for Agile/SCRUM.
• 00:52 But frankly, the bigger problem with most companies is that they don't cancel
• 00:55 projects when they should.
• 00:57 Sometimes, after project has started, it becomes evident that the project cannot or
• 01:02 should not be finished.
• 01:04 Maybe business conditions changed, maybe the technology proved to be too difficult.
• 01:08 Sometimes a problem is existing team or project plan.
• 01:11 It needs to be stopped and start a do-over with a different team.
• 01:16 For whatever reason, senior management needs to cancel the project.
• 01:21 Another important role that we have already talked about
• 01:23 is to get the project goal, objective, or vision.
• 01:26 This is often done in the strategic or product line planning processes.
• 01:31 A factor that management must consider is the organizational capacity for
• 01:35 concurrent Sprints.
• 01:37 How many SCRUM masters, product owners, and SCRUM team members do they have?
• 01:41 Of course, management can also influence that factor by training more of each, but
• 01:45 the point right now is that if management is going to select an Agile/SCRUM
• 01:49 project for initiation, they must have the trained personnel needed for
• 01:53 the work if they hope to have a success.
• 01:56 Finally, a decision that also must be made is whether the project characteristics
• 02:00 lend themselves for the Agile/SCRUM methodology.
• 02:03 We've talked a lot about these projects and compared them to traditional projects.
• 02:07 But sometimes the characteristics are such that Agile/SCRUM just won't work.
• 02:12 In that case, senior management must either change the project or
• 02:16 initiate it using a different project management methodology.
• 02:20 Let's review those characteristics.
• 02:22 When the scope is primarily one of improving or upgrading a product, process,
• 02:27 or technology, it is well-suited to the Agile/SCRUM methodology.
• 02:31 However if it's something that's totally new or different, new or emerging
• 02:35 technology, an invention methodology or stage gate approach may be better.
• 02:40 Because it is so difficult to manage and predict the inevitable inventions,
• 02:44 it must occur.
• 02:46 If the project is a scheduled driven project with a tight or
• 02:49 fixed end date, Agile/SCRUM should be considered.
• 02:52 However, if the deliver bowl is highly regulated and
• 02:56 specified, Agile/SCRUM does not work well since the stories cannot be prioritized.
• 03:01 Everything is a must have and is number one priority.
• 03:04 Agile/SCRUM relies on SCRUM team members
• 03:08 who have the technical expertise to do the project tasks.
• 03:11 If the expertise is not available internally,
• 03:14 then you'll probably need to contract for the work.
• 03:17 And it's difficult to write and
• 03:18 manage subcontracted deliverables in the Agile/SCRUM environment where stories or
• 03:23 deliverables can be quickly changed and reprioritized.
• 03:27 Our purchasing processes just don't accommodate that well.
• 03:32 If the scope lends itself to an iterative development or a creation of a basic and
• 03:37 then enhanced deliverable, it is very compatible with Agile/SCRUM methodology.
• 03:42 However, if the cost of prototypes is prohibitive, or
• 03:46 if it will use scarce or constrained resources,
• 03:49 the iterative approach of adaptive SCRUM may not be appropriate.
• 03:53 When the organization regularly does cross functional project work, and
• 03:57 I mean project work where multiple functions are simultaneously
• 04:00 working together, then the Agile/SCRUM methodology will be compatible.
• 04:04 However if the organization does multi-functional work and
• 04:08 functional silos,
• 04:09 meaning each function does their part and then hands it over to the next function.
• 04:13 This sequential approach is not compatible with how SCRUM teams work.
• 04:18 The last point is less about projects and more about the organization.
• 04:22 The Agile/SCRUM approach requires scrum master and a product owner.
• 04:27 The more difficult role here is the product owner.
• 04:29 You need to have someone who understands all the stakeholder needs and technology
• 04:34 well enough to write the story cards and is trained in the product owner roll.
• 04:38 While scrum masters can work on almost any Agile/SCRUM project,
• 04:42 product owners really do need to have subject matter expertise
• 04:46 in order to do a good job with the product backlog.
• 04:49 It's not enough to just train up scrum masters, product owners, and scrum
• 04:54 team members in order for Agile/SCRUM to be successfully implemented.
• 04:59 Senior management must select the right projects that are compatible with
• 05:04 Agile/SCRUM and not to force the wrong project through the process.

Lesson notes are only available for subscribers.