At Refactr we don’t often get RFP’s (Requests for Proposals). Most of our consulting project work comes from word of mouth and referral where we help brainstorm what is to be created at the outset. It is the only time in a project where there are routinely meetings for more than an hour - a time of much personal interaction. I would say that sending out an RFP, sends an entirely different message. At best, it is impersonal and puts up walls that must be knocked down. More seriously, when it comes to software development projects at least, RFP’s can set the stage for failure.

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.

Lean-to is live! We haven’t done a great job of keeping the work we have been doing under wraps but we haven’t been promoting it either. Since we gave a demo of our agile project tracking application, Lean-to, at minnebar in May, we have been adding features and tweaking it until we were ready to start talking about it.

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.

Read the rest of this entry »

I personally haven’t heard this question before, but Martin Fowler mentions that he has been asked whether a team should use agile development or lean development for a project. The answer is that they’re not alternatives.

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?

This is a little bit older, but pretty interesting: Nine Things Developers Want More Than Money.

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.

Much has been written in blogs and in the news media about Best Buy’s Results Only Work Environment (ROWE). And while the idea (do whatever you want, work however you like, as long as you get your work done.) is cool and it is nice to see a big company embracing some agile ideas, this is not a post about ROWE*.

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.

One of the best parts of Minnesota’s barcamp, minnēbar this year was the panel discussion on the state of technology in Minnesota. During the discussion everyone got the chance to hear from and ask questions of some leaders in the Minnesota tech and business communities, including: Doug Olson (Founder of Authorware, led the development of Adobe ImageReady, and now starting a Microsoft office here in Minneapolis), Jamie Thinglestad (Former CTO of Dow Jones MarketWatch, and 2008 Business Journal “40 under 40″ award recipient), Michael Gorman (Co-founder of venture capital firm Split Rock Partners), Robert Stephens (Founder of the GeekSquad), Dan Grigsby (2008 Business Journal “40 under 40″ award ), Matthew Dornquast (Co-founder of code42 Software).

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.

Here’s the coolest utility I’ve seen in a while: OS X Trash. It allows you to manipulate the Trash from the command line; trash files, list the contents, and empty it all from the command line. I’m actually wondering if I might want to try aliasing rm for this. I’ve known the horror of accidentally rm -rfing the wrong directory…

[via Daring Fireball]

When I initially ran across the Simile Timeline project, I was pretty impressed, both by the power and flexibility of the framework and also by how well it works. What’s more, it’s really simple to use and the site has a good tutorial for creating your own timeline.

After seeing the example timeline of the JFK assassination, I was inspired to create a timeline of my own. My first thought was to create a timeline displaying wars that the US has been in - mostly because I was really curious about how that would look: war-time vs. peace-time, etc. However, for a couple years now, that project never really got off the ground (mostly out of general laziness on my part) … until now.

To show it off, we’ve also created a playground at play.refactr.com, so that we have a sandbox to try out new frameworks or ideas - and share our experiences along the way.

I used data taken from the wikipedia entry US Wars to create the timeline. Right now, I have two separate timelines using the same data. The first timeline is just a straight-forward representation of the data. The second timeline uses the same data, but utilizes the framework’s zooming ability to warp specific periods of time. In this second case, I chose to compress the boring peaceful non-war years of US history, so we can scroll right to the interesting parts of the timeline.

The data that I’ve captured from the various wikipedia entries is pretty sparse - it’s by no means exhaustive or even representative. I just tried to grab a couple major highlights of each war to show off the timeline framework and more should obviously be added. I’m also working up another example, so stay tuned for more timeline goodness.

I put the slides (with notes) from my MinneBar presentation on iPhone development up here. I hope everyone enjoyed the presentation; add a comment or send us an email if you have any questions. Lastly, if you’ve got an iPhone app that you want developed, don’t hesitate to ask us! You can find Ben and Scott’s slides here.