Food Truck
Occupational Licensing
SupremeCourt attack?
My Product Development Process
Agility Vs Conflict
Bottle Neck

Venkatesh Rao asks: In Stephen Covey’s famous important/urgent 2×2 diagram, why is the Not Important/Not Urgent quadrant even there (other than for geometric completeness)? If you’ve always got things going on, the other three quadrants always trump the NI/NU quadrant after all, so do things in it ever get done? Do they need to? (Time Management)

I claim that the critical NI/NU stuff is stuff that usually only gets done when it moves to one of the other quadrants.

Three Examples of Jumps:

  • An example of NI/NU jumping to NI/U is making a will. (Personal Finance)

  • An example of a jump from NI/NU to I/U is a slovenly and unsuccessful screenwriter who spends all his time being unshaven and smelly and living off pizza and beer. His face is riddled with acne and he has BO. Then one day he gets a call from Steven Spielberg expressing interest in one of his scripts and asking for a meeting the following week.

  • For an example of NI/NU jumping to I/NU, consider a workaholic who neglects his health and works 100-hour weeks throughout his twenties. Assume he was healthy and fit at 22, leaving college. At some point, he faces diminishing returns from the obsessive workaholism, gains weight, loses endurance and in general, begins to falter. At this point, investing in health, which was previously NI/NU when he was living off a youthful reserve of robust health, becomes important. It is now the Bottle Neck preventing him from functioning at the next level.

The key to processing the NI/NU quadrant is to separate the potentially important and/or urgent stuff from the native stuff that will never leave the quadrant... I find it useful to draw a diagonal slash through the NI/NU quadrant like so, and maintain a separate awareness of the Potentially Important/Potentially Urgent stuff. This is stuff around which I like to maintain high situation awareness. Minor shifts in the state of play could affect these items.

z2012-07-03- Rao Not Important Not Urgent Tasks
Phoenix Project
Theory Of Constraints
Elizabeth Warren

Fearing he wouldn't be able to get her confirmed for a real appointment, Barack Obama gave Elizabeth Warren an interim appointment to lead the new Consumer Financial Protection Bureau. Under a White House plan, Ms. Warren would become an assistant to the president and a special adviser to the Treasury secretary responsible for overseeing creation of the bureau, which was established in the sweeping financial overhaul measure signed in July.

Update: Reportedly convinced that Warren could not win Senate confirmation as the bureau's first director,[47] Obama turned to former Ohio Attorney General Richard Cordray and in January 2012, over the objections of Republican Senators, appointed Cordray to the post in a recess appointment.

z2010-09-18- Warren Consumer Protection Half Appointment
Growing Your Startup Tech Product Team
Jon Stewart

Fifty Three, the team behind the critically acclaimed Paper Sketch Ing app, has raised a $30 million Series B round led by Dayna Grayson of New Enterprise Associates (NEA). Georg Pettschnigg, Fifty Three's CEO and co-founder, says the new round of funding will help jump-start Fifty Three's move into the Enter Prise space, where he hopes the creative tools that made Paper popular can also revolutionize the kind of productivity typically done on the office White Board.

z2015-03-17- Paper Funding For Whiteboard
Jez Humble
Continuous Delivery
Development Queue
Critical Chain

John Hagel sketches a FAST Business Strategy process. FAST = FocUs, Accelerate, Strengthen, Tie It All Together. This approach urges executives to move along parallel paths, operating on two very different time horizons: one horizon takes a five to ten year view of the business and the second horizon zooms in to a much more tactical six to twelve month view of the business. The one to five year horizon that is so loved by traditional business strategists actually receives very little attention in the FAST approach... FoCus is the key activity on the five to ten year horizon. This requires senior management to develop a common view on two key questions for their business. Five to ten years from now, what will the markets that we participate in look like? Then, what kind of business we will need to have in order to continue to create value in these markets?... On the six to twelve month horizon, Accelerate and Strengthen are the key requirements. By Accelerate, I mean identifying a few key operating initiatives that have the potential to significantly accelerate the movement of the company towards the long-term Focus.... On the same time horizon, Strengthen also comes into play. Here, management needs to ask, what are the major organizational obstacles that are preventing us from moving even faster to achieve our operational objectives? Then the question becomes, what can be done over the next six to twelve months to "de-Bottle Neck" the organization and strengthen our organizational capabilities so that we can move even faster in the next six to twelve month cycle?... Tie it all together integrates these three streams of activities... Few companies today have adopted anything like a FAST strategy approach. You can use five questions to determine whether a company is pursuing this approach... The FAST strategy approach provides a robust framework for incremental (and Iterat Ive) Innovat Ion.

