1.) Pair Programming

Pros – It encourages better practices of development, decreases bug occurrence, and ensures redundancy in working knowledge of software.
Cons – It either gets in the way of your personal downtime activities, like searching for nude pics of Alexandra Daddario…or it leads to an oddly intimate relationship between you and your PP partner.

2.) Use Cases

Pros – It propels developers and stakeholders to predict and plan for various scenarios of your software’s usage.
Cons – It empowers morons to participate in the process. “So, what if a feminist Eskimo were insulted by the phallic nature of the igloo in your button’s image? And if a luddite or Amish person wanted to use the software, could we make the computer run on the churning of butter?”

3.) Scrum Meetings

Pros – Developers and their boss avoid any surprising obstacles or misses of expectations by having regular daily discussions about their current progress.
Cons – Since some people don’t relate the word “scrum” with “brief”, an expected fifteen-minute conversation becomes an hour-long dissertation from Bob about how the Illuminati are running the company and about how he blew the bridge last year. Every. Single. Day.

4.) Cross-Functional Teams

Pros – Developers with different areas of expertise work alongside in order to better understand the issues faced by different departments and in order to create more innovative solutions.
Cons – Sometimes, the “powers-that-be” don’t seem to understand how to properly form a cross-functional team. “Why am I in the same room as the maintenance guy and the building’s bomb-sniffing dog?”

5.) Planning Poker

Pros– During a Scrum session, the usage of cards (instead of vocal answers) will create a more accurate estimation of time required for tasks, since the vocal answers of one could influence others’ estimates.
Cons – Its implementation increases the chance of a violent gambling ring among your software developers, which then naturally leads to the formation of mob families in your department. Productivity will naturally decrease when your developers start missing fingers.

6.) Timeboxing

Pros – By creating a physical visual chart that tracks your project’s progress instead of a hard timeline, you can get a more accurate picture of the current status and impending direction of your work.
Cons – Sometimes timeboxes can become a bit ‘crowded’. “Can we knock out this wall here? I’m going to need a bit more room…I also need somewhere to put this pallet of sticky notes…”

7.) Story-Driven Modeling

Pros – Developers and users get together in order to create detailed usage scenarios for the software, which then reveals new requirements and possible issues when further developing and/or enhancing the software.
Cons – Sometimes pairing certain developers and users can be counter-productive, especially if they develop and chronicle a relationship outside of work. “So, Peter orders a box of condoms by clicking on the ‘Purchase’ button, and then Mary hits the ‘Agree’ button in order to book the hotel room, and then [Insert Explicit Actions Here], followed by [Insert Explicit Image Here].”

8.) Test-Driven Development

Pros – By requiring developers to create tests for their functions before they implement them fully, it helps to ensure that the results are kept in the forefront of the developers’ minds.
Cons – For your more ‘special’ developers, this development style could then be mistakenly combined with their recursive practices, resulting in an infinite spiral where a testing harness is created for unit tests that gauge results from another testing harness…until they piss off the system, are absorbed into the circuitry, and must fight alongside an even older Jeff Bridges against the Uber APU in order to save humanity.

Peter Bolton is the author of Blowing the Bridge: A Software Story and has also been known to be a grumpy bastard on occasion.