Yesterday, after Lean Coffee, I had a conversation about agile software methodologies with Joe Justice, somebody I greatly respect. I expressed my feeling that the term “agile” has become a loaded one, with many conflicting meanings, and use of it can incite unintended reactions from the community. At the time I didn’t realize that I shouldn’t have said “the community” , as I now believe that it was too narrow in scope and might’ve derailed our conversation a bit. By “community” I meant the software industry as a whole (See: Agile ruined my life and halfarsedagilemanifesto).

We discussed how certain methodologies emphasize the technical team as the boundary for the new way of thinking…emphasizing divisive principles, like protecting the engineers from “the business” so that they can do their best work without interruption. These methodologies overlooks that “the business” consists of people who are also trying to do their best work toward the same goal. I strongly believe that organizational alignment is vital to work satisfaction, and being happy is vital to doing our best work.

I am certain I made some tired arguments about local optimizations that de-optimize the whole, when Joe put us back on track by explaining what “agile” means to him. His guiding agile principle (see:Principles behind the agile manifesto) is the 7th: “Working software is the primary measure of progress.”

I got to thinking about this and it started to dawn on me that this is a very easily misinterpreted principle. The definition of “Working software” can be very broad indeed. If software compiles without build errors does that mean it “works” or if it runs successfully through the happy path?

Let’s say for the sake of argument that the software is bug free; meaning it works exactly as specified and no defects exist. What if the customer doesn’t want it? Or there is no market for this mythical flawless feature? What if that feature was very expensive to produce? We’ve made working software, but was it an effective primary measure of progress? What if the engineering team worked so tirelessly on producing this software that they all hate their jobs? Eric Ries calls the aforementioned “Achieving Failure”: Delivering on time, and on budget a low defect, high-quality product that nobody wants.

I think working software as a goal is a good one, but when we silo the engineering team and “protect” them from “the business” we create an adversarial environment between groups that have the same goal. To enrich the lives of their users by producing an experience so great as to compel the customer to clamor for it and tell their friends.

Maybe a better wording for that principle could be “Delivering amazing experiences to customers at a sustainable pace is the primary measure of success.”

I could go on about the many ways one could misinterpret those words too, but I’ll leave that to the commenters.

2 weeks ago at Seattle Lean Coffee Michael Wolf shared a story about seeing two colleagues at a conference who had not seen each-other for years reunited without much fanfare. One of them looked at the other and matter-of-factly said “Hey, long time no see, what are you reading?”

Michael felt like this was a powerful question. What we’re reading at a given time could be a great window into our interests and where we are in life. Full disclosure: I’ve never been a big reader. I would still not classify myself as a big reader. I read books because they contain deeper technical and/or theoretical detail into subjects about which I am passionate. I would say presently I only read in a professional context. I read books that I hope will give me new insights into how to do my job as a tester and agile process advocate better.

I would love to hear what my peers and readers of this blog are reading. Maybe we can expose one-another to some new ideas.

Books I’ve finished recently:

Linchpin (Seth Godin): This book talks a lot about the state of our economy and the value of creative emotional workers and their work. Seth makes really insightful points about how following maps at work and being unthinking cogs in a machine will lead to your job being outsourced to a more inexpensive cog somewhere else. Conversely, if you are passionate about your work and you put emotional creative energy into it, you will be irreplaceable. You can easily replace a guy who stamps a piece of metal in a factory with a computerized robot. You can’t replace an artist with a computerized robot. This to me is analogous to the discussion around testing vs. checking. Testing is a challenging sapient intellectual art which you cannot teach a computer to do anymore than you could teach a computer to create an original painting that expresses emotion.