z2006-12-13- Hagel Fast Strategy
Wiki For Collaboration Ware
Collaboration Ware
Estimat Ing

Phil Jones is working on Mind Traffic Control, a ToDoList built on Google App Engine.

Update: he prefers to call it a "to-do queue". (cf Development Queue)

z2008-05-10- Jones Mind Traffic Control
Prioritizing Projects

Steve Yegge on Good-and-Bad Agile Software Development, and Project Management/Product Management at GooGle. Well, people pretty quickly demonstrated that XP was a load of crap. Take Pair Programming, for instance. It's one of the more spectacular failures of XP. None of the Agileytes likes to talk about it much, but let's face it: nobody does it... One of the (many) problems with Bad Agile is that they condescendingly lump all non-Agile development practices together into two buckets: Water Fall and CowBoy. Waterfall is known to be bad; I hope we can just take that as an axiom today. But what about so-called CowBoy programming, which the Agileers define as "each member of the team does what he or she thinks is best"? Is it true that this is the only other development process? And is Cowboy Programming actually bad? They say it as if it's obviously bad, but they're not super clear on how or why, other than to assert that it's, you know, "chaos".

First, and arguably most importantly, Google drives behavior through incentives... The thing that drives the right behavior at Google, more than anything else, more than all the other things combined, is gratitude... The basic idea behind Project Management is that you drive a project to completion. It's an overt process, a shepherding: by dint of leadership, and organization, and sheer force of will, you cause something to happen that wouldn't otherwise have happened on its own... We do have project managers and product managers and people managers and tech leads and so on. But the amount of energy they need to add to the system is far less than what's typically needed in our industry. It's more of an occasional nudge than a full-fledged continuous push... Incidentally, Google is a polite company, so there's no yelling, nor wailing and gnashing of teeth, nor escalation and finger-pointing, nor any of the artifacts produced at companies where senior management yells a lot... All your needs are taken care of so that you can focus, and as I've described, there are lots of incentives for focusing on things that Google likes. So launches become an EmergEnt property of the system... This eliminates the need for a bunch of standard project management ideas and methods: all the ones concerned with dealing with slackers, calling bluffs on estimates, forcing people to come to consensus on shared design issues, and so on... Google isn't the only place where projects are run this way. Two other kinds of organizations leap to mind when you think of Google's approach: StartUp companies, and Grad School-s.

Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about.

Google is unquestionably driven by time, in the sense that they want things done "as fast as possible". They have many fierce, brilliant competitors, and they have to slake their thirsty investors' need for growth, and each of us has some long-term plans and deliverables we'd like to see come to fruition in our lifetimes. The difference is that Google isn't foolish enough or presumptuous enough to claim to know how long stuff should take (No Estimates). So the only company-wide dates I'm ever aware of are the ends of each quarter, because everyone's scrambling to get on that big launch screen and get the applause and gifts and bonuses and team trips and all the other good that comes of launching things with big impact at Google. (PlannIng)

Then all you need is a Work Queue (Development Queue). That's it. You want hand-wavy math? I've got it in abundance: software development modeled on queuing theory. Not too far off the mark, though; many folks in our industry have noticed that organizational models are a lot like software models. With nothing more than a work queue (a priority queue, of course), you immediately attain most of the supposedly magical benefits of Agile Methodologies. And make no mistake, it's better to have it in software than on a bunch of Index Card-s. If you're not convinced, then I will steal your index cards.

Related: interesting Fortune Mag article on management at GooGle, with some focus on Shona Brown, the senior vice president for business operations who wrote Competing On The Edge: Strategy as Structured Chaos back in 1998 (Edge Of Chaos?). Brown runs a SWAT team of 25 strategic consultants who are loaned out internally on ten or so projects at a time - restructuring a regional sales force here, guesstimating a market size there. The company's goal, says Brown, is to determine precisely the amount of management it needs - and then use a little bit less.

