My team (3 devs) has been using Shape Up since January and it’s been amazing. I don’t think I can ever go back to scrum.<p>It allows devs to be creative, do what needs to be done, and ship a real feature. All without any product managers, and zero meetings.<p>Corporate companies could never imagine not counting all their beans, but man it is so freeing if you have the option.
In case you are interested in Shape Up and want read more about it, Ryan Singer - the inventor of the methodology - has written a really great book about how they have been, and currently are, building and shipping products and features at 37signals.<p>The book is called "Shape Up" (doh) and the electronic version is totally free:<p><a href="https://basecamp.com/shapeup" rel="nofollow">https://basecamp.com/shapeup</a><p>I would also really recommend the rest of the books, lots of great thoughts on development and management from actual experience. Also free:<p><a href="https://37signals.com/books" rel="nofollow">https://37signals.com/books</a>
In addition to the roughly standard 2-week scrum teams I work with, I am also working on launching a from-scratch project with two developers, and our process is roughly:<p>1. I keep a backlog of new features that are needed.
2. The backlog items vary in completeness/specificity from "mostly there" to "a sentence or two description". Some of the items are large and need to be subdivided.
3. At any given time, the devs each have 2-3 items they are actively working on.
4. The items range from a day or two up to a week or two for the really big ticket items (e.g. "get performance in boundary cases from 'won't load at all' to 'loads in < 10 seconds'")
5. When a dev puts something in for code review, if they're down to too few items, they check in with me to figure out what to add to their active list. We go over the outstanding list to figure out value vs. effort and make some choices.<p>Item 5 generally happens weekly, sometimes even every few days. They work fast.
Symantec, which once sold programming tools, tried a unique approach - scheduled maintenance. The product team worked on one product at a time. When they finished an update, they'd go on to the next product. Products were not updated out of cycle.
The "betting table" reminds me that I continue to think there's a large, mostly untapped market for good internal betting and prediction market software in large software companies. The primary problem around them seems to be psychological: it's very, very painful to lose a bet that feature X will be shipped by date Y in state Z, and even more painful to see your own track record of failures grow over time, even if you are also accumulating successes.
I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done.<p>There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
<i>> Scrum with 2 week sprints may work very well in larger corporates, but startups who need to pivot regularly and change direction may not be as well suited to such a fixed process.</i><p>If your pivot frequency < 2 weeks, sprint length is not the problem.
Our (complex physical product in a combined design office / factory) method: 10 minute chat together in the morning, identify any problems we'd like help with, anyone can ask to change focus at any time. Sometimes a team works on the same problem, usually people take sole responsibility for something on their own but take it from and bring it back to the group to keep everyone vaguely aware of where things are going. We may state what we think we'll get sorted for the day and what we're aiming for the next few days or week. Rarely do we look beyond a few days because it's too vague/unrealiable. At the end of the week we quickie summarize what got done by email (way shorter/higher level than git logs). If there's an over-arching goal or time pressure everyone is informed and we work toward it. No forms or friction for lateness, leave, lunch, ordering stuff, printing, etc. People are judged on commitment, ideas and progress. Factory floor and equipment, design office and electronics lab all on site. No management except keeping a weekly journal for the team's aggregate progress, setting some priorities start of week, and compressing updates to stakeholders. Oh yeah, and mobile devices are locked in a cabinet at the front door during work hours - if you don't like it work somewhere else or take the day off.
In good hands, any product development process works well; in bad hands, any product development process fails. It is not about processes, methodologies, or frameworks - it is about people and what people do.
I'm a fan of <a href="https://programming-motherfucker.com/" rel="nofollow">https://programming-motherfucker.com/</a>