"It turns out that we don’t know the procedure. We haven’t got any clue to just how difficult the procedure is. We aren’t computers. We don’t follow procedures. And so comparing the complexity of the manual task, to the complexity of the procedure is invalid.

This is one of the reasons that estimates are so hard, and why we get them wrong so often. We look at a task that seems easy and estimate it on that basis, only to find that writing down the procedure is actually quite intricate. We blow the estimate because we estimate the wrong thing."

"If you adopt economical driving habits, you’ll end up putting less gasoline in your tank.  But if you skip past the economical driving habits and just put less gas in your tank, you’ll end up muttering grim imprecations as you trudge down the highway with a gas can."

"Are you wasting development time polishing things that you don’t yet understand? "

"Iterative development plans to rework items. Not because they are of low quality, not because they are defective, not because they are unacceptable, but because we chose to limit the scope of them earlier so that we can get to learn something about them sooner. This is a product development technique. Kanban is mainly a manufacturing technique. Software development resembles manufacturing to a degree of approximately 0.0 so it’s a bit of a puzzle why this manufacturing technique has become quite so popular with software developers. Added to which the software industry has a catastrophically bad track record at adopting management ideas from manufacturing in an appropriate way. We in IT are perennial confused about manufacturing, product development and engineering, three related but very different kinds of activity."

"The story of Goat Island has parallels for us engineers.  Because we cannot predict results, we know that patience, hope and courage are functions of the design process.  Every so often, we have to remind ourselves of that.  We also know that patience is a function of a good retrospective.  Just as it took a certain amount of time for the snappers to grow large enough to take on the urchins, I think there is a certain – and measurable – amount of time for participants in a retrospective to open up and start moving beyond the superficial.  That amount of time is more than two hours."

"I find that the big things on the top of the story map look a little like vertebrae. And the cards hanging down look a little like ribs. Those big things on the top are often the essential capabilities the system needs to have. I refer to them as the "backbone" of the software. I stole this term from Dr. Dan Rawsthorne who might use the term slightly differently than I do.



When it comes time to prioritize stories, I don't prioritize the backbone. It just "is." I do prioritize the ribs - the stories hanging down from the backbone. Place them high to indicate they're absolutely necessary, lower to indicate they're less necessary. When you do this, you'll find that all the stories placed high on the story map describe the smallest possible system you could build that would give you end to end functionality. This is what Alistair Cockburn refers to as the "walking skeleton". I always try to build this first."

"Agile Coach Camp is about creating a network of practitioners who are striving to push the limits in guiding software development teams, while staying true to the values and principles at the core of the Agile movement. We've invited practitioners who, like you, are passionate about their work, active in the field and willing to share what they've learned.

Do you have a technique or practice worth sharing with your peers? Or an idea you'd like to test out with some leaders in the community? Are you facing challenges and want to get some perspective from other practitioners, or hear how they do things? If you feel you’d benefit from connecting with 70-75 Open Agile Process Facilitators, ScrumMasters, XP Coaches, Trainers, Change Agents, and Mentors to talk, draw, debate, and explore ideas, then this unconference is for you."

"A story isn't done until it is being used by real users in production and has been validated to be a useful part of a product."

"Riff is a a recent spin-off project from Jesse Sielaff’s work to bring a Ruby-like language interpreter to the browser. Riff is a plugin for Racc (a LARL(1) parser generator for Ruby). Riff extends the output generation portions of Racc and writes javascript instead of Ruby. If you’re familiar with LALR grammars this should add a handy tool to your javascript arsenal."

"Noticing the pain as soon as possible and then fixing the problem - whether it is a rigid design, fragile tests or something else - requires skill. Not everybody is alert to the pain, but instead they keep on writing bad code until making changes becomes too expensive and a rewrite is needed. Not everybody fixes the problem when they feel the pain, but instead they implement a quick hack and leave an even bigger mess for the next developer. But for those who have the necessary skills and discipline, TDD can be a powerful tool and they can use it to write better code."

"new Scrum::BaseScrum() //raise NotImplementedException"

"Simply put, you will not improve unless you strive to get better. You will not improve unless you:
look back on what you accomplished
reflect on what prevented you from doing even better
try to apply lessons learned the next time around
It almost seems so obvious that it's not worth the 15 minutes that it takes your team. But, as anyone that has ever practiced regular retrospectives knows, they are an invaluable tool for identifying group problems that might have otherwise gone unnoticed."