z2006-10-02- Yegge Agile Google
Issue Tracker

Jorge Aranda notes A critique from Alistair Cockburn on how the Agile Software Development movement is under attack from Taylor Ism led me to an essay by DaveWest on the philosophical incompatibilities between Lean Development and agile techniques, and this in turn led me to finally give a read to Peter Naur’s 1985 text, “Programming as Theory Building.”.. Naur’s programmer’s theories are essentially Mental Model-s in the sense I (and many others before me) present them, and both he and I claim that the overarching goal of a software development organization is to build those models (or theories) during the life of the project. I could actually restate my thesis contributions as extensions to Naur’s sketch in two ways: first, I explore what I think is the main challenge that software team members find today: to build consistent mental models (or in the terms of the thesis, to develop a shared understanding (Shared Language)) of the world, among potentially large groups of people, in the face of abundant, shifting, and tacit information, and unclear or exploratory goals. Second, I outline some attributes of team interaction (TeamWork) that make such a challenge easier to overcome.

DaveWest's essay is titled: Lean and Agile: Marriage Made in Heaven or Oxymoron?: Lean and Agile are grounded in fundamentally different World View-s and therefore will inevitably find themselves in opposition on critical points... Production and process vocabulary and metaphors are pervasive throughout the entire (Lean Development) book. Although there is a clear rejection of 19th century ideas about production (e.g. Taylor Ism) there is an equally clear adoption of enlightened production models (e.g. the ToyOta production model)... The observable activities associated with Theory Building include telling a lot of stories, exploring ideas, trying things to see if they work, testing your understanding, populating your physical space with evocative reminders of your understanding, and doing these things iteratively in increasingly comprehensive increments. Looks a lot like an agile environment, but bears little resemblance to a production environment.

z2011-04-20- Lean Agile Production Vs Theory Building
Minimum Viable Product
Theory Building
Hypothes Is
Innovators Solution
Taylor Ism
Lean Development
Mary Poppendieck

Mary Poppendieck sees serious confusion about the ScruM role of Product Owner and its fit with the classic role of Product Manager... In this company, the Product Managers found it impossible to handle both the customer-facing and team-facing jobs at the same time. So most teams had added an additional person to assist the Product Manager by preparing stories for the team, and called this person the Product Owner. The job of these Product Owners resembled the classic role of business analyst... Critical tradeoffs between business and technical issues often fell to these Scrum Product Owners, yet they had neither the first hand customer knowledge nor the in-depth technical knowledge to make such decisions wisely... Product Managers who lack the time, training, or temperament to handle both the customer-facing and the team-facing responsibilities of software development have two options. They can appoint Scrum Product Owners for each development team, or they can provide high-level guidance to a development team capable of designing the product and setting its own priorities. We observe that the second option generally works better, because an intermediary Product Owner brings a single perspective and limited time to the complex job of designing a product... The entire team needs to be part of the design decision process. Team members should have the level of knowledge of the problems and opportunities being addressed necessary for them to contribute their unique perspective to the product design.

z2010-12-23- Poppendieck Product Owner Problem
Market Distortion
OccupationalLicensin g
Trade Guild
Credential Ism
How To Raise Reality Hackers
Average Is Over
Intern Ship

Robin Marantz Heng asks: Why are so many people in their 20s taking so long to grow up? (Adult Hood) The traditional cycle seems to have gone off course, as young people remain un tethered to romantic partners or to permanent homes, going back to school for lack of better options, traveling, avoiding commitments, competing ferociously for unpaid Intern Ship-s or temporary (and often grueling) Teach for America jobs, forestalling the beginning of adult life. (The Family, Life Cycle)

Sociologists traditionally define the “transition to adulthood” as marked by five milestones: completing school, leaving home, becoming financially independent, marrying and having a child. In 1960, 77 percent of women and 65 percent of men had, by the time they reached 30, passed all five milestones. Among 30-year-olds in 2000, according to data from the United States Census Bureau, fewer than half of the women and one-third of the men had done so.

