Andy Webb - Agile Project Management Methodology for Beginners: Scrum Project Management for Beginners

Agile Project ManagementMethodology for Beginners: Scrum project management forbeginners

by Andy Webb

Text Copyright 2015 AndyWebb

All Rights Reserved

Smashwords Edition

Disclaimer: This book contains generalinformation that is based on authors own knowledge andexperiences. It is published for general reference and is notintended to be a substitute for professional advice. The publisherand the author disclaim any personal liability, either directly orindirectly, for the information contained within. Although theauthor and the publisher have made every effort to ensure theaccuracy and completeness of the information contained within, weassume no responsibility for errors, inaccuracies, omissions andinconsistencies.

*****

Dedication:

To my parents.

*****

By AndyWebb

http://thetruemanager.com/freegift

*****

CONTENTS

*****

*****

INTRODUCTION

*****

My first experience with Agile was in 2005 ata small tech startup company on the West Coast. At the time, theconcept of software as a service (SaaS) was in its infancy, and weended up developing a great product that fell short of itspotential because the public was still committed to desktopsoftware.

But the seed had been planted, and Ive spentmy entire career since then working as a contractor in smallstartups developing software products. With the emergence of cloudcomputing in 2008, a lot of pieces fell into place for me. Sincethen Ive been part of several great projects, including a numberof mobile web applications. Invariably, the most successfulcompanies Ive worked for used Agile to manage their teams.

My intent in writing this book is to use myexperience as an Agile team member to introduce readers to thebasic principles of Agile. This is not an advanced Agile practicemanual. In fact, I believe that once you learn the basics, the bestplace to learn advanced Agile methods is on the job. My role is toexplain its basic concepts and lay out how the various parts ofAgile fit together as a whole system in the real world of projectmanagement.

The books primary focus is on the Scrumvariant of Agile because Scrum is the best known and most widelyused of the Agile methodologies. In its original form, it predatesAgile itself and served as inspiration for Agiles principles. Forthis reason, I made a conscious decision to use Scrum as a lensthrough which the reader can view Agile in practice. Readers shouldknow that Scrum isnt the only form of Agile, or even the best onefor all projects. Its simply the best vantage point (in myopinion) for understanding Agile, and lightweight softwaredevelopment methods in general.

Agile is a powerful tool for fosteringteamwork and mutual support, but only when all of the team membersshare the same understanding of how it works. Agile is great fordefining roles and generating problem solving strategies, but itcan also serve as a source of inspiration and camaraderie. This isespecially critical in a startup environment, where the pressurecan be tremendous.

The principles of Agile are so powerful thatthey extend far beyond the software development world. It was myintent in writing this book to present the underlying structure ofAgile in simple enough form that you, the reader, can pick it upand apply it to tasks as diverse as managing a non-tech company,building a house, mastering a new skill or hobby, or living a moreproductive and meaningful life.

I hope this book lays the foundation for youto put the Agile method into practice as you strive for the goalsyou want to reach, and that it becomes a permanent part of yourlife toolkit.

Andy Webb

*****

CHAPTER1

AGILE OVERVIEW

*****

What Is Agile?

Agile is a lightweight software developmentmethod that aims to be more efficient than traditional, plan-drivendevelopment models. Agile seeks to do more with less:

- more team-level decision making

- faster development time

- faster response to shifting customerdemands

- faster problem solving

- more customer satisfaction

- smaller teams

- less expense

- less wasted effort

- fewer features in the end product thateither dont work or are never used

As a contractor on several development teamsin the early 2000s, I experienced firsthand the inefficiencies ofplan-driven methods for developing software. I confess my guilt asan aider and abettor in developing numerous examples of what cameto be known as bloatware. These programs often took three or moreyears to develop, yet their customer satisfaction levels were poor.After working on Agile teams for a few years, I came to understandwhy those massive projects of the past so often turned into massivefailures. Here is a summary of the mistaken assumptions that led tothe proliferation of bloatware.

Full-Featured Is Always Best: beforeAgile, there was a widespread dogma that good customer servicealways meant developing software with hundreds of features toaddress each and every perceived customer need, large or small, asif they were of equal importance. In reality, full-featuredsoftware was a limited market, and customers were hungry for simpleprograms that were easy to learn and would solve their specificproblem.

Belief in Static CustomerExpectations: another issue was the belief that customer demandcould be captured in snapshot form and would conveniently remainunchanged while the development team did its thing. This might havebeen true before the internet, but as soon as consumers startedusing the web, customer demand for features began to shift on adaily basis. The old development models were aiming for a targetthat had long since ceased to exist.

Long Product Development Cycles:predictive (plan-driven) development models dictated that a programcouldnt be released until all of its features were finished andbug-free. The desire to release quality products is admirable, butthe size and scope of those products meant they would be obsoletelong before their release date.

The Agile methodology was a reaction ormaybe rebellion is a better word against these dogmas. As aveteran Agile team member, I want to emphasize that this wasntmerely an attempted power grab by coders who didnt like authority.So-called cowboy coding, where theres no supervision and teammembers just go off and do whatever strikes their fancy on thatday, doesnt make sense from a business perspective. The point ofthe Agile movement is that the old, micromanaged development modeldoesnt make good business sense either. The real focus of Agile isto once again put the customers needs at front and center, wherethey belong.

The Agile Manifesto

Lightweight development methods such as Scrumhad been in use since the mid-1990s but were known by few peopleother than the teams that were using them. Agile became a movementin February 2001, at a meeting at the Snowbird Resort in Utah.There, 17 software developers got together and refined theunderlying principles of lightweight methodology into the AgileManifesto.

We are uncovering better ways of developingsoftware by doing it and helping others do it. Through this work wehave come to value:

Individuals andinteractions over processes and tools
Working software overcomprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

Source: http://agilemanifesto.org

The original drafters of the Manifesto wrote12 Principles of Agile soon afterward. These principles grew out ofthe Manifesto and were written to provide more specific guidance toteams that wanted to use Agile for software development. The 12Principles are listed in the Appendix of this book.