Back To CourseAgile & Scrum Training
9 chapters | 131 lessons
Stephen has worked as a Project Manager and is PMP certified, as well as certified by the Scrum Alliance.
Casey provides training for companies who want to learn and use Agile. She spends her time going over the high-level principles that are behind each aspect of the methodology, as well as the low-level details of the people, work, and processes that are necessary for implementation. Her goal is to help people understand Agile and do it well. At the end of her training, she always makes sure to discuss the problems and pitfalls with a focus on the same high-level principles and low-level details. If these are not done well, the benefits of Agile are lost.
The first topics that Casey reviews are the high-level principles, which are the four components of the Agile Manifesto, which is a set of values written in 2001 by individuals from the field of software development who were striving for an alternative to heavy, slow-moving methodologies. The values are:
The pitfall that exists is becoming overzealous and completely ignoring the items on the right. The manifesto states that the items on the left like individuals, working software, customer collaboration, and responding to change are valued more than the items on the right like processes and tools, comprehensive documentation, contract negotiation, and following a plan. This does not mean that the elements on the right have no value. Agile that is completely absent processes and tools, documentation, contract negotiation, and planning will be ineffective.
When the high-level principles are not fully understood or not done well, it makes it difficult to implement Agile because the principles are the basis of the low-level details. However, avoiding the pitfall associated with the principles does not guarantee that the low-level details will be done well. This is why Casey also goes over the problems and pitfalls related to people, work, and processes.
One the largest potential pitfalls in Agile involves the people, specifically the roles that make up the team. For an Agile team to be successful, each position must effectively be filled, including the Product Owner who requests the work, the development team that completes the work, and the Scrum Master who tries to enable the development team to work as effectively as possible. The Product Owner and Scrum Master roles are more straightforward because single individuals fill them. The development team role is often more problematic because it is filled by multiple individuals.
The problem areas for Product Owners and Scrum Masters are opposite and could be described as a Product Owner taking on the characteristics of a Scrum Master and vice versa. Product Owners need to be decisive, own the product, and be the gatekeeper for requirements. It is problematic when they accept all requests from stakeholders or regularly change their minds about requirements. Scrum masters need to serve the development team and trust them to self-manage. The pitfall is to micromanage or dictate everything the team does.
The development team is all about cross-functionality. Agile is at its best when the various team members are engaged throughout the completion of project work, in both development and testing. The pitfall is for the different team members to identify and divide by their function. Sometimes it is even to the point where one team is entirely made up of developers and another is made up entirely of testers. The skill sets are different, but each team member can bring value in each phase of the project work.
One of the most crucial aspects of any project methodology, including Agile, is the project work. Specifically, in Agile, the project work is broken down into smaller, more manageable portions, known as user stories. The quality of user stories plays a significant role in how effective Agile can be. User stories that are consistently too complex are problematic. Additionally, user stories that are regularly subject to change and not consistent are an issue as well.
The other pitfall related to project work involves its completion. The team commits to fully develop and test each user story within a given sprint, which is a repeated interval of typically 2 to 4 weeks that occurs throughout the project. Failure to complete a user story in the sprint is just that, a failure. However, if the team is not accountable for unfinished work, it can easily lead to a lax attitude about fulfilling sprint commitments and a regular occurrence of carryover.
The final aspect of implementing Agile involves the processes. These include the various meetings that occur each sprint and the purpose of them. Sprint planning is where user stories are reviewed and committed to by the team. Daily standups are a recurring meeting where the team checks in and provide specific updates. Sprint review is where completed user stories are shown to the Product Owner and other stakeholders. Sprint retrospective is where the team reflects on the successes, failures, and needed improvements from the Sprint.
Ideally, the team utilizes the Agile processes according to best practices and, as they gain more experience, adapt and tailor each process to their specific needs. The pitfall is not reaching this ideal. One possibility is the team might deviate from best practices too early and does not learn what would be most effective for them. They might even try to eliminate some of the meetings. The other possibility is that the team does not mature and start to tailor each process to their specific needs. Instead, they rigidly do everything by the book, keeping practices that do not provide a benefit or missing out on things that could add value.
Agile can fail in the high-level principles or the low-level details, as there are problems and pitfalls with both. At a high level, the Agile manifesto can be taken too far where instead of valuing each of the items with some over the others; some items are not valued at all. At a low level, there can be problems with the people, work, or process. Regarding the people, it is problematic when the Product Owner, development team, or Scrum Master do not fulfill their role. For the work, the pitfall is that user stories are too complex or change too much and that there is no accountability to complete them in the sprint. The pitfall for processes is that things like Sprint planning, daily standups, Sprint review, or Sprint retrospective are done too rigidly for too long or too loosely too soon.
To unlock this lesson you must be a Study.com Member.
Create your account
Did you know… We have over 95 college courses that prepare you to earn credit by exam that is accepted by over 2,000 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.
To learn more, visit our Earning Credit Page
Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.
Back To CourseAgile & Scrum Training
9 chapters | 131 lessons
Next LessonAgile Planning: Process & Tools