Jeffrey Jensen Arnett says what is happening now is analogous to what happened a century ago, when social and economic changes helped create Adolesc Ence — a stage we take for granted but one that had to be recognized by psychologists, accepted by society and accommodated by institutions that served the young... An understanding of the developmental profile of adolescence led, for instance, to the creation of junior high schools (Middle School) in the early 1900s, separating seventh and eighth graders from the younger children in what used to be called primary school. And it led to the recognition that teenagers between 14 and 18, even though they were legally minors, were mature enough to make their own choice of legal guardian in the event of their parents’ deaths.

z2010-09-01- Henig Adulthood20 Somethings
Coming Apart

Studies have illustrated that crime and delinquency, education, psychological distress, and various health problems, among many other issues, are affected by Neighbor Hood characteristics. Thresholds, or Tipping Point-s, also prove important. In a recent review of research, Galster notes that studies suggest “that the independent impacts of neighborhood PoverTy rates in encouraging negative outcomes for individuals like crime, school leaving, and duration of poverty spells appear to be nil unless the neighborhood exceeds about 20 percent poverty, whereupon the externality effects grow rapidly until the neighborhood reaches approximately 40 percent poverty; subsequent increases in the poverty population appear to have no marginal effect.”

z2011-03-15- Neighborhood Poverty
Charles Murray

Charles Murray has a new book coming out: Coming Apart: The State of White America, 1960-2010 978-0-307-45342-6

z2012-02-02- Murray Coming Apart Book

This is a copy of an email I just received from Number Two Son's fifth-grade (Elementary School) teacher - this is Barrington Il's Public School TAG program. I think it captures the awesomeness of the Self Contained program there... (see also z2009-10-15-BarringtonTag)

Good Monday Morning! And a beautiful day it is. Today, students will take the MAP math test in the afternoon, and they will take the MAP reading test on Wednesday morning. The students take an off-level test - meaning they start at the middle school level. I can talk more about this at conferences - or send me an email if you want more information. The students have been reading short biographies about artists, and on Friday, they will choose which artist they will study more in depth. We will be having an ART FAIR on October 27 - so save the evening! Your child will bring home more details on Thursday. (They created a piece of art in the style of their chosen artist, then for the ArtFair dressed up as the artist and explained their work/life to clusters of parents wandering through the "gallery".) This week we'll learn about fingerprinting and do some activities - we'll also be learning about secret codes in math. We'll be working on new leads for writing and using similes to good effect. We'll be reading Chasing Vermeer and learning more about Vermeer, stolen art, and Alexander Calder in connection to the mystery. Ask your child to tell you at least three things they learned in school each day!

This morning (we) put a SPECIAL POSTCARD in the mail to each child. Please look for it and be sure that your child reads it and brings it to school on Friday. They are not supposed to talk about it with any other student. It's a BIG secret. They'll be using the coded message on their card to put together clues with other students in order to solve a"mystery" here at school that will result in a fun treat!

Also - on Friday afternoon, we'll be making mobiles in the style of A. Calder and would welcome parent help. There are a lot of little strings to tie and we know from experience that a lot of the kids have trouble with that. We'll start the mobiles at about 1:20 - so if you can come then - we'd really appreciate it. We think the mobiles will take about an hour to make.

Mar'2015: same class just did this "Invention Convention" project.

z2010-09-13- Barrington Tag Snapshot
Mind Wide Open
Sugata Mitra
#01 update on SOLE network
Bryan Caplan
Bell Curve

The shooting of Michael Brown occurred on August 9, 2014, in Ferguson Mo, a suburb of St. Louis. Brown, a young black man, was fatally shot by Darren Wilson, a white PolIce officer. The disputed circumstances of the shooting of an unarmed man and the resultant protests and civil disorder received considerable attention in the United States and abroad.

The day after the shooting, local and national leadership planned a vigil and other responses. On the evening of August 10, police tried to break up the crowd, and some protesters responded violently, looting various stores in the neighborhood, including a QuikTrip.

