Howdy Quardeviants! Hope you had a great fall. In November I attended the SQE Better Software and Agile Development Practices Conference East, in Orlando — now if that conference name doesn’t just roll off the tongue, I dunno what does. But it was a tremendously enjoyable experience. I learned a bunch. I met some very cool, knowledgeable people. I had fantastic late night conversations with Gil Zilberfeld from TypeMock; some good mobile security discussions with Nabil Hannan from Cigital; I met Scott Barber briefly, who I’d known of from Jon Bach; and I got some good presenting advice from Antony Marcano from RiverGlide. I really enjoyed his tutorial on Acceptance Test Driven Development with Cucumber. I also really enjoyed Jared Richardson’s talk on Continuous Integration with Jenkins. And of course the whole week was superbly kicked off with LitheSpeed’s Sanjiv Augustine delivering the Certified Scrum Master class. Sanjiv was great. It was really energizing, and I wanted to share some tidbits of information, thoughts, and cultural learnings for make benefit glorious nation of Quardeviants, in no particular order. My own presentation was just so-so, I’m afraid. Some folks seemed to enjoy it, but I was too nervous and not free-flowing enough. I’m new to the speaking game so I fully intend to get better. Got some positive feedback but more importantly tips for improvement. Hope you enjoy your holiday seasons with these nuggets of agile, testing, engineering, process and methodology goodness!
- Pretty much everything I previously didn’t like about Scrum were spot on. But I see now, the problems aren’t unfixable, and they aren’t unpreventable. So I like Scrum more now. Being a newly-Certified Scrum Master, I feel some kind of Jeffersonian responsibility to let people know Scrum is good, but not great. It’s revolutionary but can be abused or turned into a tyranny all the same.
- Continuous integration and continuous deployment do more to minimize risk and promote quality than testing. If you’re not doing CI and CD, stop all other forms of process improvement and start there. First heard Google+ Test Director James Whittaker assert this, at November’s QASIG, and each day now I see the reasons why more and more. This was emphasized over and over at BS/ADP2011. Biggest impact your team can make.
- Sanjiv: Agile is not a solution to resource issues.
- I really liked Scrums’ emphasis on avoiding technical debt. Didn’t know they were as into that.
- Cool Eisenhower quote I’d forgotten: “Plans are useless, but planning is indispensible.”
- Scrum and Agile don’t inherently mitigate risk very well; it still takes a deliberate active effort to mitigate risk. Something that helps: tackle the riskier items first. So simple, but maybe not obvious.
- We all know the value of keeping the scope small, but I didn’t fully recognize the value. So many reasons. This was key to my biggest hangup on fully endorsing Scrum or Agile. The potential detriments these methodologies have on quality scarcely come into play when scope is kept properly small enough.
- Scrum also advocates keeping the team small. Value there’s easy to see, mostly on account of communication. Which is important. But if 9 is the upper bounds of team size, and your approach to communication is “more is more,” then perhaps team sizes of 10+ is not the real problem? Big scalability red flag for me.
- Agile also doesn’t consider architecture design very well. Recognize it’s an execution methodology for engineering, not a substitute for innovation.
- Best to keep a sprint isolated from further change. Feedback, review and re-baseline after a release, but too constant change makes it difficult to get anything done and much of your work ends up being waste.
- Sprint-to-release ratio doesn’t have to be 1:1!
- There were tiny little lizards all around me at the pool. Very cute.
- Jenkins is very cool. If ya didn’t know.
- Lot of people put unit testing off because the value doesn’t materialize in the short term. The value builds exponentially over time. Patience, y’all!
- I heart Cucumber.
- Agile doesn’t scale all that well. “Scrum of scrums” of multiple integrated teams is about the best they can come up with. I’m still trying to come up with a better way. Possible 2012 blog post.
- Surprised that Scrum views meetings as waste. They are. They have value but they steal time and should be minimized. But SCRUM=Standups, Comprehensive Retrospectives, Unlimited Meetings! Surprising.
- Learned that the much-maligned Waterfall model originally a) enforced upstream recursion (that is, after each phase, review what was commissioned from the prior phase, evaluate whether what was performed was on the money) and b) called for two full passes through the waterfall. Two iterations, but only one release. Most of us have released after the first pass.
- I really didn’t like this definition of success: “on time, under budget, meets requirements.” So much room to meet that criteria with flying colors and still fail, you could ride a herd of elephants in the space between. You could fail in the market. Requirements could be off the mark, incomplete, or crap. Aspire to make greater things, Scrum.
- Using a defect tracking tool as your release tracking tool is conducive to poor quality. Focus is on resolving the identified issues.
- I keep coming across this Standish Group Chaos Report that 2/3 of what is engineered is waste, because users don’t use it. It came up at BS/ADP2011, too. The figure is from 2002. I wonder how relevant it is today.
- The Agile Manifesto says, “Individuals and Interactions over Processes and Tools.” Most know how to grok that, but sometime folks use that to throw the baby out with the bathwater. It should not be a rejection of processes and tools.
- Same with “Working software over comprehensive documentation.” But yes, documentation should be lean. I have a handful of methods for keeping documentation lean that I hope to tell you about next year.
- These kind of statements have a kindred spirit in the rhetoric against best practices. There’s value in the substance offered up by the crowd railing against best practices. We’d do well to listen to them. But again, baby with the bathwater. Scrum is itself, a set of best practices, modularized and served like a buffet, where you get to pick the ones you want. So Scrum has no room to criticize best practices. The danger of too dogmatic an opposition to best practice dogma is opposition to knowledge. Our industry likes to share lessons learned, what we’ve figured out works and why, and what doesn’t as well and why. Then you decide what to use. I don’t understand why “best practices” should be a four-letter term, so to speak.
- To quote a hardware engineer from antiquity, “Sabbath was made for man, not man for the Sabbath.”
- Keep coming across this sentiment in Agile: “right features @ right time for the right price” and “make sure we’re building the right thing.” But I think Agile is pretending, here. Talking the talk, but Agile really just manages the “how to,” there’s no intrinsic impetus for “pretotyping,” as Alberto Savoia puts it. Product Owners decide if you’re building the right thing, but really they’re just a proxy, and it’s still guess-work. I have more thoughts on this matter, and even a new methodology (with narrow applicability), that I hope to discuss more next year, but for now let me just say that Alberto’s work captures most of it in a nutshell much better and more effectively, and the “Test Is Dead” talk from GTAC and James Whittaker’s follow-up with “How Google Tests Software” extended the concept very well.
- Last point I’d add to the pretotyping/testing at proof-of-concept level idea that I heartily endorse, is that testers who know the techniques and value of structured exploratory testing are probably best at finding bugs before code is written. I learned more from Jon Bach than anyone else in this industry. He and I once worked on a small project for an eCommerce site that couldn’t afford testing. We performed “business scenario” testing, covering ops, processes and software integration, and found stuff that software testing alone couldn’t have found.
- Good Lean principle: decide at the last responsible moment.
- Fellow Scrum Master Tamera Webb implored to me that testing one sprint behind does not work. Why? Devs have already earned their points, so there’s low incentive to implement the quality. The bugs are thrown onto the backlog, where they can scarcely compete with new features in value. Quality demonstrably suffers in this method.
- I always bristled at the dogmatic shouting from Agilistas that stabilization sprints, bug-fix sprints, were “doing Agile wrong.” Felt it capped quality, even more arbitrarily than quality intrinsically is. I see now, this is another reason small scope is so important. Small enough scope makes room for exhaustive quality. Now, in any model, the detriment of punting quality has always been apparent. The value-driven definition of “done” that Agile teams tend to agree on makes punting quality more harmful. I can see now, why the hard stance on punting quality.
- That said, teams on legacy products that transition to Agile will definitely face the reality that existing defects cannot all always be fit into scope, and will have to punt some things to another iteration.
- Velocity: thankfully this is becoming more and more maligned. Lot of people still use and endorse it. Ron Jeffries recently said, he helped sell the idea of velocity, and now regrets it. He told me it’s usually more harmful than helpful. It can be used to calibrate a team transitioning to Agile, but the metric shouldn’t leave the team.
- Sanjiv still endorsed velocity, but qualified that: “Know when to stop. Returns diminish over time, and you want to avoid false accuracies of over-analysis.”
- Scrum is a bit too reactive. Chases acceptance through iteration, review and feedback. “Don’t Know What You Want Til You See It” is an old adage and I think a single from hair metal band Cinderella. If you want innovation, don’t rely on Agile to catalyze it. Use Agile to manage the execution.
- Similarly, stories with acceptance criteria can be prone to focusing too much on meeting AC, akin to functional requirements. Expected failures are often included in AC but it’s easy to call unexpected failures out of scope. That’s punting quality.
- Agile’s focus on value is maybe a little myopic.
- Counting test cases? Please stop. There’s honestly no value in it, it tells you nothing but misleads you greatly. It’s worse than velocity.
- Love, love, LOVE the concept of Theory X and Theory Y management. Now that I’ve learned about it, I see many cases in which both theories actually MAKE the direct reports what they are perceived to be.
- Don’t like the 3 daily standup questions: what did I work on, what will I work on, is anything blocking? Knowing when to escalate a blocking issue is requisite for knowledge workers. Lean mgmt 3Qs alternative: what, so what and now what? Report what’s important, and extrapolate why.
- Joanna Yeh from Electronic Arts pointed out the same thing in so many words: Scrum Masters manage dependencies and blocking issues but the team is responsible for discovering and surfacing them.
- Loved this from Sanjiv’s training: Encourage forthrightness, blameless observations and failing and observing fast. Discourage defensiveness, CYA and fear of failure.
- Heroics breeds co-dependent relationships with customers. Saw it in myself before seeing it in others.
- If the user doesn’t care about security, and the PO is a proxy for what the customer cares about, where is the impetus for security? Another Agile problem. Mitigable, but first you need to recognize it.
- Technical conferences sometimes feel like a compendium of knowledge I already mostly acquired from blogs, Twitter, and wiki-surfing, but there’s always some stuff that your experience and exploration misses, and sometimes the compendium helps bring clarity and reinforcement to what you kinda conceptually knew previously. So I’m saying, they’re worth the money.
