Slashdot Mirror

First thing is: forget about milestones. Milestones have 2 problems: first they put a fixed date for delivery, that means a fixed amount of time. Second they assume a fixed amount of work done until that Milestone. And finally they assume the work aka code is "finished", "polished" and tested.

Currently you say that you want to do better estimates ... with no experience and likely no reference data this is nearly impossible to do with milestones.

The most important thing is to get an idea about your "speed" or "velocity".

In agile methods like Scrum (see here http://www.controlchaos.com/about/) or eXtreme Programming you try to work in fixed iterations of e.g. 3 weeks (you can define your own length like 2 weeks or 4)

You put everything you can think about into a prioritized "to do list", often called "backlog". The customer has to prioritize. Your goal is to plan for the next iteration, usually called a sprint. Just take the as many high prioritized items from the backlog into your sprint.

After the first sprints you likely realize that you put always to much work into one sprint (the same would happen in a milestone but with worth consequences). The point is: now you get a feeling for your velocity. You can react on this by changing the sprint length (4 weeks, advantage: less overhead in planing, disadvantage: longer feed back circles from the customer), or by stuffing or by tools or by changing priority of features. The managers are now in the position to be able to manage.

In the long run you will have to break down items on the backlog in useable small work load items. It does not make sense to have one item with estimated work of 100 hours and 15 items with estimated work of 20 hours and 50 items with estimated work of 6 hours in your current sprint. One rule of thumb is: no backlog item should have more work assigned than 16h (I personally prefer 8h). If you have bigger items, try to split them. E.g. pan to "analyze" a certain problem in this sprint, assign 16h for use cases/stories/or what ever specification you use, 8h for architecture or database design, 8h for a rough code concept. Put the implementation of this into the following sprint!! So you can get feedback between sprints.

After a few sprints you will be able to put "the right amount" of work into your sprint and yout estimates on the items in the backlog become better. Remember Joh? Two sprints ago we estimated that tricky stored procedure to take 16h but we nearly needed a week for it. Lets better estimate this one on 20h instead!

The problem with milestone based planning and GANNT diagrams is: every work piece has an amount of time associated + a buffer. The buffer is always an uncertainty that is added so a chain of tasks add up their buffers. Starting times of tasks in the future are unnecessary far in the future, nevertheless buffers tend to get used up. Nevertheless there will be buffers that are to small, because the complete task was estimated completely wrong. Bottom line on a small GANNT diagram with 4 parallel _big_ work flows (like backend development, frontend development, database development, testing), all consisting of roughly 25 tasks (done in parallel or sequential) you have bottom line 100 task, all with a buffer. The likely hood that you reach your milestone in time is basically very close to zero.

I don't want to come to the conclusion that GANNT based planning does _NOT_ work, e.g. you can add also buffers at the beginning of the tasks ... but I don't want to go into this.

However in your situation you will be likely completely overwhelmed by simple tools like MS Project or other GANNT tools.

Regarding your question: UML is the right thing. It always is, no matter what other zealots say. The question is what kind of diagrams and with what kind of elements do you want to use? For the database ER diagrams might be enough, but what about "flow charts" (in UML called activity diagra

We have a scheduled meeting every single day, at the same time. Lasts 10-15 minutes most days-- it's longer on Tuesdays. It's an essential part of our process, which is a sort of modified Scrum, and it works extremely well.

With the Scrum development process, the requesting parties are able to get feedback every 24 hours. The development team's does not commit to delivering more than they believe can be achieved in thirty days. See if you can get your bosses to buy in. Here's a website: http://www.controlchaos.com/about/

Scrum is another development process that attempts to address the "silo's of expertice" problem.

That's why Scrum can be good - if you follow all the rules.

Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.

- Scrum is an agile process to manage and control development work.

  - Scrum is a wrapper for existing engineering practices.

  - Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing

  - Scrum is a process that controls the chaos of conflicting interests and needs.
Scrum is a way to improve communications and maximize co-operation.

  - Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.

  - Scrum is a way to maximize productivity.

  - Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.

  - Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.

- Scrum is an agile process to manage and control development work.

  - Scrum is a wrapper for existing engineering practices.

  - Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing

  - Scrum is a process that controls the chaos of conflicting interests and needs.
Scrum is a way to improve communications and maximize co-operation.

  - Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.

  - Scrum is a way to maximize productivity.

  - Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.

  - Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

Had no idea what Scrum is so found this

What is Scrum? Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. It's attributes are:
* Scrum is an agile process to manage and control development work.
* Scrum is a wrapper for existing engineering practices.
* Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing * Scrum is a process that controls the chaos of conflicting interests and needs.
* Scrum is a way to improve communications and maximize co-operation.
* Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.
* Scrum is a way to maximize productivity.
* Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.
* Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.


Original article can be found: http://www.controlchaos.com/about/?SID=8ef7eb5b2a0 69a2710abef27d02c851f&SID=7da824062baf60b8e78ec5f9 9836f092

... any of the Agile project management methods? I am using Scrum and it works perfectly for this kind of situations.

people do

That is why until organizations learn to ignore their big huge engineering-based waterfall processes and start focusing on developing their people both individually and as teams, they will not see any significant improvements in their ability to use IT more effectively. Agile methods are really great because they turn the focus away from the process (use the minimum process that can possibly work), to the people (teamwork, communication, collaboration, mentoring, etc.). That isn't to say that agile methods are easy... far from it. In many cases it takes a huge cultural shift for an organization to adopt agile methods. However, the effort is worth it because suddenly projects that used to take 18 calendar months are being finished in 4 or 6 calendar months... simply by eliminating the worst wastes in the corporate system, amplifying the team's learning, and allowing them to make decisions about how they do their work.

This is an interesting argument, and it's one I hear a lot here, but let me ask you something;

What was your improvement in productivity, and how was it measured? What was the reduction in your (delivered defects):(effort expended) ratio? What was the reduction in your (lines of code delivered):(effort) ratio? One or both of these ratios have to go down.

If you don't have these numbers, you can't really say you've improved productivity, especially with a process like Scrum. Scrum makes it very easy to think you're more productive, because it gives you results every 30 days (in fact, to a lesser degree, every single day with your Scrum meeting). But are you actually more productive? There's a fair rework cost incurred by Scrum, due to the constant introduction of new requirements, which Scrum hides very well.

I don't have these numbers either, and I'm not sure if anyone has done such a study (although I've encouraged the group here that's pushing Scrum to measure them), so I can't say for sure which process is "better" from this perspective.

I will agree that Scrum does an excellent job of making developers feel good, which is one of their stated aims, but unfortunately, software exists not to please its developers, but to please its users.

• What is it that you absolutely need?

• What would go along with these critical feature well?

• What would be "icing on the cake?"

1. 1) Mockup something and present it to them.

1. 2) Ask "Is this what you're looking for?"

