There’s a distinction between creative work that people do for “work” and what they do outside of work. Work/life balance for computer geeks, knowledge workers, or artists has nothing to do with not being creative or solving problems. It’s about giving your brain a break from the same, constant grind and giving yourself time to think and be refreshed.

Like Bex, as a programmer and computer geek, when I go home, I still talk about and think about technology. But that doesn’t mean that I’m still “working.” I may be solving similar types of problems, but I get a lot of relaxation and enjoyment from not working on the same exact problems. Outside of work, I do iPhone development, personal Grails and Groovy projects, AppleScript, play with bayesian algorithms in perl, tinker with embedded linux, spend time with my family, and more. Those are all geeky technology things. But that’s my point - that’s still work/life balance because it gives me a break.

Finally, Bex quotes Isaac Schlueter as saying “An artist doesn’t stop being an artist when he goes home.” It’s true, but that artist doesn’t always work on the same projects when he gets there.

Applications of all types are now spread across multiple screens as I try, mostly in vain, to come up with a strategy that doesn’t leave me needlessly flipping through 3 to 5 pages just to find the thing I want. I have tried to organize them by grouping like apps together on screen but I don’t really want a whole screen for music-related apps or games. Then I tried by frequency of use with the most frequently used apps on the first couple screens and then those I rarely use on the last few. This too was less than ideal as it isn’t readily apparent when I am search for something how many times I really use it. I guess I could try alphabetical.

How about adding folders?

The folder is a simple organizational mechanism that could help keep my applications in order: Creating and naming folders and then dragging apps into them could work nicely. (like shown above)

Double tapping the folders brings up a radial menu of its contents - app icons - that can be clicked. I have mocked up how that may look (see below). A simple, dark overlay similar to a lightbox effect to represent the mode change would work well.

This example only shows a folder with six applications in it and I am uncertain how to deal with folders containing more than eight. Perhaps there would be a number on the the folder and then single tapping would tab through them.

Until I get something like this the number off application I will be downloading will be significantly restrained.

Bonus gripes to Apple:

1. Please let us delete (or at least hide) those app you included on the phone that we do not use. I don’t need stock quotes and notes.

2. When updating an app, don’t move its position. This is very annoying.

3. Get the stability and fluidity of the interface back to the point where it was when the phone first launched. I don’t think you can totally blame the apps being installed, but if you can, then be more stringent on the apps you let in the store.

4. For next iPhone INCREASE THE RAM!

An RFP attempts to describe and document the project. The first part of this (to describe) is good, but the intent for an RFP to do anything other than get some ideas down and start a dialog between the stakeholders and developers* is misguided. An RFP is drafted prior to development, when the least amount of information is available and with a small subset of the whole team in place.

Another side-effect of the RFP process is the creation of a mindset that software development is something that happens to an organization by an external source. Software development should be one of the most collaborative endeavors into which businesses enter. Stakeholders and developers should work side-by-side in designing the software, customers and those who use the software should be involved in the use-and-feedback loop.

To underscore the idea that RFP’s are simply the “hello” to a longer conversation, we often informalize the process right up front by meeting in person and responding with text emails rather than fancy Word or PDF file proposals. Our hope is that this helps to establish a new tone for the project and have found that when formality dissolves away, real communication happens.

* The terms developers and software developers are used here to encompass all people who develop software including visual, information, and interaction designers, client-side coders, server-side programmers, etc. I could also have used software designers to mean the same bunch of folks.

We wanted to let everyone know that we have pushed out some significant updates to Lean-to that we hope will get people excited. Here are a few of the highlights:

• Add people to your account and manage settings
• View plan and backlog views for your stories/bugs
• Track team progress with report views
• Get more info on list views with new context menus
• Add tests to stories in improved ways
• Assign stories or bugs to iterations from the backlog view
• Filter lists to show only those stories or bugs assigned to you
• More invite and project options
• Various interface improvements

We hope that you enjoy the new changes in this release and we ask that you don’t hesitate to use the feedback link to let us know what you like and don’t like about Lean-to.  We’ve got lots more on our own backlog, but we’d love to hear what you want from Lean-to.