Protests and rioting lasted for over 2 weeks. As the details of the original shooting event emerged from investigators, police established curfews and deployed riot squads to maintain order... On August 13, while police were clearing a McDonald's restaurant, The Washington Post reporter Wesley Lowery and The Huffington Post reporter Ryan Reilley were arrested... Al Jazeera America Journal Ist-s covering the protests in Ferguson on Wednesday night were also tear-gassed and shot at with rubber bullets by a police SWAT team. Along with peaceful protests, there was looting and violent unrest in the vicinity of the original shooting. Widespread media coverage examined the post-9/11 trend of police militarization (SWAT) when dealing with protests... The Justice Department will investigate Ferguson police force for possible misconduct or discrimination.

But a revealing vote this past June shows just how uphill the battle is to stop the trend of turning police into soldiers. On June 19, progressive House Democrat Alan Grayson (FL) offered an amendment to the defense appropriations bill that would block the “transfer” of “aircraft (including unmanned aerial vehicles), armored vehicles, grenade launchers, silencers, toxicological agents, launch vehicles, guided missiles, ballistic missiles” from the Department of Defense to state and local police forces. The amendment attracted the support of only 62 members, while 355 voted against it (14 didn’t vote). Included among those voting against it was Rep. William Lacy Clay (D), who represents Ferguson. Clay was joined by every senior member of the Democratic Party leadership team, including Reps. Nancy Pelosi (CA), Steny Hoyer (MD), and Assistant Democratic Leader James Clyburn (SC).

Sept05: Rep. Hank Johnson has set his sights on reforming the Department of Defense’s 1033 Program, the mechanism through which local law enforcement agencies can request and obtain military surplus equipment.

  • Sept16: Hank Johnson and Raul Labrador’s bill, the Stop Militarizing Law Enforcement Act has already received support from numerous legislators on both sides of the aisle.

Mar04'2015: Darren Wilson will not be charged by the Justice Department. Jonathan Capehart summarizes: What DOJ found made me ill. Wilson knew about the theft of the cigarillos from the convenience store and had a description of the suspects. Brown fought with the officer and tried to take his gun. And the popular hands-up storyline, which isn’t corroborated by ballistic and DNA evidence and multiple witness statements, was perpetuated by Witness 101. In fact, just about everything said to the media by Witness 101, whom we all know as Dorian Johnson, the friend with Brown that day, was not supported by the evidence and other witness statements.

  • But a wider report was severely critical of the entire system.

Mar11'2015: 3 officials, including the chief of police, have resigned since the Justice Department's report.

z2013-08-11- Brown Killed By Ferguson Police

Sept'2014: Giles Bowkett on ScruM. Scrum, the Agile methodology allegedly favored by Google and Spotify, is a mess... Consider Story Points... If it had a name, this informal (Planning Poker) game would be called something like "the person with the highest status tells everybody else what the number is going to be.".. Planning Poker isn't the only aspect of Scrum which, in my experience, seems to consistently devolve into something less useful. Another core piece of Scrum is the Standup Meeting... I've twice seen the "15-minute standup" devolve into half-hour or hour-long meetings where everybody stands, except for management... At this second company, virtually everything landed in the parking lot, and it became normal for the 15-minute standup to be a 15-minute prelude to a much longer meeting... Scrum's ready devolution springs from major conceptual flaws... there's a fundamental cognitive dissonance between "sprints" and "sustainable development," because there is no such thing as a sustainable sprint... Another core idea of the Agile Manifesto, the allegedly defining document for Agile development methodologies: "working software is the primary measure of progress." Scrum disregards this idea in favor of a measure of progress called "velocity.".. Story points, meanwhile, are completely made-up numbers designed to capture off-the-cuff estimates of relative difficulty. Developers are explicitly encouraged to think of story points as non-binding numbers, yet velocity turns those non-binding estimates into a number they can be held accountable for... If you're tracking velocity, your best-case scenario will be that management realizes it means nothing... I don't think highly of Scrum, but the problem here goes deeper. The Agile Manifesto is flawed too. Consider this core principle of Agile development: "business people and developers must work together." Why are we supposed to think developers are not business people?.. The Agile Manifesto might also be to blame for the Scrum standup. It states that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation." In fairness to the manifesto's authors, it was written in 2001, and at that time git log did not yet exist. However, in light of today's toolset for distributed collaboration, it's another completely implausible assertion, and even back in 2001 you had to kind of pretend you'd never heard of Linux if you really wanted it to make sense. Well-written text very often trumps face-to-face communication... In addition to defying logic and available evidence, both these Agile Manifesto principles encourage a kind of babysitting mentality. I've never seen Scrum-like frameworks for transmuting the work of designers, marketers, or accountants into cartoonish oversimplifications like story points. People are happy to treat these workers as adults and trust them to do their jobs. I don't know why this same trust does not prevail in the culture of managing programmers.

