Practical Agility

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

Search This Blog

Showing posts from 2018

View all

Posts

Phoenix - A Challenge to the Public Sector

on March 22, 2018

0

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

Labels

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

anxiety
apple
architecture
aviation
backlash
bduf
bears
blogs
book
boyd
business involvement
canada
certification
change
coaching
collaboration
communication
community
competence
conference
conventional wisdom
core hours
cots
craftsmanship
culture
cutter
defects
depression
design
effective
engineering
estimation
evolution
experiment
failure
fear
Fibonacci
firearms
flow
gcms
golf
gps
humour
india
industrial logic
innovation
interaction design
java
java eclipse rcp
jean tabaka
kanban
kent beck
larman
leadership
lean
leanstartup
learning
life lessons
long-term
mac
manifesto
mbti
meetings
mental illness
microtesting
miscellaneous
motivation
object-oriented programming
onsite customer
ooda
ottawa
pair programming
people
perception
planning
play
politics
portfolio management
post-agile
practices
pragmatism
principles
product management
product manager
product owner
professionalism
programming
project management
public sector
quality
requirements
resource
responsibility
rights
risk
risk analysis
royce
safety
scaling
scrum
scrummaster
sfagile
shared
shared understanding
shopify
shuhari
simplicity
slack
slashdot
slow
social skills
software design
software development
splitting
sprint review
standup meeting
steve jobs
store
story mapping
survival guide
system thinking
TDD
team
technical debt
technical practices
testing
training
transition
tribe
trust
understanding
user stories
values
velocity
virginia satir
waterfall
whole team
work
xp

Show more Show less

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.