Add people to your account and manage settings
In addition to inviting others to share your projects, you can now add “official” users to your account. Unlike people you invite/share with, users have all the privileges that you do - adding/editing/deleting projects, adding and inviting new users, etc. To access these new features, just go to the Settings page (under your email address/username and the gear icon) and open the Account section.  You’ll also notice that you can change your personal info on this same page, such as  changing your password and adding a real name, which is used when taking (i.e. assigning to yourself) stories and bugs.

View plan and backlog views for your stories/bugs
We have changed the way your stories and bugs are organized. Just as before you can still get views of either stories or bugs, but if you are like us, you often like to see stories and bugs together in one list (by iteration). Well now you (and we) can. In the new Plan view you can see items that are already “on plan” because they have been assigned to an iteration. All those stories that are not yet assigned to an iteration can be found in the Backlog view.  When you are on the backlog view you can simply drag your stories or bugs to an iteration and drop them into that iteration. Try it out, it’s fun.

Track team progress with report views
We have added a couple of ways to visualize your project’s progress and speed. In addition to some charts showing completed/incomplete stories and bugs, you can now view burn-up and velocity charts.  A burn-up chart shows you your progress in completing Stories and Bugs with an estimated project completion target.  The nice thing about a burn-up chart (as opposed to a burn-down chart) is that it makes it very easy to see the impact that requirements changes are having (because you can see added or removed stories or bugs very easily).

A new way of adding tests to stories
Now you can add multiple tests for a story. You can assign the tests to one of the following categories: Acceptance, Integration, Performance, Regression, Usability depending upon your needs.

Get more info on the list view with new context menus
Now you can get more information and options for any story or bug in the list views (without going to the detail page) by expanding the new context menus for that particular story/bug. Simply hover over the story or bug in the list and a little “tab arrow” icon will show up to the right of the row. Click the icon and the long description of the item will be displayed (and is editable when clicked) as well as the option to delete the item or go its detail view.

Assign stories or bugs to iterations from the backlog view
One of the nicest additions in this release is the ability to drag and drop Stories and Bugs from the Backlog view to assign them to an iteration.  Not only can you drop them onto an existing iteration, but you can also create a brand new iteration from the Backlog view.  We think this makes the Backlog view a lot more functional and more friendly to use.  We even give you a count of the number of Stories/Bugs in the iteration as well as the total estimate for the iteration.

Filter lists to show only those stories or bugs assigned to you
If you take a look at the drop down menus under Plan and Backlog, you’ll notice a new option called “Mine” that will filter either of these views to just show the Stories or Bugs that are currently assigned to you.

More invite and project options
Be sure to check out the account settings page (under the gear icon) because we’ve added several new features there too.

The Projects section allows you to rename, archive, or delete your projects from a convenient central location.  It will also show you any projects that you have joined through an invite and allow you to leave that project when desired.

The Invites section allows you to manage outstanding and accepted invites for your projects.  This means that you can now remove shared access to a project, or even revoke an invite before it has been accepted.

Interface improvements
You may notice we moved a few things around and added a few touches here and there. The biggest improvement is the project options and selection box. This has always been in the upper right part of the screen but we have moved it from the sidebar up into the “cloud” where the Account settings link can be found. This change not only cleans up the sidebar area and allows for future feature inclusion there, but also more clearly designates the project-related functions as outside of the context of a specific project.

We’re ready for Firefox 3! In fact, Lean-to is optimized for our new favorite browser, which is both much faster and better at rendering XHTML and CSS than than its predecessor.

Lean development is a type of agile development.

In fact, Mary and Tom Poppendieck title their book “Lean Software Development: An Agile Toolkit.” And the introduction describes the book as a set of thinking tools for translating lean principles into effective agile practices.

In his post, Martin refers to Richard Durnall’s thoughts on using lean principles with agile projects, which I also enjoyed.

The better question is, how many lean principles are appropriate to implement for this project?

It should be inherently obvious, but seeing lists like this every once in a while is a good reminder that creating and maintaining high-performing teams is clearly more about people than it is about process, technology, or anything else.

