tag:blogger.com,1999:blog-26005960443140075622024-03-05T02:10:07.019-08:00All Critiques, Great and SmallNotes on software development and education, in the small and in the large.Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.comBlogger34125tag:blogger.com,1999:blog-2600596044314007562.post-49573258706908685622021-04-18T09:29:00.004-07:002024-02-21T10:00:02.261-08:00Sublinear: all you need in a burndown tool, no more.<p>Burndown charts: managers love them, many smart Agile gurus hate them. Ron Jefferies has <a href="https://ronjeffries.com/articles/019-01ff/story-points/Index.html" target="_blank">disowned even the concept of story points</a>. A recent video from Bob Hartman and Peter Saddington labels <a href="https://www.youtube.com/watch?v=eudbFB8476E" target="_blank">burndown charts as more BS than Agile</a>.</p><p>Part of me agrees with the haters. Tools like Jira, Zenhub, and Linear leave me cold. They are complex and include features that encourage bad practices, including letting you assign</p><ul style="text-align: left;"><li>iterations to stories, when we know that such predictions are fictions</li><li>priority labels to stories, when we know that leads to all stories being top priority</li><li>team members to stories, when we know that you should pull stories from the top</li></ul><p>But on the other hand, burndown charts have been critical in my agile development courses at Northwestern. They are how clients learn to be realistic about what will get done, put high value stories first, and seriously de-scope early in a project. </p><p>Here's my alternative. My vision of what a project tracking tool should look like, in a Google Sheet.</p>
<iframe allow="autoplay" allowfullscreen="" height="293" src="https://northwestern.hosted.panopto.com/Panopto/Pages/Embed.aspx?id=d9bf8a7b-11e9-4cb5-9d21-ad0501486768&autoplay=false&offerviewer=true&showtitle=true&showbrand=false&start=0&interactivity=all" style="border: 1px solid #464646;" width="520"></iframe>
<p>Here's <a href="https://docs.google.com/spreadsheets/d/1MPn4RVQbhbeg3_a2p6MDABQuBRdir9nR9lE8a1kt9EA" target="_blank">the sample sheet</a>. Feel free to copy and play with it.</p><p>To me, the most important aspect of this tool is that it puts the stories front and center. Not graphs, not velocity. The focus is on what stories might get done, and what stories probably won't get done. As always, less is more.</p><p>But if you also want a chart, here's <a href="https://docs.google.com/spreadsheets/d/1vzO1F3xpkGu7Q06zxHQpj3ZA563cE2AT3EIDi7YnX6k/edit?usp=sharing">a version that does that too</a>.</p><p><br /></p>Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com1tag:blogger.com,1999:blog-2600596044314007562.post-88829832484311030332017-02-18T15:06:00.001-08:002017-02-20T11:33:41.090-08:00Agile is Hopeless<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfq9HWEHv4Tgmd0jBQ1NlCG0y6L888o9uYiJLqlMkP_IKZUy85xn-FFyaSzEOE8knQo24zNjkkUPnc8jJqGd7_xgTY0GsEI_0p06zyqOcJU4_vWNVLXKXvIMICZ7QzDckodypYGA2nwxg/s1600/output_iduqqG.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfq9HWEHv4Tgmd0jBQ1NlCG0y6L888o9uYiJLqlMkP_IKZUy85xn-FFyaSzEOE8knQo24zNjkkUPnc8jJqGd7_xgTY0GsEI_0p06zyqOcJU4_vWNVLXKXvIMICZ7QzDckodypYGA2nwxg/s320/output_iduqqG.gif" width="320" /></a></div>
<br />
<div style="text-align: center;">
(click to enlarge)</div>
Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-61114751676092888162015-11-03T14:13:00.004-08:002015-11-03T14:13:59.625-08:00Supersonic / Steroids / Appgyver heads upI've been using <a href="http://www.appgyver.com/" target="_blank">Supersonic</a>, also known as Steroids and Appgyver, in my agile software development class. It's almost perfect for my purposes:<br />
<ul>
<li>It installs relatively easily on both MacOS and Windows. Good Windows support is rare.</li>
<li>Students work in HTML, CSS and JavaScript, specifically Angular, which I prefer over Objective-C, Swift, or Java.</li>
<li>The Supersonic QR-code deployment tool makes deployment and redeployment for testing about as fast and easy as updating a web page.</li>
<li>One codebase can run on Android and iOS.</li>
</ul>
But there's a couple of flies in the ointment to be aware of.<br />
<br />
First, at Northwestern, students can get <a href="https://developer.apple.com/programs/ios/university/" target="_blank">a free educational iOS developer license</a>. It lasts for an academic year. It puts them in a Northwestern team. The intent is that students develop apps using a single <a href="https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppStoreDistributionTutorial/CreatingYourTeamProvisioningProfile/CreatingYourTeamProvisioningProfile.html" target="_blank">wildcard provisioning profile</a>. This works great except with Supersonic. Their cloud building tool <a href="http://community.appgyver.com/t/can-i-use-wildcard-team-provisioning-profile/61" target="_blank">does not support team wildcard provisioning</a>.<br />
<br />
That means that we need to create specific app profiles for every student app that needs an ad hoc debug deploy. As you can imagine, that set can become a bit unwieldy, and needs to be groomed periodically.<br />
<br />
Second, test automation has been a challenge. I had hoped to use <a href="http://appium.io/" target="_blank">Appium </a>to communicate with the apps via <a href="http://www.seleniumhq.org/projects/webdriver/" target="_blank">the Selenium Web Driver API</a>. A few students got something to work using Java to drive the tests, but so far no luck using tests written in JavaScript. The pieces are there but things just don't connect. Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-43831511308361346402015-04-29T14:47:00.000-07:002015-04-29T14:47:22.505-07:00The 4-Panel Storyboard Revised and AppliedI'm pushing clients really hard on using <a href="http://allcritiquesgreatandsmall.blogspot.com/2015/01/the-4-panel-storyboard.html" target="_blank">the 4-panel storyboard</a> for initial project envisioning in <a href="http://www.cs.northwestern.edu/academics/courses/394/" target="_blank">my agile software development class</a> this quarter. I'm having them use named persona and explicit pain points. I.e., instead of this<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8D7TP0JVvX36YHnAdbF9MX-vrRLOqUvqyWuwjl2s2bsMrt9HNsUNuixuq2oLHpdqyhH_7W0v-cpD1KzejTgoaeoJfEKY0S9pQJa033cUj16B0KxsEVOKNrVVLl06beH_Nvc84x7tYlMM/s1600/four-panel-storyboard.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8D7TP0JVvX36YHnAdbF9MX-vrRLOqUvqyWuwjl2s2bsMrt9HNsUNuixuq2oLHpdqyhH_7W0v-cpD1KzejTgoaeoJfEKY0S9pQJa033cUj16B0KxsEVOKNrVVLl06beH_Nvc84x7tYlMM/s1600/four-panel-storyboard.jpg" height="136" width="320" /></a></div>
<br />
<br />
I want<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhi14f8L4CehgjY_Q3TDeeGRrUzSz06Ukm2KcRAAakUT_ohe_UOuMQzcJTqxqxOnS9AbRvaXxeHsjjhy-zfTM1XlHqLZo0tzwVoNRqep6O3_GWHwTCV1Klvt7px7iHld6x3cZUyUGWi7Qg/s1600/four-panel-storyboard-v2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhi14f8L4CehgjY_Q3TDeeGRrUzSz06Ukm2KcRAAakUT_ohe_UOuMQzcJTqxqxOnS9AbRvaXxeHsjjhy-zfTM1XlHqLZo0tzwVoNRqep6O3_GWHwTCV1Klvt7px7iHld6x3cZUyUGWi7Qg/s1600/four-panel-storyboard-v2.jpg" height="136" width="320" /></a></div>
<br />I believe the 4-panel storyboard<br />
<ul>
<li>forces clients to get real in panel 3 about what their value proposition actually looks like</li>
<li>properly discourages clients from developing the usual slew of data-entry wire-frames </li>
<li>provides the clients with an early user-testable object — "Has this happened to you?" "Does this look like something you could and would use?"</li>
<li>provides developers with a one-page, easy to read, contextualization of problem, target user, and intended benefit</li>
<li>defines the first clear deliverable, i.e., a working version of panel 3 </li>
</ul>
<br />
So far, coaching clients on developing the storyboards has been much easier than my previous attempts to coach clients on developing an MVP via a product box. (I still encourage product boxes, and some other elements of <a href="https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/" target="_blank">the Inception Deck</a>.) Over ten quite different projects and clients, convergence has come pretty quickly:<br />
<br />
<ul>
<li>They send me an initial draft, close but too busy</li>
<li>I send a revision cobbled together from pieces of their draft</li>
<li>They send a pretty decent final revision</li>
</ul>
This has been true for clients with and without software project experience.<br />
<br />
I'll be watching now to see whether the storyboards appear to be improving initial client-developer communication, and if so, do they also improve the value of the initial deliverables.<br />
<br />
<br />
<br />
Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-88886505554239816292015-01-28T13:00:00.000-08:002015-04-30T14:02:42.666-07:00The 4-Panel Storyboard<div class="separator" style="clear: both; text-align: left;">
In preparing materials on storyboarding for this year's <a href="http://fcei.northwestern.edu/curriculum/nuvention/web.html" target="_blank">NUvention Web+Media course</a>, Daniel Eiden, one of the TA's, included the following from <a href="http://ryandaugherty.blogspot.com/2011/06/storyboard-scenarios-for-nurses-aide.html" target="_blank">Ryan Daugherty's blog</a>.</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEq4iN30aBcLXmfvCh0S2x2jl-2XyDZ_N9f7jrGyIMLFaA2smKGTuRI_2VsSWX5EWUHqZT5mSvbvYmtcyzcAAckULCSJ5FEpe7YVG1W_bttv7jaqpVO_pow9O33_rOZlZ1D-8CWmQejYo/s1600/SupportingStoryboard(smaller).jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEq4iN30aBcLXmfvCh0S2x2jl-2XyDZ_N9f7jrGyIMLFaA2smKGTuRI_2VsSWX5EWUHqZT5mSvbvYmtcyzcAAckULCSJ5FEpe7YVG1W_bttv7jaqpVO_pow9O33_rOZlZ1D-8CWmQejYo/s1600/SupportingStoryboard(smaller).jpg" height="271" width="640" /></a></div>
<br />
I LOVE THIS STORYBOARD.<br />
<br />
Simple? <span style="color: green; font-size: larger;">✔</span>
Visual? <span style="color: green; font-size: larger;">✔</span>
Personas clear? <span style="color: green; font-size: larger;">✔</span>
Problem clear? <span style="color: green; font-size: larger;">✔</span>
Payoff clear? <span style="color: green; font-size: larger;">✔</span>
Solution explicit, focal and distinct from payoff? <span style="color: green; font-size: larger;">✔</span>
<br />
<br />
Pretty impressive and lightweight. Panel 3 is what I meant by <a href="http://allcritiquesgreatandsmall.blogspot.com/2015/01/the-scene.html" target="_blank">the Scene</a>. What the user sees. No "a miracle occurs" allowed.<br />
<br />
Could even be reduced to 3 panels if personas and problem can be conveyed in Panel 1. <br />
<br />
I'm planning on making all my teams do these early and often.<br />
<br />
<div style="text-align: left;">
<i>[Update: in doing so, I have made <a href="http://allcritiquesgreatandsmall.blogspot.com/2015/04/the-4-panel-storyboard-revised-and.html" target="_blank">one small tweak</a>.] </i></div>
Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-32524180802603617492015-01-09T07:34:00.001-08:002015-01-09T07:34:57.821-08:00The SceneObviously, from posts like <a href="http://allcritiquesgreatandsmall.blogspot.com/2012/01/scenario-backlogs.html" target="_blank">this</a> and <a href="http://allcritiquesgreatandsmall.blogspot.com/2012/11/the-scenario-canvas.html" target="_blank">this</a>, I'm a great proponent of scenarios, as in persona, problem, and payoff. I probably point people to <a href="http://www.slideshare.net/KimGoodwin/storytelling-by-design-scenarios-talk-at-confab-2011" target="_blank">Goodwin's Storytelling by Design</a> more often than any other slideset, even if her title gets it backwards.<br />
<br />
But scenarios are hard to get right. It takes many iterations before students get the hang of them. Yesterday I reviewed the following example from a student team in <a href="http://fcei.northwestern.edu/curriculum/nuvention/web.html" target="_blank">Northwestern's NUvention Web course</a>:<br />
<blockquote class="tr_bq">
Ann, an 80 year old grandmother, wants to live independently. However, her family are worried about her safety and don't feel comfortable with her living on her own. Ann is able to share her vital signs with her family. They are all recorded and kept for her automatically in her Vital Patch web page. There is also a fall monitoring detection, which automatically sends an alert to her family and/or 911 when a fall is detected.</blockquote>
What's wrong? There's a persona here, a problem, a payoff.<br />
<br />
Or is there? What's the payoff? Ann can post data? The family can see that data? So what? This is just potential payoff. There's something missing here. In my critique, I suggested finishing the scenario with this:<br />
<blockquote class="tr_bq">
Ann's daughter Susan, who lives 300 miles away, sees that her mom’s blood pressure has been increasing over the past 3 months. Susan calls her mom and works out a plan to have a friend near Ann drive her to a doctor's visit. </blockquote>
<br />
Now there's a real payoff. Something good just happened.<br />
<br />
Then I realized that what I had now was <b>The Scene</b>. The Scene is a visualization of an event that motivates the creation of your product. Novelists and movie directors often talk about how some work of theirs began with just one powerful one image. They often weren't sure what it meant but they needed to find the story to make the scene happen.<br />
<br />
The Scene needs no prologue with persona and problem. I see Susan at home, at her terminal, studying the screen. She frowns. She picks up the phone and dials a number. "Mom? Hi, um, I was just looking at your VitalPatch, and I noticed ...."A conversation starts that may prove crucial to her mom's health. As I think about what would make The Scene work dramatically, I get a clearer picture of who Susan and Ann are, what she sees on that web site, and other core scenario components.<br />
<br />
Find The Scene. It's the real starting point of your journey to a Minimum Viable Product. In the words of Winston Churchill, The Scene is not the end. It is not even the beginning of the end. But it is the end of the beginning.Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-73343228683934112632014-12-09T10:13:00.003-08:002014-12-09T10:13:52.412-08:00An AI ManifestoWhile researcher and journalists have certainly written much nonsense about AI, none of it competes in my mind with the recent silliness from <a href="http://www.cbsnews.com/news/stephen-hawking-warns-artificial-intelligence-could-be-threat-to-human-race/" target="_blank">Stephen Hawking</a> and <a href="http://www.theguardian.com/technology/2014/oct/27/elon-musk-artificial-intelligence-ai-biggest-existential-threat" target="_blank">Elon Musk.</a><br />
<br />
To that end, I offer an Artificial Intelligence Manifesto, modeled of course on <a href="http://agilemanifesto.org/" target="_blank">the Agile Manifesto</a>.<br />
<br />
<blockquote>
<span style="font-size: large;">We are developing computational models of cognition. Through this work we have come to value intelligence that</span><br />
<ul><span style="font-size: large;">
</span>
<li><span style="font-size: large;">
bases its decisions on benefits and costs, rather than politics and religious dogma</span></li>
<span style="font-size: large;">
</span>
<li><span style="font-size: large;">
exposes the depths of its uncertainties, rather than saving face and scoring points over opponents</span></li>
<span style="font-size: large;">
</span>
<li><span style="font-size: large;">continually learns from failure, rather cherry-picking the facts that fit its opinion </span></li>
<span style="font-size: large;">
</span>
<li><span style="font-size: large;">
takes its goals from the needs of modern society, rather than the distant needs of biological survival and domination</span></li>
</ul>
</blockquote>
Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-499689704059481942014-06-25T09:17:00.000-07:002014-06-25T09:17:27.655-07:00Why competency-based learning is not enough<a href="http://allcritiquesgreatandsmall.blogspot.com/2010/06/critique-based-assessment.html" target="_blank">Critique-based learning</a> and <a href="http://allcritiquesgreatandsmall.blogspot.com/2014/06/education-so-much-to-critique-so-little.html" target="_blank">my virtual talk on education in 2025</a> say much that is also said by proponents of <a href="http://www.ed.gov/oii-news/competency-based-learning-or-personalized-learning" target="_blank">competency-based learning</a>, including the emphasis on proficiency over seat-time, multiple pathways through a curriculum, formative over summative assessments, and teachers as mentors not graders. <a href="http://net.educause.edu/ir/library/pdf/CSD6174.pdf" target="_blank">When Success Is the Only Option</a> by Sturgis and Patrick as an excellent overview of the ideas of CBL.<br />
<br />
So is all I'm saying really CBL? Is CBL sufficient to define what education needs to be? Let's look at two large examples of CBL: <a href="http://www.flvs.net/Students/Pages/find-course.aspx#highschool" target="_blank">the Florida Virtual School curriculum</a> and <a href="http://www.wgu.edu/wgu/institutional_catalog.pdf" target="_blank">the 2014 Western Governors University course catalog</a> (course listings start on page 40). What you see there looks identical to the courses you see offered in any traditional curriculum: Chemistry I, College Geometry, US Government and Constitution, etc. Compare those courses with the role and story driven offerings suggested by slide 21 of <a href="http://allcritiquesgreatandsmall.blogspot.com/2014/06/education-so-much-to-critique-so-little.html" target="_blank">my virtual talk</a> or actually offered at <a href="http://www.xtolcorp.com/courses/" target="_blank">XTOL</a>.<br />
<br />
CBL is built on the same broken discipline-defined foundations-first content structure of traditional curriculum. Competency rather than seat-time is the right idea -- but competent in what matters just as much.<br />
<br />
<br />Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com1tag:blogger.com,1999:blog-2600596044314007562.post-59059921435435346662014-06-20T08:09:00.000-07:002014-06-20T08:10:21.327-07:00Education: So much to critique, so little timeI don't mind giving talks but I suck at sending things to conferences. <br />
<br />
So I created a standalone virtual talk on what's wrong with education -- it's a long list -- and what it could be like instead. You can see it at Roger Schank's <a href="http://www.engines4ed.org/curricular-revolution/index.cfm" target="_blank">Engines for Education site</a>.<br />
<br />Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-12022499370453376272014-06-20T07:34:00.000-07:002017-01-30T13:27:49.820-08:00Scrum GrumpsIn my software development course at Northwestern, I emphasize early delivery of value and team development. I start with the second and move to the first over the 10 weeks of the course. I constantly refer students to those whose ideas have fed into my understanding of lean agile, including DeMarco and Lister, Brooks, Weinberg, Beck, Cunningham, Jeffries, Cohn, Rothman, Rasmusson, Ries and many more.<br />
<br />
The one big thing I don't do is claim to teach Scrum. I teach most of the parts, such as user stories, backlogs, velocity, and daily standups (not "scrums"), but there are a couple of terms I avoid and actively un-teach when students come across them.<br />
<h3>
Sprint</h3>
Sprint says run like crazy, but not for very long. I know that's not what "Scrum Sprint" means but that's what "sprint" means. Words matter. I want my students to see development as <a href="http://lisacrispin.com/2011/03/20/shortening-the-feedback-loop/" target="_blank">steady loping</a>, not repeated mad dashes. There's just one sprint in my course: a hackathon at project start to get the very first testable slice to the client. This first mad dash has benefits for the product, developers, and client-developer relationship. The one bad side is technical debt but the code base is still small and you have plenty of time to pay off technical debt. I use <b>iteration</b>.<br />
<br />
The length of sprints, from two to four weeks, is also problematic. For anyone new to agile, I prefer one week. Move to two weeks when things are humming along -- or move to continuous delivery and drop iterations all together.<br />
<h3>
Scrum Master</h3>
[Edited January 30, 2017]: Master? Words matter. Master sets up a power relationship with developers I am not at all comfortable with. Even worse, here is how Scrum Master is defined in <a href="http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf" target="_blank">the Scrum Guide</a>:<br />
<blockquote>
The Scrum Master is responsible for ensuring Scrum is understood and enacted.
Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.</blockquote>
<br />
No wiggle room here. A Scrum Master is an enforcer. The Scrum Master tells you when you are and are not doing Scrum properly. This is about as far removed from a role I would want someone to play as can be.<br />
<br />
What do I teach is the needed? <b>Agile coaches</b>. The role of an agile coach is to help you identify ways in which team and business needs could be better served. An agile coach is good at<br />
<ul>
<li>detecting when things are going off the rails before the team does</li>
<li>identifying counter-productive processes and attitudes</li>
<li>suggesting simple and effective things to try to improve the development of both the product and the team</li>
<li>making these ideas real with stories from personal experience and case studies</li>
</ul>
<h3>
Increment</h3>
My minor grump is the definition. <a href="https://www.scrum.org/scrum-guide" target="_blank">The Scrum Guide</a> defines an increment as "the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints." This is an odd use of increment. In normal English, an increment is an increase or addition, not the accumulated total.<br />
<br />
But my real grump is with the commentary under the definition of Done: "Each Increment is additive to all prior Increments." I am <a href="http://www.agileproductdesign.com/blog/dont_know_what_i_want.html" target="_blank">not the first</a> to note that an additive view of implementation fits very poorly with the realities of product development. I use <b>version</b> with no commitment to steady growth. <a href="http://lean.st/principles/build-measure-learn" target="_blank">Build-measure-learn</a>.<br />
<br />
<br />Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-26341297244205157262014-04-11T07:35:00.001-07:002014-04-11T07:35:09.106-07:00Courage in Profiles(For those under 100, <a href="http://www.jfklibrary.org/Events-and-Awards/Profile-in-Courage-Award/About-the-Book.aspx">the source of this title</a>.)<br />
<br />
At least half of the student teams I coach in agile software product development have creating a user profile interface as their first or second user story. They're so used to seeing them in Facebook and elsewhere, that they assume they must have them.<br />
<br />
Profiles are <a href="http://blog.codinghorror.com/reducing-user-interface-friction/">friction</a>, pure and simple. There is no user payoff in creating a profile. How silly would an app be if all you could do with it was create a profile? Well-known sites can get away with profiles because users already
know they want the services those sites provide and are willing to put
up with some friction. Your fledgling app is unknown and
probably not all that good yet. Users have no incentive to put up with any
friction with your app. <br />
<br />
Nor is there any value gained in early testing of a profile creating interface. No risk is reduced, because such pages are not hard to build, and no business value proposition is validated.<br />
<br />
"Maybe so," the teams reply, "but our app <b>has </b>to have user profiles."<br />
<br />
I've yet to see that actually be the case with any team.<br />
<br />
The first argument for user profiles is usually "we need to know who the user is so that we can attach data to them." For example, if someone joins a scavenger hunt game, we have to know who they are so we can keep track of what items they have found.<br />
<br />
This argument confuses identity with a user profile. To give someone an identity, all you need to do is give them a unique URL that they can bookmark and/or save on their home screen. <a href="http://signalvnoise.com/archives2/writeboard_the_appless_webapp.php">Writeboard </a>(recently retired) from Basecamp worked this way. When doing early product development, it's a way to get test users started with no friction or commitment on their part, and total control over the identity on your part.<br />
<br />
The second argument for user profiles is so that users can specify preferences, e.g., what name they want to appear under, how and how often they want to be sent messages from the app, and so on.<br />
<br />
This argument assumes that the only way to collect preferences is to interrupt the user's experience. How many apps have you used, from Google, Facebook, and elsewhere, where you wanted to change one thing, e.g., whether to get email reminders, and you had to go a preferences page with dozens of options to search through? Now consider the alternative: you get a reminder you don't want. It includes a link that says "don't send reminders in the future." One click. Done. Or your favorite restaurant searcher shows the places too far away, so you click adjust the radius of search and say yes when it asks if you want this radius to become the new default. Two clicks. Done.<br />
<br />
Not only do these alternatives have way less friction, the friction is connected to immediate payoff, not some potential future benefit.<br />
<br />
So does this mean you should never implement a user profile and preferences page? Not at all. Such pages are a great way for users to review and adjust their current settings. But such pages are just nice to have's. They aren't and should never be critical to your app or your early development process.<br />
<br />
Have courage! Put user profiles where they belong, on the backburner, off the main line of development.Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-63803342075162530862013-07-30T14:16:00.000-07:002013-07-30T14:16:37.464-07:00My Rubric RantI'm a calm guy, really. Normal blood pressure, definitely not Type A.<br />
<br />
Unless someone gets me started on rubrics for courses. In that case, get a fresh drink, reserve at least an hour, and don't expect to get a word in edgewise.<br />
<br />
To save my voice and your time, here's <a href="http://www.cs.northwestern.edu/~riesbeck/rubrics-rant.pdf">my rant on rubrics</a> in easy to digest PDF form.Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-63654783585670463362013-05-18T10:34:00.001-07:002013-05-22T07:32:30.300-07:00EBD: the right way to sell AgileFor quite some time, I've been summarizing agile development as "early and frequent delivery of value." But it has struck me that skeptics have a good reason to be unswayed by such a claim. Of course "early and frequent delivery of value" would be nice. Ditto "easy," "seamless," "fun to use," and all those other claims every product and methodology has promised since the beginning of marketing. It's quite right to treat such promises as so much hot air. What matters is what you deliver.<br />
<br />
So instead, let's ask a few easy questions.<br />
<blockquote class="tr_bq">
What's better for making decision, more evidence or less? </blockquote>
Can I assume we all agree here? Next question.<br />
<blockquote class="tr_bq">
What kinds of evidence are better:<br />
<ul>
<li>user surveys or user observations</li>
<li>historical data or last week's results</li>
<li>expert opinion or actual measurements</li>
</ul>
</blockquote>
Still with me?<br />
<blockquote class="tr_bq">
Which kinds of evidence can you get from:
<br />
<ul>
<li>requirements</li>
<li>high-level design</li>
<li>implementation</li>
<li>testing</li>
<li>deployment</li>
</ul>
</blockquote>
Final question.<br />
<blockquote class="tr_bq">
How does the above flow of evidence compare to the evidence gained from weekly user tests on working code?</blockquote>
<div>
And this is how you explain agile to skeptics: It's EBD -- Evidence-Based Development.</div>
<div>
<br /></div>
Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-24289875566530025042013-02-03T13:26:00.002-08:002013-02-03T13:26:24.306-08:00The Easter Egg Hunt: An Lean Startup Coaching Story (Really)"Hey, Bobby! Guess what? The Easter Bunny left a whole bunch of Easter eggs outside! Wanna go find them? Follow me!<br />
<br />
"Here's your basket. Start hunting!<br />
<br />
"Whoops! Not in the house, Bobby. You gotta get out of the building.<br />
<br />
"WHOA! Not in the street! Back up! Here, little guy, let me point you. That's right, look in the yard.<br />
<br />
"Honey, don't give up already. You're not finding anything, because you're just standing there, looking around. The Easter Bunny hid those eggs. You gotta move around. You gotta look behind things. You gotta pick things up.<br />
<br />
"That's better.<br />
<br />
"Yay! You got one!<br />
<br />
"Whoa! Where are you going, skipper? You're not done yet. There's a lot more out there. Don't stop with just one egg. Keep looking, guy.<br />
<br />
"Yay! Another egg! And another! You're doing great now, Bobby. Keep going!<br />
<br />
"Um, Bobby? Bobby? Your basket is getting awful full! Watch what you're doing. Some of the eggs you found are falling out of your basket.<br />
<br />
"What, you gotta go to the bathroom? Oh, OK, come on in, then. But be careful! Whoa! Slow down! Don't run or you're going to tr...<br />
<br />
"Oooooh, Bobby..."Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-67500947565315220792012-11-06T14:20:00.002-08:002012-11-08T09:14:16.713-08:00The Scenario CanvasAfter several years of trying, I surrender. I will never get my students to put goals into their user stories ("As a ... I can ... <b>in order to </b>...").<br />
<br />
So, following up on <a href="http://allcritiquesgreatandsmall.blogspot.com/2012/01/scenario-backlogs.html">my earlier post about scenario backlogs</a>, and triggered by Roman Pichler's <a href="http://www.romanpichler.com/blog/agile-product-innovation/the-product-canvas/">Product Canvas</a>, I'm now experimenting with having my teams plan and report progress to me with <b>Scenario Canvases</b>. A Scenario Canvas is nothing more than a short context scenario plus the exact set of user stories need to support that scenario. No more, no less.<br />
<br />
<img alt="" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAWMAAAEQCAIAAADqFoLZAAAXLElEQVR4nO2dvWolR7eGdRv7PnxpBt3AAVuJjc0JxhiHcvBhGHFSZYMSB3ImjAcExzA4EZPIDkZg6BPouClXrb+qrv7dzxMMrepVa63q3eut2t2l0cXbt28HAACTC5QCAFxQCgDwQSkAwAelAAAflAIAfFAKAPBBKQDAB6UAAJ+Ln3766R0AwD/8/PPPglL8+OOPJwCAf/jss89QCgBwQCkAwAelAAAflAIAfFAKAPBBKQDAB6UAAB+UAgB8UAoA8EEpAMAHpQAAH5QCAHxQCgDwQSkAwAelAAAflAIAfFAKAPBBKQDAB6UAAB+UAgB8UAoA8EEpAMAHpQAAH5QCAHxQCgDwQSkAwAelAAAflAIAfFAKAPBBKQDAB6UAAB+UAgB8UAoA8JldKUanvRzuFK5DFVyurYFSLATXoQou19ZAKRaC61AFl2troBQLwXWAXbOOUqSNNzc3T09Prz8+Pj6+efMm6Pn29vbDhw+jq+fn54eHh6urq6qsrq6unp+fh2F4eHiwc9baLy8v7+/vxyEMw/Dhw4fb21uj7/X1dTrkYM7xWK+WDw8Pr0MbhuHp6enm5kbz+fDw8PLyMgzDy8uLeA1rP6/gR2N8Coaw3tzcPD4+jgaPj4/a0KAjKyvFw8NDGT4iFmm1ZFxfX8ezSmvJzllsv7q6eq2xktShPeSXl5eIWMRjaZapGtqW2TU0kh+Kzyv+0Yzt5acwnsoS1px/+PDBvYAwhZWVQuTx8dH2eXd3N95Yl5eXr43jTRy5acqg6cys3aZl+zi5jd0vLy/Hu/nu7q7XkKtiaYIyDEM2/WqWLy8v9uXSkq/6aEpX49DGltQ+XaeUIBazsrJSvLy8jPduuqS0fY5TUDYVB7unlukN7fop28eWNJPLy8vXxufnZ3HI49Q6llBWmXbOdqyxVl9eXl5n+1RQ0pTKqr68vCz16FTzeVV9NManUNrf3NyMjXd3d2PC9/f3YztfQ+ZjZaVIP9rxph9aH/vFu9v3luanbE/nZPsL8/QhB2ONE28W6Pn5+f7+Pi3g0VKs0nSKnp58/DbQ7EdhSldPr4yCG1maQRvrP9GMtGtcXV3d3t4+PDxkX1/jWZULiqr00gltRCzj6UMOxmq4CCLpMqch+chHY3wKpb1hfHV1FR81tLFXpbi9vR0XuiVtWbWlJz7kG4rnlNOHHIzVcBHcy1iVfPyjMVKN51A7amhjl0pxe3s7Wj4/Pz8+Pt7d3b158yZ+u7Tddlr75eXl7e1t+Vi+7X2KjRsr7nD8OuNaxpOv+miMVMtTY4uxpog87oE2dqkU45Q1feFtn01vyuvr64j/7G2/GzGeczDWKCLx5xTug8B48lUfjTH28tSYLc8pVmGXSiGadVxTjJPtuAHh+vo6faA4Wo6FIT4UnPhVPyMYK/7uY5z/09cxY2PbgqjqozHGXp7i3ce67FIpxvt+rOSbmxuxkquyGkknapHRcrx9n56exul6vHeb932KxGMZ+ymyCdmwTHdJxZOv+miMsYunjD1dAwuKmdmlUqRfBFLGO9LdpmkHSp+lj6RPE1Nj7SmjtkezbchVsbIVUDqEzGE6URuW8eSrPhpj7NopTSyQibnZpVKcTqc3b96MM//Ly8vrLyCMFe5u13MDpf6fnp5etyFpvbLnBU9PT+V36elDjsc6/fu3OV4viP17H+NXG9GyKvn4R2OM3Tj1egXGofF7H8vA/3kFAD4oBQD4oBQA4INSAIAPSgEAPigFAPigFADgg1IAgA9KAQA+KAUA+KAUAOAjK8Xbt2/LVgCAFJQCAHxQCgDwQSkAwAelAAAflAIAfFAKAPBBKQDAB6UAAB+UAgB8UAoA8EEpAMAHpQAAH5QCAHz6K8Up+atQCxAJt3BKVaE3eLkASnavFBsHpYBjMK9SjP83RnY2bSwNshatMQsXtCkjBgOl3cthah7siKVxJHrzpbP9AxjMqBRiLWk3ulF+Wk26Hd3ompl41uhuNNoR7b529LZLh0xAGwt9+3DrIXi7a54jNkZ0o4vWGEw1Uv+1luIxSgGzstC3j7hSlF3SdiNc0EaMbiRsDM0ecjxiraV4LF66shGlgDb6KEVwQtMah+R2jwdqaLGrcWKtisZLKoXdxfAM4LKEUlStKQw/g37rByUgbtamFMERNeTmRm/IByBOt28f4qK9XPRGik3z41ZaxEaMbiQs+skiZm4jylhGtIdguKq6dIZ/AAP2aAKAD0oBAD4oBQD4oBQA4INSwMr89ttv33///X+gE1999dUcH1PPdx/BxgabuZmYAy8UpvDu3bv379+vncVx+OGHH+ZwO69SzNqxI1Ny2EL+uwal6Ms+lKLcXDAeiBOvux9BaxmknQiRs6XPSMR4o5Ftcc38DRRZ3/JH7YKLvbYpaihFX3agFNmtOUhFIoqFcazd+g0aUR64GRpdgvkPeokGL4s7HDdPrddGQCn6sgOlKI+N6dTuKPZy6zZY9qXPKqWozT9SnEEBbVM09yKsy+pKcXFxsZaHi4Re4XasFIO5zM46ppSNRqyhRikyn24OxhAmqkyVW5RiDtZViu699q0UopnRMe62QSniXUQyg2al6D7w2l4bIVOKsQzSg3HWTadfcTYWDdK+ZZllZ8cfxbN2oNJzZqYdiG61Hw+rFA0lUfbtuKYofbZVYCQZcchaGu7ZZqWILHDWwlaKrE60U6JB1m6ftY2rfnQT1iSmLUrGjpVi8L59ZH3FFtGteOyWU+nTzcEYgmtmFKcoVcbZSEqnhLSXdv1XJ7imGJK6cpUibdGWCWJEY00h/qjlLLa7a4qzUAqYj4kVvk2BGHGVYvzRXguUfatm/imLCJQCVqNcGkxx1SWlmSifaGZze7Y+N9YUo0FmHFSKSKzsbNlYei57GTWfCaL4I0oB58jq7z4OBkoBxwSl6AtKAccEpejLMZWi6iu09oIg3n3il3+7l/tapM1tFdqboy0/qkAp+nJMpahi9VcAG1eK+AvjTYFS9GXrSqFtTBiSe9TYa2BsDTAMMg9lAqJl2R5J2/Cg+Q/O7VrmxjVxyx6lOFt2oBRZ0WqNg1Te2inxIItrxyottUbblVufrooZZvZgg37K0CjFGbIDpSiPtTu1SilED/FYaaO2fKhNW+QkEXESyTySQHwgmwKl6MvBlcKuLq0lEiveOF0pjNxEnXLDidImOtHiBpNfEZSiLwdXCtuh1hKJFW+cVSmCHScOx+iIUpwJO1CK8i5vUArDyTGUIrimyNYjwWSyRpTiDNmBUgz/vq0H6cbVDMRFtbjwFuMOrUphZ5UZBDVLbBEHaGc+2sf9iKlq9hsBpejLPpRimV5wJFCKvhxQKZAJGFCK3mxdKQDaQCn6glLAMUEp+oJSwDFBKfqyb6WofSSx4iOMmULXvri137M0xNosKEVf9q0UtaAUU/JBKc6ZrStFuZ9C3IDgbrsodwQMyqaA4E4BbbuEGGKQysxI1Q6RhYvEKu2DEbXxsp/i3NiBUhgaEZEP0V471gzKrMS+kfRsJ3aqhpkdy7a384mksUFQir7sQCmMY3eG1OwjXWozjIcTzSaOqCqWmyFKARlnrRQpZbubWGa5O6XQBm6vSiKxtgBK0ZezVop46EhWu1MKw7nIvpTijz/+uL6+/g904vr6eo6PaWdKUVsD2cxcGy4+wPiI+irFAdYUsAs2oRRD8R1BW29nEbX6L83cHLIE4gN00xPFyIhVla09ZNcSIMhG91M0QDEAzAdKAQA+x1EKAJgPlAIAfFAKAPDZ098lnSPKigmIr0WqPNgGe3lw8/vvv3/77bffQSe++eabOT6ms1CK1ROYXsYHVgr2aPZl63s0B33ngvFuX9w9Ufq0FwVpFG33QWkvniqdZ13K7sZOCs1zZiDmn9pE9kTYSrHlXRUoRV+2rhRiLZX1YBtrPsWzoh9bKSIHmX8j1YgqxYdmXyu3yI0Q7mVcF5SiL7tRisErP82gds4UuweVwuhl+3djid2DSmF4iyhFiT2KjYBS9OUIStFwE5dd7KANSqE5N9JLVwGlB3uYkczLxCauKezLuC4HU4qLi4vx3+budovN7pWiyiByVjRoUIoq/1osu0uDUgTPig7d6JvikEoRb9dsxuPDKoW7ZMgMgmVsl+VoEFSKiIho3gapekWHzUoR1xGxi5ZSxM/yZEpRVsjFP4zHZXvavTRI+4qFl53KzMRemfMsfzEHzYk2TC1tbRSvbF0pBqlcxRV1aWCsikUJcH1mK+2sVNyVjnu2jBUZpu1ZdBLUnUgI4yKvi60UxjRrLNTd6hV72VG04jRiickb2RqDjeezA6UYWeWO3GYZgEtwTTEepD9mroyZX/ScmWVdxKCa8ywHMXkt21ql0PJ5ZetKUc7kC4NS7BRXKcYf7bVA2bdtdeBGcfOMJC96qFpTaGxdKQDaKJ9oilO6eKr0Zq8OxnYtnNiirR3cNUU5ECPboVAKLW0x7ghKAcfkYO8+VgelgGOCUvQFpYBjglL0BaVo4fRvJrrqmNWS4TYOStEXlKKFhcu7oyuUogv2s89aPw1RuvivYgdKUU7d4saqoJlo6XouDeLZarnZrmqHo7mack2qxmK3LM8CSjG3H5SiArFi07uwLBLDTLNMWyJdjPIW09C624JVNRzRlW1mX5PasRgtq6C9JU2PxdeH4tnMTHtnqTVqPrX3ppl/Oysj81JrmrVjr0qRNbbd61PCafNtc7ZuSvExBlsmKoVmtu5SYiS4mzvyo+0k3ug6zNpFhxlt42rgOEpRVq9WRWKR14abmK3YJXMVGc7CSjEUV0+78toVXoxapSgn82ENpXDXFNkwUYr/Z0rpugXZXEhzK8X0eo60TPEsjsUeyMK0rSlEY9tJR6WwXTV70FxVsVelyG7oOUprC0rRa03R4KR5LO7olqHtOYVd2KJZRCnEiGJfzb/YXRxXmYw2liq2rhSDtJQd70hjVTzot6yxNna7uBOp6FzMzUgjHZ0rCrarKdekdix2x4Wx331MLJtaDOlZPoc2tqsUf/75538pnE4n7dROub+/73LdYWRTSjEoTxmWjD7Rw3aV4u+///5fhdPppJ3aKc/Pz12uO4ywR7Mv21UKgCmgFH1BKeCYoBR9QSngmKAUfdm6Usz6/Nx+/bHuo3sX9y2Mezbiv1cmy4NS9AWlUBu3dutnzJ0eSgEpm1aK7LW8+5Y++Kp/0PcgpI2ppR0lkkbpKmgmOh+K+tRCuAkMpmJGhl86cS/RAqAUfdm0Ugz1m4vTY61mRJ9By4Y0RFe9cgtmaySglXR8+KJmGaNYBpSiL8dUCqNL3M/E7navXs6D2QYTcAciGhiZrAhK0ZfjKMUgfVtp8ON2TzG6265EP7tQCi1t0aZ0uxgoRV8OpRSZwdxrCjth29XEabz0s4xSGI2uk4V5//79119//R104osvvpjjY9r0c4qgn4nds172DNzsfLpStC2OjBFVaTqcOZ3/2mB6bNx8pYHYIjovG+1etWmU4dzcbOcTlUIbqZuMFrrqEgG8sugezefn5//eNqfTae0ULGZN7+PHj4vdCbA7FlWKT58+vds2p9Np7RRy0rXJrIH++uuvxe4E2B383gcA+KAUAOCDUgCAzz5+Q2x6XPHlwnS3VbT5rOpV+y6Dtx4QZPdKUcuKec6tFA3+9/Kpwep0Vop0QnM3HWhdsn0EVTsRMnvxrLE5QvNvTNSaQ3s3hNtLuwJaJukpN3kxpbX4+PHj2tsaD8X19fUcH9NcO68GpbDdLhFd0E7ZGlGbm+ZKNHO7RIYW0axgznYmdsSFecfvfXRlN7/3MZhlaXfRiiGoFBHPtbnZ9dmQSaSxIRPRsiq9tUAp+oJSCMdlLNfzRpQiRXNelYloiVKcISiFY7YvpTAitmUiWqIUZ8gOlKL2Xiy7LKkUbm4R++lKwZoCpejLDpRi+Hfxp+3BLmVfV4AalMItzohbLUljFJmN3Suz1HrZORvXxHa1JHtXCuOvk1f96UDXOPhn0LerFJ8+ffofndPp1HBqGdIEfv311y4XFGrZi1JoJdrrj5ietVLYWrCuUmTRUYq1yJSi/GvjF/8wHpftaffSIO2rTf5lx9KJGCst4NKPGNf1ViY/FEqhDWe7SgEwBVspsgLTTokGWbt91o0SMYs3ug6DgUpQCjgmwTXFeJBN4yliS2mvmYkJrKgUkTXFUIBSwDFxlWL80V4LlH2DJZp134hSuMqljWXrShF5oVDlyvYzJUqwb+2I5niPYL8Nnbv7MpRPNLOFQDavGmuK0SAzdks0kyFtiWF0jCuFGFHsa6wpRA+vnJ1SzMeZK8XW2Mu7j164S5uJbFop0pfzxsYK+wV+6WFsLx26Z42FSTBDVymMlCLDd82m+DFGalw6+wOaiXNTikF/xNCFTSvF4G1tEu9Uu3vQYXnWve+DGdpKoXkwanKiWWlvHEdGqmnEwmJxhkoxK3tSimCj2H0wC7WqwuOxRIOgUkSia8ZVZm7+tVHifmZFe6LZHdvzfHEXZvdKkWJ0H8xCnVUpsgw7KkXqvIxlm1XlH7E8W6WIsB01aY61e6UIdh+KkltGKYIJGJ6rogcvyHkqhfjqYdDfHZTvSkr7QXqnoL0ocYNqDxrs6GUIexRtYnEcpVhsTRFfv4i9gkqRHdTKUNzMzl803qlSiAda9RpdBql0XR3RghoeIlnZSbqh4+xAKaqW35oHu1CDt7uYjJaVNgR3QZQNJ4ue9SobI2biFYv4MUYaVIrF9OJ4ShFPMltHGKHjbF0ptsnC0yM0cDylqF1TuOOtAqWIkq1NYOPYzynGxuzHUgLSU1m7oQXlWa2S07NlhmX0LE8jW01Z2sQCpYBjEtlPYQvHTCwTpTsoBRwTVynEuX3OjBYKMRMoBRwT9mj2ZetKYb+iWwX35YXRpWxf+NmH+y7jMPTaebXfVUBfUIpqeilF+SJzYmLNmRySiUqBQGTsWynsCbltr4HtOW0f/41sXnAlz84z24yQ5eD2Sg+mXNIdYbwlFV9qXEhoHcU3Kcdmx0pRloTWUSwqw0nQcyYHQYeGZ9uDGMuNmxnYmdgD3xeiUribEYKWxivPo7IDpSgZT6VmZUejpaGwg31dy8zAnsPdWLWS15bnHqlSirHR2IZg/HgO7EAptBZRPjLLTFlEuRGd2G7L3MS+VRUY96CJQqSXPaLBHPi+qF1TVEkDStGLpb99RJy4RTIlgXij5rnBbVWI2ouwd7GY8pwiay87ohS9OJfnFEaju6ZwlcJdU0QMssa2VdIeYT9FX3asFIO3VC7PivbxxvRUmYlhYLvSog9KDRs5lOPNjsVM4pd0R6AUfdm6UoDNAUp6Jn755Zcvv/zyO+jE559/PsfHhFLMiLYSAdgdKAUA+KAUAOCDUgCAz+aUYsmv9L1iBf0c6dUmnBsoxXJ+UArYL533U0T2O2i7CbJ/xR0KdoE1bLgI5mwMpMxQ2wpRDqrqythjAZiV/v+L/xDeepgVgOYnqBSaZ6NvMGd7IHFRE1XGHmabYgJ0Z5Y9mrWVo5kZtWQnYHubkrOYjNg3nkzQIUoBKzK7UqSUjUbfoVIpUs+2t4acy7SNKFlHN5nRoXtlxMQAFmC5NUXQbIpSxD1X5SxaujN8MJzo0O0CsDBLf/vIpm7RLFjnbQm0dSnT7hVukJQirqEAyzCvUgzKN4JSNbK+5QI7UifiytxYrsdz1tLWRqeFc/Wo9GaPBcmAZdjcfgoNygNgRfahFMb6AgAWYB9KAQDrglIAgA9KAQA+KAUA+KAUAOCDUgCAD0oBAD4oBQD4oBQA4INSAIAPSgEAPigFAPigFADgg1IAgA9KAQA+KAUA+KAUAOCDUgCAD0oBAD4oBQD4oBQA4INSAIAPSgEAPigFAPigFADgg1IAgA9KAQA+KAUA+KAUAOCDUgCAD0oBAD4oBQD4oBQA4INSAIDP/wE20FyxnQl+QwAAAABJRU5ErkJggg==" /><br />
<br />
Note that there are no goals in the user stories. The goals, constraints, affordances, and so on, come from the scenario. The scenario establishes a need in a situation. The user stories satisfy that need. <br />
<br />
To develop, pick the scenario that is most critical for your business case, e.g., for testing or demoing. You identify the user stories and write them down. Then start with the user story that is the <b>payoff point</b> in the scenario, the point where the user need is met. Typically this is one of the later stories. Hardwire or fake the other stories if necessary. You need to see if the idea really does pay off, or if it needs more. As you go, mark the stories that are done. Some may be already done from a previous scenario.<br />
<br />
I expect I will still have plenty to critique in what they send me, e.g., <br />
<ul>
<li>Scenario bits clearly added just to demo a feature. "Sally wondered how many things she had loaned out, so she opened <b>MyStuff </b>and clicked <b>Loaned count</b>."</li>
<li>User stories that align poorly with the scenario need. "Fred was hungry and stuck downtown. Where could he get something vegan? He open <b>FeedMe</b>, started clicking nearby restaurants and opening their menus."</li>
</ul>
[Edit: Related is Goodwin's <a href="http://www.slideshare.net/KimGoodwin/storytelling-by-design-scenarios-talk-at-confab-2011">Designing by Scenarios</a> (e.g., slide 55), but I'm not trying to create a design tool. I'm looking for a more focused tool than backlogs for client/developer communication.]<br />
<ul>
</ul>
Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com2tag:blogger.com,1999:blog-2600596044314007562.post-30824690864879283422012-11-01T18:43:00.000-07:002012-11-01T18:43:11.307-07:00The Number One Myth about TeamsSome of the simplest ideas are the hardest to teach because of interference from an equally simple wrong idea. The number one misconception about teams that afflicts managers and team members alike is this:<br />
<blockquote class="tr_bq">
The purpose of teams is to split up the work.</blockquote>
Follow this and you get silos, low value bus factors, miscommunications, bottlenecks, etc.<br />
<br />
Here's the alternative.<br />
<blockquote class="tr_bq">
The purpose of teams is to gang up on the work.</blockquote>
Follow this and you get pairing, swarming, bonding, low work-in-progress, continuous improvement, etc.Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com1tag:blogger.com,1999:blog-2600596044314007562.post-47837394371240970752012-07-20T09:44:00.003-07:002012-07-20T09:44:56.989-07:00Riesbeck's Rules for FlinchingAgile thinking is fine, but agile feeling is even better. If you want to do things right, it helps to react negatively and viscerally to doing them wrong. These days, I can't help flinching as soon as I hear someone say that they<br />
<ul>
<li>are working on anything the client / end user can't use</li>
<li>are waiting for someone else to do something</li>
<li>are making something complete</li>
<li>are too busy to write tests</li>
<li>haven't shown the client anything new this week</li>
</ul>
<i>Wait a minute! Writing tests is writing something end users can't use. You're being inconsistent!</i><br />
<br />
Only if you think the goal is to never flinch. Software development is a tightrope walk over Niagara Falls. <i> </i> You have to expect to flinch a lot. The goal is to flinch less often and less hard.<br />
<br />
Or, alternatively, turn these rules into a drinking game. Take a drink every time you hear one of the above things. The worse things get, the less you'll care.<br />
<br />
Me and my liver will stick with flinching.Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-8728218296324214332012-04-15T18:10:00.004-07:002012-04-15T18:10:55.347-07:00The One-Button AppSince my friend and colleague Todd Warren has made <a href="http://www.forbes.com/sites/startupviews/2012/04/11/3-lessons-for-any-startup-from-the-instagram-acquisition/">a brief reference to it</a>, I figured I should try to explain one-button apps, and why I push [sic] them.<br />
<br />
With a one-button app, you achieve your primary goal with just one button push. No click click click check select check click submit. Just "do it." Todd's favorite personal example is the Flashlight app for the iPhone. Press a button and the light comes on. It's one of the few apps he liked enough to buy the premium version.<br />
<br />
Twitter is a one-button app. Type and send.<br />
<br />
Angry Birds is a one-button app. Stretch and let fly.<br />
<br />
There's a reason Amazon patented and fights to protect 1-click buying.<br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
If your product isn't a one-button app, how can you expect anyone to really get it in a 5 minute pitch? If your first testable release isn't a one-button app, how can you tell what your users really feel about your core value proposition, and not other issues?</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
Most initial student ideas I see for smartphone apps fail to find the one-button essence of their idea. Students design apps that are too general. General is often the enemy of simple.<br />
<br />
Take the example of reserving courts (basketball, tennis, squash, etc) on a college campus. The general solution is a classic calendar-based event scheduler, where first you have to select the type of court, to get the calendar of reserved times, then do the usual time selection rigamarole -- and you haven't even contacted the people you want to play with yet.<br />
<br />
To get a one-button app, first pick a common use case, like arranging pickup games. Those are always the same people on the same court type. When you start the app, all you see are buttons for today's free times for that type of court. Press one of those buttons reserves the court and notifies the people you play with. They get a "can you play at ..." message with buttons to say "OK" or "Can't make it." If too few OK's are registered within the next hour, you get a message and buttons to "Cancel" or "Keep."<br />
<br />
That's it. Just one button push to do what you normally want to do. Only on the first use, do you have to pick a court type, and, when you pick a free time, say who to notify. These choices are remembered for future use. They're easily changed, along with many other options, via a preferences panel.<br />
<br />
But the core value of the app is in that one button push.<br />
<br />Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-8257340394508341832012-01-04T10:26:00.000-08:002012-01-04T10:26:26.831-08:00Scenario BacklogsHere's a problem I've seen a lot in my conjoined MPD 405 / EECS 394 software development course: poorly motivated iteration backlogs.<br />
<br />
Me: Why did you tell your team to build that this week?<br />
Them: It was the highest priority item.<br />
Me: Why?<br />
Them: It's a must-have for our MVP.<br />
<br />
That's really no way to run a railroad. It definitely isn't <a href="http://allcritiquesgreatandsmall.blogspot.com/2011/11/plan-like-theres-no-tomorrow.html">planning like there's no tomorrow</a>, because you could easily end up with 3 top priority items for 3 different user types, and nothing to deliver for anyone. Importance by itself isn't enough to determine coherence.<br />
<br />
What I teach now is to create <b>scenario backlogs</b>. A scenario backlog is the set of user stories needed to support a complete user scenario. Until you have complete
scenarios working, you have no demo, and not much you can use to get
validated learning. An example I used in my fall class on mobile app development was an "exercise buddy" that would let a user create sets of exercise routines. The user could then "run" a workout, and the app would call out the steps for the user to do. There are a number of user scenarios needed for the MVP:<br />
<ul>
<li>End user starts the app and selects a workout. App calls out the steps for each subroutine in a workout set, switching automatically, and logging the workout in a diary at the end.</li>
<li>End user reviews and modifies the workout, including getting new routines from the server.</li>
<li>Trainers partnered with the app developers create routines on the server for end users to download.</li>
</ul>
(Don't push me on this. The only exercise I do is hyperventilating if you count that as aerobics.)<br />
<br />
If you look at must-haves, there are plenty, from the calling out of workout steps to the server-side entry of expert-designed routines. If you just pick must-haves for an iteration, you don't get much guidance.<br />
<br />
Instead, prioritize scenarios. Which scenario will determine whether this is a viable product? I think the answer is clearly the first scenario. If no one wants to use their phone to direct their workout, don't even bother with the rest.<br />
<br />
Make a scenario backlog consisting of all the stories needed to make the first scenario work for real. We don't need to support editing workouts, or entering routines on the server. We make a canned workout routine and get all the text to speech and timing and so on working.<br />
<br />
Work on just those stories, over one or more iterations, simplifying when possible. When done, you can start doing some real user testing and find out what else people want, like maybe responding to "pause" or "repeat" verbal commands, or music.<br />
<br />
While validated learning is happening, work on the next most important scenario. <br />
<br />
The nice thing about a scenario backlog is that a scenario provides coherent comprehensible contexts for writing acceptance tests and for deciding what the simplest thing is that could possibly work.<br />
<br />
<br />Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com1tag:blogger.com,1999:blog-2600596044314007562.post-82794816356420414802011-11-21T09:32:00.001-08:002011-11-21T09:45:20.708-08:00Plan like there's no tomorrowA mistake I see a lot when I'm coaching client/managers on developing release and iteration plans is delaying some of the most valuable stories until the 2nd or 3rd iteration. This is in a course project with only 4 iterations to begin with!<br />
<br />
I think it arises from being used to creating schedules to fill the time allotted to the project. You know you can't do everything at once, so you take the pile of valuable stuff and spread it out. With enough repetition of the MVP mantra, they get the idea that they need to think small and high value, but that just reduces the size of the pile, not the urge to spread things out.<br />
<br />
So I tell them "plan like there's no tomorrow." Assume the project has been cancelled. This is your last iteration. What do you put in it to get the most value you can in this final turn? If you really take seriously the idea that this is all you get to do, you start creating an iteration plan that takes thin slices of value from those later iterations. Pack in all the goodies that your developers are willing to commit to, just not as complete and fancy as you'd hoped those goodies would be.<br />
<br />
The danger of planning for the future is trusting that the future will still be there. So plan like there isn't a future.Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-76395893270154401682011-10-06T09:42:00.000-07:002011-10-06T09:42:47.842-07:00Sometimes it's not what you slice, but whoI push slices a lot in my lectures on development. Whether it's for determining a minimum viable product, or breaking things down into testable releases, you can't be too thin. <a href="http://alistair.cockburn.us/Elephant+carpaccio">Elephant carpaccio</a> as Cockburn says. <br />
<br />
But slicing what you build is not the only place to look. Sometimes, it's important to think about slicing your target users. I was just hearing about a project rollout in crisis in a large enterprise because of the number and variety of users who need to be updated. It's basically your classic updating of the base level enterprise operating systems and all the attendant applications that affects. <br />
<br />
Mass rollouts are famous for, if not failure, at least a lot of grief and midnight oil expenditures. If it hurts when you do that, don't do that! Slice the rollout. But just as you have to think about how to slice a product, so that you don't <a href="http://www.blogger.com/blogger.g?blogID=2600596044314007562#editor/target=post;postID=5389084707288978413">slice out the important part of the product</a>, so too you need to think about how to slice your initial targets. Doing it division by division or region by region is as bad if not worse than a mass rollout. The first division in line gets all the bugs and missteps, often becomes disconnected from the rest of the company, and rightly feels like a lab rat.<br />
<br />
Instead, look for the small audience that would be OK with glitches in the change process. What group really really wants this change, or what group is pretty tech-savvy and hence likely to find workarounds give useful reports on what's broken?<br />
<br />
Don't stop with one slice. "We had a pilot rollout, now we're going live everywhere." Pilot groups are never representative of the total audience. Even if your initial slice was not a tech-savvy group, they knew they were in an experiment and almost certainly gave you the benefit of the doubt. That's not going to be true of everyone else.<br />
<br />
Instead, you need to keep slicing. There are many criteria for the next slice. It might be the next group who most wants the change. It might be the group your first group interacts with the most. It might be the group that's most concerned about the change. Why that last group? Because at this point you can still afford to give them the extra attention and handholding they need at this. Plus you find out what the worst case reactions and snafus are.Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-72456287942582543222011-09-07T12:07:00.000-07:002011-09-09T06:54:36.080-07:00Designing CS101: From Causes to Learning ObstaclesLet's recap <a href="http://www.cs.northwestern.edu/%7Eriesbeck/gbs/gbs-design.html">the process of designing a learning experience</a> for introducing computer science to non-CS students. <a href="http://www.cs.northwestern.edu/%7Eriesbeck/gbs/gbs-design.html#q1">What mistake is the target audience making that they care about</a>? I chose "<a href="http://allcritiquesgreatandsmall.blogspot.com/2011/03/failure-driven-course-design.html">many people are missing out on a satisfying career</a>." <a href="http://www.cs.northwestern.edu/%7Eriesbeck/gbs/gbs-design.html#q2">Why do they make this mistake</a>? There are many causes, especially sociological ones, but I chose "<a href="http://allcritiquesgreatandsmall.blogspot.com/2011/04/from-failure-to-causes-in-course-design.html">people don't get to see what computer scientists actually do</a>." They may take a programming course, often with "exciting" assignments like printing an amortization table. They may someone in a movie or TV show rapidly typing cryptic text on a computer screen. They may get to take a course programming games or robots. Unfortunately, none of these are accurate depictions of <a href="http://academicearth.org/lectures/what-do-comp-scientists-do">what we spend our days doing in CS</a>, namely coming up with new ideas for old problems, or even better, new problems. For me, the neat part of CS is that I get to come up with ideas that may change the world. I can do it with surprisingly small resources, compared to other transformational disciplines like medical research.<br />
<br />
Sp now the question is to identify <a href="http://www.cs.northwestern.edu/%7Eriesbeck/gbs/gbs-design.html#q3">why a learning experience is needed</a>. You don't need course for walking, ordering food in a restaurant, going to school, playing videogames, etc. You learn these and many other things by watching other people do it, and/or trying to do it yourself and learning from failure. We only need courses when this natural process doesn't work. That might be because there's no one to watch, e.g., a master violinist practicing techniques, or learning from failure is not an option, e.g., brain surgery, or a handful of other reasons.<br />
<br />
So why don't people learn what computer scientists really do naturally? I think it's pretty clear that it's because there's no opportunity. Most people don't mix with computer scientists doing their job. TV doesn't show it because there's nothing to watch. An intro programming course doesn't help, because programming, while critically important, is not the career. If you don't get people to understand being a doctor or medical researcher by making them take an anatomy course!<br />
<br />
So I'm going to answer the third question with this: "people don't get to see what CS is really like simply because there's no opportunity to be exposed to people doing CS."Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-23360287532222363922011-07-11T12:31:00.000-07:002011-09-09T06:57:41.671-07:00Fear of failureJonathan Rasmussen in <a href="http://agilewarrior.wordpress.com/2011/07/10/love-it-when-youre-proven-wrong/">Love it when you're proven wrong</a> argues for the benefits of being proven wrong. As a strong advocate of learning from failure, I can't argue with the benefits.<br />
<br />
Furthermore, fear of failure is a big problem in agile teams. It occurred in 17 of 17 organizations surveyed in <a href="http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2011/0711/W_SW_PeopleoverProcess.pdf">People over Process</a> (PDF) by Conboy et al. in the July/August 2011 IEEE Software. [One of the best such survey articles I've seen by the way. Seek it out for that and the other 8 challenges they discovered.]<br />
<br />
But I don't think seeing the learning benefits addresses the real problem. The big negatives of being wrong are <span style="font-weight: bold;">social</span> -- embarrassment, loss of face, loss of future ability to influence decisions, etc. The individual cognitive gains of learning from failure are swamped by the perceived social costs.<br />
<br />
That's why to enable learning from failure in my courses, I have most learning occur in private extended homework activities and one-on-one in-depth critiquing exchanges.<br />
<br />
Getting team members to embrace individual failure without negative consequences is really hard. If only we could get developer teams to emulate improv groups. In <a href="http://www.northwestern.edu/magazine/winter2010/feature/the-real-stephen-colbert_print.html">a profile in the Northwestern alumni magazine</a>, Stephen Colbert described the event that clinched for him why he wanted to work in comedy and improv, not serious theater.<br />
<blockquote>
I saw someone fail onstage — terribly, <i>massively</i> fail onstage,” Colbert recalls. “And we backstage laughed so hard at this woman’s failure, and our laughter was so joyful and not derisive. I remember turning to a friend of mine, Dave Razowsky, and we threw our arms out wide and hugged each other in laughter and literally fell to the ground in each other’s arms over the <i>joy</i> of that <i>failure</i>.</blockquote>
Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com1tag:blogger.com,1999:blog-2600596044314007562.post-15550071606332483512011-05-13T13:10:00.000-07:002011-09-09T06:57:32.306-07:005 Whys, Harder than it looks, Part 1: What's a Failure?An exercise I gave <a href="http://www.cs.northwestern.edu/academics/courses/394/">my software project management class</a> at Northwestern this year is doing 5 Whys process improvement analysis, as in <a href="http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2296">this video</a> and <a href="http://www.startuplessonslearned.com/2008/11/five-whys.html">essay</a> from Eric Ries. I also strongly recommend Tony Ford's <a href="http://www.slideshare.net/tony4d/tech-talk-thefivewhys20110301public">experience report</a> and <a href="http://www.ign.com/blogs/ign-tech/2011/02/17/blogs-outage-and-five-whys/">example analysis</a>.<br />
<br />
<div>
There were three parts to the exercise:</div>
<ul>
<li>identifying some key failures</li>
<li>developing a 5 Whys causal chain for each failure</li>
<li>proposing process improvements to address each step in each chain</li>
</ul>
<div>
I showed the Ries video, assigned the Ries essay, and then had them do similar analyses on several failures in the project they had just finished. I did these as <a href="http://allcritiquesgreatandsmall.blogspot.com/2010/06/critique-based-assessment.html">critiqued exercises</a>, figuring that it would take a few iterations to get right. I was right about the need for iterations, way off on the "few" part. Each part has been quite hard for most of the students. </div>
<div>
<br /></div>
<div>
First up:</div>
<h3>
What is a 5YA failure?</h3>
<div>
A project has lots of failures, but only some are appropriate for a 5 Whys analysis. Both Ries and Ford uses examples involving some form of web site failure. Here are some of the things my students submitted and the critiques they got. There were many similar examples of each type of problem.</div>
<ul>
<li>Our team had to implement image upload three times</li>
</ul>
<div>
I classify ones like this as as "bad choices led to rework." Clearly something you'd like to avoid in the future, but is it a 5YA (5 Why Appropriate) failure? I say no, because there's no user story failure. A 5YA failure is a <b>user failure</b>, like "the web site crashed" or "the search function returned 'page not found' errors." Without knowing what user stories were impacted and how (broken, missing, slow, ....), you have no idea how to prioritize the importance of the failure and therefore how much effort to expend in trying to avoid it in the future. Furthermore, making things run smoother is much less motivating than avoiding embarrassing public failures. </div>
<ul>
<li>Our client changed the design of the website twice</li>
</ul>
There were a lot of these "requirement changes led to rework." This has three fundamental things wrong with it. The first problem is the same as the previous example. There's no specific user story impact. Second, this is not a developer failure. You can't fix what you can't control. What you need to fix is how your process handles the things you don't control. It's not a 5YA failure if your cloud service dies. It is a 5YA failure if you have no backup. Third, and most important, this may not even be a failure at all. Iterating on designs is a good thing, if driven by actual usage. The whole point of agile is that it's impossible to get it all correct up front. The corollary is that sometimes we'll get it wrong. That's not a failure. That's life.<br />
<div>
<div>
<ul>
<li>XXX was working on a fork of the repository so almost none of his code got integrated</li>
</ul>
<div>
I leave what's wrong here as an exercise for the reader. It's one of the points already made.</div>
<ul>
<li>The code XXX submitted for "index" view of the "projects" controller didn't work</li>
<li>Buggy and totally non-working code was checked in</li>
</ul>
These are just way too broad and non-specific. "Didn't work" doesn't distinguish "nothing happened" from "wrong results" from "error page appeared." The devil is in the details. Ignore those details and the devil remains. Trying to fix the problem "code is buggy" leads to ineffective measures like "test more!" and expensive ineffective measures like "everyone goes to Java camp this summer!" How the user story actually breaks leads to very different analyses, responses and priorities.</div>
<h3>
A 5YA failure is a bug report</h3>
<div>
My final recommendation for my class was that a 5YA failure should be writable as a bug report. That is, it should be put in the form "when a [user-type] does [action], [failure event] occurs." Failure events should distinguish between nothing happening, the wrong things being return, errors being returned, and so on.</div>
<br />
<br /></div>
Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0tag:blogger.com,1999:blog-2600596044314007562.post-37049367664552226382011-04-26T12:22:00.000-07:002011-09-09T06:54:53.318-07:00Designing CS101: From Failure to CausesSo far, <a href="http://allcritiquesgreatandsmall.blogspot.com/2011/03/failure-driven-course-design.html">I've argued</a> that the goal for a CS principles course that makes the most sense is to deal with the failure "students who don't know what CS is about miss out on a chance to find a career they'll really enjoy in software development or computer science."<br />
<br />
<a href="http://www.cs.northwestern.edu/%7Eriesbeck/gbs/gbs-design.html#q2">The next question</a> then is "Why do they make this mistake?" There's a lot of data on this, particularly for females and minorities, e.g., to pick one pretty much at random, <a href="http://jite.org/documents/Vol9/JITEv9p115-131Buzzetto808.pdf">this survey-based study</a>. In this study as in many others, the usual reasons given for not pursuing computer science is that it's too hard and computers are boring. Other studies and articles have focused on beliefs that computer science is all about programming and that that is a solitary activity. Yet others have focused on the presence of role models, again particularly for females and minorities, and the image (or lack thereof) of computer science in the popular media.<br />
<br />
I have my doubts about that last one. Female hackers have been a staple on <a href="http://www.imdb.com/title/tt0285331/">24</a>, <a href="http://www.imdb.com/title/tt0364845/">NCIS</a>, <a href="http://www.imdb.com/title/tt1132290/">Warehouse 13</a>, and elsewhere for some time. These reinforce the nerdy image but are otherwise very positive and emphasize membership in a working group over being a loner.<br />
<br />
What about the perception that CS is about programming and programming is boring. Are those beliefs wrong?<br />
<br />
One approach has been to make programming more fun. <a href="http://www.alice.org/">Alice</a>. <a href="http://scratch.mit.edu/">Scratch</a>. <a href="http://www.amazon.com/Introduction-Computing-Programming-Multimedia-Approach/dp/0131176552">Computing and Multimedia</a>. I love these but so far I've not seen them move past the introductory level and hit the place where most agree real CS begins: algorithms and data structures. This also doesn't address the issue of what you do in CS.<br />
<br />
Another approach is to skip the programming and go straight to <a href="http://csprinciples.org/">the big ideas</a>. That's what started this series of blog entries. But if the goal is to show that CS is an interesting career, then it' s not the ideas students need to see. That's like thinking a biology course introduces you to what biologists do. Students need to see and try doing things that accurately reflect what computer scientists actually do. What fills their days? What makes them want to come to work? What's a moment of joy?<br />
<br />
So, my conclusion is that students misunderstand what people do in CS, besides programming, because they've never seen it done nor had a chance to try doing it, particularly pre-college. In this, CS isn't really different than math or biology or many other fields. Most education is badly constructed around facts and ideas rather than skills and activities. If there was a glut of computer scientists, this wouldn't matter, but as far as most U.S. companies and the government are concerned, we have a growing shortage.<br />
<br />
On to question 3!Chris Riesbeckhttp://www.blogger.com/profile/09361434968521805027noreply@blogger.com0