Flat Cluster Development

The ideas of FlatClusterDevelopment are a currently untested theory of JeffDay. I encourage you all to contribute your thoughts towards them, after reviewing thoroughly :)

(I'm working on this document at this very moment)

I think the ChangeYourOrganizationDiary, especially the earlier part before much progress had been made, shows some good "bad examples" of why this methodology is superior to a traditional company.

Flat Cluster Development is a Software Development Methodology that replaces traditional management. It is designed to resolve many issues relating to traditional management of software development efforts. It provides the following

SOLUTIONS TO EXISTING PROBLEMS / BIGGEST DIFFERENCES

With orthodox management, a typical company would have hired several extremely smart and capable employees, but the only ones who get to make decisions are the ones who (in most circumstances) don't know how to perform the job.
Prevent ego or pride from becoming a factor in decision-making. Instead we depend on rational decisions based upon the input of ALL team members.
No member of the company will give due-dates or deadlines, EVER. This might be recognized as the most obvious departure from traditional development. In lieu of giving deadlines, team members are paid on a sort of commission system, based upon how much of the workload they pull; therefore, the motivational factor to complete things is a tangible, financial benefit. Lack of deadlines also provides the following benefits:
1. Customers will never be disappointed if the product isn't released "on-time". The actual consumer public will typically be unaware of the product until it is released for public testing.
2. Much stress and friction between departments, caused by deadlines, is eliminated.
3. Quality of the product will be significantly higher because no corners will be cut in attempt to meet deadlines.
There is no traditional concept of "hire" or "fire". Various teams (described later) exist within this methodology. As long as a person is a member of one of the teams or is still within a 30-day grace period of leaving a team, he/she is still considered an "employee". New members petition the team they would like to join, and are elected into the team based on a voting system. If they are approved, they should never be removed from the team unless they decide to remove themselves.

Because it is essential that team members are able to work well together, the following criteria should be examined before accepting someone's petition to join any team:

Self-motivated.
Smart.
Gets along with other team members.
Possesses skills that can benefit the team.
Team can afford to have another member.

Types of teams (read these topics for the above to make sense):

Elected roles:

FlatClusterProjectAdvocate
- The primary communication link between the Scout Team and the Project Team.
FlatClusterProjectLeader
- Serves a 2 week term. In charge of motivation for Project Team members, and acts as the authority for commission points.

Can you give us some relevant experience which shows why you might believe this should work? The approach seems somewhat naive. For example,

Deadlines are often imposed by outside sources. You may have a 1 year contract; you better deliver at the end of a year if you want a renewal. A potential customer may request a new feature; you better have the feature in place when the customer schedules his evaluation. A major trade show may be occurring; you better have something to show or teach your sales reps how to tap dance. You may want to sell during the Christmas rush; you better have something to show when stores are doing their purchasing in August. If you ever want to release or deploy the product, you may want to let the sales, marketing, and support people know about it and schedule their time to get training before it hits the field. A new regulation may be imposed; you may want to get release out before your customers face the risk of a criminal violation. Deadlines are often real.
Talk to anyone who has been a project manager on a task and see if he thinks it could be accomplished in 2 week intervals. I know most of my time is spent on people outside the development team, my time with the development team is usually taken up with setting direction and helping with individual improvement plans. Motivation, though important, is not that time consuming; you only need to provide motivation on a few individual occasions.
Although developers may be smart and capable, they are also often, unfortunately, very far removed from the actual users of the software. They have the least knowledge and, therefore, capability to make the necessary decisions. -- AnonymousDonor

Wow, AnonymousDonor, you sound like a project manager. :) A couple counterpoints... Regarding deadlines, if you are being dealt out brownie points based on how quickly and accurately you can accomplish something, theoretically you will finish the project as fast as possible while retaining the required quality level. The lack of deadline makes it POSSIBLE for the project to be completed EARLIER than anticipated, otherwise, the feeling of having a whole week left will cause FeatureCreep to occur and the length of time to drag out to fill what is available. (Length of time it takes to complete a project acts like a Gas in this case and fills to expand available space.) It costs more money, well, certainly more time, to release a product that does not meet the minimum quality requirements or lacks necessary features and then have to recall it or release urgent updates. This would be disasterous for programs of financial natures, especially. It only makes sense to release a stable product, even if it is not "on time" -- again, if no deadline is declared, there is no "on time". You can only program as fast as you can program, and if you want to sell during Christmas it is tough luck if the project simply cannot be completed and stable by that time. On the other hand, perhaps one of the FlatClusterProjectLeader or FlatClusterProjectAdvocate's duties could be to look for "good times" to release, do some type of guesswork forecasting and try to adjust the SIZE of the team by advertising openings to get more programmers involved (if this indeed would make things faster :) Goals are not a problem. Strictly Internal dates known to the project team do not cause the pitfalls of deadlines that are published to other departments or to the public. *cough* Windows Vista... If even they can't do it, with all the resources at their fingertips, then what is the point execept to embarrass and disappoint?

