Talkin’ about…
acceptance tests agile use cases antipatterns AONW apologies assumptions Christopher Alexander communication customer service data and algorithms design for test design patterns design roots documentation drawing driven meme DSLs emergent design Eric Evans fun habitable software icebreaker IEEE design column index cards JAOO living software OOPSLA open space parametric polymorphism PLoP podcast problem frames Responsibility-Driven Design SD Best Practices software development processes software history structured design TDD teamwork terminology test-driven development travel use cases wizard-of-oz prototypes workshopsPast Entries
- March 2012 (2)
- September 2011 (1)
- August 2011 (5)
- July 2011 (3)
- May 2011 (1)
- February 2011 (1)
- January 2011 (1)
- December 2010 (1)
- July 2010 (1)
- April 2010 (2)
- October 2009 (1)
- August 2009 (1)
- June 2009 (2)
- March 2009 (1)
- January 2009 (1)
- November 2008 (1)
- September 2008 (1)
- August 2008 (2)
- June 2008 (1)
- April 2008 (1)
- February 2008 (2)
- November 2007 (1)
- October 2007 (1)
- September 2007 (1)
- June 2007 (1)
- May 2007 (1)
- April 2007 (3)
- February 2007 (3)
- January 2007 (1)
- September 2006 (2)
- August 2006 (2)
- July 2006 (2)
- June 2006 (1)
- April 2006 (2)
- February 2006 (3)
- January 2006 (3)
- November 2005 (4)
- October 2005 (7)
- September 2005 (1)
- July 2005 (3)
- June 2005 (5)
- May 2005 (3)
- April 2005 (2)
- December 2004 (2)
Reactions…
- Talman Stoner on How far should you look ahead?
- Talman Stoner on Agile Architecture Myth #5: Never Look Ahead
- John Schwartz on Agile Architecture Myth #5: Never Look Ahead
- Rebecca on Agile Architecture Myth #5: Never Look Ahead
- Chris Collins on Agile Architecture Myth #5: Never Look Ahead
Category Archives: Agile
How far should you look ahead?
I’m a consultant. So an easy answer would be, “It depends.” My real answer is more nuanced: only look ahead far enough to see some significant issue and a plausible way to resolve it. If you want to get better, … Continue reading
Posted in Agile, Software Architecture, Software Design
1 Comment
Agile Architecture Myth #5: Never Look Ahead
Stop it! Stop anticipating! Get coding. Get that next user story working. Don’t. Ever. Anticipate. This seems to be a common agile mantra these days. Since we allegedly aren’t good at anticipating how code will evolve, well frack it, let’s … Continue reading
Posted in Agile, Software Architecture, Software Design
Tagged agile design, anticipation, design, looking ahead
4 Comments
Agile Architecture Myths #4 Because you are agile you can change your system fast!
Agile designers embrace change. But that doesn’t mean change is always easy. Some things are harder to change than others. So it is good to know how to explain this to impatient product stakeholders, program managers, or product owners when … Continue reading
Re-thinking Thinking and Planning
In the tutorial, Hooray We’re Agile Testers! What’s Next?, Janet Gregory apologized a couple of times for saying upfront thinking or planning. I know Janet wanted to let the audience know that she isn’t a fan of massive test plans … Continue reading
Posted in Agile
Leave a comment
Who Defines (or Redefines) Landing Zone Criteria?
Who should be in on discussions that set landing zone criteria? Because most landing zone have architectural implications, someone knowledgeable about the system architecture, in addition to the product owner and other key stakeholders should have a lot to say … Continue reading
Posted in Agile, Requirements, Software Architecture
Tagged facilitation, landing zones
Leave a comment
Landing Zone Targets: Precision, Specificity, and Wiggle Room
A landing zone is a set of criteria used to monitor and characterize the “releasability” of a product. Landing zones allow you to take product features and system qualities and trade them off against each other to determine what an … Continue reading
Posted in Agile, Requirements, Software Architecture, Software Design
Tagged landing zone, target values
Leave a comment
Agile Landing Zones
In my last post I introduced the idea of landing zones, a set of criteria used to monitor and characterize the “releasability” of a product. A landing zone contains system attributes that must be achieved to declare “success”, along with … Continue reading
Posted in Agile, Requirements
Leave a comment
Introducing Landing Zones
On an aircraft carrier, the landing zone describes a small section of deck that a pilot must touch down in to land the plane safely. By analogy, a landing zone for a product describes a range of measurable attributes that … Continue reading
Posted in Agile, Requirements, Software Architecture
Leave a comment
Software Architecture Stewardship
On agile teams, architects do more than design and implement the interesting tricky bits. They typically balance a wide range of concerns: short-term goals, overall system design integrity, risks versus efforts, design expediency… The successful agile architects I know aren’t … Continue reading
Posted in Agile, Software Architecture
Leave a comment
Agile Architecture Myths #3 Good Architecture Emerges
Last time I left the cap off of the toothpaste, a small blob of toothpaste flowed onto the counter. No planning; it just emerged. Now I know that emergent software architecture is another thing entirely. We can’t anticipate everything about … Continue reading
Posted in Agile, Software Architecture, Uncategorized
5 Comments