Personal Kanban (Jim Benson & Tonianne DeMaria Barry): This book changed the way I think about every task I tackle in a given day. I found this book very easy to read, entertaining and non-dogmatic. After I read this book I started organizing my backlog in post-its. When I travel places I take a notebook and some post-its so I can manage my flow on the road. Jim and Tonianne have written the definitive guide to turning the stress of a given pile of tasks and transforming it into an innocuous backlog of sticky-notes. Where I once finished a task and forgot about it, I now have a nice satisfying pile of stickies under the “Done” column to celebrate. While I once wondered how I’d ever be able to tackle my busy workload, I now have a nice limited work in progress column. How I have used the concepts learned in this book to change the way I handle my work and home tasks is a blog post in itself. For now I’ll just suggest you read this book. My copy has been abandoned in San Francisco in hopes it’ll help infect my engineering team with these principles an concepts.

Reads in progress:

Specification by Example (Gojko Adzic):This book eats its own dog food. You could have accurately titled this book “Specification by Example by Example” because it’s full of real-world examples of various business and technical challenges surrounding the practice of building living executable documentation in a domain specific language using a collaborative whole team approach to software development. Gojko covers high-level business examples as well as technical details around various approaches and tools useful to solving real-world challenges. I haven’t finished this book yet, (about 80% finished) but so far it’s been really great.

Anything You Want (Derek Sievers): “Anything You Want” is a short book chronicling Derek Sivers’ experience building CD Baby. I was attracted to his book by his videos on Vimeo which I Came across on Twitter. It’s a short book that I accidentally almost finished by virtue of having great difficulty putting it down after I bought the kindle version. Derek was not an aspiring tech startup. He wasn’t at meetups trying to elevator pitch angel investors. He was a musician frustrated with the poor options available for distributing his CD. He taught himself to code so he could make a shopping cart and accept credit cards on his website long before paypal existed or even eCommerce became catchy. Soon his friends started asking if he wouldn’t mind selling their CD too. Slowly his little project expanded to the point where he needed to hire an employee. Eventually CDBaby took off and was wildly successful. Throughout this experience Derek didn’t lose touch with his customers. He never strayed from his mission to help independent musicians get paid for their music even when big labels came around offering bags of money to give their artists special treatment. It’s a quick read but a great one.

I miss the mob from Derek Sivers on Vimeo.

Hell Yeah or No from Derek Sivers on Vimeo.

Start Now. No funding needed. from Derek Sivers on Vimeo.

Lessons Learned in Software Testing (Kaner, Bach, Pettichord): This book is the exploratory tester’s bible, why haven’t I finished it yet? Because every time I open it and start reading I put it down and go test. I mean it’s like I’m building a marble sculpture and reading a book about sculpting techniques. I read a chapter and run downstairs to my workstation and dive into testing. I would ordinarily say that a book that is hard not to put down is not a book worth reading. But there is too much good stuff in this book for me to sit down and keep reading. I have often considered doing a “Bold Boast Book Club” on this book in order to motivate me to finish it, but I am having too much fun using this book to improve my craft. If you’re a tester, or a programmer, or a product manager, this book will help you to think about software in a different way.

Okay So tell me what are you reading? What do you think about what I’m reading?

I was highly impressed with the efficient democratic process of using a kanban to run a meetup.

Seattle Lean Coffee is held every Wednesday at Kakao Coffee at 415 Westlake.

Usually somebody (often Jim Benson, or Jeremy Lightsmith) shows up with some post-it pads and sharpies. A kanban is created on the table with a ready, doing and done sticky note marking the swim lanes. The attendees each write down what they’d like to discuss on a post-it sticky note and stick it in under the “ready” column. Once the backlog is populated each attendee takes a moment to describe their topic in a sentence or two. Once we’ve heard all the topics there is a vote. Each attendee marks the topic that interests them most. We’re limited to 2 votes each and less than 5 minutes after we all started we have a prioritized backlog. We pull the topic with the most votes to the doing column and get started talking. Once we move a topic into the “doing” column somebody keeps time on the discussion. The time-box is usually set to 8 minutes. After 8 minutes we have a silent roman vote. The roman vote consists of holding up thumbs. Thumb up means “I’d like to continue this topic” Thumb sideways means “I am ambivalent” and Thumb down means “I’m ready to move on to the next topic.” If the majority shows passion (thumbs up) or ambivalence (sideways) we set a timebox for half the original time (4 minutes in this case). When I facilitate I’ll adjust the time-box according to passion. If we barely made a “yes” vote I’ll set a shorter box (e.g. 2 minutes) and we’ll continue. Once the majority votes to move on, we pull the current sticky to the “done” column and then start a new time-box on the next topic.

