English audio based English [Auto-generated]
The Project Management Institute and Agile Alliance® chartered this practice guide to create a greater understanding of agile approaches in their communities. The vision for this practice guide is to equip project teams with tools, situational guidelines, and an understanding of the available agile techniques and approaches to enable better results.
Until recently, Agile was seen as a set of management practices relevant to software development. That’s because Agile’s initial advocates were software developers and its foundational document was the Manifesto for Software Development of 2001. Fifteen years later in 2016, following recognition by Harvard Business Review, McKinsey & Company and the 2015 Learning Consortium Project, Agile is now spreading rapidly to all parts and all types of organizations.
Now we go to the third chapter: Life Cycle Selection. Projects come in many shapes and there are a variety of ways to undertake them. Project teams need awareness of the characteristics and options available to select the approach most likely to be successful for the situation.
Implementing Agile is mentioned in both chapter 4 and chapter 5. Chapter 4 will discuss about creating an Agile environment and chapter 5 will discuss about delivering in an Agile environment.
As mentioned in the previous chapter. Implementing Agile has two separated parts: Creating an Agile environment and Delivering in an Agile environment. In the previous chapter, we discussed how to create an Agile environment. Now, we talk about how to deliver in an Agile environment.
Every project exists in an organizational context. Cultures, structures, and policies can influence both the direction and the outcome of any project. These dynamics can challenge project leaders.
In the Agile Planning Onion, the first three levels are typically outside the purview of the agile team. Decisions about organizational strategy and portfolio investments are made by PMOs, business stakeholders, or product management. Agile teams are generally responsible for the last three levels of planning starting with Release Planning.
In this chapter, we talked briefly about Scrum, the most popular Agile project management framework being used today. The remainder of this course will focus on the ins and outs of Scrum. We will look in detail at how Scrum works, and the roles, meetings and artifacts used in Scrum. You will come away with a good understanding of Scrum and how it is used for organizational change.
Remember that we said that Scrum is simple. Scrum consists of just three roles: the Product Owner, the Scrum Master and the team. And there are surprisingly few rules. In this chapter we will explore each of these in some detail.
The Scrum framework includes a set of four distinct meetings as highlighted in the diagram below. These are sometimes called events, ceremonies or rituals, depending on the organization or trainer. They are the Sprint Planning meetings part 1 and 2, the daily Scrum or standup, the Sprint Review and the Sprint Retrospective. There are a couple of other unofficial meetings that we will cover in this Chapter as well.
We have already introduced the Scrum artifacts in the previous units. These include the Product Backlog, Sprint Backlog and the Potentially Shippable Product Increment as shown in the diagram below. We will explore each of these in detail in the sections that follow.
The focus of this Chapter will be to explore in detail what it is like to be on a Scrum team. Every Scrum team is a little bit different in terms of personality, approach, challenges and even in the way that they use Scrum.