And a follow-up. I'm hoping to find out more, later, about what it's like when you're on a Scrum team and it actually works. To be fair, not every Scrum experience I've had has been a nightmare of dysfunction; I just think the successes owe more to the teams involved than to the process... Of all the criticisms of my blog post that I saw, literally every single one overlooked what is, in my opinion, my most important criticism of Scrum: that its worst aspects stem from flaws in the Agile Manifesto itself... The Agile Manifesto existed because developers and consultants had begun to recognize that many ideas in tech management were unnecessary, inessential historical relics... In many industries, companies just do not need to have synchrony or co-location any longer (Distributed Team). This is an incredible development which will change the world forever. Do not expect the world of work to look the same in 20 years. It will not.

Feb20: Ron Jeffries responds. My first reaction, instead, was to point out that almost none of the things Giles complained about are actually part of Scrum. They are, of course, things that people trying to use Scrum sometimes do... But still, is it unfair to expect the tool to be used wisely? Well, maybe not unfair, but perhaps unrealistic... I’ll wager Giles’s team’s Product Owner didn’t have that as their prime responsibility. I’d even put a little down that they didn’t have a real Product Owner at all. Three bloody roles, Scrum has, and only three. If you can’t get that right, don’t call it Scrum, OK?... I no longer recommend velocity, which means that I also no longer recommend story estimation in points or other measures (No Estimates).

