1 We Can’t Go On Like This

To understand the rise of agile models, we need to review the all-too-common problems faced by projects through the 1980’s and 1990’s.

1.1 Failures & Tension

• Large projects were notoriously prone to late delivery or to never being completed at all.
• Management was frustrated by developers, who were seen as undisciplined and ignorant of or unconcerned with the realities of the corporate world.
• Developers were increasingly upset over what they saw as as incompetent management practices.
   

  Tension between management and developers dates back to our earliest days.

  Consider the introduction of the programming language COBOL in 1959 that replaced familiar-looking calculations like

  X = Y + 1
  

  by

  ADD 1 to Y GIVING X.
  

  This created the illusion that managers could read the code being written by their subordinates to help keep track what they were doing.

  Of course, this hope was futile. Understanding individual statements is useless without an appreciation of algorithms and a familiarity with common programming patterns and practices.

  • Most software projects were managed by “traditional” business managers who were not and had never been software developers.
  • The entire structure of the Waterfall Model is more concerned with documentation and accountability to management than with the realities of how to develop good code.

1.2 Common Problems

• Developers felt that too much of their time was wasted on elaborate documentation that would be signed off on by managers and, thereafter, never actually read or used by anyone ever again.
• Developers would be pigeon-holed into specialized roles…
  • "You’re the database guy. She’s the server guru. He’s the requirements writer.
  …and would be rotated into and out of projects when their specialized role seemed relevant.
• Project development times on the order of years meant that, by the time a project was delivered, the world had changed to the point where the original requirements were no longer relevant.
  • During much of this time, customers were closed out of the process.
    • This led to many unpleasant “surprises” when the software was finally released.
  • But management’s conviction that a signed requirements document == a binding contract meant that changes in real-world requirements could not be revisited.

• Inflexible schedules set early in the project led to “crunch time” behavior leading up to each milestone.

  • Forced overtime, lost weekends & canceled vacations were treated as normal expectations.
• The choice of development procedures and tools were often imposed from above by management, with little input from the developers themselves.
  • “The company paid a lot of $$ for that new software tool, so you will use it.”
  • “Guess what? The company has just hired XYZCo to provide you all with training in, according to what they tell our VPs, the hottest new documentation technique of the decade. Training runs all of next week from 2:00-5:30 each day.”

In Death March: Managing “Mission Impossible” Projects, 1997, Edward Yourdan writes that programmers on small scale projects are comparatively fortunate because…

A tight-knit group of less than ten people is more likely to stick together through thick amd thin, as long as the commitment isn’t for more than six months or so; and a group of highly motivated people is more likely to be willing and able to sacrifice their personal lives (not to mention their health!) for three to six months, as long as they know the regimen of long nights, wasted weekends, and postponed vacations will come to an end on a matter of months.

The fact that this practice was regarded as normal tells you a lot about the those days.

For that matter, the fact that a book with that title could be one of the more popular books on software engineering can tell you a lot about the state of the practice.

2 The Agile Manifesto

2.1 The Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

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

2.1.1 The Twelve Principles of Agile Software

1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4) Business people and developers must work together daily throughout the project.

5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7) Working software is the primary measure of progress.

8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9) Continuous attention to technical excellence and good design enhances agility.

10) Simplicity – the art of maximizing the amount of work not done – is essential.

11) The best architectures, requirements, and designs emerge from self-organizing teams.

12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

2.2 The Message to Management:

What do the manifesto and, especially, the twelve principles, say to management?

Keep your @!#$% paws off our work!

You’re paying us big $$ for our professional expertise. So trust us to use that expertise

5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• Management should not choose our tools and procedures.
• Management should not be obsessed with detailed monitoring.

7) Working software is the primary measure of progress.

• i.e., not documentation written primarily for the purpose of gathering management signatures

8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• No crunch-time panics

11) The best architectures, requirements, and designs emerge from self-organizing teams.

• Stop imposing specialized roles on developers.
• Teams should manage themselves for their day-to-day work.

2.3 The Message to Developers:

But the manifesto is not just a power-grab by programmers.

Developers have to accept some responsibility.

6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Communication among team members is essential.

9) Continuous attention to technical excellence and good design enhances agility.

• Be a professional: do a good job even when no one (other than your team members) is watching.

10) Simplicity – the art of maximizing the amount aof work not done – is essential.

• Don’t show off by making things more complicated than they need to be.

12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

• Take the responsibility to recognize when things are going well and when going badly.
• If things are going badly, it’s the team’s job to fix it.

2.4 The Message to Customers

Customers should expect to be more involved, and will get a better project earlier.

1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4) Business people and developers must work together daily throughout the project.

It is probably telling that the first 4 principles are all customer-oriented.

3 The Common Characteristics of Agile Process Models

3.1 Keeping it small and fast

• Incremental development, on short intervals.

  • Something newly working that is useful to the customer must be demonstrated every 1-4 weeks. (1-2 is most common.)

• Small teams

  • Typically on the range of 5-15 people.
  • This means that agile is focused mainly on small to medium scale projects.
    • Large to massive projects will need to fall back to Waterfall or other earlier models.

3.2 Self-Organizing

• Communication among peers is the model.

   

  In one popular Agile variant, “Scrum”, each developer answers three questions in the daily meeting:

  1. What did you work on yesterday?
  2. What are you working on today?
  3. is there any problem blocking you from making progress on that?

  • Often facilitated by a daily meeting limited to no more than 15 min. to simply bring one another up to speed on what each person accomplished in the previous day.

  • Purpose is to identify problems, but not to fix them. Fixing problems gets done after the meeting.

• Very few pre-defined roles.

  And even those are “part-time” roles – the person is still primarily another developer.

  e.g., the “Scrum Master”’s special job is mainly to run the daily 15-minute meeting, ask each team member those three questions, and make sure no one strays off topic.

(Of course, not every company that claims to do agile development buys into this. What do you do if you are a company with a bunch of middle managers on the payroll who used to try to manage software projects? Why, you call them all “Scrum Masters” and put them in charge of the daily meeting, which then gets longer and less productive as everyone tries to explain technical issues to a non-technical manager, who in turn expects instant solutions to any problems that are identified.)

3.3 Technical Competency

Developers are expected to be up-to-date in the best practices of their profession.

• Tools: IDEs, version control, configuration management, test frameworks
• Practices: Clean Coding, SOLID design, Test First Development, Test Driven Development
• Documentation: API documentation, User Stories

We’ll learn about most of these in the coming weeks.

A team must have all the skills required for the project.

• Each person need not have all those skills.

  If the project requires, e.g., a database, there are likely to be some people on the team who are more skilled with databases than others.

  • But each person should be leaning.

Teams share responsibility for the quality of the code that they produce.

• Team members inspect one anothers’ work on a regular basis.

4 Agile and CS 350

The team project is a crucial component of this course.

We will be following a largely agile approach, with some adjustments:

• We will start by writing a formal requirements document.

  • This is not common in agile development.
  • However, most agile teams are already familiar with the application domain in which they will be working.
  • Writing a requirements document is a way to acquire that familiarity.

• We will need to build up to the technical competency expected of agile developers.

  • We will, of necessity, be learning the tools and techniques over the course of the semester.

Nonetheless, the emphasis is on the process.

• Teams need not actually complete the implementation of the program.
• But they are expected to demonstrate that they have settled into a process that would allow them to make steady progress towards completing it.