Once the clock strikes 10, we re-iterate that there is no commitment to end on time and either continue the discussions or end Lean Coffee for the day. Once we’ve decided Lean Coffee is over we hold up our hands to give feedback. We call it R.O.T.I. (return on time invested) vote. We all hold out our hands showing anywhere from 1 to 5 fingers. 5 fingers signifies that we could not imagine having spent the last 90 minutes in any better way. 3 fingers is still good, it just equates to a “B” and 1 finger means what 1 finger usually means. Anybody giving an R.O.T.I of 2 or 1 is asked to share what we could have done as a group to make this experience better so we can do so next time.

We get people from all walks of business in attendance. Software Engineers, Project Managers, Manufacturing, Healthcare, and High Tech have all been represented in the few short weeks I’ve attended lean coffee.

The quality of the conversation is always shockingly high. I always learn something and have so much fun being exposed to so many contexts that I would normally never experience. I suppose I’m a process nerd since I get tremendous enjoyment out of trying to apply my experiences in software to health care, and government contexts as well as learning new things from them to apply to my work.

The format is simple and powerful, there is no reason you can’t have lean coffee if you’re not able to come to Seattle. Tweet some tweets or blog to get interest, invite your co-workers to coffee or other like-minded peers and bring a stack of post-its and some pens. It’s that easy! Seriously we can all learn a lot from each other just by getting together and having a conversation.

Next week is the Conference for the Association of Software Testing in Lynnwood WA (just outside Seattle) and I am honored to have been invited to present with Lanette Creamer.

We’re not planning on spending an hour in front of the audience talking while we point at slides full of bullet points. We’ll be discussing “When should a tester test less?” She’ll be presenting her experience in being asked not to test and I’ll share my experience not testing in the context of a major product refactor effort. We’re confident our short experience reports will fuel a passionate discussion from the audience.

I think of every presentation as a learning opportunity for audience and presenter alike. We are certain that there are many contexts in which not testing (even when asked to do so) could be irresponsible or dangerous and are excited to discuss with the many skilled and opinionated practitioners that will be in attendance at CAST 2011. The conference schedule is full of brilliant minds in the testing community and represents great professional development value for all of it’s attendees. I could not be more excited to meet many of my testing colleagues from around the world.

It’s not too late to register to attend CAST.

I’m also thrilled to have been invited to speak at STPcon this fall in Dallas. I’ll be doing an interactive jam session on Acceptance Test Driven Development there. I’ll write up a separate preview post on the details surrounding that talk as the date approaches.

I wanted to write a quick post to add more value to my previous entry about SF Agile Conference 2011.

I wrote about what a revelation Eric Ries’ Leanstartup Keynote was and shortly after the conference I noticed that Steve Denning’s blog on Forbes.com has been magically extracting my thoughts and writing them more eloquently than I ever could. I’m not kidding though it’s eerie, the weekend following the conference while I was trying to wrap my brain around the concepts Eric presented about validated learning and innovation accounting, Steve posted a 4 part blog series on the subject.

I pre-ordered Eric’s book and participated in his experiment. It’s fun to feel like a part of something. You can pre-order as well here

Steve Denning Lean Startups Part 1: Something New In Innovation: Lean Startups

Steve Denning Lean Startups Part 2: A Scientific Method For Creating Innovation

Steve Denning Lean Startups Part 3: Most Changes Make The Product Worse

Steve Denning Lean Startups Part 4: Using Kanban To Validate Innovation

Shortly after returning to Seattle I started scouring google for Eric’s talk. I found one he gave just 2 months prior to SF Agile con at Google.