Mar04'2015: Bowkett addresses Scrum again, but not apparently responding to Jeffries. Water Fall used too much written communication, but Agile doesn't use enough. (He's a big fan of GitHub.)

Mar04'2015: Bowkett responds to Jeffries. Scrum's a fad in software management, and all such fads go away sooner or later. The most embarassing part of this fracas was that, while my older followers took it seriously, my younger followers thought the whole topic was a joke. Velocity is, in my own working life, less "going away" than "already gone for years.".. The first time or two that I saw Scrum techniques fail, my teams were using them informally. I thought, "maybe we should be using the formal, complete version, if we want it to work." The next time I saw Scrum techniques fail, we got official Scrum training, but the company was already being mismanaged, so I thought, "maybe it doesn't matter how full or correct our implementation is, if the people at the top are messing it up." The next time after that, management was better, and the implementation was legit, but we were using a cumbersome piece of software to manage the process. So I thought, "maybe Scrum would work if we weren't using this software." Eventually, somebody said to me, "hey, maybe ScruM just doesn't work," and it made more sense than any of these prior theories.

z2015-03-04- Bowkett Jeffries Scrum Argue
No Estimates

Ron Jeffries says Estimat Ing is EVil. (No Estimates)

Teams applying Agile Software Development ideas almost always get some improvement... Teams that are getting good but not great results are our main concern here... these teams are often excessively concerned with estimation, and with living up to their estimates.

Does it surprise you to know that if a team has more work thrust upon it than they think they can accomplish, they generally fall short? It shouldn’t. Does it surprise you to know that it is common, only two weeks after someone pushed more work on them, that same someone expresses disappointment that the team has “broken its promise?” It shouldn’t... Teams that are asked to do more than they can do will say, “We’ll try.” And they will try. This rarely works out well. To be sure of getting done, they’ll begin to over-estimate everything. In order to get done quickly, they’ll cut back on important aspects of work you can’t see.

The Agile Manifesto calls for Working Software. Take the next problem, solve it with working software. Really solve it, which means getting that solution in the hands of the people who need it. It’s not about planning, predicting, and projecting. It’s about choosing, building, and providing.

It seems that “they” (Gold Owner) often want to know how long something is going to take, and how much it will cost. My view is that “they” don’t even know what they want, so we bloody well can’t possibly know how long it will take. However, “they” are often powerful and have the money we need, so we need to answer their question, even though we cannot... Most of the time, “they” know how many people they’ll give us, and how much time. They do that head-shaking thing until we “estimate” the numbers they have in mind. So we should turn the question around. “How much did you want to spend, and when did you hope to see the product?” Then they tell us, and we decide whether we can do something reasonable within that budget... It’s pretty much guaranteed to be wrong. But it might be large enough to let you get started, and start making fine-grained decisions on what to do next and what to defer. Do the Agile thing, producing a running system every couple of weeks... Why not have a full product that does very little at first (MVP), then more and more?

Get yourself a “customer” or “Product Owner” (Goal Donor) who can make decisions on what to do next and what to defer. Work in very short cycles. Two weeks. One week. One feature at a time, in two days. Short. Do features from most important to least. Every time a feature is done, or at least every two weeks, build an integrated, tested version of the software. Show it to everyone. If possible, get it to users who need it. If your software is slated to save lives, save some lives with it. Observe what happens. Factor that into what you do next. You’re shipping a complete product now, every week or two. When the deadline arrives, it’s just another shipment. If everyone is satisfied, and likely they will be, stop. If they want more, you’re all set to do more, every two weeks.

This approach shortens all the cycles that delay getting value. It shortens the communication lines between the people who want things and the people who do things. It shortens the communication lines between the people who create things and the people who use them. Take the most important ideas, build them quickly, get them out there.

This is the best anti-estimating thing I've read.

Apr03: ok maybe not evil? What we build is not solely the purview of some Product Overlord who decides what we’ll do and takes all the risk. The business people may make final calls, but many of the decisions are best made by the team—not just how to do things, but what to do. We do have a responsibility to help guide the project, using our creativity and our special knowledge... It’s true that many top teams do not estimate in any real sense of the term... it’s good to build up a team—and an organization—that is strong enough to work without estimation. But this is an advanced way to work, not the way to start. It’s not good to refuse to estimate, or even to resent it, in an organization where it’s needed. On the contrary, we need to learn to do it well, in a way that influences the organization positively.

Now, let’s look at just one legitimate need, helping the organization decide whether to go ahead with a project... Suppose we kind of think that maybe we could get a rudimentary but usable product in six months, and the investor is willing to invest up to about a million dollars to get to positive cash flow... We want to get our business people fully engaged in making live decisions about spending money based on what they see. So let’s get to thinking about feature selection, not just dates. “So let’s do this: Let’s take two weeks to produce a more concrete answer... “Yes, that’s right. Every two weeks we’ll talk with you about what to do next. We’ll do it and show it to you. If it’s good enough, we’ll continue. If not, we’ll stop. That way, your risk is never more than another $20,000.”... We estimate, with some certainty, that we can produce useful information in two weeks. If we think we can’t do it, we’d better suggest four or six or eight weeks. Furthermore, we estimate that a viable product is probably possible in six to nine months. If we have no idea, or worse yet, we sincerely doubt it, then we cannot legitimately invite him to find out—at least not in the terms above. We owe it to him to say, “Frankly, this sounds like a two- or three-year project to us. We could be wrong: here’s what we’d have to learn to find out. Here’s what it would cost to find out, and our best guess right now is that the answer would be bad news.”

This is Estimation, Not Negotiation! They’ll say, “What about May 5th?” Bah, we hate when they do that. So how can we give the project the information it needs without playing this game? Move from Date Estimation to Velocity Estimation. “It’s up to you. We can split things down to this size, we can guess our speed now at about three items per two weeks, and you’ll know every two weeks what’s really happening. You can use that information to decide what to do, and what to defer, so that you can get the best possible product for any date you pick.”... If they add up the figures to get dates, and then start trying to adjust the dates, don’t negotiate: turn the conversation back to the rate of progress... Someone might try to push the velocity. “Can’t you do seven every two weeks? That way you could get done on time.”... “Based on our experience, we’ll get between three and five done. It would be unwise to assume anything higher than that, because it’s not likely to happen.”

It still sounds like he's validating estimating 6mo in advance, which you then get held to. (Except of course you immediately start changing. But that exec probably still isn't going to be happy...) I Commented here.

