2 Revolution and counterrevolution

 

This chapter covers:

  • The core concepts of pre-Agile project management
  • Creating and using visualizations in project management
  • A comparison of the pre-Agile approaches with Agile
  • Agile is simple, but not easy
  • Agile works, in part, by omitting some aspects of project planning
  • Agile projects can fail, and Agile can be ineffective
  • Domain knowledge, critical thinking, communication, and experience are necessary ingredients of success

In Chapter 1, the way Agile was born out of dissatisfaction with other project management approaches that failed when applied to software development projects was introduced. Agile is so successful in replacing those previous approaches that most organizations practicing Agile use it without the background of why it is necessary.

The demand for Agile project management has created a lot of expedient training classes and certification exams. A great majority of books on Agile promise to get the reader certified as a “Scrum Master.” These books and classes reach Agile mostly without context. Agile without context, and without a critical view of the ways Agile can easily be misapplied makes failed Agile projects more likely. A good place to start gaining context is by looking at what preceded Agile, and what went wrong, such that a different approach was needed. This context enables seeing the differences Agile brought to software development project management .

2.1 How managing software projects used to be done

2.1.1 Project management is a large and varied discipline

2.1.2 Systems analysis and the automation of project management

2.1.3 Powerful tools accessible to anyone

2.2 Key concepts in project management

2.2.1 Tasks

2.2.2 The critical path

2.2.3 Resources and resource leveling

Over-committed resources

Slack

2.2.4 Milestones

2.3 Visualization

2.3.1 The Gantt chart

2.3.2 The critical path method chart

2.4 The art of systems analysis style project management

2.5 Traditional project management is too brittle for software

2.5.1 Incomplete software has no value

2.5.2 Software development is definitely not like civil engineering

2.5.3 Value in new software is often found where you also find risk

2.6 Software is a fundamentally different business activity

2.6.1 Project management made for software

2.6.2 By coders for crafting code

2.7 Comparing Agile practices to predecessors

2.8 No true Scotsman puts sugar on porridge

2.9 Agile overshoot

2.9.1 Agile is simplistic about management

2.9.2 Every person in a business is a business person

2.10 An incomplete list of the ways Agile can suck