Regarding the Two Weeks... I think you missed the point entirely. It was not saying there is a two week timeframe to accomplish something. It is saying that every two weeks the Project Leader is up for possible impeachment. She/he could serve for four months, if deemed worthy by the rest of the team (whose interests all include direct financial benefit from the success of the team.) The rotation of project leaders could also be useful getting fresh brains working on the direction of the team. This way things don't become stale.

And, on your third point, I believe it was mentioned that the Project Advocate would, along with unallocated members of the FlatClusterScoutTeam, shadow the customer to get real world experience on how the software will best be implemented. Since anyone can join the Scout Team and since the Advocate also belongs to the FlatClusterProjectTeam this is almost a direct liason to the real world.

Anyone else care to comment? Are these good counterpoints, or do the objections outweigh them? Has anyone tried any pieces of this methodology on an actual project?

I think it's hoplessly naive, and some of this comes from the (common) view point that projects begin and end with code. No deadlines? What about training and rollout? People can't just wait around on tenderhooks waiting for the delivery at any moment. If it's a product, you need documentation and packaging produced. If the software is just part of a product (embedded in a phone) you have to fit in with their schedules. In general, software is only part of the overall product and just telling people "it will be done when it is done" is terribly disruptive to the other parties who need to do their stuff.

Quality trumping deadlines?

: "Quality of the product will be significantly higher because no corners will be cut in attempt to meet deadlines".

If you miss the Christmas period for your toy-of-the-moment because of this, I'd like to see you explain to the customer

: "Yes, I know it's now January and no-one's buying it, but just feel the quality".

Project leaders changing every two weeks (potentially). Better hope there's nothing time comnsuming for them to learn to come up to speed, then.

: "Instead we depend on rational decisions based upon the input of ALL team members."

I think you'll be disappinted by how rational people really are, and the time it takes to reach decisions. The facts do not speak for themselves, they're filtered through people, who have egos and pride whether or not you wish to banish that. I don't believe you can run a project on direct democracy; not everyone's viewpoints should have equal weight - people's skills and experience should affect things.

: "the only ones who get to make decisions are the ones who (in most circumstances) don't know how to perform the job."

Again a common misconception on this Wiki in particular is that there's nothing different about (project-)managerial decisions compared to technical ones. Would you insist that that job of building a skyscraper had prior experience in laying concrete? Marshalling, motivating people and resources to deliver a success for the business is utterly different from determining the software architecture. Trade-offs between this feature and that are business decisions not development ones.

Agility, integrity, coherence and flexability come from having a single person in charge of making decisions. I've seen several companies founder because of attempted rule by democracy. Most business people, and most books on management tell you the same thing: Find the right person and put them in charge.

Your suggestions have merit in limited circumstances, and perhaps in those circumstances what you suggest is near optimal. There are more cases, however, where some of your suggestions would be disastrous. Some types of software delivery require delivery, commissioning, training, and documentation. Some contracts have deadlines with liquidated damages attached to overruns. Some commissioning and training requires long-haul flights. In these circumstances your suggestions seem less obviously correct. Indeed, in some contexts they are obviously wrong.

Perhaps you should look at the assumptions you've made about what's being delivered. Show that in those circumstances what you've suggested is not only a good idea, but obviously the best idea. Then relax the assumptions and see what breaks.

I also agree that this is naive. I think the idea of getting input from all team members is not so bad, but the nonesense about a deadline; well it sounds like it comes from a developer that has a very insular view of the world. Don't you want your launch team to be able to plan? Is development the center of the universe and it is ok for everyone else to twiddle their thumbs until Development is good and ready? We don't care about competition or market share? Sorry, but for a company to have a strategy one often needs to plan. We prefer to plan and to use small (say two week) cycles while measuring velocity so that we know if we will hit the planned date or not. We deliver quality because we believe in building quality software. If by measuring velocity we can see that we will miss the planned date, we can negotiate with other stakeholders to either push the date out or remove features that will enable us to maintain the originally planned deadline. Because sometimes, a date is more important than having all the fetaures while other times it is more important to get all the features in than to hit the date. In commercial software, both of these choices often have to do with Market Share.

"Customers will never be disappointed if the product isn't released "on-time". The actual consumer public will typically be unaware of the product until it is released for public testing."

That sounds like its written from a COTS perspective. Most software isn't COTS. Most software is written after it is sold and contracts have been signed. Even COTS software development has to be funded, and that funding relies on promises of delivery. Any method that ignores deadlines is doomed in the real world.