For meetings in previous years, see all meetings
The Value of Refactoring on an Agile Team
Refactoring is often viewed as a technique to clean up existing messy code. If that were always true, then Agile projects would require up-front design, because teams rarely get around to those “big refactorings,” and rarely will a Scrum PO or XP Customer buy (prioritize) a “refactoring story.” In truth, Agile processes require design to emerge. Rob will describe what it means to refactor clean, well-tested code. He will also demonstrate the actual business value of refactoring, and suggest ways to make sure refactoring and Emergent Design are given the necessary time to flourish.
BayXP/SV Agile event planning
We’ve been enjoying these monthly discussions so much we thought it would be worth trying something a little larger in scale. This meeting will be to start the planning a larger event so please attend if you’re interested in helping to organize the event. Some of the decisions to be made:
- Agenda: What do we want to talk about? Fix a theme or pot-luck?
- Audience: open to public? invite only? require people to apply to attend?
- Format: lectures? workshops? open space?
- Duration/timing: 1 day? 2-day? Mid-week vs weekend?
- Cost: charge admission? get sponsorship?
Be the change you want to see in the world… starting with the event you’d like to attend.
What is the Agile Core? Practices and/or Values
Wednesday, February 25th, 2009
Discussion topic:
At the last meeting there was a questions: why is waterfall so easy to describe, but it is so hard to describe Agile?
This is a problem because things that are easy to describe spread faster and broader than things that are hard to describe.
So is there a core to Agile that is easy to describe?
Are there some practices that are simply non-negotiable?
How would you describe Agile to someone who had never heard of it? How would you describe it to a skeptic?
If talking through these questions around the table sounds like fun, come on down and join us.
Aha Moments:
- I might have to change my organization
- It’s not a unified answer (like an elephant)
- Hmm… I had four principles but turned out that I couldn’t remember the one about value
- There is no core of agile that is easy to describe
- All the answers are right but all different. So maybe there is something fundamental that it is not possible to describe.
- Trust keeps coming up. I think I need to do a lot of deep thinking about how to gain trust
- Both core and non-negotiable are highly contextual and depends on what you don’t have
- You can’t go very fast unless you are disciplined.
Theme Discussion: There’s An Idea I’d Like to Try (SV Agile + BayXP)
Discussion topics:
- “I’d like to try having the team work on just one feature at a time. No iterations, just a single feature from start to finish, rinse & repeat.”
- “I’d like to try having ‘automated monkey testing’, a tool that would explore the application with random input to find problems.”
- “I’d like to try having personas (from Goal Oriented Design) that could plug into automated acceptance test, so you could test different paths to the same behavior.”
- “I’d like to try starting from a photoshop mockup and then code through the application reaching the data layer last. This is backwards from my usual approach.”
Aha Moments:
- Corey: We’re not doing enough user persona modeling.
- Doug: I had never considered persona based testing before.
- Tye: It was new to think of a hierarchy of importance that goes Interaction > Domain > Data Layer.
- Kevin: It is shocking how often we think of the role of QA as being destructive. (About breaking things rather than confirming that behavior works.)
- Mark: Get one thing done before moving on. (But why is it that some of us want it? It feels like nobody else does…)
- Dave: I need exercises for working outside my comfort zone, for removing scar tissue. Without that I’m missing opportunities to improve.
- Mark: Why is waterfall so easy to describe while describing agile so hard? (This will be the theme for next month’s meetup!)
- Jeff: People don’t like to do what they’re bad at, they avoid it. They’d rather do what they’re good at. (A duh and aha at the same time.)
- Kevin: Don’t make me do stuff I’m not good at it.
- Phillippe: Automated monkey testing after a good quick smoke test could be useful.
- Phillippe: Need focus in an iteration rather than a random collection of stories.