Discussions

News: "Top Development", - the next projectmethod replacing Scrum...

  1. I think waterfalls, spiralmethods, iterative methods, agile methods (Scrum) etc. have failed at meeting the functional requirements at a given cost. "Top Development" is an iterative project method that uses prototyping of the system as the main focus. The method can be used in small project with only a few project members or by large projects with several hundreds of project members. It's primary use is for information technology projects, but it can also be used for other types of projects where worktime are the main cost. The method emphasizes planning at the beginning of the projectperiod in combination with iterative development. In addition it has focus on the systems infrastructure before implementing the functional requirements. When the infrastructure is in place, the project is "Over the Top", - that's is why the method is called "Top Development". To avoid bad choices of technology, frameworks etc., it uses "Throw'n go" at every review of a prototype. It is best for the final system to throw away bad elements as early as possible during a projects lifetime. All parts of the method are well documented. In addition to this description, there is templates for organization charts, processflow, task lists, project estimation, risk analysis, project reporting, projects milestones etc. Both commercial and non-commercial projects can use this method at no costs. You can view the full documentation at http://www.fibon.com/topdev/topdev.pdf I would like to have some feedback from the community about this project method.

    Threaded Messages (20)

  2. Though I can pick up words and parts of sentences in Norwegian, reading technical doc. crosses that line bigtime. The google translater refuses and isnt that good anyway on translations. So please add an translation to the article.
  3. +1 What kind of "community feedback" do you expect without an english translation? You probably could reach a better audience on a local site. At least mention in the article that the document is in norwegian. Regards, Raffaele
  4. So what is new?[ Go to top ]

    What is it in this project method that is new? Why can't you do prototyping within RUP or Scrum? I have been in several project where I have been asked to break down my work into unit of various size. The problem is always that if they are large they are of no benefit and if they are small they are usually wrong and it is hard to keep track of which you are working on. I think prototyping can save a lot of time and is a good way to communicate with the stakeholders, but why do we need a whole new project method for this? Renaming an iteration a prototype does not change anything.
  5. Translation, RUP, Scrum etc.[ Go to top ]

    Hello, I apologize for not been able to translate all the document to English, but the google-translation will give you the main parts until I do. All other documents are already translated: organization charts, project flow, project reporting, task list, estimation of time, throw'n go milestones. The focus on infrastructure is the main difference compared to other project methods. In addition there is strong focus to get rid of not working elements as early as possible (Throw'n go). It is also free and complete with all templates ready to use. I think RUP is too large and complex. And I do not like their phases(Inception, Elaboration, Construction, Transition). I think Scrum has way too little focus on planning, especially at the beginning of a project period.
  6. Fixed cost development[ Go to top ]

    I admit I haven't read the Norwegian document nor attempted a translation, but I did look at the pictures. :) The very first sentence appears to promise that this process can implement a project at a fixed cost. No process has yet managed to achieve accurate estimates of development time. To achieve fixed costs we need to accurately estimate the total development time. If the author has found a way to achieve accurate estimates then we have a significant breakthrough. I could not, however, see this in what I could read of the document.
  7. I think waterfalls, spiralmethods, iterative methods, agile methods (Scrum) etc. have failed at meeting the functional requirements at a given cost.
    Now, that's because no method can accurately predict: 1) Erratic customers (yes, they tend to change requirements at the end of the project cycle) 2) Technical problems 3) Key personnel quitting 4) And so on... I also have to ask: You claim that "Scrum has failed", effectively. What kind of statistical material are you using? My experience is that Scrum, implemented correctly, works fairly well. But of course can still not predict the unpredictable behavior of customers and project members. There are some interesting insights in your method, but I personally think the throw-away prototype approach is a HUGE and COSTLY mistake. Seasoned developers are very good at creating systems iteratively without throwing away anything. The important part of any project management style is getting the right people and making the most of them. That's black art; human understanding, not methodology.
  8. There are some interesting insights in your method, but I personally think the throw-away prototype approach is a HUGE and COSTLY mistake. Seasoned developers are very good at creating systems iteratively without throwing away anything.
    I think this is a much more interesting discussion than the described project method. What is it that the stakeholder can test? The answer is the user interface. In "agilistic" development a working system should alway be created and that is a waste. It is better to do as much as possible of the part they can test and understand and when that part is "perfected" the rest of the system can be developed.
  9. I just want to say that there seems to be much more skepticism and emotion in debates about new methodologies than there is about new "frameworks". I applaud the author for going down this route
  10. There are some interesting insights in your method, but I personally think the throw-away prototype approach is a HUGE and COSTLY mistake. Seasoned developers are very good at creating systems iteratively without throwing away anything.
    I think this is a much more interesting discussion than the described project method. What is it that the stakeholder can test? The answer is the user interface. In "agilistic" development a working system should alway be created and that is a waste. It is better to do as much as possible of the part they can test and understand and when that part is "perfected" the rest of the system can be developed.
  11. you always make a project at fixed price because what the client gives you is in fact money. The "only" variable is "features set"
  12. Hello again, I totally agree that the most important part of any project management style is getting the right people and making the most of them. And using whatever method is better than using no method at all. My experience is that very few are able to use Scrum as it is ment to be used. They are using Srum but.... I think Scrum do not have the answer for the real challenges software development is faced with. Some problems are: *co-locations of team members -that is not possible in the real world. "Top Development" has an organization structure that makes it possible to have internal/external project-members spread all over the world. *100% dedicated project members -This is not possible for large projects. Software systems are the most complex constructions in the world. Large systems need special knowledge on different parts during different timespaces in the project. "Top Develoment" has a framework to make that happen. I think "Top Developement" reflects the real world in a far better way than Scrum. But as I said earlier: Using whatever method is better than using no method at all. About the "Throw'n go": You are not supposed to throw away the protoype, but only parts of it that did not meet the expectations. For example: It can be very difficult to know if a gui-framework is mature enough to go into production. If the "review" tell us that it is not, then get rid of it. Many projects don't do that and the bad decision becomes a huge cost for the system later on. -Harald PS! Thank you for all the feedback(forum, e-mail) so far.
  13. *co-locations of team members
    -that is not possible in the real world.
    Scrum in distributed teams is increasingly popular, and works just fine. Co-location isn't mandated, nor hard, once you set the rules straight. There are studies on the topic you can check out.
    *100% dedicated project members
    -This is not possible for large projects. [snip]
    That argument makes no sense to me. Scrum, and everything else out there, assumes you are as intelligent and dedicated as you'll ever be. Organizations use whatever resources they have and makes the best of them. Good organizations fire unproductive personnel.
    About the "Throw'n go":
    You are not supposed to throw away the protoype, but only parts of it that did not meet the expectations.
    Fair enough. Mainly an iteration in disguise, then?
    For example: It can be very difficult to know if a gui-framework is mature enough to go into production. If the "review" tell us that it is not, then get rid of it. Many projects don't do that and the bad decision becomes a huge cost for the system later on.
    I agree, and Scrum offer an even better solution IMO: namely, you do NOT implement an elaborate GUI framework, or any other complete piece of functionality/architectural layer. You initially implement a thread throughout every layer (or whatever technical system design you choose) to prove to yourself and the customer that the general approach is correct. Then you simply iterate and refine with some timely checkpoints. My experience, and from what I hear from others, is that Scrum works very well when implemented correctly. When incorrectly implemented, or you have incompetent people on the team, nothing works anyway. Assuming you have decent people, the nice thing about Scrum is that it gets out of your way most of the time. The few things you have to do mainly work out automatically after the first few iterations. IMNSHO.
  14. ...100% dedicated project members[ Go to top ]

    My experience is that in large organizations employees are participating in several projects at the same time. In a project one person can participate 10%, sometimes 70% etc, sometimes at the beginning of the project period, sometimes only in the end. In addition there is non-project related work. People have different skills that the project most use. I think it is very important to use a project method that uses the right people at the right time and percentage during the project period. Not a team where all the people are 100% dedicated despite some are needed elsewhere, or the skill is not needed right now or the project need a more skilled person for a period...
  15. Is it April 1st already?[ Go to top ]

    ...there is templates for organization charts, processflow, task lists, project estimation, risk analysis, project reporting, projects milestones etc.
    Epic Fail
  16. Templates[ Go to top ]

    Look at the references at the bottom of the the document.
  17. Too many buzzwords[ Go to top ]

    "Top Development" sounds like training for D&S practitioners. "Throw n go," "over the top" ... Any new methodology that uses a bunch of clubby new terms (and presumably enforces a culture of a chirpy Top Master) should be reconsidered. It has "jumped the shark" before Fonzie has even mounted the surfboard. Maybe the methodology is good, but I can't imagine using these terms. Also, these days, any new methodology should have a free, portable software counterpart for guidance, rather than a PDF.
  18. Comments are relevant[ Go to top ]

    Hi, Sometimes comments are more important than the article itself
  19. A backward step?[ Go to top ]

    Looks like waterfall in iterations to me. A more rigid process does not magically allow you to deliver a fixed price project: what allows this it flexible scope and delivering business value early. Contrary to the argument here Agile techniques have been very good at this: hence their widespread adoption by industry. This paper looks like another I've seen where a waterfall organization attempted to adapt their procedures to be more Agile. If you want to deliver good software you have to be prepared to change for the sake of the solution. Have I missed the innovation here?
  20. I am not an Agile / Scrum expert, so these are my opinions based on what I have read and based on my experiences. In each aspect of this approach, I think everyone has differences in how they do things and how they interact with others. From this respect, it is important early on to kick off your project to understand the scope of the project, userstand all stakehold requirements (which includes the customer, the user, the architect, the tester, the developer, etc) break it down into smaller identifiable components, and eventually implement the needs. I think this seems to be personalized version of existing methodologies, which in any methodology should occur. Conforming to strick methods can be helpful at times but it can also force people to work in ways that they are not accustom to nor are they likely to be their way of doing things. It seems to lack focus on early user stories / use cases which can drive much of the requirements which can be helpful in determining criteria for if an iteration is good or not. This can also help develop unit testing that can help evaluate how well user requirements are being met. The multiple iteration seems consistent with other agile methods with weekly deliverables being the normal iteration period as I am aware. Throwing out each prototype to me also seems to be a potential waste. Some part of the prototype could be reused, reducing the time needed to re-do things again and again. Some means of change control is important as well, as it can provide some tracability between or against iterations. If changes are needed, you can indicate against what and track the change and rational for the changes. Some aspect of risk management also could be useful to insure when "throwing out" something you don't get rid of something important (there is a saying [when giving a baby a bath] "don't throw out the baby with the bath water"). However some level of risk management could potentially be addressed as part of change control, tracking, or project status mechanism. Some of the functional requirement aspects could benefit from some "system engineering". Much of the administrative duties do seem to be more project management related responsibilities, which in my eyes have often been over looked, under appreciated, or not performed well for the project. Might think about aspecs of "earned value" as well which basically is a means of determing how well your plan compares against your actuals including some aspect of how close to completing the project you. I have gone on long enough...I hope this is of help. Eric
  21. Key Contribution: Over the Top[ Go to top ]

    I'm both a scrummaster for a small development team and enterprise scrummaster for my division (and a CSM blah blah blah). I tried to scan this to find the new contributions. The only thing that resonated for me was the concept of "over the top". In our world of 200+ developers, Scrum causes heartache for some stakeholders: They can't start PR, marketing, etc. significantly in advance of a release, because developers won't commit to both release-date and feature-set. (They can commit to either release-date OR feature-set, but not both.) We realize this is a problem, and it is gradually changing how we prioritize work: we are starting to prioritize essential infrastructure and features earlier. Once we reach "production ready", then product management has a freer hand to introduce features they want to experiment with. It is at this point that engineering can say, "Release anytime." This "over the top" point is where product management has much more control, and they typically have months left to implement all these less-infrastructure-impacting features. Product managers can, at that point, set the release date based on the features they think they want to provide, and the (by now stable) team velocity. When the release date arrives, the implemented feature set may not be exactly what product managers expected, and they just have to deal with that (i.e. not list inessential features in marketing materials). I think most Scrum implementations self-organize around their specific needs, and will likely get to this strategy if they need it. But Harald has given it a decent name: "over the top".