UPDATE:Talk he gave the other night at PARC is now available. I think it’s more current and actually an improvement in some ways over the talk he gave at agilecon, both were excellent.

I proceeded to search for more videos of the speakers. I was not successful finding most of them, but I did find a condensed version of Zach Larson and Tim McCoy’s Lean UX talk. With the bonus of stumbling onto a former colleague of mine from WebTrends Jeff Gothelf at the same talk.

Design + Lean Startup = Lean UX (Video)

I would have loved to find more videos of the speakers at SF Agile Conference 2011.

If anybody stumbles upon more talks by Josh Kerievsky, Ted Young or Eric Ries I’d love to hear about it and will update this blog post accordingly.

Many thanks to Steve Denning for blogging my thoughts. I should add that Steve’s blog has not just been posting my thoughts on lean startup, but on management in general. Multiple times a week he writes something pertinent to something I am struggling with or about which I have strong feelings. You could do worse than to follow him on Twitter @Stevedenning.

Thanks entirely to the generosity of Lisa Crispin and Angeline Tan I was able to attend the inaugural San Francisco Agile Conference. In fact Angeline upon hearing that Volunteermatch was working to transition from a hierarchical waterfall process to a more agile Scrum process generously offered tickets to our entire organization.

I had been excited to see Jurgen Appelo speak about Agile Management and was bummed when I read in his blog post that he would not be coming.

When I sat down at 9AM and Eric Ries started talking about his leanstartup movement, he apologized for talking about accounting so early in the morning. What does leanstartup have to do with agile principles? I’d never heard the term before. Eric is a charismatic speaker who really engaged the entire room. He gave an exciting talk about the importance of making entrepreneurship more boring.

Usually I’d think that “Innovation Accounting” at 9AM would put a room full of people to sleep but we were riveted. The concept that we should stop wasting people’s time seemed like common sense. Eric talks about how much time we waste as an industry building products before we even know if there is a customer for them. The application of this methodology to existing orgs struck me. We have a user base, how do we know that we’re engaging them in our user research and identifying what matters to them. How do we know we’re innovating if we don’t show those customers disruptive designs rather than showing them small improvements to products to which they’re already accustomed? It took the rest of the conference for Eric’s keynote really sink in.

In fact it would not have been wrong to rename “SF Agile Con 2011″ “SF Leanstartup con 2011″ because so little of this conference was about Scrum or the practices of agile. Actually my outlook on Scrum changed dramatically due to this conference.

It was amazing to see people like Zach Larsen and Tim McCoy talk about Lean User Experience design, and shifting the product team’s focus off of deliverables and onto product stewardship.

Ted Young gave a revelatory talk about post-scrum agile practices. In Ted’s talk he explained how his team escaped Scrum’s rote processes in the interest of actually being agile rather than just doing agile. His team began to identify processes that were beginning to suck for them. In fact they coined a new term within their group. “Retrospectives were starting to feel ‘grindy’ and no longer felt productive or fun.”

This opened my mind in an unexpected way. How is practicing Scrum processes or blindly following Scrum tools agile? You’re doing things that are not adding value to your team because a specific and rather dogmatic school says you should do them. The Scrum Alliance dictates how you do your job rather than the context of your business. To me, that doesn’t seem agile, it seems rigid and guided. It seems like your scrum team is following a map.

So how does Ted’s team celebrate releases or discuss issues if they don’t have scheduled retrospectives? They visualize their retrospective need by having a wall dedicated to it. If somebody on the team feels like there is an issue they’d like to discuss in retrospective, that team member puts an index card or sticky note on the retro wall. Once they reach an agreed upon critical mass (I think he said it was 3 cards) on that wall, they have a retrospective to discuss those issues.

To the dogmatic “Certified Scrum Master” this may seem irresponsible, to me it seems brilliant. No more “rosy retrospectives” where everybody says things went great for fear of rocking the boat, no more retrospectives just for the sake of following a map. You could argue that Ted’s team was trumping Scrum process with lean principles. Of course to the uninitiated or somebody transitioning from waterfall to scrum, Ted’s methods may seem like an excellent excuse to abandon scrum altogether.

