Skip to main content

Practical Agility

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

Search This Blog

Showing posts with the label scrum

Posts

Pragmatic Agile - Remember the First Value!

on April 10, 2012

agile pragmatism scrum scrummaster values

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Agile in its Second Decade

on April 05, 2012

agile kanban manifesto scrum xp

+

Get link
Facebook
X
Pinterest
Email
Other Apps

"Guaranteed to Pass"

on January 31, 2012

agile certification scrum

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Great New Scrum Extensions!

on October 10, 2011

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Technical Excellence in Scrum

on September 16, 2011

agile scrum technical debt technical practices

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Raising the Water Level

on July 22, 2011

agile flow lean scrum

+

Get link
Facebook
X
Pinterest
Email
Other Apps

The Fighter Pilot Who Changed Software Development

on July 14, 2011

agile boyd lean ooda scrum

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Worth Repeating - XP Bills of Rights

on June 29, 2011

agile rights scrum xp

+

Get link
Facebook
X
Pinterest
Email
Other Apps

A New Daily Standup Dysfunction

on May 05, 2010

agile scrum standup meeting

+

Get link
Facebook
X
Pinterest
Email
Other Apps

False Advertising?

on December 27, 2008

+

Get link
Facebook
X
Pinterest
Email
Other Apps

The Practices Do Matter... At First

on November 19, 2008

agile practices scrum shuhari xp

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Agile Circling the Drain?

on November 16, 2008

agile agile adoption scrum xp

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Call it what it is!!

on September 24, 2008

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Scrum is not Enough

on June 20, 2008

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Bloodletting

on November 14, 2005

agile agile adoption larman scrum slashdot waterfall xp

+

Get link
Facebook
X
Pinterest
Email
Other Apps

Dave Rooney

Archive

2018 1
- March 1
  - Phoenix - A Challenge to the Public Sector

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
- June 2
- May 2
- April 3
- March 1
- February 2
- January 2
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...

"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