For meetings in previous years, see all meetings
Practitioner Discussion (SV Agile + BayXP + Cupertino Agile)
- BayAPLN meetings in the South Bay?
- Lost points problem. (Stories started but not completed in an iteration.)
- How do you grow agile with management buy-in but without additional budget?
- Moving from automation functional tests to unit tests
- Velocity is about prediction not score.
- “The slippery slope to Selenium”
- We might miss the boat on adopting agile.
- “Lost points” can be an incentive to finish stories in the iteration.
- Agile propaganda makes it hard to convince others to suspend their disbelief. We have to rely on assertions without the evidence of our direct experience.
- Not just “velocity” that is misnamed it is “points”.
- Maybe I don’t have a problem.
- Iteration boundary is artificial. Maybe it doesn’t matter?
- Action matters more than logic. If you finish a story go help someone else.
- Fast test vs slow test
- Need to be brave enough to go all the way
- Scott Adams is right: We are just moist robots in some ways
- Invite a guest observer as a way to make sure you following through on what you said you’d do.
Practitioner Discussion (SV Agile + BayXP + Cupertino Agile)
- What metrics can you use outside consumption to show things getting better (assume goodwill, no gaming)
- Finally! a post-adoption success story
- Can you really do agile with long feedback times?
- When people say they’re doing agile you need to clarify which agile: Project management agile or developer practice agile?
- Unexpected downsides in tracking “partial velocity”, partially done work
- When transitioning to agile the right metrics can help developers coming from ground zero
- The idea of custom fit agile, of being as agile as you can for the circumstances (ala Crystal)
- Teams will lie? Really? That’s not something I’ve seen
- Bugs escaping an iteration is much more of a lagging indicated than expected
- The struggle to communicate “across the chasm” is even more pervasive than expected
First Joint Meeting: Silicon Valley Agile + BayXP + Cupertino Agile
This meeting will be run as an Open Space. Each person should come with a topic they are interested in discussing. I will collect the topics, we’ll vote on them and set the agenda for the rest of the evening.
Topic proposals can cover any subject related to Agile, but the best topics will relate to some real current problem or recent accomplishment. The scale of the proposed topics can vary. If we have a lot of small topics (“Any recommendations for testing my AJAX app?”) then we’ll cover more items than if we have larger (“How do you do your iteration planning?”) or more controversial topics (“Is Scrum Evil?”).Meeting Notes:
- Scale matters: transitioning a large group requires significantly more planning & work than just doing one team.
- Related: remember The Law of Raspberry Jam (the wider you spread it the thinner it gets)
- It can take a lot of work to make sure a team self-organizes the right way
- The psychology of change is important
TDD+RoR Lab Building a DotVoting System .
September 24th, 2008 by Philippe Hanrigou
We are going to build a dot-voting system on RoR using Test-Driven Development. Please bring your laptop to the meeting.
Please note that people will save themselves time and headaches by bringing a non-windows laptop if they can ;-) RoR works better on Unix platforms (OS X, Linux, BSD, etc)
You should have the following program installed on your computer:
- Ruby on Rails
- a Ruby IDE like IntelliJ IDEA with Ruby Plugin, Eclipse with RDT, or textmate on Mac.
Best practices and tools for web testing .
August 27th, 2008 by Philippe Hanrigou
The purpose of this talk is to share my field experience in establishing web acceptance test suites with high return on investment (ROI) for web application. My ThoughtWorks team successfully transformed a 3 hours web testing suite that despite high maintenance efforts was always red, into a passing sub-20 minutes build that provides quick and accurate feedback while requiring minimal maintenance. This session covers best practices and tools that you can put in place to achieve your own success story.In my experience, attaining high value from traditional acceptance web testing is hard to accomplish mainly because:
- Tests are brittle: In other words they keep failing and require a lot of maintenance over the course of the iterations—even when your application has no new defects!
- Testing is slow: Web acceptance testing involves a full application stack and a flurry of network chats between browsers, web servers, databases and other processes. Not surprisingly this comes with a lot of performance overhead and the environment requires a non-trivial set up. Consequently a web acceptance build typically takes hours to run and accounts for a tremendous delay in development feedback.
- It is difficult to assess the exact impact of current failures in terms of actual application functionality: A single UI change in a “hub-page” (say the login page) can cause most of the test suite to fail while from the user’s perspective, the application is working just fine.
- Some application states are hard, if not impossible, to reach solely from the UI. The traditional approach here has been either to avoid testing these cases or to write tests that rely on large, complex and well-known data sets, which become increasingly harder to maintain and comprehend.
- Keeping the build blazing fast by leveraging cheap hardware and aggressively parallelizing test runs.
- Implementing aggressive test isolation.
- Putting the Web acceptance tests in total control of the application state.
- Keeping the tests razor sharp.
Agile approach in geographically distributed projects .
July 30th, 2008 by Dmytry Mykhaylov
The presenter would share his experience about ~30 projects for ~10 companies which he has accomplished with different level of success but where remote (aka “off-shore”) engineering resources been used. Similarities among projects, executive “patterns” and “anti-patterns” and “how agility may help” represent the core of the presentation.
Pragmatic Unit Testing in C# 2nd edition
March 2008 by Matt Hargett
January 2008 by Slava Imeshev