One risk of exposing teams that don’t adhere to agile/lean principles to Ted’s revelation is they might say “Since we have no safe environment in our retrospectives due to a blame-driven hierarchical command-and-control culture, why should we have retrospectives at all? What’t the point of daily stand-up for that matter? Why not stick to what has always worked for us?”

For teams that are succeeding with agile principles, but for whom the toolkit offered by Scrum becomes rote and meaningless, Ted’s team has derived a brilliantly context-driven solution.

Dave Sharrock gave an excellent talk about building agile teams. He shared with us The Ringelmann Effect supporting the theories behind keeping scrum teams small and self-organizing. He specifically presented the social loafing drawbacks of large teams. He also talked about how harmful traditional management can be to the creativity and success of agile teams. He reminded us all that self-organizing teams are not self-directed. We all need to be constrained to the goals of the business, but we need to be free to use our creativity to solve those challenges. When management doesn’t trust us as professionals to apply our expertise there is a visible impact on the quality of the output.

At the end of the conference Joshua Kerievsky from Industrial Logic gave an awesome closing keynote. He shared how sometimes necessity drove innovation at Industrial Logic. He shared accounts of how they used leanstartup and validated learning to grow their business. They used “feature fakes” to gauge customer interest in product changes. He closed the keynote by making a strong statement.

“A lot of us are riding the agile wave right now, but we should turn around and see the monster wave that is Leanstartup. It is a massive wave with the potential to dwarf the agile movement in the near future.” -Joshua Kerievsky

I started to feel like Scrum as a rote process is far less important than delighting our customers. In fact I believe one message I could summarize from Eric’s keynote it’s that if you’re not delighting your customer, it doesn’t matter how clean and disciplined your internal engineering processes are, because you’re on the decline.

There were literally scores of stories that caused what I’d call an “Ah ha!” moment for me. When I walked out of the room at the end of the conference I felt like I needed a couple days off to digest what I’d just learned. There was far more value in this conference than I could communicate in one blog post. In fact I anticipate blogging a lot more in the future about these subjects.

I got a TON of value from this conference. I made smart new friends like, Dave Sharrock, Dave Rooney, Ted Young and Josh Kerievsky.

As an amusing footnote to this conference, on the way out as we piled into the elevator the door-alarm went off and Josh Kerievsky had to pull his arm out of the elevator as the door was about to close on him. He just barely missed our elevator. When the door closed our elevator jarred 6 inches before coming to a complete stop. Lanette Creamer, Dave Rooney, Ted Young, two unsuspecting SFSU students and myself got to spend 90 minutes on that hot elevator. Maybe it was the conference buzz or the fun company but when we were rescued by the OTIS guy after 90 minutes the security guard (who had been listening to us on the intercom) said “They should study you guys, I’ve never heard people laugh while stuck on the elevator, and you guys laughed the whole time!”

When we arrived late to the networking event I informed Josh he just barely missed out on 90 minutes trapped on a hot elevator with us and he graciously bought us all a round. What a hilariously fun way to end a paradigm shifting conference.

Thanks so much to Agilemeister for having me there, and to the presenters and attendees for challenging my preconceptions and contributing to my personal and professional growth.

I can’t wait to see you all at San Francisco Agile Conference 2012! I just hope we can get tickets before they sell out.

(Note: I found a lot of info including some videos of similar talks shortly after attending, my next blog post will include links to them for further enjoyment)

Last week I visited Jon Bach at his new place of business in San Jose, California at eBay.

Jon single-handedly turned what had been planned as an informal gathering of testers into an awesome mini-conference. I intend to blog about that mini-conference in a future post but before the conference Jon and I got together to catch up and for me to make good on a promise I made last fall to learn and present him with my newly acquired Cucumber skills.

Earlier in the week after spending much time learning cucumber, I presented ATDD and Cucumber to the Product management and Engineering teams at Volunteermatch.