z2013-02-06- Jeffries Estimating Is Evil
Product Owner

EricRies emphasizes how Iterat Ive development lets you test your Business Model. Referencing Steve Blank's Customer Development model. Agile Software Development is not always well adapted to the StartUp experience. That's not entirely surprising, because most agile methodologies have their roots in big companies (BigCo). They are specifically designed to build products in situations where the problem is known but the solution is unknown. Thus, they engage in rapid communication between the engineers and an authoritative in-house customer or Product Owner, who can give them fast resolution on feature decisions as they come up. This is a huge improvement over ever-more-detailed specification documents. But startups routinely face the problem that they don't even know what problem they are trying to solve... We were always convinced that the next feature we were about to ship would be "the big one" that would fix the product and help us make our paltry monthly revenue targets - only $300 a month in those early days. But these dreams of the instant fix never materialized. No one major release solved the problem, because the problem wasn't a lack of features. We eventually realized that our initial product concept, which had seemed so brilliant at the whiteboard, was fundamentally flawed. But because we took a disciplined approach to LearnIng we were able to find out before it was too late. Because we had tried every variation of features, had measured the behavior of the people we were bringing in, and were committed to a revenue plan, we were forced to change direction.

z2009-03-23- Ries Startup Iterate Experiment

Idea for spreading a complex set of recommendations, like for OpenNet...

Here's my thoughts for the day on making this stuff more consumable by the rest of the world, and perhaps giving a context for the individual stream of news/issues.

1. Get a bunch of people together for a couple days: Reed, Frankston, Isenberg, Kushnick, etc.

2. envision/design a future net that encompasses broadband, mobile, voice, etc. Finish the job with a grandiose label/brand (Stupid Network, End To End Network, UbiNet, UniNet, SkyNet, LolNet, whatever). (Print t-shirts.)

3. organize the principles that led you to #2 (much of which is tacit to you folks, but few others)

4. figure out the policy/civic-action steps to get there (maybe multiple paths: simplest vs more-pragmatic, etc.)

5. document all the above in a Concept Map, IBIS graph, outline, whatever

6. Write a 1-page summary (elevator pitch?) covering #2-4 above. Have all the gurus "sign" it.

7. Turn every node in #5 into a Tag, and perhaps an anchor page somewhere (a wiki? doesn't have to be universally-editable) providing more detail/narrative on that point.

8. Make every policy paper, every issue white-paper, every news blurb, etc. link to the appropriate nodes/tags. That way people who go "huh?" over a particular bit can go find some context, and then get led back to the overall design idea.

9. Publish as an OReilly book. Do slide shows. Have rich net dude underwrite documentary about your slideshow, etc.

10. Get the Made To Stick guys to help take it further.

One example that doesn't really do that much of the above, but provides some fodder: Agile Manifesto (yes many people have many issues with that group/meme, but ...)

Just a thought...

z2007-06-29- Meme Path
Agile Manifesto
Scrum A Breathtakingly Brief And Agile Introduction
Larry Wall

Agilo is a TracWiki plugin that adds ScruM-tracking features like Pivotal Tracker's. Now if only it worked for RedMine...

z2010-10-29- Agilo For Trac Scrum
KevinMarks Android MicroPub app
Clarke Ching
#02 a fresh history

My Intro Blurb:

This is the publicly-readable WikiLog Thinking Space of Bill Seitz (a Product Manager and CTO).

My Calling: to accelerate Evolut Ion by increasing FreeDom and Opportunity and AgenCy for many people via DAndD of Thinking Tools (software and Games To Play) that increase the LeverAge of Free Agent-s and smaller groups (Small World).

See Intro Page for space-related goals, status, etc.; or WikiNode for more terse summary info.

Beware the War On The Net!


Seeking: Product Manager-type position in established organization with entrepreneurial culture, local to Barrington Il or remote. My value: accelerating business-changing product development.



My Recent Key Pages:
My Blog Roll:
Follow me on Twitter