Locked lesson.
About this lesson
The Agile/Scrum project management methodology is an iterative approach that requires fewer resources than other approaches.
Exercise files
Download this lesson’s related exercise files.
Agile/Scrum Methodology .docx59.4 KB Agile/Scrum Methodology - Solution.docx
61.2 KB
Quick reference
Agile/Scrum Methodology
The Agile/Scrum project management methodology is an iterative approach that requires fewer resources than other approaches.
When to Use Agile/Scrum Methodology
The Agile/Scrum approach works well when the project goals have some flexibility. The iterative nature allows the team to rapidly change direction based upon what they discovered in a preceding iteration. It does require a co-located team and versatile multi-functional team members.
Instructions
The Agile/Scrum methodology is the most flexible of the methodologies discussed. There is both flexibility in the project goals and the project approach; although it requires flexible team members to be effective. There are many Agile methodologies, the Scrum methodology relies of rapid iterations by empowered teams. Each iteration may go through all the of the typical project phases in order to create a minimally viable product or project result. The approach relies on prioritization of requirements so that only a subset of the requirements is addressed in any iteration. The use of traditional project management tools is minimized since they add very little value with this approach. An illustration of this approach is shown below for a generic software development project.
The approach uses a small inter-disciplinary team to conduct the project activities. Because of the inter-disciplinary nature of the team, there are no set roles among team members. Anyone can work on anything. The focus is to get something working. So the project activities are pointed to achieving the minimally viable product – not a full featured product. Also, because of the nature of the team, issues are worked on by whoever on the project team is available to work on it. A general rule of thumb is, “You find it - you fix it.”
The advantages of this approach are both in the size of the team and its flexibility. The small co-located nature of the team provides excellent communication and rapid issue resolution. There are no big committee meetings; the team members just to talk with each other to find a resolution to a problem. The team members are able to create and maintain a prioritized list of requirements, and work to the priorities, not to everything in a requirements document. One of the key characteristics is that this approach often requires just a fraction of the normal amount of people. This again leads to better communication and more flexibility.
However, there are weaknesses with this approach. The weaknesses which I will discuss are those I observed with companies who tried to use this approach in the past without some of the Agile/Scrum practices. Many of the topics we will discuss later will address and attempt to manage these weaknesses.
The first is that it may be difficult to find the multi-discipline “superheroes” to do this type of work. It is not a coincidence that this is the approach that most start-up companies use. They need the entrepreneurial mindset to overcome some of this problem. Another problem is the confused lines of responsibility. This will particularly be true if this approach is attempted with a large team or a team that is not co-located. The other weaknesses are the unpredictability in this approach. There is unpredictability on what will be the characteristics of the final result, on when it will be ready, and on the level and quality of both documentation of both the execution of the project and the results of the project.
Hints and Tips
- Don’t attempt this approach without using the Agile/Scrum tools. The weaknesses will overwhelm the benefits.
- This is an approach that leverages flexibility. Don’t try to tie it down precisely. If you need precision, use sequential or concurrent.
- 00:03 Hi, this is Ray Sheen.
- 00:04 Now, let's look at the Agile/Scrum approach, or
- 00:07 at least what the approach looked like until some of the principles of
- 00:11 Agile/Scrum discipline were actually applied.
- 00:15 >> For starters, you see that there is no wall.
- 00:18 There's no difference between the team members.
- 00:21 All are equal and can potentially do anything on the project.
- 00:25 So the designer is the coder.
- 00:28 This can greatly simplify the project management work and team coordination but
- 00:32 it does mean that you may need some multifunctional super hero's
- 00:35 to do the project work.
- 00:38 So let's look at how this project work is organized.
- 00:41 One thing that you immediately see as that it is done in iterations or
- 00:44 waves instead of the fully integrated concurrent approach.
- 00:48 This approach takes a piece of the project work, completes that and then goes and
- 00:52 gets another piece and adds that on to it.
- 00:55 In the example I'm showing four iterations.
- 00:58 I've seen projects with as few as 2 and as many as 12.
- 01:02 During each of the iterations multiple activities are done,
- 01:05 such as concept design, coding and testing.
- 01:08 This approach has grown out of the approach
- 01:11 that has been used by high tech start-ups for years.
- 01:14 A few people work to get a basic product ready to go and
- 01:17 then start adding features and functions in successive releases.
- 01:21 The approach relies on a small interdisciplinary team doing the work of
- 01:25 each iteration.
- 01:26 By inter-disciplinary, I mean that each individual is able to do multiple tasks or
- 01:30 activities, they are not narrow specialists.
- 01:34 The approach is focused on performance.
- 01:36 Get this iteration to work, and
- 01:37 work as well as possible, any problems will then be fixed on the next iteration.
- 01:42 And any issue can be resolved by anyone, in fact,
- 01:45 it's usually a case of you found it, you fix it.
- 01:49 If you have the knowledge and the capacity to work on a problem, work on it,
- 01:52 there's no such thing as, well that's his job.
- 01:55 So what are the pros and cons of the Agile/Scrum approach?
- 01:59 Before I go through the list, let me point out that
- 02:02 this is the list I work with before the Agile/Scrum methodology was codified.
- 02:06 Some of the Agile/Scrum techniques we'll be looking at soon,
- 02:09 directly address the problems in the con's list.
- 02:13 First the pro's.
- 02:14 There is excellent team communication.
- 02:17 This approach is almost always done with a collocated team.
- 02:21 I don't mean the team members are just in the same building somewhere,
- 02:24 I mean everyone is in the same room.
- 02:26 So communication with the small group like that is very easy.
- 02:30 Issues are quickly resolved.
- 02:32 You don't need to hold a committee meeting, you just fix it.
- 02:35 There's normally a very clear understanding of the customer needs and
- 02:38 prioritization of those needs.
- 02:40 The team does not try to create a solution that does everything for
- 02:43 everyone, each iteration is usually focused on a prioritized set of needs.
- 02:49 This approach works well with startups,
- 02:51 because it requires the fewest number of people on the team.
- 02:55 However, there are some problems with this approach, and this list of problems in
- 02:58 particular, are one's that existed before the Agile/Scrum methodology came along.
- 03:05 It's often difficult to find the multidisciplinary super hero's.
- 03:08 With a small team, every one is wearing many hats and
- 03:12 they may not be anyone with the needed experience or knowledge on the team.
- 03:16 The confused lines of responsibilities occur when the team starts to grow and
- 03:21 the small ad-hoc planning and
- 03:22 discussion is no longer adequate to communicate who is doing what.
- 03:26 I worked with a company one time that had grown up from a high-tech startup.
- 03:30 The development process had originally been that while developing a new system
- 03:34 anyone who had a good idea could try it.
- 03:37 Well, the company had grown and now there are over 50 engineers instead of just 3,
- 03:42 and each of these engineers felt that their job title was chief engineer.
- 03:47 Their development process have become a disaster as each engineer
- 03:50 was experimenting with their own ideas at the same time on the same systems.
- 03:55 Another problem with this approach was the unpredictable project cycle time.
- 03:59 It often can't be accurately estimated when a project starts if it will take
- 04:03 three, six or nine iterations to create a result that meets all of the stated needs.
- 04:09 This approach also often has unpredictable product performance.
- 04:13 Each individual on the team who is working on some aspect of the product
- 04:17 continued to work on it until they felt it was good enough.
- 04:20 Everyone had a different standard.
- 04:22 Finally, documentation was often abysmal, no one wanted to do it, so
- 04:27 it was left to the end, slapped together and often wildly inaccurate.
- 04:31 This led to problems for those who are tasked with sustaining and
- 04:34 maintaining the project results.
- 04:36 This approach is lean and fast, but it often is out of control and
- 04:42 that's why we need the Agile/Scrum methods and tools.
- 04:47 We'll build on the inherent strengths of this approach and
- 04:50 address the weaknesses by selecting and
- 04:52 applying some of the best practices from sequential and concurrent methodologies.
Lesson notes are only available for subscribers.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.