The presentation went alright, at least the cucumber stuff worked as designed.

Emboldened by my recent success with cucumber, I knocked together a very simple cucumber script for eBay.

After quickly making sure it ran successfully, I felt prepared to demo it to Jon at eBay the following day. I showed him how the system worked and explained briefly how it fits into a larger behavior driven development process.

The presence of Doug Hoffman (President of AST) was an unexpected surprise. Jon was kind enough to wait until I was done to point out the fact that I was presenting to a test automation expert a mere 2 days after my first ever automation success.

I ran the cucumber script for Jon and Doug…

Jon quickly pointed out that my check would pass even if no results were found. I very quickly realized the fatal flaw in checking the results page for the word “concertina”.

The obvious false pass scenario being, if the page reads “0 Results Found for concertina” the assert would see the word “concertina” and report a passing “green” result.

I manually identified a search query that would return 0 results and replaced the concertina query in my cucumber scripts and ran it again. Sure enough it passed.

So while Jon worked on getting ready for the mini-con I frantically worked to fix my error. Minutes later I gleefully proclaimed my victory.

Jon asked “What did you do to fix it?” and I showed him the new step.

“That’s some seriously brittle code!” said Jon.

To which I defiantly replied “Look it works!” running it a 2nd time, only to have my hubris laid bare by a big red error proclaiming that my latest assertion failed.

As I recalled what I had seen during the brief appearance of the browser I remembered seeing something truly unexpected.

The first run showed “497 results found for Concertina”

The second run showed exactly “500 results found for Concertina”

I immediately realized that the script interpreted this result as 50 “0 results found for concertina” and correctly, failed my assertion.

Given that there was a 10% chance of this test failing, the fact that it did so on the 2nd run while I brazenly defended my “adequate” code was truly amazing. Jon, Doug, and I were all in awe and we had a great laugh.

(Note: I have yet to successfully reproduce this in a screencast for this blog post and I’ve tried at least 20 times)

At that point Erin Hasenkamp (A principle SDET on Jon’s team at eBay) had joined us and suggested I use a different message in my script.

I did so and we were able to confirm the solution was valid. Erin pointed out that in their culture those kind of front-end checks are very risky since messaging is highly variable. Basically, something that reads “0 results were found for that search” might read “We found no results for that search” a week later.

Apart from that risk this proved to be somewhat prescient to the evening’s events since Doug gave a great lightening talk about the dangers of “false positive” passing automated tests.

I then demonstrated how we can refactor some of these checks to fold checks under single feature steps and Doug warned me against what he referred to “doing me favors” mainly meaning that if there is nothing telling us that code is being run we may be hiding functions from ourselves.

Ultimately this was the perfect event to bring me into my new realm of automating acceptance checks. Before our mini-conference even started I learned a valuable lesson about being overly reliant on automated checks and pitfalls around building those checks.

I will be adopting a new process ensuring that all of my acceptance checks are peer reviewed by at least one other colleague. Since I still don’t have programming skills this will be easy since I’ll need to lean heavily on my dev team for help building these checks.

I am working on a post showing how I was able to learn to make this work without actually developing extensive programming skills. As I continue to experiment with this tool I will blog my progress, success and failure alike. My hope is to produce a blog series on ATDD/Cucumber the likes of which I sought while struggling to learn this tool.

My thanks to Jon Bach, Doug Hoffman and Erin Hasenkamp for this experience and their expertise.

In a nutshell ATDD (Acceptance Test Driven Development) involves bringing every team member that will touch a user story together at the beginning of a sprint to discuss the story to outline acceptance criteria and attain a shared understanding of the stakeholder’s vision.

There is a lot more to ATDD to discuss however for the sake of brevity I’d like to focus on the aspect that excited me the most, story workshops.

In a story workshop every team member who will touch the user story is gathered to discuss details of the story. One person facilitates the discussion, and after the story is described, testers and programmers ask questions and share concerns with the stakeholder. The end goal is to have shared understanding through examples of the stakeholder’s expectations. Programmers might ask if an implementation strategy is acceptable, testers almost certainly will discover areas of risk in the story’s description.

