Skip to main content

Practical Agility

Rants and musings about making the software world a better place.

Search This Blog

Showing posts from June, 2012

Posts

Test-Driven Development as a Design and Learning Technique - Introduction

on June 25, 2012

agile design TDD

+

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

Stoop and Scoop

on June 04, 2012

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

Dave Rooney

Archive

2018 1
- March 1

2015 10
- May 2
- April 3
- March 3
- February 2
2014 20
- October 1
- September 1
- August 3
- April 1
- March 6
- February 4
- January 4
2013 5
2012 12
2011 41
- November 2
- October 4
- September 3
- August 2
- July 5
- June 13
- May 4
- February 4
- January 4
2010 24
- October 2
- September 7
- August 4
- June 1
- May 3
- April 2
- March 2
- February 3
2009 15
- December 4
- November 1
- June 3
- May 3
- April 1
- March 1
- February 1
- January 1
2008 18
- December 2
- November 6
- October 1
- September 2
- June 3
- February 2
- January 2
2007 7
- November 3
- October 1
- June 1
- April 1
- March 1
2006 19
- September 3
- August 3
- May 3
- April 1
- March 1
- February 5
- January 3
2005 4

Show more Show less

Labels

#noestimates
2010
abandonment
accountability
agile
agile adoption
agile humour
ambler
america
analysis

Show more Show less

Popular Posts

Waterfall vs. RAD vs. RUP vs. Agile (Scrum, XP, etc.)

When I broke into this industry in the mid to late 1980's, it was pretty well a Waterfall world. By that I mean the minimal definition of waterfall from the top of page 2 of Winston Royce's seminal 1970 paper Managing the Development of Large Computer Systems that showed the flowing steps of Requirements, Analysis, Design, Coding, Testing, etc., and not the more comprehensive definition that followed in the rest of that paper. I was a good soldier, defining and designing everything up front... well, OK, sometimes I cheated and did some coding work because I was impatient or bored and needed to get moving forward, but generally I followed those steps. In the early 1990's, along came this cool concept called Rapid Application Development (RAD). The consumers of the systems we were building were also impatient - they wanted value NOW, and were willing to have corners cut with the design and documentation. So, RAD espoused getting something - anything - into production RIG

Fibonacci Must Die!

Leonardo Fibonacci died over 760 years ago but he had a profound effect on mathematics in western civilization. He brought what he had learned from mathematician in north Africa back to Europe and authored the book Liber Abaci , which described such things as the Hindu-Arabic numeral system and place value of numbers. In the book he also showed how a number of mathematical problems were solved using the techniques he had learned, one of which was the growth of a population of rabbits. Although he didn't invent it, that sequence bears his name today, and is seen in many places in nature. The use of the Fibonacci sequence in a slightly modified form has also been popularized in the Agile community as values which can be used to estimate the effort required to deliver work. This is usually tied to the Planning Poker technique created in 2002 by James Grenning , and Mike Cohn's Mountain Goat Software sells decks of planning poker cards that use the values 0, 1/2, 1, 2

"How Thin is Thin?" An Example of Effective Story Slicing

Graphene is pure carbon in the form of a very thin, nearly transparent sheet, one atom thick. It is remarkably strong for its very low weight and it conducts heat and electricity with great efficiency. Wikipedia If you have spent any time at all working in an Agile software development environment, you've heard the mantra to split your Stories as thin as you possibly can while still delivering value. This is indeed great advice, but the term "thin" is relative - our notion of what thin means is anchored by our previous experience! To help communicate what I mean when I say that Stories should be thinly sliced, I'm going to provide examples from a recent client who was building a relatively standard system for entering orders from their wholesale customers.

Is Predictability Really What We Want?

Predictability in software system delivery is as close to a Holy Grail as it comes in the IT industry. I’ve heard many people stress being able to have a predictable delivery cadence as something valuable to them. As recently as today I saw a reference to “predictability over commitment” on Twitter! But why is predictability so important to so many people? The people who pay for the software we create certainly want to get away from systems that cost more than was originally expected and take longer to deliver than thought. They also want fewer surprises from defects that show up only when a system is in production use, which require more time and money to fix. The people who manage software delivery groups certainly want to be able to know how much their teams can deliver over a certain time period so they can work proactively to deal with issues such as training and career development.

Subscribe via E-mail

Enter your email address (we won't share it with ANYONE!):

Delivered by FeedBurner

Report Abuse

Powered by Blogger