“Working software” isn’t enough… (Agile Principle #7)

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. :-)

Posted in Uncategorized | 4 Comments

LeanCoffee Topic: What are you reading?

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?

Posted in Lean, Seattle Lean Coffee, Uncategorized | 2 Comments

Seattle Lean Coffee Could be Anywhere.


A couple months ago I began attending Seattle Lean Coffee. I had first heard of lean coffee last year when Jon Bach and Jim Benson told me about it at my first SEASPIN (Seattle Eastside Area Software Process Improvement Network).

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. :-)

Posted in Agile, Lean, Leanstartup, Scrum, Seattle Lean Coffee, Uncategorized | 4 Comments

CAST 2011 Preview

CAST

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.

Posted in Uncategorized | Leave a comment

SFAgile Leanstartup follow up\Steve Denning is in my head.

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.

Posted in Agile, ATDD, Leanstartup, Scrum, Uncategorized | Leave a comment

SF Leanstartup… er I mean Agile Conference Blew my mind.

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.

Lean Startup Book

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)

Posted in Agile, ATDD, Leanstartup, Scrum, Uncategorized | 3 Comments

A funny thing happened on the way to eBay.


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.

Posted in Uncategorized | 1 Comment