Tutorials and Keynotes
Classes, case studies, and panels
The first session I attended started at 8:30 AM and the last activity ended at 8:30 PM. Needless to say I am happy to be back home relaxing at the couch. Here's some notes on what I attended:
a) Gerard Meszaros gave a tutorial on how things that need to be considered when going from concept to product backlog. Most practitioners have tend to pay attention to the activities closer to the implementation such as stories, use cases, and unit tests; and spend less time, if any, on the what needs to be done to translate the customer's concept into the right design. That is no design is as bad as BDUF because we end up with story blinders. Such lack of functionality not only delays projects but are a source for the need to redesign later on; and under-designing is as bad as over-designing. Projects require an iteration zero to do up-front planning. Five levers need to be covered: Product vision; product roadmap; release plan; iteration plan; and daily plan
b) Robert C Martin, a.k.a. uncle Bob, gave a keynote speech in his usual entertaining and engaging way about the state of the art of XP after ten years of existence (actually more since it started in 1995) . He is quite a showman as a presenter. Taking as starting point the xp diagram he pointed out that scrum covers the outer ring only. Scrum has been extremely successful because it talks at a business level in a way that the business people can understand and makes them more likely to buy in the methodology. The innermost layer is the geeky layer and the middle layer is the glue that sticks the other two together. The success of Scrum has been so tremendous that XP has been falling behind in terms of adoption. This is a very dangerous thing because agile loses effectiveness without good practices. The result is that blindly following scrum leads us to think we are moving fast whereas we are not because over time the cycles become harder to keep up with due to the code being harder and harder to maintain.. This doesn't mean agile is bad; it isn't because it exposes the problems and traditional/waterfall doesn't. What it means is that we need to raise the bar as programmers. This brings the central point of his presentation: we need to develop good software, period. Robert also pointed us to the Manifesto for Software Craftsmanship (http://manifesto.softwarecraftsmanship.org/main) which was put together very recently.
Raising the bar.
Manifesto for Software Craftsmanship As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
© 2009
c) Scott Ambler gave a tutorial on Agile Model Driven Development (AMDD) with two focus points:
The negative impact that traditional and waterfall approaches to software development have on productivity, quality, and deliverables. And the importance to drive our agile activities based on practice vs theory. Throughout the entire tutorial Scott went over and over again on the importance to plan and act honestly in the best interest of the success of the product and the organization. Regarding modeling he pointed out that the right model to use is the one that best communicates with the target audience keeping focus on the product's construction with the goal to develop a high quality system. Another important factor for large organizations is scaling distributed teams making sure that the minimum necessary up-front design is made. Note that this doesn't mean BDUF but that a larger amount of design is needed for larger teams than for small and for colocalized teams. Also, for remote teams it is more effective to divide the work based on product features than on job function because that reduces the amount of remote communication needed; although strong coordination will still be needed.