1. 3) Architect your framework (real coders should be taking part here!)

• Extreme Programming
• Feature-Driven Development
• Scrum
• Crystal

http://www.controlchaos.com, Home Page Good overview.

• which tasks they worked on yesterday
• how long they've spent on each task
• how much more time each task will take to complete
• what they're going to be working on today
• any blocking issues they might have

The project manager (who is not a developer and not a manager manager) is responsible for keeping track of the tasks and the hours and making that information available. It's always clear who has responsibility for what and who's blocking whom from getting their work done.

This does a great job of keeping developers productive, and since developers get to make their own estimates (and the total amount of work that can get done in a development cycle is based on 40-hour weeks), it also does a good job of keeping them sane.

(It works well with eXtreme Programming practices like pair programming and story-driven design, too.)

But in lots of web-systems-development contexts the emphasis is on getting new sets of features built as quickly as possible, and there's a strong pressure to be in "permanent protyping" mode.

Prototyping is where you intentionally ignore a lot of the factors important in the real world, so that you can quickly bring some desired aspect to apparent completion. A great example is building a movie set: you only build the walls and finish the surfaces that the camera sees, but the sink doesn't have plumbing and there's no glass in the windows.

On a project of any size, the notion of "permanent prototyping" is a dangerous myth. If you're building for long-term quality and flexibility, you can't cut corners; they always come back to bite you. Trying to turn a movie set into a real house is much more painful than just building a real house, especially if there are people living in it already.

A better solution is to pick one of the various agile methodologies, like Extreme Programming, Feature-Driven Development, or Scrum. All of these methods focus on building very high quality software in a way that's amenable to change.

XP, for example, lets the biz folks change the spec every week or two if they want. (Which sounds like disaster, but smart people quickly realize that making random turns every few blocks is not the best way to get somewhere.) That gives you all the benefits of "permanent prototyping" without getting it's biggest drawback: the speed with which you reach critial mass.

You're certainly right that expert programmers don't absolutely need static typing. But for experts, static typing isn't that much of a burden, and even us geniuses have those occasional Friday afternoons where our brains go to the bar two hours before our bodies.