For the purposes of this class Elisabeth ran us through a few mock story workshops during which Dan Snell volunteered to play the part of the stakeholder. This was a brilliant way to teach by doing. We uncovered many interesting aspects of the story workshop that were best illustrated by allowing the group to collaborate on this mock story.

Some of the things we uncovered may seem rudimentary and obvious. When defining acceptance criteria it’s important not to take these important details for granted. Other things were less predictable. As testers in the room began to come up with test cases Elisabeth wrote them down on her flip chart. Some test cases were too deep to merit being included in basic acceptance. But mostly the test cases were simple. It may seem like a small thing to stand up and say “If the user inputs a date which occurs in the past, and it still posts a listing, this story fails acceptance.” until this seemingly obvious assumption is immediately shot down by the stakeholder in the room. She might say “I never thought to write that case into the story, but now that you mention it, I want it to post outdated listings.”

Maybe adding this feature is so involved that the engineer in the room pipes up and says “If you want me to code something that will allow an expired listing to be created it will conflict with existing code and require a significant refactor.” Maybe the stakeholder demands this feature. She can most certainly have it, but the effort to create and test it will drive it well out of scope for the story. In this case a new story is born and we move on to wrapping up the story in question.

One of the testers in the front row actually exclaimed in mock-frustration “I don’t care it’s your product!”

This simple story resulted in a lot of discussion. Elisabeth was flipping that flip chart and taping paper to the wall as quickly as we were defining criteria. In the end we felt like we had achieved a shared understanding of what the stakeholder wanted to get from the story. Every boundary we could think of at the time was addressed and accepted or rejected by the stakeholder. This didn’t mean the story was chiseled in stone, but I believe by having the story workshop we significantly reduced the odds that changes would be needed. Or if changes were needed it would not be due to a lack of communication. I would imagine that this understanding would reduce the amount of discussion necessary later when changes are needed.

During sprints I see a need for this kind of shared understanding. I find issues when testing that are not bugs but might be areas that might confuse a user.
I always take these concerns to the stakeholder and sometimes they tell me they are perfectly happy with the story the way it is. But sometimes they decide to accept my suggestion and make a change. When that happens the dev has to double his effort. He now has to remove what he did and replace it with the change. I think this is where a team pays the cost of not having story workshops.

