Scrum (eBook)

What You Need to Know About This Agile Methodology for Project Management

Robert McCarthy (Autor)

eBook Download: EPUB

2020 | 1. Auflage
110 Seiten
Robert McCarthy (Verlag)
978-1-393-18884-1 (ISBN)

Infos

 Did you always want to be a great project manager, able to manage projects like a breeze? But you can't figure out the best way to do it? This book can change things for you... keep reading!  You're probably frustrated about projects not going the way you wish. You've probably tried solution after solution, withoutgood or efficient results. Do you want to change things around and make a shift to a far more efficient and effective way of managing your projects? If so, then you've come to the right place. You see, managing projects doesn't have to be difficult. Even if you have tried multiple project management methodologies, it is easier than you might imagine. A study conducted by Tomas Gustavsson in 2016 shows that so-called agile methodologies result in far greater outcomes during projects, due to better teamwork, customer interaction, and more flexibility. Similar insights can be found in research conducted by Zahid Masood, who adds that agile methodologies result in a reduction of costs, faster completion of projects, and better management of scope. Thus, you can tackle your projects as you've never done before-without the hassle old methods bring about. Here's a tiny fraction of what you'll discover: -  Project management in the past and present, and how it can damage you and your organization.  -  What Scrum is all about and why you need it.  -  What roles and responsibilities can be found in Scrum, and how they deliver value almost secretly.  -  How to gather your All-Star Scrum Team.  -  How to get the ultimate rewards from various artifacts and ceremonies.  -  Practical examples to get things started.  -  Common mistakes that can cost you thousands of dollars.  -  And much more!    So if you want to learn more about scrum, scroll up and click the 'add to cart' button! 

Textauszug

Every innovation has its history. The same goes for methodologies to manage projects. Nowadays, more organizations adopt what we call agile methods for project management. When you ask someone to describe the term agile, you’re likely to get multiple different answers. Therefore, it is helpful to take a look at the origins of this agile-way of working. That’s precisely what we’ll do in this chapter. Furthermore, you will learn more about various agile concepts, its components, multiple benefits, and much more.

The Origins of Agile Methodologies

Before organizations practiced agile methodologies, they employed the so-called “waterfall method” to get through projects. Winston Royce first mentioned this waterfall method in his paper, Managing the Development of Large Software Systems, that he published in 1970. Royce proffered a diagram for software development, similar to the one you see below:

In the chart, you see the various phases of software development. Starting with the System Requirements and Software Requirements, it was possible to come to an analysis. Afterward, it was possible to design the program based on this analysis. When the design was ready, it was time to start coding and testing the software. Finally, the software would go to operations and would be used. As you see, each phase flows into a new one, without going back to a previous phase, similar to a waterfall. What I found particularly interesting to note is that Royce himself didn't see this method as optimal. This became evident in his paper when he described a more iterative and step-by-step approach of going through these phases (i.e., agile).

There is a reason the method goes through the phases like a waterfall. Remember that in the 1950s and 1960s, computers were as big as a house! They had various intricate parts that were hard to work with and needed professionals to change any of these parts. These computers were very time-consuming and complex to develop. Thus, the waterfall method was introduced to tackle this endeavor. There are numerous challenges involved by practicing this method. In the waterfall method, there are specialized people per phase. Just think of business analysts, architects, and designers, developers, QA specialists, and infrastructure specialists who did the deployment. The problem is the gaps between these activities and the need to transfer information between these phases. A lot of documentation was developed through each stage. The business analyst starts with the documentation and passes it to the designer who adds to it. Analysis and design together are what we call “Big Design Up Front” or, in short, BDUF. When the design is ready, the document is passed on to the developers. When they are done with the product, they hand it over to the testers. Afterward, they hand it over to the IT-staff who help the customers implement the software.

What usually happened was that when the developers were busying themselves with the program as described in the documentation, they found that what they had to create didn't work out. Then a change needed to be made. And this change was not found in the documentation made earlier. Now we have code that doesn't match the documentation—the same documentation that took the analysts and developers a lot of time to craft. Therefore, there had to be a way to go back to this documentation and improve upon it, remove parts, or add new elements.

Furthermore, within the waterfall method, milestones are generally used. These are detailed with a description and the date by which they should be achieved. However, in practice, it's challenging to always stay within the specified time frame. Sometimes more time is needed, making every defined milestone inaccurate. Also, the professionals in these phases didn't talk with the other professionals that weren't in direct relation to them. For instance, there is no clear communication between the testers and designers or analysts and the IT-staff.

