Audrey R. Troutt's Posts - Agile Philly2024-03-28T16:17:45ZAudrey R. Troutthttp://www.agilephilly.com/profile/AudreyRTroutthttp://storage.ning.com/topology/rest/1.0/file/get/1547944725?profile=RESIZE_48X48&width=48&height=48&crop=1%3A1http://www.agilephilly.com/profiles/blog/feed?user=3nhmesguecoky&xn_auth=noProduct Sashimi is delicious!tag:www.agilephilly.com,2010-10-06:3783271:BlogPost:32882010-10-06T15:30:00.000ZAudrey R. Troutthttp://www.agilephilly.com/profile/AudreyRTroutt
On October 2nd I participated in a <a href="http://productsashimi.com/">Product Sashimi</a> workshop with J. B. Rainsberger and Bonnie Aumann.<br></br>
<br></br>
This workshop was all about learning how to "slice a product thinly" so that you can actually ship something of value quickly. We also spent a lot of time working on how to help turn a fuzzy customer product idea into something concrete that you can start to work on. I summarized it to my team like this: You customer comes in and they are…
On October 2nd I participated in a <a href="http://productsashimi.com/">Product Sashimi</a> workshop with J. B. Rainsberger and Bonnie Aumann.<br/>
<br/>
This workshop was all about learning how to "slice a product thinly" so that you can actually ship something of value quickly. We also spent a lot of time working on how to help turn a fuzzy customer product idea into something concrete that you can start to work on. I summarized it to my team like this: You customer comes in and they are usually asking for a whale. At the end of the project what they really wanted was a crab. Your job is to start from their request for a whale and 1) trim the whale down to the meaty parts they really want/need and 2) slice that meaty part thinly so that you can actually start development and deliver value soon.<br/>
<br/>
I happen to work in an academic environment where my customers are colleagues with ideas for software and tools that will help their research or will be used internally for staff. No money actually changes hands for each project, but my team is a scarce resource and we have a lot of projects to handle, more than we can actually deliver. It's not that different from when I was a consultant with paying customers who need the maximum solution at minimum cost and they need it yesterday. You always want to get to delivering value as soon as possible, which means slicing the problem thinly, and you want to make sure that you know you are working on the most valuable things first, which means understanding their business and their needs.<br/>
<br/>
The biggest challenge is understanding what the customer is asking for. Often times they struggle to put it in to words. Sometimes they can describe the solution they are looking for, but it doesn't match the problem they are describing. As knowledgable tech resources we immediately want to get to the meat of what they want, so our first question is "why do you want that?". A great reminder that J.B. and Bonnie kept mentioning is to consider how what you say sounds to the customer. Have you ever had an exchange like this:<br/>
<br/>
<blockquote>Customer: I want an X. Can you make that for me? <br/>
<br/>
Dev: Why do you want X?<br/>
<br/>
<br/>
Customer: What do you mean, 'why do I want that'?!<br/>
</blockquote>
<br/>
Depending on your tone and your relationship with your customer it can sound like you are questioning <em>their own judgement of their needs</em>, when in fact you are really just trying to understand their needs better. J.B. Gave a lot of great examples for what you can say instead. I won't give them all away, but one of my two favorite takeaways from the workshop was the Magic Wand technique.<br/>
<br/>
<blockquote>Customer: I want an X. Can you make that for me? <br/>
<br/>
Dev: Okay, (using imaginary magic wand) TADA! You have an X. Tell me a little about how you are going to use it.<br/>
<br/>
<br/>
Customer: Well...<br/>
</blockquote>
<br/>
This is going to go much better than the example above. It takes a lot of practice to get good at posing those questions.<br/>
<br/>
My second favorite technique is the Lost Luggage Technique. Have you ever been the last one waiting for your bag to arrive on the luggage belt at the airport and then the belt shut off? So you go to the little room and tell them your bag is missing. Usually they will hand you a laminated sheet with pictures of suicases on it and ask you "which one of these does your bag most closely resemble?" followed by "How does your bag differ from the one in the picture?". This is a great technique because it grounds the conversation in something concrete and focuses both of your attention on the ways in which your understandings of the object in question differ.<br/>
<br/>
For example, the customer describes what they want. It sounds a lot like a blog to you. So you say, "What if I give you a WordPress blog? What more do you think you need?"<br/>
and then listen to what they say. Oh, and write it down. Maybe they don't know everything a blog is capable of, so you might share that with them and check again. At this point it is all about listening, and keeping the conversation grounded in concrete terms as much as possible.<br/>
<br/>
As you are listening and writing down what you are learning this is when the sashimi slicing begins. First you want to want to figure out the scope of this<br/>
You have to identify the simplest most barebones solution that could possibly fit the description of what the customer needs and then build out from there to find a simple solution that you can actually deliver. As J.B. put it succinctly, the goal is to learn what you don't have to do and try not to do it.<br/>
<br/>
Once you have cut down the big fuzzy product description into a smaller fleshy piece now the slicing begins. In the training we went over techniques for identifying the major problem areas (maybe 4-8 of them) and then breaking those down in to features and then generating scenarios for those features.<br/>
<br/>
I just gave my team a recap of some of the things that I learned at the sashimi workshop and it started a great discussion about how we are doing in understanding our customers' needs, how to define what is good enough (if you and your customer are both happy could you still not be done?) and even a quasi-role-playing session with our boss as the customer for a real request that had just come up. I am going to need a lot of practice asking those gently leading questions like "Tell me more about how you'd like to use that" and "I'm curious how you came up with the idea of a X".<br/>
<br/>
When we got out of the meeting another one of our internal customers came over with a real request and we decided to see if we could use our new skills to help us learn more about what she is asking for. They ended up beating her with imaginary magic wands, but at least they didn't start off with "Why do you want that"!?!<br/>
<br/>
I did successfully apply the lost luggage technique earlier this week. It's such a simple technique. I found myself with another developer and a customer and we were all talking in abstract terms about a report that she wanted. So, I drew a picture and I said "What if this was the report? would that meet your needs?" and the conversation became much more productive after that. A lot of practice is definintly needed, but I feel like I'm already getting value out of these techniques. I really wish this workshop was a month long so that I could soak up and really practice all of the things that Bonnie and J.B. were sharing with us.<br/>
<br/>
Cross posted from <a href="http://audittyindeed.blogspot.com/2010/10/product-sashimi-is-delicious.html">my blog</a>.Code Kata Augusttag:www.agilephilly.com,2010-08-25:3783271:BlogPost:31682010-08-25T13:30:00.000ZAudrey R. Troutthttp://www.agilephilly.com/profile/AudreyRTroutt
<p>Thank you to Andre, Bonnie, Adam, Aaron and Sebastian for coming out to Code Kata night at the Math Forum! This was an experimental kata night in that we were trying out architectural katas for the first time.</p>
<br></br>
<p>In the beginning we went through a summary of the basic elements of architecture: communication/distribution, presentation/interaction, state management, processing, resource management and tools. For this we followed the slides that Ted Neward provided especially for this…</p>
<p>Thank you to Andre, Bonnie, Adam, Aaron and Sebastian for coming out to Code Kata night at the Math Forum! This was an experimental kata night in that we were trying out architectural katas for the first time.</p>
<br/>
<p>In the beginning we went through a summary of the basic elements of architecture: communication/distribution, presentation/interaction, state management, processing, resource management and tools. For this we followed the slides that Ted Neward provided especially for this event and exercise. The idea is, roughly, that when you are designing the architecture of a system you have to consider each of these elements. I think we can all agree that one way or another requirements inform your technological choices. Asking questions about the system with regard to each of these elements can make it more likely that you don't miss support for a critical aspect of the system. Here are a few examples:</p>
<br/>
<ul>
<li>Communication/Distribution: In what format does data travel? JSON? XML? Over what medium? http? filesystem?</li>
<li>Presentation: What sort of perspectives in to the system do you need? do you need an admin console?</li>
<li>State Management: Does the state need to be persisted across different sessions?</li>
<li>Processing: Does processing need to be transactional?</li>
</ul>
<br/>
<p>Then we made two groups, each randomly selected a kata and spent 25 minutes trying to come up with a suitable architecture to meet the requirements. At the end of the time each group presented their proposal for 3 minutes and fielded 2 minutes of Q and A from me and the other group. I played the role of the customer/game master, answering clarifyng questions about the application.</p>
<br/>
<p>I think it is fair to say that these exercises were hard. One of the exercises was to build a MMORPG. None of us had any experience building similar systems, so there were a lot of open questions about what was possible and how it could be done. I was probably not the best customer for this project either, since I have hardly seen a MMORPG before, let alone thought about how I would want one to work. Even if you are familiar with the domain and know about some of the relevant technology, it is still hard to cover all of the architectural bases in 25 minutes.</p>
<br/>
<p>In the retrospective that followed the question came up, what are these exercises good for? Would this exercise really be valuable to the customer? Andre voiced his skepticism of architecture as a subject because that is not how he would ever work with a customer. As agile-minded folks, we prefer to see the architecture emerge as you are iterating and building the system with your customer. I don't think these exercises are really intended as practice for starting a project with a customer, although I may have set that up by calling myself the customer at the beginning of the exercise and saying that I would decide if I wanted to buy the system at the end. I like these exercises because it is an opportunity to wonder about how things work, and it piques my curiosity to go learn about technology that I haven't had a chance to use at work before (or yet?).</p>
<br/>
<p>One benefit that we saw of these exercises is that they could get the whole team involved in design. Sebastian told us that his team actually does something similar on a regular basis. Pairs will take a card off the wall, think about how they are going to do it and "pre-sell" the approach to at least on the other pair (more for major changes). When the story is done they can present the result and the rest of the team has a chance to say "hey--that's not what you sold me!" which can help to reveal what the pair learned while they were building it. We also discussed ways of displaying architecture or the state of the system in the team area. One idea was modular printouts on the wall, legos or knex. All of these could be kept up to date as things changed. Sebastian once used the printouts as a progress chart, checking off parts of the system as they were completed.</p>
<br/>
<p>All in all this was a fun kata night and I look forward to the next one. Many thanks to Ted Neward of Neward & Associates <a href="http://tedneward.com">http://tedneward.com</a> for letting us use his slides and architectural katas for our kata night.</p>Pair Exchange Programtag:www.agilephilly.com,2009-11-19:3783271:BlogPost:20572009-11-19T22:00:00.000ZAudrey R. Troutthttp://www.agilephilly.com/profile/AudreyRTroutt
<p>I just finished the first ever pair programming exchange program!</p>
<br />
<p>It all started when I was at <a href="http://sdtconf.com">SDTConf</a> back in October. I don't remember the exact conversation, but the question was generally if software development as a <a href="http://manifesto.softwarecraftsmanship.org/">craft</a> takes two programmers pairing together to pass on and practice the craft then how will it ever scale?</p>
<br />
<p>Someone jokingly suggested that…</p>
<p>I just finished the first ever pair programming exchange program!</p>
<br />
<p>It all started when I was at <a href="http://sdtconf.com">SDTConf</a> back in October. I don't remember the exact conversation, but the question was generally if software development as a <a href="http://manifesto.softwarecraftsmanship.org/">craft</a> takes two programmers pairing together to pass on and practice the craft then how will it ever scale?</p>
<br />
<p>Someone jokingly suggested that <a href="http://www.coreyhaines.com/">Corey Haines</a> should get a bigger car--Corey travels all over the place pairing with people and promoting the craft of software development. One idea that I think Corey actually proposed was the idea of a pair exchange.</p>
<br />
<p>The idea is simple: we can't all get Corey Haines or another big name in the XP, Agile, Craftsman, etc. communities to come and pair with us, but there are lots of smart people in every town. If you two are both passionate about practicing and improving your skills then why not use each other as a resource? Everyone has a vacation day to spare, take a day and go pair. If your boss will let you, bring your pair partner to work.</p>
<br />
<p>I know a lot of developers in Philadelphia and I had no trouble thinking of the perfect programmer to pilot my pair exchange program with. Woody Zenfell III is not only one of the smartest and most professional programmers I have ever worked with, but we make a killer pair. It is like our brains are wired almost exactly oppositely, but we get along really well. I like that he is fun to work with and we get a lot of good work done together. Plus, I know his company already and I know that he is on a team of 1 and is probably missing working with other developers.</p>
<br />
<p>When I first brought this idea up to my manager I had reason to be optimistic. My manager sees the value of pairing, even though my team doesn't really practice it much, and he is very supportive of learning and professional growth. I was thrilled when he agreed to the whole thing, both me going to Woody's office for a day and for Woody to come and pair with me and chat with my team. Woody's boss was also game and we were set!</p>
<br />
<p>We decided to do one day at each office, back to back. Since this was our first pair exchange we didn't really know what to expect other than that we would show up, work on some stuff and see what value we get out of it. For me, I knew Woody's code base pretty well, having actually worked on it with him back in our consultant days. For Woody, my team culture and our domain and the code base were all new, so a chunk of time in the morning went to talking about those things. Other than that we just paired; it was awesome. At Woody's place we had some tasks that needed to get done and so we did them. At my place we talked about design for a long time and wrote a test that I was having a hard time writing. Lots of great side-conversations happened with my teammate neighbors. It was fun and we got a lot done.</p>
<br />
<h2>What did we get out of it?</h2>
<br />
<p>For this first exchange it seemed like we were for the most part exchanging little tips, tricks and techniques that make us more efficient and effective. Woody, for example, showed me how he is creating dependency graphs (actual pictures) for all of the stored procedures and reports in his system, automatically, so that he can more confidently make changes to them. He is also getting those database elements into source control and refining a test and deployment process for them, which is something I hadn't thought of before, but is really smart given how important those reports are to his company. He also showed me <a href="http://easymock.org/api/easymock/2.5/org/easymock/Capture.html">captures</a> in EasyMock, which were exactly what I was always dreaming of but never had because we were still using EasyMock 2.3. In return I showed him ctrl+r in cygwin/linux for searching your history. Then he showed me <a href="http://linux.die.net/man/1/pushd">pushd</a> and popd--that's just so handy.</p>
<br />
<p>In addition to tips and tricks we had a lot of conversations about how we do things, like how we work with our users and what process we follow for organizing our work and testing and deployment.</p>
<br />
<p>At the end of the second day we took several laps and talked about the experience. We agreed that it was definitely valuable and something we want to do again. We imagined that after a while we will run out of tips and tricks to show each other and then we didn't know what would happen then, but maybe that we could use each other as reinforcements for when something really sticky comes up and we need a fresh perspective. We talked about doing it again quarterly or monthly or more randomly. We aren't sure how our bosses viewed the experiment, and of course they would have to feel like they are getting a good deal out of this for them to allow it to continue. A lot of factors went in to making this experience go smoothly: the fact that we have both paired a lot before and with each other before, that our bosses are agreeable, there are no super-high security requirements that would prevent guests from coming over and peering at the code, etc. I am curious how well it would go if I was pairing with someone I didn't know very well.</p>
<br />
<p>I would love to hear about more people who are trying this sort of exchange. If you don't have teammates who pair (or teammates at all) you don't have to miss out on the benefits or pair programming--the discipline and the sharing of new ideas.</p>
<br />
<p>Reposted from <a href="http://audittyindeed.blogspot.com/">auditty indeed</a>.</p>