Alternatively a programmer while trying to implement something defined in a wire frame or a user story might discover something unforeseen that requires diverting from the defined criteria. I see this sometimes in story notes (e.g. “This story is ready to be tested, as per my discussion with (the programmer) these changes to the user story were made.”

Of course it’s hard to quantify that cost. Story workshops are definitely expensive. A complex story workshop can take hours to wrap up. Lean/agile methodologies abhor rigorous documentation and heavy process. This can make story workshops a tough sell. How does one explain that we’re not proposing to create a tome of specifications for each story. We’re not trying to revert to a waterfall process. We’re not slowing the process down with this story workshop, ultimately we’re trying to speed it up. Much like test driven development it seems like a lot of overhead at the start of the project but I suspect, like TDD, the end result can be increased throughput and improved quality.

There is a lot more to ATDD than the story workshop I’ve described here and as I learn more about those aspects I’ll share them in this blog. In 10 days or so I’ll be taking what I’ve learned and holding my first mock story workshop with my product and development teams. Hopefully, despite having taken her class way back in October, I do Elisabeth justice. I am eager to hear other people’s experiences with this process and thoughts about this post. Please comment and discuss, as I still only have an academic understanding of ATDD. I am very eager to hear others’ real world experiences.

Okay so long time no blog.

I’ve been pretty slammed with having a baby and family coming to visit so I’ve been slow to get back on the horse.

Also once you stop blogging it’s hard to start back up. Excuses aside I have many topics for which I am working on blog posts for so please bear with me.

A few months back Jon Bach graciously offered me an opportunity to speak at the March meeting of QASIG .

He felt I had something worthwhile to say about my current project at Volunteermatch with regard to defect reporting as being potentially harmful to a project.

I wanted to write up a quick experience report about that in order to share my point of view as a speaker.

The weeks leading up to the talk evaporated like an ounce of spilled alcohol in the Kalahari desert. I could detail the unbelievable series of events that led me to write a simple bullet list that would become the first slide deck I ever presented professionally the night before and morning of the talk, but I’ll leave it at that.

The folks at Quardev were all very accommodating and Jon Bach was extremely helpful to what little preparation I was able to muster amid the chaos. I arrived with a plan to discuss my project at Volunteermatch and the unique scenario in which filing defects can be detrimental to the improvement of a product.

I envisioned that there would be a lot of, possibly heated, discussion and at worst we’d all learn something. Hopefully a room full of folks would not have learned that I have no idea what I’m talking about.

The talk could have gone worse. I hadn’t anticipated lacking a clock and losing complete track of time. I had planned on using my phone to remotely control my laptop for the slides and therefore an excuse to watch the clock on my phone, but there was a system in place when I arrived which foiled that plan for me. Quardev was well equipped and prepared, I should have assumed as much.

I ended with a discussion that, if I had it to do over again, would have been nearer the beginning of my talk. I’d have introduced myself, and Volunteermatch, given a 10 minute description of why I was asked not to seek out defects and then have a discussion with the audience about these kinds of real-world dilemmas in testing. As it turned out, I spoke about Volunteermatch, discussed at, length the specific challenges of being a sole tester in a newly agile methodology while being a remote employee before starting the discussion about the morality of defect tracking before we ended kind of unceremoniously with me asking if we had a text message question from Jon , realizing time had run out long ago, and being asked if we were done, by a polite and engaging audience. The end was so ill-managed by myself that I honestly wondered what that noise was when people applauded.

Shortly after my talk I was approached by the facilitator and told “James would like you to call him.” I had no idea James Bach would be tuning in, and fully expected a heap of much deserved criticism. Much to my amazement he was highly complimentary and spot on with specific and constructive suggestions. After I got off the phone with him I was energized and eager to turn around and go back inside and start over.

I have so far kind of hoped this talk would shuffle on down my google search results but I realize everybody has to start somewhere. I think rather than hope this talk shuffles into the ether, I should post a link to it on this blog and own my performance. I will use this blog to expose my ignorance at every possible juncture in the hopes that I learn as much as possible from my mistakes.

I really enjoyed meeting and discussing testing with the people who came to my talk. They were all very pleasant and engaged and for that, as well as Quardev’s invitation I am exceedingly grateful. I am especially grateful to Lanette Creamer for taking time to come see me and participate in the discussion. I came away excited about my other upcoming speaking engagement at CAST and with a strong desire to return to Quardev and speak on another topic in hopes of showing folks what I’ve learned.

March QASIG Video Link

I should likely have posted this on Wednesday but this week has been hectic as I predicted in my previous post.

I panicked a little over the weekend that I was in danger of failing to complete my first ever “Bold Boast Book Club” by the deadline. So I made time to fit in more sessions, mostly by trading sleep for reading time. I didn’t want to ignore comprehension or distractions by plowing through extra long sessions, so I confined my sessions to 1 hour (unless I was so engaged that I lost track of time.) If I was distracted in less than an hour I’d stop, as well.

I managed to finish reading “Agile Testing” on Wednesday morning before I went to work, way ahead of my 15.34 day estimate.

Anyway, in short I really enjoyed Agile Testing. There are some great concepts and ideas within it’s pages. I also was pleased to see how much of the book I already knew. I will be writing some more detailed posts about the book in the days to come.

I realized that I was missing the 2nd most important part of this deadline this morning. Bold Boast Book Club is half reading motivation, and half blogging motivation. Had I failed to blog by today my status (win or lose) then I would have missed half of the challenge.

Perhaps people could comment on what my next “Bold Boast Book Club” challenge should be?