Project Planing

Created on Jan. 21, 2013, 3:12 p.m. by Hevok & updated by Hevok on May 2, 2013, 4:42 p.m.

There are lot of things that should be done in all directions and it is hard (next to impossible) for a single person alone to deal with all of this at once. The focus of the beginning of a Project should be attracting Developers and other team members and making it easier for them to understand the Aim and Scope of work and to contribute.

There are Developers that are doing and producing something and experts that help on different issues (for instance experts to consult).

For the process of iterating (sprint) planning choose a time for iteration (next 2 weeks for instance), choose priorities, write down feature lists, assesses feature together (in terms of their importance and complexity), decide one the final product of the iteration, and create personal plans.

The problem with methodologies (like Scrum) is that they do NOT WORK if team members do not understand why this or that element or rule should be followed. So the best way is to choose only those parts (rules, elements of methodologies) that all team members understand and consider as important. Understanding means to know how the team (and s/he personally) will benefit from each specified element.

There is no need in using all elements and rules at once. It may even be harmful if the team use them only because they seem to be interesting without deeper understanding.

Most of the agile methodologies are based on several assumptions:

  1. We do more or less innovative things so that we cannot plan and understand everything. Of course there must be be some long-term vision, but it needs to be experimented through making intermediate products, like iteration (sprint) results. In case where everything can be planned beforehand without corrections from reality checks Agile (including Scrum) is less suitable, while Waterwall is suitable and vice versa.

  2. Every result of the iteration (sprint) should enable to test some ideas and have some real value. It should not be a simple list of features, rather than it should be a system/subsystem core part of subsystems etc. that will be developed. For instance in the end of this sprint there shall be a basic relationship related functionality and basic chat functionality as a product of the sprint.

  3. Every member of the team should have understanding of the whole Project not only her/his parts. It will let she/her propose ideas and give feedback to others. When something innovative is being developed, feedback is desperately needed for everything.

  4. When developing together on relies on each other. And that is why one should learn to assess the time and efforts spend on different features In the same time we are limited in Developers and resources so the most important features with minimum efforts to implement should be chosen first.

  5. Developers have to change and rewrite a lot. Simply because the product they develop is innovative and failures are normal part of the process. In the same time rewriting a lot of things is painful. That is why unit-testing should be used. With unit-tests it is easy to rewrite parts or the whole applications many times simply because they show what is broken on changes.


Tags: phases, planning, stages, technology, tasks
Categories: News, Quest
Parent: Denigma
Children: Lean Startup

Update entry (Admin) | See changes

Comment on This Data Unit