As a follow-up to my post earlier this week, I wanted to post some pertinent bits of a recent discussion I had with Geek Squad founder and current Best Buy executive, Robert Stephens. He is implementing a plan to “think small” from inside the behemoth that is Best Buy. Stephens’ plan addresses each of the points that Mike Speiser of laserlike.com concludes are important advantages that startups have over large organizations in terms of innovation, namely: the investment model, incentives, and risk taking.

His idea would focus on technology and software solutions developed by small teams or individuals within Best Buy (or failing that, using small teams or individuals from the outside). The first step would be to create an infrastructure that allows for projects to get up and running with very limited administrative or technical setup. Once a problem or opportunity is identified, employees are encouraged to bid for the opportunity to tackle a problem by offering up their solution and what it would take in terms of time and money. The best ideas are funded (in the form of a bonus) or, in some cases, combined into teams. We aren’t talking about large “corporate-type” budgets either - these could be a couple thousand to twenty thousand dollar budgets. The goal is to side-step the typical flow of events in corporate business: get an idea, meetings and discussion, document the idea and discussions, sending the idea “up the flagpole”, having more meetings, having the idea morph, incorporate additional ideas, and finally either get the “green light” or be canceled weeks, if not months after the solution would have ideally been implemented.

This concept allows Best Buy to act like a startup in all the ways that are important. It allows for “distributing investment and other decisions” (a new investment model) across the organization allowing for risk-taking by individuals who are incetivized by the ability to create something great and get paid extra for their efforts.

* For more on ROWE, check out this Tim Ferris post for more on ROWE or the blog of ROWE instigators Cali Ressler and Jodi Thompson.

A large portion of the talk was comparing the environment in Minnesota with those on the coasts in terms of entrepreneurial spirit, startups, and venture money with a good deal of discussion mirroring Dan Grigsby’s post titled A Plan For Minnesota. The consensus seems to be that our tech start-up community isn’t thriving,  not for lack of access to great people or ideas (or even money though I think that’s debatable) but rather for lack of guts.

It definitely takes guts to leave a nice salaried job where, frankly the expectations for you are set pretty low. Big banks, insurance companies, and even tech-focused companies rarely can sustain the culture and spirit that got them there. The sheer size of the machine becomes so large that innovation and personal accountability shrink into the shadows. Despite billions of dollars spent on research inside Microsoft, Oracle, Yahoo, and yes even Google, all too often the game-changing innovations are created by small, hungry companies who then get purchased.

Venture capitalist, Mike Speiser over at laserlike.com has some great insights on this. He looks at the 2007 R&D investments at 3 major companies (Microsoft: $7.1 billion, Google: $2.1 billion, Yahoo: $1.1 billion) and then the $5.1 billion VC’s put into startups and makes some observations:

My strong suspicion is that the return earned by investors on that $5.1 billion (in aggregate) will exceed the returns on the $10 billion (in aggregate).  If you buy this argument, then there is only one logical conclusion. There isn’t too much money in venture, but rather there are too many good people in large firms.

He states that startups are the right place for innovation for these three reasons (I am paraphrasing here):

1.  The investment model - Big companies often won’t kill bad projects where small companies must. Startups are more practical and results oriented in what they prioritize. Centralized knowledge and limited employee ownership/investment hinders large organizations. Large firms should create a system for distributing investment and other decisions.

2.  Incentives - Paying for performance is easier in small companies. The probability of success equals the number of experiments per invested dollar times the number of dollars.

3. Risk taking - In big companies perceived risk curtails innovation and agility. This must be overcome.

There is a positive selection bias in startups towards an appetite for risk.  People have “overcome” their fear — at least enough to be at a startup.  When you have an entire group of people who have overcome their fear, you get positive feedback.  People egg each other on to break the rules.  To “think different.”  To be open minded.  That sets off a cycle that drives people to throttle risk up and up and…

As much of the panel at minnēbar concluded, it is this last point that they believe is holding Minnesota back as a hotbed for technology startups. Minnesotans are hard workers but for whatever reason, are more risk averse than their coastal brethren.

[via Daring Fireball]