Running Notes

1 - One feature/bug fix at a time is the preferred method, never happens like that though, always starts with one then bleeds into 4 more. Then come complaints that its taking too long. I believe there is a best practice but customers haven't got one, oh yes they have "only work on my stuff" gets it done quicker.

2 - Lots of features (known as a "clusterfuck"). Deploy... and pray.

3 - We collect features requests / enhancements, as well as bugs. We have a Governance board that prioritizes the changes, decides which features/bugs to put into the next change set, and defines the next piece of work.

Bugs always take priority. We sometimes do a single large changes, sometimes a set of small ones. The business users prioritize, IT scopes and implements.

4 - Much of what i do is similar to others, requirements gathering, etc. But one unique feature/product I develop very early is a Mind Map. I can quickly gather requirements, and then click-and-drag items around the page to properly organize them. And from this, if i want, I can produce a GANTT Chart to schedule my work.

{ Link }

5 - Usually, I get the business to bunch up a few requirements, implement in a preprod environment and get them to test (and hope they do). Once I get the green light, I promote to prod.

For small bugfixes, I often do in place if I am confident, for larger issues, I do in preprod then promote

6 - If we're talking ideal conditions here:

1) Meet with customer.
By "customer" I meant the person/people requesting the solution.
2) Work with (consult) the customer to create a requirements document.
3) Create a project plan for the solution based on the requirements document.
4) Get "sign off" on project plan.
5) Evaluate technologies/plans to create solution.
6) Create a technology strategy document, consisting of the detailed plan to create the solution and create any mockups/wireframes possible based on the requirements and project documents.
7) Present the technology strategy document to the customer, get sign-offs or revise as needed.
8) Start Development.
9) Alpha Release.
10) Work with customer to create a functional gap analysis document.
11) Create a technology strategy document to address the FGA.
12) Present the technology strategy document, get sign-offs, etc.
13) Start Development.
14) Pilot Release.
15) On Error GoTo 10
16) Release!

7 - When planning for development of our Lotus product wiki application, we try to pick a theme or set of goals, then we look through the line items/bugs to see which ones support the theme or goals. Feedback is one of the key factors when we pick the theme.

We figure out which features/bug fixes we want for a release, then ask the developers to size each item.

Normally we try to keep the schedule around 12 weeks or so, and we'll compare the sizings to the schedule, prioritize features and determine which ones can be deferred, or scale some features back to what's necessary to support the goals, saving the "nice to have" things for if we have time in the current schedule, or defer them for a future release.

Once we have a solid plan we present to a board of stakeholders and come to an agreement of what the plan will include, then we execute against the plan.

The plan usually involves a design phase, development phase, feature testing phase, triage/bug fix phase, regression phase, regression bug fix phase, and finally a deployment phase where we roll out the new iteration to all of our wikis.

Of course, there are those times when a critical issue comes up that needs to be fixed outside of a regular release schedule. We try to address those issues immediately and deploy fixes as soon as possible.

8 - Great feedback everyone, keep it coming!

9 - Interesting... we're closely related to Ben Poole's methodology.

The governance of a project is dictated by who "cares" about the project and how much it is being audited.

Projects that affect dollars typically have requirements, estimates, testing sign-offs.

Departmental applications that help clean up processes typically have little written down except for sign-off.

10 - We're Internal development but it goes something like this:
1) Idea is submitted by anyone in the company
2) My boss decides if it is even worthy of consideration
3) I Make my best guess how long it will take me to build
4) If it takes longer than 10 hours, It goes back to the submitter to give a rough guess as to the the return on investment
5) It then goes to a committee to determine where it goes in my list of priorities, to actually schedule the work.
6) I build a really sweet application that does what they need (vs what was specifically asked for)
7) Everyone is happy, and the company saves a fortune.

11 - We're Internal development but it goes something like this:
1) Idea is submitted by anyone in the company
2) My boss decides if it is even worthy of consideration
3) I Make my best guess how long it will take me to build
4) If it takes longer than 10 hours, It goes back to the submitter to give a rough guess as to the the return on investment
5) It then goes to a committee to determine where it goes in my list of priorities, to actually schedule the work.
6) I build a really sweet application that does what they need (vs what was specifically asked for)
7) Everyone is happy, and the company saves a fortune.

12 - Oh, and for the bug fixes, they call me up and say "Hey Tim this doesn't work right" and I say "OK Try now" and they say "Hurray!"

13 - I like these sort of questions. Best approach is never to take big steps without validation from the client/stakeholders on the way.

What you're talking about is either iterative/big-bang/incremental approaches.

1/ Iterative is good when customer has no idea and they need to see it before they know. Turn around has to be weeks than months and the customer agrees things will evolve. But you will get issues with ongoing improvements are hampered by older code. (I don't like this approach on bigger apps).

2/ big bang. Customer has very clear requirements and the scope probably won't change (much). Project is only a couple of months. (Good for simplistic requirements and you want a long period of coding to deliver stuff). This works best on batch oriented problems like pushing data in and out of systems and there is low-user interaction.

3/ incremental. Customer needs features NOW but can wait for a bunch of others and priortise. Causes alot of testing for regression bugs, but is great for getting results in a short space of time and agreement of features/requirements are informal. (Good in more complex environments, allows you stage releases. I prefer this in most cases).

14 - We have an application management database where we continously register ideas for improvement and bugs.

We have quarterly updates, including bugs fixes and a limited list of improvements. (say max 100 hours of dev)

Every half year there is a new version released (200 hours of dev)

With every order for a database, users buy the service of bug fixes and continous improvement. This is a fixed fee. Every month they pay for hosting services (mostly costs for disk-space).

The hard part is to also deliver every quarter the updates. Sometimes we skip one or 2 over and place them all in a release.

15 - We hold a JAD session (joint app dev) with the end users. This is when get flush out all the requirements from data through functionality to business rules. It's amazing how many don't know what the rules are for the work they do. The user have to rate the function by need, from "would be nice to have" ro "It must do this". The jad session have run from 3 hours to 4 days in length depending upon the size of the project.
We then create a design document with screen mockups, data schemas, deliverable scedule and UML diagrams. For some projects we will break it into to multiple projects instead of one long one.
During development the users will test the app and we fix bugs. Bugs mean it doesn't perform as specd or it is obvious such as allowing text in a number field.
Change request are collected and rated by the impact to the delivery dates and cost then need to be approved by the customer to be included.

The longest project was 5 years for a bio-terrorism alert system in Domino. At the end they had us add functionality because we were going to be way under budget.