It should be clear that this method is far from ideal in the rapidly changing digital era we live in today. Fortunately, there's a new, more agile approach to deal with projects. The new procedure was mainly created in response to the developments of computers in the 1980s and 1990s. Computers became easier to employ, and Software as a Service (SaaS) and the internet became available. In 1986, Hirotaka Takeuchi and Ikujiro Nonaka wrote a paper in the Harvard Business Review named The New New Product Development Game. In this paper, they delved into the phases of the waterfall method, namely: analysis, design, develop, test, and finally deploy. Besides giving more detail about the steps, they pointed out something very innovative. They showed that these phases don't only work on their own. In fact, the stages they proffered showed that the phases should have a very distinct overlap. Thus, information was better communicated between the professionals in each stage. For example, the analyst actively checks on the design and even looks at the development, from time to time. The paper suggests that the analysts should be around more frequently during the development phase, so that even at the end of the development phase, there is still a business representative (analyst) who can deliver the appropriate information.

Takeuchi and Nonaka described this process as being like a “scrum.” This was derived from the Rugby term, when all players are linked together. Being linked together, they all work toward a common goal: trying to push the ball down the field. This symbolizes a team walking through the phases together, all the way to the end. Furthermore, from this paper, many processes, methods, and frameworks were developed and enhanced, such as Scrum by Jeff Sutherland and Ken Schwaber, Extreme Programming (XP) by Kent Beck, Kanban by Taiichi Ohno, and many more.

Fast forward to the 21st century, and current “thought leaders” have concluded that they're striving for similar goals. They are trying to achieve the same objectives to make processes more efficient, effective, and worthwhile. They found out that a lot of what they were doing in their methods has, in fact, a connection with other methods. The methods were more interconnected than the thought leaders imagined. Thus, because many of the core values in these methodologies were the same, they came together to bring to life what's called The Agile Manifesto, published in 2001. This manifesto introduced the world of project management to values it was in dire need of. It outlines that individuals and interactions are more important than processes and tools. But processes and tools still have a place; they just shouldn't intervene with, for instance, communication with stakeholders or professionals in a project. Besides, the manifesto values working software more than having comprehensive documentation. Don't get me wrong, documentation still has its place, but the actual, pure-practice of working with the software has the upper-hand. Customer collaboration is more significant than contract negotiation. Sometimes things change. Therefore, we must be able to have some form of dynamism in contracts; this isn't possible without adequate customer collaboration. In an agile approach, we value responding to change more than following a strict plan. No doubt, the adage, “If you fail to plan, you're planning to fail,” sounds clear in our minds, but planning shouldn't be too rigid. Rigidness is what prevents organizations from moving through projects quickly. Moving quickly isn't possible without the flexibility to respond to changes swiftly.

Sometimes finding a more balanced approach between the values is necessary. In various organizations, people use tools such as Zoom or Skype for Business to make communication possible with remote workers or external stakeholders, using technology to support a focus on individuals and interactions. Therefore, extremes should be avoided. Each project should be evaluated individually to figure out how much each value should weigh.

The Key Agile Concepts

To develop a correct agile mindset, you should understand various agile concepts. The first concept you should know about within the agile-approach is short feedback loops. In the waterfall method, a customer may see no product for months, maybe years on end. If it turns out that the customer wanted a different feature or perhaps an entirely different product, it's too late. A key concept within agile is to get information to the customer as soon as possible, so they can find out ways to move forward in the shortest possible time. Thus, it's possible to fix things while the project is still running. The same goes for professionals, such as developers and testers, or even business analysts. With an agile mindset in place, every team member thinks “big” about the end product, but they work “small,” so they can fall and get back up rapidly and learn from these missteps swiftly every single time.

The second concept is the so-called just-in-time way of gathering requirements and finishing the design. Frequently, developing software is compared to building a house. Honestly, it's nothing like building a house. There is no need to have complete blueprints outlining every intricate aspect of design from A to Z. What I've seen in practice is that development works exponentially better when working from a kind of “to-do list,” as simple as that may sound....

Produkt-Details

• Erscheint lt. Verlag: 10.1.2020
• Verlagsort: Njurunda
• Sprache: englisch
• Themenwelt: Wirtschaft ► Betriebswirtschaft / Management ► Unternehmensführung / Management
• Schlagworte: agile development • Agile methodology • Agile principles • Product Backlog • Project Efficiency • Project Management • Scrum • SCRUM Framework • sprint planning • Team collaboration
• ISBN-10: 1-393-18884-2 / 1393188842
• ISBN-13: 978-1-393-18884-1 / 9781393188841