Loading ...
Sorry, an error occurred while loading the content.

What is wrong with this process

Expand Messages
  • Max Pendyshchuk
    Hello! I want to describe our development process. Here are many processes which are (in my opinion) not so good organized (and even very bad). I tried to
    Message 1 of 14 , Nov 30, 2006
    • 0 Attachment
      Hello!

      I want to describe our development process. Here are many processes
      which are (in my opinion) not so good organized (and even very bad).
      I tried to avoid my comments here, I will give them in replies. So I
      would like to read your feedback ¡V all your remarks, thoughts,
      proposition, your experience etc. Maybe you can write how it works at
      your company or how do you wish it should work¡K

      In answers, which are addressed personally to me, you can use
      English, German, Russian, Ukrainian. You can also use some of these
      foreign languages, if you have a good idea, but are not sure, how
      to ¡¥serve¡¦ it in English. For previous situation you can use some of
      other foreign languages too, if, as you think, I could
      understand/translate it (e.g. Dutch). The most important thing for me
      is to understand what is wrong here, what we can improve and so on.

      This story is organized in this way ¡V the first part is tale from one
      of managers, the second ¡V is my, as from one of developers. This
      document was reread for some of other developers or managers, so I
      think in general it is good described, but we could forget something.
      I will describe it in my answers, if I have questions, which show
      that we have not depicted a little.

      Part I. Manager¡¦s point of view

      1. The Beginning of the Project

      Usually projects come without strict requirements. The specification
      for the project is a draft document that describes project
      functionality on the highest level.

      After establishing connections with the customers the project leader
      studies the document, and creates a time-line for it. A project
      manager is responsible for dividing the project into logical parts,
      setting up the order in which these parts will be implemented
      (priority), and for rejecting those features that cant be implemented
      within the time-line.
      This step includes couple of iterations. Functional description is
      detailed a little bit, but yet explanation remains on the top level.

      After the general strategy is worked out by the project leader, we
      gather at the project meeting and discuss what has to be done in the
      project. That is, the project leader tells the team members what has
      to be done. After that a first set of tasks is assigned to the
      developers and the process switches to common development process
      (see Common Development Process chapter).

      2. Common Development Process

      We have agreed to use EVO as a basis for our project development
      process.
      So we have concepts of Cycles and Deliveries and EVO one-to-one
      meetings and Weekly Synchronization Project Meetings. I will describe
      our common working cycle.

      Thursday (also known as 'Big Planning Day')
      On Thursday morning all of the project leaders have a Weekly Team
      Management Meeting (WTMM). The following issues are discussed on the
      meeting.
      Previous cycle ¡V results, what to do different (in order to discuss
      it on the team meeting)
      Next cycle ¡V tasks (on the top-level) for the next cycle for each
      developer

      After this meeting a next cycle working area letter is sent to the
      developers. And the Big Planning begins (usually starting around
      16:00).
      While planning next cycle, the team member
      estimates his working area and breaks it into tasks, each with
      implementation duration less than 6 hours;
      describes details of each task: Description, Functional Requirements,
      Implementation Ideas. Also such details as estimated implementation
      time, reviewer and due day are filled.
      Usually we fail to complete the planning by 18:00 Thu. So we either
      have to stay till later (19:00 ¡V 20:00), or the planning is
      accomplished on Friday in the morning (in around 45 minutes).
      During the planning process the project manager becomes the help desk
      of the team, answering questions like ¡§How much fields the should
      be ...¡¨ or ¡§I will implement this using ... Yes or No¡¨ or just ¡§Which
      technology should I use ..¡¨.
      As I've already mentioned the working area for a team member is
      described only in general, and it's his responsibility to get the
      details. Unfortunately such details often should be discussed with
      the customer in such case project leader becomes a 'proxy' between
      the customer and the developer.
      Even if the requirements come unclear we never write detailed
      functional description as a separate document ¡V its assumed that the
      details are described in EVO. There is one more excuse to avoiding a
      separate detailed functional description ¡V it's when the project has
      a very short time-line (2 months). It's also said that writing a
      separate document is useless since the requirements are unclear and
      they will change anyway.

      Friday (once called a 'Big Meeting Day')
      The work on Friday usually starts at 9:30. At this time One-to-One
      (121) meetings start. The 121 meeting is performed in a following
      manner.
      Each team member comes to a project leader and (if not forgotten) we
      discuss the results of a previous cycle. Team member does the
      analysis of what could have been done differently and how to improve
      it. Then the previous cycle is closed and we proceed to the next
      one.
      The team member defends his planning, being reviewed by the project
      leader. If there are any remarks the project leader sends the
      developer back to re-plan particular part. The general spirit in our
      company is to demand as clear and detailed plan as possible. But
      usually I try to avoid sending people back for re-planing if the
      remarks are minor. This sometimes makes me think that I¡¦m not making
      the honest effort in my job. I agree that the plan should be as clear
      as possible, but when a person comes to defend his tasks it seems so
      ridiculous and pedant to send him back for re-planning.
      Those who failed to accomplish their planning the day before, hastily
      try to accomplish it before the team meeting, and for this reason
      usually their plan is not realistic enough (optimistic) and it misses
      details that consume more time than it was planned.

      So in the end all team members defend their tasks and weekly team
      meeting begins.
      In theory this meeting is called to help us to synchronize tasks and
      to share information (like ¡§Kolya knows how to do that and that so
      Vanya may ask him about that when implementing his task¡¨ etc.). It is
      held in the following way.
      The team gathers around one of the PC¡¦s. We start from the previous
      cycle and TRY to analyse it. What has been done what was planned to
      be done how to improve it next time (in case the goal wasn¡¦t
      achieved). Some team members try to share their analysis about why it
      went wrong.
      Writing this I see that we act like a team of losers, always
      searching for explanations (that is excuses) that we program
      ourselves that it would go wrong next time and that we will have to
      analyse it next time and explain why it was wrong. So we do our work
      bad to have something to tell to the others on the project meeting
      next time.
      It¡¦s clear that a successful team have no need in explaining itself.
      But I don't know how to break that circle of ours.
      If a person may is involved in several projects he has to attend
      several project meetings.

      To conclude in hours we spend: from 0:45 to 3:30 hours for the
      planning and 2:30 for the meetings. Personally I spend 2 hours on Thu
      (17:30 ¡V 19:30) and 1.5 hours on Friday (9:00 ¡V 10:30 between 121
      meetings with my team).
      In fact one half of Thu and one half of Friday is spent for the
      planning process. But yet we have a hell lot to improve in our
      planning.

      And one final remark about planning. It¡¦s demanded in English as a
      company standard. Yet some team members have a poor level of English.
      And sometimes we need a decipherer to understand what was meant in a
      task. At the same time the developer explains a beautiful plan in
      Ukrainian.

      Friday (after meetings), Monday-Wednesday, Thursday (before planning)
      (the Development)
      The development process is trivial enough. Developers just accomplish
      their tasks and fill the result form.
      The results of what has been done;
      The still to-do in case something is incomplete or something
      unplanned, that has to be done, arisen upon task implementation;
      The analysis;
      If the first two are quite transparent, the third one requires more
      explanation. Initially this field was introduced to analyse
      incomplete tasks: why it¡¦s incomplete, what has to be done
      differently next time, any wise thoughts. Couple of weeks ago this
      task became mandatory for all of the tasks, requiring ¡§what has to be
      done differently next time, any wise thoughts¡¨ from the developer.
      Well I understand the psychological aspect of such an ¡§innovation¡¨
      even for successful tasks. The developer will think about the results
      and about the task one more time, maybe he will find some other
      brilliant solution for this task and will write it down all this into
      paper and into subconsciousness at the same time. So the next time he
      faces the problem he will use a better solution.
      But on practice it sometimes looks ridiculous when you have to
      analyse sort of successful ¡§Type a letter¡¨ tasks. Maybe for this
      reason there is so much resistance from the team concerning this
      innovation.

      What concerns the project managers, they usually spent a fair amount
      of time to contact with the customer to ascertain tasks (~1h/day),
      and to consult team members about the project (usually tactical and
      strategy solutions to be made; some technical questions also; in
      total ~1h/day). All the other time (14 EVO hours of 30 EVO hours /
      week) project leaders act like a common developers.
      On Wednesday the project managers check the completeness status on
      tasks from the previous cycle and start rough planning of the next
      cycle for their teams. And on Thursday the story starts all over
      again.

      Part II. Developer¡¦s point of view

      As you have read above we use Evolutionary Project Management, by Tom
      Gilb. Development cycle = 1 week, delivery = 2*cycle = 2 weeks. After
      each cycle or delivery (it depends on project) we show our results to
      the customer. Cycle begins on Friday and finishes on Thursday.

      1. Working area

      Every Thursday I get mail with working area for the next cycle. Here
      is some samples of tasks in mail (here are tasks for some developers,
      nothing is omitted, I changed only some names: Project1, ¡K, Theme1,
      ¡K):

      ¡K
      Max P. (Project1):
      - investigate JasperIntelligence (viewlet about creation & deploy
      simple report)
      - deeply check all Project1 tables (mapping, questions, ETTL).
      - ETTL & periodical jobs
      - GA on wed 16.00
      ¡K
      Natali D. (Project2):
      - by using new DAO methods to bind them with screens (Stepan develops
      them),
      - after that all screens should use business logic if new methods
      appear ask Stepan to develop.
      - Handle all Mantis issues related with presentation layer.
      - Finalizing one of demo screen with Ajax framework
      ¡K
      Oleg M. (Project3, Project4):
      - Finalize Per Developer Report (see mantis);
      - Create 2 themes from existing design (Theme1, Theme2);
      - Refactor Screen1 (remove HTML tags from Java code);
      - Bind Screen1 to Search;
      - Fix mantis remarks;
      ¡K

      2. Planning

      After the lunch I start to analyse them splitting on tasks. Of
      necessity I consult with project manager or other team members -> if
      something is unclear, I ask them (e.g. tasks above like ¡§Fix mantis
      remarks¡¨, ¡§¡Kif new methods appear¡K¡¨ and some other from our ¡§real
      life¡¨) After I have set up my tasks list, I split them on smaller, if
      it is possible, and begin to plan them according to priority (this
      priority is set by me, if it is not indicated in mail or it is not
      solved by team or PM). For a start, I group it by the days. E.g. on
      Friday I¡¦ll do two tasks, for each I give 3 hours (total hours for a
      day should be 6 hours, we plan only 6 hours from 8 working hours; we
      leave 2 hours for helping each other (it is not our personal task, if
      it was not planned. Sometimes we help to other developers, who
      develop other projects, to find some bug, to help with advice ¡V so it
      is little unplanned tasks), coffee/tea/¡K, news reading etc.). For
      each task I write

      1)name
      2)description
      3)to which project this task belongs
      4)how may hours I plan to spend
      5)when I¡¦ll do it (date)
      6)how will I solve this problem / do this task ¡V algorithms, ideas,
      frameworks, libraries and etc.
      7)what is assumed as a basis ¡V e.g. project specification, an issue
      from bug tracker system¡K
      8)which results should I get.

      We use made by our developers tool for task registration, reporting¡K

      In much the same way I deal with all tasks and I get my scheduling
      for whole cycle. For planning we have about 3.5 hours (but this time
      depends on tasks complexity, some times it can be only 1 hour).
      I have also to check my descriptions for clarity ¡V each other
      developer should understand what/when/how/¡K will I do. I can ask
      somebody to check my planning.

      3. Plan checking

      On Friday, in the morning, project managers check our tasks. It is
      121 meetings. We begin as a rule from previous cycle analysis. Each
      project manager reread planning of their team members and, if they
      have questions/remarks developer should correct his planning. In some
      cases he has to replan all tasks. After project manager marked all
      tasks as checked, developer starts to implement them.
      It is quite possible, that before or during 121 meeting project
      manager declare, that we need to change tasks priority because of
      customer¡¦s requirements or company project politic, and we need to
      replan. Such situation can not be foreseen because customer can
      change his wish for the night.

      4. Project meeting

      As a rule, on Friday we have project meetings.
      Every Project Meeting starts with analysing of the results of
      previous cycle (planned week). Project Manager asks every team member
      to make short analysis. After that team discusses next cycle: every
      team member opens EVO tool and describes every planned task ¡V day by
      day. Team member explains his tasks and how he intends to do them,
      etc. If other team members have questions for him, they ask. Usually,
      project manager has questions, related to management process, and
      sometimes for technical side of task. After everyone describes his
      tasks, there is some time to estimate current project state (how
      successfully project moves, what still to do for the release, etc).
      Sometimes a discussion may occur between team members about
      preferable way of implementation in some task, but usually it's more
      like reporting about the implementation of the task to other team
      members.
      Project meeting we hold only if developers count is more than or
      equal to 3 (as I have noticed). E.g. I am occupied with project,
      which is developed by 2 programmers, so I have forgot, what does it
      mean ¡V project meeting ƒº
      It is possible, that as result of project meeting can be replaning.

      5. Task finalizing
      At the end of workday (or after programmer finish task), programmer
      should write for all today¡¦s tasks results of their implementation:
      1)Which results have programmer got?
      2)How much time did programmer spend for it?
      3)Does source code meet the company requirements?
      4)Does design meet the prototype?
      5)Was test cases written?
      If task was not done, developer should write how does he estimate the
      task status (how many percents was done), what still to do. He has
      also to analyse, why it is not done and how to avoid it in future.
      Developer has to analyse even if my task is done ¡V He should write
      how could he do it better, his opinion about this task, how to
      improve such task implementation in future¡K

      6. Some my remarks

      Everything written above refers to developer, tester, designer and
      project manager (they should plan everything too).
      If during cycle something is changed (e.g. new tasks, which should be
      done now), we shift our tasks, some tasks get status ¡¥future¡¦ ¡V it
      means they will be done on next cycle or something like that.
      You could see in this letter some time data, so for better
      understanding of them I want to write, that in Ukraine work-day
      begins on 9:00 and finishes on 18:00. Lunch-time in our company is
      13:30-14:30.

      And now I want to hear your opinion. I hope this ¡¥story¡¦ will help
      you too.
      Thank you in advance, Max.

      PS: At the moment when this article was finished we have started
      changing our management approach. We agreed to perform a big project
      meeting before the planning - to discuss what was to be done, has
      been done, and what to do next. And then after planning ¡V a small 30-
      min meeting to synchronize what we have planned (after the planning
      and one-to-one meetings). This approach gives team members feeling of
      being more involved into a process. And it also helps to do better
      analysis of the tasks of each team member.
    • Vickydhiman
      Hello Max: Is it possible to describe your process at a high level of detail rather than focussing on nitty gritty? What are guiding principles and values
      Message 2 of 14 , Nov 30, 2006
      • 0 Attachment
        Hello Max:

        Is it possible to describe your process at a high level of detail rather than focussing on nitty gritty? What are guiding principles and values which drive your process?

        Thanks

        Max Pendyshchuk <gotischerose@...> wrote:
        Hello!

        I want to describe our development process. Here are many processes
        which are (in my opinion) not so good organized (and even very bad).
        I tried to avoid my comments here, I will give them in replies. So I
        would like to read your feedback ¡V all your remarks, thoughts,
        proposition, your experience etc. Maybe you can write how it works at
        your company or how do you wish it should work¡K

        In answers, which are addressed personally to me, you can use
        English, German, Russian, Ukrainian. You can also use some of these
        foreign languages, if you have a good idea, but are not sure, how
        to ¡¥serve¡¦ it in English. For previous situation you can use some of
        other foreign languages too, if, as you think, I could
        understand/translat e it (e.g. Dutch). The most important thing for me
        is to understand what is wrong here, what we can improve and so on.

        This story is organized in this way ¡V the first part is tale from one
        of managers, the second ¡V is my, as from one of developers. This
        document was reread for some of other developers or managers, so I
        think in general it is good described, but we could forget something.
        I will describe it in my answers, if I have questions, which show
        that we have not depicted a little.

        Part I. Manager¡¦s point of view

        1. The Beginning of the Project

        Usually projects come without strict requirements. The specification
        for the project is a draft document that describes project
        functionality on the highest level.

        After establishing connections with the customers the project leader
        studies the document, and creates a time-line for it. A project
        manager is responsible for dividing the project into logical parts,
        setting up the order in which these parts will be implemented
        (priority), and for rejecting those features that cant be implemented
        within the time-line.
        This step includes couple of iterations. Functional description is
        detailed a little bit, but yet explanation remains on the top level.

        After the general strategy is worked out by the project leader, we
        gather at the project meeting and discuss what has to be done in the
        project. That is, the project leader tells the team members what has
        to be done. After that a first set of tasks is assigned to the
        developers and the process switches to common development process
        (see Common Development Process chapter).

        2. Common Development Process

        We have agreed to use EVO as a basis for our project development
        process.
        So we have concepts of Cycles and Deliveries and EVO one-to-one
        meetings and Weekly Synchronization Project Meetings. I will describe
        our common working cycle.

        Thursday (also known as 'Big Planning Day')
        On Thursday morning all of the project leaders have a Weekly Team
        Management Meeting (WTMM). The following issues are discussed on the
        meeting.
        Previous cycle ¡V results, what to do different (in order to discuss
        it on the team meeting)
        Next cycle ¡V tasks (on the top-level) for the next cycle for each
        developer

        After this meeting a next cycle working area letter is sent to the
        developers. And the Big Planning begins (usually starting around
        16:00).
        While planning next cycle, the team member
        estimates his working area and breaks it into tasks, each with
        implementation duration less than 6 hours;
        describes details of each task: Description, Functional Requirements,
        Implementation Ideas. Also such details as estimated implementation
        time, reviewer and due day are filled.
        Usually we fail to complete the planning by 18:00 Thu. So we either
        have to stay till later (19:00 ¡V 20:00), or the planning is
        accomplished on Friday in the morning (in around 45 minutes).
        During the planning process the project manager becomes the help desk
        of the team, answering questions like ¡§How much fields the should
        be ...¡¨ or ¡§I will implement this using ... Yes or No¡¨ or just ¡§Which
        technology should I use ..¡¨.
        As I've already mentioned the working area for a team member is
        described only in general, and it's his responsibility to get the
        details. Unfortunately such details often should be discussed with
        the customer in such case project leader becomes a 'proxy' between
        the customer and the developer.
        Even if the requirements come unclear we never write detailed
        functional description as a separate document ¡V its assumed that the
        details are described in EVO. There is one more excuse to avoiding a
        separate detailed functional description ¡V it's when the project has
        a very short time-line (2 months). It's also said that writing a
        separate document is useless since the requirements are unclear and
        they will change anyway.

        Friday (once called a 'Big Meeting Day')
        The work on Friday usually starts at 9:30. At this time One-to-One
        (121) meetings start. The 121 meeting is performed in a following
        manner.
        Each team member comes to a project leader and (if not forgotten) we
        discuss the results of a previous cycle. Team member does the
        analysis of what could have been done differently and how to improve
        it. Then the previous cycle is closed and we proceed to the next
        one.
        The team member defends his planning, being reviewed by the project
        leader. If there are any remarks the project leader sends the
        developer back to re-plan particular part. The general spirit in our
        company is to demand as clear and detailed plan as possible. But
        usually I try to avoid sending people back for re-planing if the
        remarks are minor. This sometimes makes me think that I¡¦m not making
        the honest effort in my job. I agree that the plan should be as clear
        as possible, but when a person comes to defend his tasks it seems so
        ridiculous and pedant to send him back for re-planning.
        Those who failed to accomplish their planning the day before, hastily
        try to accomplish it before the team meeting, and for this reason
        usually their plan is not realistic enough (optimistic) and it misses
        details that consume more time than it was planned.

        So in the end all team members defend their tasks and weekly team
        meeting begins.
        In theory this meeting is called to help us to synchronize tasks and
        to share information (like ¡§Kolya knows how to do that and that so
        Vanya may ask him about that when implementing his task¡¨ etc.). It is
        held in the following way.
        The team gathers around one of the PC¡¦s. We start from the previous
        cycle and TRY to analyse it. What has been done what was planned to
        be done how to improve it next time (in case the goal wasn¡¦t
        achieved). Some team members try to share their analysis about why it
        went wrong.
        Writing this I see that we act like a team of losers, always
        searching for explanations (that is excuses) that we program
        ourselves that it would go wrong next time and that we will have to
        analyse it next time and explain why it was wrong. So we do our work
        bad to have something to tell to the others on the project meeting
        next time.
        It¡¦s clear that a successful team have no need in explaining itself.
        But I don't know how to break that circle of ours.
        If a person may is involved in several projects he has to attend
        several project meetings.

        To conclude in hours we spend: from 0:45 to 3:30 hours for the
        planning and 2:30 for the meetings. Personally I spend 2 hours on Thu
        (17:30 ¡V 19:30) and 1.5 hours on Friday (9:00 ¡V 10:30 between 121
        meetings with my team).
        In fact one half of Thu and one half of Friday is spent for the
        planning process. But yet we have a hell lot to improve in our
        planning.

        And one final remark about planning. It¡¦s demanded in English as a
        company standard. Yet some team members have a poor level of English.
        And sometimes we need a decipherer to understand what was meant in a
        task. At the same time the developer explains a beautiful plan in
        Ukrainian.

        Friday (after meetings), Monday-Wednesday, Thursday (before planning)
        (the Development)
        The development process is trivial enough. Developers just accomplish
        their tasks and fill the result form.
        The results of what has been done;
        The still to-do in case something is incomplete or something
        unplanned, that has to be done, arisen upon task implementation;
        The analysis;
        If the first two are quite transparent, the third one requires more
        explanation. Initially this field was introduced to analyse
        incomplete tasks: why it¡¦s incomplete, what has to be done
        differently next time, any wise thoughts. Couple of weeks ago this
        task became mandatory for all of the tasks, requiring ¡§what has to be
        done differently next time, any wise thoughts¡¨ from the developer.
        Well I understand the psychological aspect of such an ¡§innovation¡¨
        even for successful tasks. The developer will think about the results
        and about the task one more time, maybe he will find some other
        brilliant solution for this task and will write it down all this into
        paper and into subconsciousness at the same time. So the next time he
        faces the problem he will use a better solution.
        But on practice it sometimes looks ridiculous when you have to
        analyse sort of successful ¡§Type a letter¡¨ tasks. Maybe for this
        reason there is so much resistance from the team concerning this
        innovation.

        What concerns the project managers, they usually spent a fair amount
        of time to contact with the customer to ascertain tasks (~1h/day),
        and to consult team members about the project (usually tactical and
        strategy solutions to be made; some technical questions also; in
        total ~1h/day). All the other time (14 EVO hours of 30 EVO hours /
        week) project leaders act like a common developers.
        On Wednesday the project managers check the completeness status on
        tasks from the previous cycle and start rough planning of the next
        cycle for their teams. And on Thursday the story starts all over
        again.

        Part II. Developer¡¦s point of view

        As you have read above we use Evolutionary Project Management, by Tom
        Gilb. Development cycle = 1 week, delivery = 2*cycle = 2 weeks. After
        each cycle or delivery (it depends on project) we show our results to
        the customer. Cycle begins on Friday and finishes on Thursday.

        1. Working area

        Every Thursday I get mail with working area for the next cycle. Here
        is some samples of tasks in mail (here are tasks for some developers,
        nothing is omitted, I changed only some names: Project1, ¡K, Theme1,
        ¡K):

        ¡K
        Max P. (Project1):
        - investigate JasperIntelligence (viewlet about creation & deploy
        simple report)
        - deeply check all Project1 tables (mapping, questions, ETTL).
        - ETTL & periodical jobs
        - GA on wed 16.00
        ¡K
        Natali D. (Project2):
        - by using new DAO methods to bind them with screens (Stepan develops
        them),
        - after that all screens should use business logic if new methods
        appear ask Stepan to develop.
        - Handle all Mantis issues related with presentation layer.
        - Finalizing one of demo screen with Ajax framework
        ¡K
        Oleg M. (Project3, Project4):
        - Finalize Per Developer Report (see mantis);
        - Create 2 themes from existing design (Theme1, Theme2);
        - Refactor Screen1 (remove HTML tags from Java code);
        - Bind Screen1 to Search;
        - Fix mantis remarks;
        ¡K

        2. Planning

        After the lunch I start to analyse them splitting on tasks. Of
        necessity I consult with project manager or other team members -> if
        something is unclear, I ask them (e.g. tasks above like ¡§Fix mantis
        remarks¡¨, ¡§¡Kif new methods appear¡K¡¨ and some other from our ¡§real
        life¡¨) After I have set up my tasks list, I split them on smaller, if
        it is possible, and begin to plan them according to priority (this
        priority is set by me, if it is not indicated in mail or it is not
        solved by team or PM). For a start, I group it by the days. E.g. on
        Friday I¡¦ll do two tasks, for each I give 3 hours (total hours for a
        day should be 6 hours, we plan only 6 hours from 8 working hours; we
        leave 2 hours for helping each other (it is not our personal task, if
        it was not planned. Sometimes we help to other developers, who
        develop other projects, to find some bug, to help with advice ¡V so it
        is little unplanned tasks), coffee/tea/¡K, news reading etc.). For
        each task I write

        1)name
        2)description
        3)to which project this task belongs
        4)how may hours I plan to spend
        5)when I¡¦ll do it (date)
        6)how will I solve this problem / do this task ¡V algorithms, ideas,
        frameworks, libraries and etc.
        7)what is assumed as a basis ¡V e.g. project specification, an issue
        from bug tracker system¡K
        8)which results should I get.

        We use made by our developers tool for task registration, reporting¡K

        In much the same way I deal with all tasks and I get my scheduling
        for whole cycle. For planning we have about 3.5 hours (but this time
        depends on tasks complexity, some times it can be only 1 hour).
        I have also to check my descriptions for clarity ¡V each other
        developer should understand what/when/how/¡ K will I do. I can ask
        somebody to check my planning.

        3. Plan checking

        On Friday, in the morning, project managers check our tasks. It is
        121 meetings. We begin as a rule from previous cycle analysis. Each
        project manager reread planning of their team members and, if they
        have questions/remarks developer should correct his planning. In some
        cases he has to replan all tasks. After project manager marked all
        tasks as checked, developer starts to implement them.
        It is quite possible, that before or during 121 meeting project
        manager declare, that we need to change tasks priority because of
        customer¡¦s requirements or company project politic, and we need to
        replan. Such situation can not be foreseen because customer can
        change his wish for the night.

        4. Project meeting

        As a rule, on Friday we have project meetings.
        Every Project Meeting starts with analysing of the results of
        previous cycle (planned week). Project Manager asks every team member
        to make short analysis. After that team discusses next cycle: every
        team member opens EVO tool and describes every planned task ¡V day by
        day. Team member explains his tasks and how he intends to do them,
        etc. If other team members have questions for him, they ask. Usually,
        project manager has questions, related to management process, and
        sometimes for technical side of task. After everyone describes his
        tasks, there is some time to estimate current project state (how
        successfully project moves, what still to do for the release, etc).
        Sometimes a discussion may occur between team members about
        preferable way of implementation in some task, but usually it's more
        like reporting about the implementation of the task to other team
        members.
        Project meeting we hold only if developers count is more than or
        equal to 3 (as I have noticed). E.g. I am occupied with project,
        which is developed by 2 programmers, so I have forgot, what does it
        mean ¡V project meeting ƒº
        It is possible, that as result of project meeting can be replaning.

        5. Task finalizing
        At the end of workday (or after programmer finish task), programmer
        should write for all today¡¦s tasks results of their implementation:
        1)Which results have programmer got?
        2)How much time did programmer spend for it?
        3)Does source code meet the company requirements?
        4)Does design meet the prototype?
        5)Was test cases written?
        If task was not done, developer should write how does he estimate the
        task status (how many percents was done), what still to do. He has
        also to analyse, why it is not done and how to avoid it in future.
        Developer has to analyse even if my task is done ¡V He should write
        how could he do it better, his opinion about this task, how to
        improve such task implementation in future¡K

        6. Some my remarks

        Everything written above refers to developer, tester, designer and
        project manager (they should plan everything too).
        If during cycle something is changed (e.g. new tasks, which should be
        done now), we shift our tasks, some tasks get status ¡¥future¡¦ ¡V it
        means they will be done on next cycle or something like that.
        You could see in this letter some time data, so for better
        understanding of them I want to write, that in Ukraine work-day
        begins on 9:00 and finishes on 18:00. Lunch-time in our company is
        13:30-14:30.

        And now I want to hear your opinion. I hope this ¡¥story¡¦ will help
        you too.
        Thank you in advance, Max.

        PS: At the moment when this article was finished we have started
        changing our management approach. We agreed to perform a big project
        meeting before the planning - to discuss what was to be done, has
        been done, and what to do next. And then after planning ¡V a small 30-
        min meeting to synchronize what we have planned (after the planning
        and one-to-one meetings). This approach gives team members feeling of
        being more involved into a process. And it also helps to do better
        analysis of the tasks of each team member.



        Everyone is raving about the all-new Yahoo! Mail beta.

      • Steven Gordon
        Max, The description is missing the most critical piece of information necessary to determined if there is even anything wrong with this process: - Is everyone
        Message 3 of 14 , Dec 1, 2006
        • 0 Attachment
          Max,

          The description is missing the most critical piece of information
          necessary to determined if there is even anything wrong with this
          process:
          - Is everyone who counts (i.e., the stakeholders/customers) satisfied
          with the results of this process?

          If there is concrete dissatisfaction, then we need to examine what
          outcomes people are dissatisfied with and do root cause analysis to
          see where the process is causing problems that the business people
          care about.

          If, on the other hand, the business people are currently satisfied
          with the outcomes, then there is not enough motivation to facilitate
          process change anyway.

          Steve

          On 12/1/06, Max Pendyshchuk <gotischerose@...> wrote:
          >
          >
          >
          >
          >
          >
          > Hello!
          >
          > I want to describe our development process. Here are many processes
          > which are (in my opinion) not so good organized (and even very bad).
          > I tried to avoid my comments here, I will give them in replies. So I
          > would like to read your feedback – all your remarks, thoughts,
          > proposition, your experience etc. Maybe you can write how it works at
          > your company or how do you wish it should work…
          >
          > In answers, which are addressed personally to me, you can use
          > English, German, Russian, Ukrainian. You can also use some of these
          > foreign languages, if you have a good idea, but are not sure, how
          > to 'serve' it in English. For previous situation you can use some of
          > other foreign languages too, if, as you think, I could
          > understand/translate it (e.g. Dutch). The most important thing for me
          > is to understand what is wrong here, what we can improve and so on.
          >
          > This story is organized in this way – the first part is tale from one
          > of managers, the second – is my, as from one of developers. This
          > document was reread for some of other developers or managers, so I
          > think in general it is good described, but we could forget something.
          > I will describe it in my answers, if I have questions, which show
          > that we have not depicted a little.
          >
          > Part I. Manager's point of view
          >
          > 1. The Beginning of the Project
          >
          > Usually projects come without strict requirements. The specification
          > for the project is a draft document that describes project
          > functionality on the highest level.
          >
          > After establishing connections with the customers the project leader
          > studies the document, and creates a time-line for it. A project
          > manager is responsible for dividing the project into logical parts,
          > setting up the order in which these parts will be implemented
          > (priority), and for rejecting those features that cant be implemented
          > within the time-line.
          > This step includes couple of iterations. Functional description is
          > detailed a little bit, but yet explanation remains on the top level.
          >
          > After the general strategy is worked out by the project leader, we
          > gather at the project meeting and discuss what has to be done in the
          > project. That is, the project leader tells the team members what has
          > to be done. After that a first set of tasks is assigned to the
          > developers and the process switches to common development process
          > (see Common Development Process chapter).
          >
          > 2. Common Development Process
          >
          > We have agreed to use EVO as a basis for our project development
          > process.
          > So we have concepts of Cycles and Deliveries and EVO one-to-one
          > meetings and Weekly Synchronization Project Meetings. I will describe
          > our common working cycle.
          >
          > Thursday (also known as 'Big Planning Day')
          > On Thursday morning all of the project leaders have a Weekly Team
          > Management Meeting (WTMM). The following issues are discussed on the
          > meeting.
          > Previous cycle – results, what to do different (in order to discuss
          > it on the team meeting)
          > Next cycle – tasks (on the top-level) for the next cycle for each
          > developer
          >
          > After this meeting a next cycle working area letter is sent to the
          > developers. And the Big Planning begins (usually starting around
          > 16:00).
          > While planning next cycle, the team member
          > estimates his working area and breaks it into tasks, each with
          > implementation duration less than 6 hours;
          > describes details of each task: Description, Functional Requirements,
          > Implementation Ideas. Also such details as estimated implementation
          > time, reviewer and due day are filled.
          > Usually we fail to complete the planning by 18:00 Thu. So we either
          > have to stay till later (19:00 – 20:00), or the planning is
          > accomplished on Friday in the morning (in around 45 minutes).
          > During the planning process the project manager becomes the help desk
          > of the team, answering questions like "How much fields the should
          > be ..." or "I will implement this using ... Yes or No" or just "Which
          > technology should I use ..".
          > As I've already mentioned the working area for a team member is
          > described only in general, and it's his responsibility to get the
          > details. Unfortunately such details often should be discussed with
          > the customer in such case project leader becomes a 'proxy' between
          > the customer and the developer.
          > Even if the requirements come unclear we never write detailed
          > functional description as a separate document – its assumed that the
          > details are described in EVO. There is one more excuse to avoiding a
          > separate detailed functional description – it's when the project has
          > a very short time-line (2 months). It's also said that writing a
          > separate document is useless since the requirements are unclear and
          > they will change anyway.
          >
          > Friday (once called a 'Big Meeting Day')
          > The work on Friday usually starts at 9:30. At this time One-to-One
          > (121) meetings start. The 121 meeting is performed in a following
          > manner.
          > Each team member comes to a project leader and (if not forgotten) we
          > discuss the results of a previous cycle. Team member does the
          > analysis of what could have been done differently and how to improve
          > it. Then the previous cycle is closed and we proceed to the next
          > one.
          > The team member defends his planning, being reviewed by the project
          > leader. If there are any remarks the project leader sends the
          > developer back to re-plan particular part. The general spirit in our
          > company is to demand as clear and detailed plan as possible. But
          > usually I try to avoid sending people back for re-planing if the
          > remarks are minor. This sometimes makes me think that I'm not making
          > the honest effort in my job. I agree that the plan should be as clear
          > as possible, but when a person comes to defend his tasks it seems so
          > ridiculous and pedant to send him back for re-planning.
          > Those who failed to accomplish their planning the day before, hastily
          > try to accomplish it before the team meeting, and for this reason
          > usually their plan is not realistic enough (optimistic) and it misses
          > details that consume more time than it was planned.
          >
          > So in the end all team members defend their tasks and weekly team
          > meeting begins.
          > In theory this meeting is called to help us to synchronize tasks and
          > to share information (like "Kolya knows how to do that and that so
          > Vanya may ask him about that when implementing his task" etc.). It is
          > held in the following way.
          > The team gathers around one of the PC's. We start from the previous
          > cycle and TRY to analyse it. What has been done what was planned to
          > be done how to improve it next time (in case the goal wasn't
          > achieved). Some team members try to share their analysis about why it
          > went wrong.
          > Writing this I see that we act like a team of losers, always
          > searching for explanations (that is excuses) that we program
          > ourselves that it would go wrong next time and that we will have to
          > analyse it next time and explain why it was wrong. So we do our work
          > bad to have something to tell to the others on the project meeting
          > next time.
          > It's clear that a successful team have no need in explaining itself.
          > But I don't know how to break that circle of ours.
          > If a person may is involved in several projects he has to attend
          > several project meetings.
          >
          > To conclude in hours we spend: from 0:45 to 3:30 hours for the
          > planning and 2:30 for the meetings. Personally I spend 2 hours on Thu
          > (17:30 – 19:30) and 1.5 hours on Friday (9:00 – 10:30 between 121
          > meetings with my team).
          > In fact one half of Thu and one half of Friday is spent for the
          > planning process. But yet we have a hell lot to improve in our
          > planning.
          >
          > And one final remark about planning. It's demanded in English as a
          > company standard. Yet some team members have a poor level of English.
          > And sometimes we need a decipherer to understand what was meant in a
          > task. At the same time the developer explains a beautiful plan in
          > Ukrainian.
          >
          > Friday (after meetings), Monday-Wednesday, Thursday (before planning)
          > (the Development)
          > The development process is trivial enough. Developers just accomplish
          > their tasks and fill the result form.
          > The results of what has been done;
          > The still to-do in case something is incomplete or something
          > unplanned, that has to be done, arisen upon task implementation;
          > The analysis;
          > If the first two are quite transparent, the third one requires more
          > explanation. Initially this field was introduced to analyse
          > incomplete tasks: why it's incomplete, what has to be done
          > differently next time, any wise thoughts. Couple of weeks ago this
          > task became mandatory for all of the tasks, requiring "what has to be
          > done differently next time, any wise thoughts" from the developer.
          > Well I understand the psychological aspect of such an "innovation"
          > even for successful tasks. The developer will think about the results
          > and about the task one more time, maybe he will find some other
          > brilliant solution for this task and will write it down all this into
          > paper and into subconsciousness at the same time. So the next time he
          > faces the problem he will use a better solution.
          > But on practice it sometimes looks ridiculous when you have to
          > analyse sort of successful "Type a letter" tasks. Maybe for this
          > reason there is so much resistance from the team concerning this
          > innovation.
          >
          > What concerns the project managers, they usually spent a fair amount
          > of time to contact with the customer to ascertain tasks (~1h/day),
          > and to consult team members about the project (usually tactical and
          > strategy solutions to be made; some technical questions also; in
          > total ~1h/day). All the other time (14 EVO hours of 30 EVO hours /
          > week) project leaders act like a common developers.
          > On Wednesday the project managers check the completeness status on
          > tasks from the previous cycle and start rough planning of the next
          > cycle for their teams. And on Thursday the story starts all over
          > again.
          >
          > Part II. Developer's point of view
          >
          > As you have read above we use Evolutionary Project Management, by Tom
          > Gilb. Development cycle = 1 week, delivery = 2*cycle = 2 weeks. After
          > each cycle or delivery (it depends on project) we show our results to
          > the customer. Cycle begins on Friday and finishes on Thursday.
          >
          > 1. Working area
          >
          > Every Thursday I get mail with working area for the next cycle. Here
          > is some samples of tasks in mail (here are tasks for some developers,
          > nothing is omitted, I changed only some names: Project1, …, Theme1,
          > …):
          >
          > …
          > Max P. (Project1):
          > - investigate JasperIntelligence (viewlet about creation & deploy
          > simple report)
          > - deeply check all Project1 tables (mapping, questions, ETTL).
          > - ETTL & periodical jobs
          > - GA on wed 16.00
          > …
          > Natali D. (Project2):
          > - by using new DAO methods to bind them with screens (Stepan develops
          > them),
          > - after that all screens should use business logic if new methods
          > appear ask Stepan to develop.
          > - Handle all Mantis issues related with presentation layer.
          > - Finalizing one of demo screen with Ajax framework
          > …
          > Oleg M. (Project3, Project4):
          > - Finalize Per Developer Report (see mantis);
          > - Create 2 themes from existing design (Theme1, Theme2);
          > - Refactor Screen1 (remove HTML tags from Java code);
          > - Bind Screen1 to Search;
          > - Fix mantis remarks;
          > …
          >
          > 2. Planning
          >
          > After the lunch I start to analyse them splitting on tasks. Of
          > necessity I consult with project manager or other team members -> if
          > something is unclear, I ask them (e.g. tasks above like "Fix mantis
          > remarks", "…if new methods appear…" and some other from our "real
          > life") After I have set up my tasks list, I split them on smaller, if
          > it is possible, and begin to plan them according to priority (this
          > priority is set by me, if it is not indicated in mail or it is not
          > solved by team or PM). For a start, I group it by the days. E.g. on
          > Friday I'll do two tasks, for each I give 3 hours (total hours for a
          > day should be 6 hours, we plan only 6 hours from 8 working hours; we
          > leave 2 hours for helping each other (it is not our personal task, if
          > it was not planned. Sometimes we help to other developers, who
          > develop other projects, to find some bug, to help with advice – so it
          > is little unplanned tasks), coffee/tea/…, news reading etc.). For
          > each task I write
          >
          > 1)name
          > 2)description
          > 3)to which project this task belongs
          > 4)how may hours I plan to spend
          > 5)when I'll do it (date)
          > 6)how will I solve this problem / do this task – algorithms, ideas,
          > frameworks, libraries and etc.
          > 7)what is assumed as a basis – e.g. project specification, an issue
          > from bug tracker system…
          > 8)which results should I get.
          >
          > We use made by our developers tool for task registration, reporting…
          >
          > In much the same way I deal with all tasks and I get my scheduling
          > for whole cycle. For planning we have about 3.5 hours (but this time
          > depends on tasks complexity, some times it can be only 1 hour).
          > I have also to check my descriptions for clarity – each other
          > developer should understand what/when/how/�wbr>K will I do. I can ask
          > somebody to check my planning.
          >
          > 3. Plan checking
          >
          > On Friday, in the morning, project managers check our tasks. It is
          > 121 meetings. We begin as a rule from previous cycle analysis. Each
          > project manager reread planning of their team members and, if they
          > have questions/remarks developer should correct his planning. In some
          > cases he has to replan all tasks. After project manager marked all
          > tasks as checked, developer starts to implement them.
          > It is quite possible, that before or during 121 meeting project
          > manager declare, that we need to change tasks priority because of
          > customer's requirements or company project politic, and we need to
          > replan. Such situation can not be foreseen because customer can
          > change his wish for the night.
          >
          > 4. Project meeting
          >
          > As a rule, on Friday we have project meetings.
          > Every Project Meeting starts with analysing of the results of
          > previous cycle (planned week). Project Manager asks every team member
          > to make short analysis. After that team discusses next cycle: every
          > team member opens EVO tool and describes every planned task – day by
          > day. Team member explains his tasks and how he intends to do them,
          > etc. If other team members have questions for him, they ask. Usually,
          > project manager has questions, related to management process, and
          > sometimes for technical side of task. After everyone describes his
          > tasks, there is some time to estimate current project state (how
          > successfully project moves, what still to do for the release, etc).
          > Sometimes a discussion may occur between team members about
          > preferable way of implementation in some task, but usually it's more
          > like reporting about the implementation of the task to other team
          > members.
          > Project meeting we hold only if developers count is more than or
          > equal to 3 (as I have noticed). E.g. I am occupied with project,
          > which is developed by 2 programmers, so I have forgot, what does it
          > mean – project meeting 
          > It is possible, that as result of project meeting can be replaning.
          >
          > 5. Task finalizing
          > At the end of workday (or after programmer finish task), programmer
          > should write for all today's tasks results of their implementation:
          > 1)Which results have programmer got?
          > 2)How much time did programmer spend for it?
          > 3)Does source code meet the company requirements?
          > 4)Does design meet the prototype?
          > 5)Was test cases written?
          > If task was not done, developer should write how does he estimate the
          > task status (how many percents was done), what still to do. He has
          > also to analyse, why it is not done and how to avoid it in future.
          > Developer has to analyse even if my task is done – He should write
          > how could he do it better, his opinion about this task, how to
          > improve such task implementation in future…
          >
          > 6. Some my remarks
          >
          > Everything written above refers to developer, tester, designer and
          > project manager (they should plan everything too).
          > If during cycle something is changed (e.g. new tasks, which should be
          > done now), we shift our tasks, some tasks get status 'future' – it
          > means they will be done on next cycle or something like that.
          > You could see in this letter some time data, so for better
          > understanding of them I want to write, that in Ukraine work-day
          > begins on 9:00 and finishes on 18:00. Lunch-time in our company is
          > 13:30-14:30.
          >
          > And now I want to hear your opinion. I hope this 'story' will help
          > you too.
          > Thank you in advance, Max.
          >
          > PS: At the moment when this article was finished we have started
          > changing our management approach. We agreed to perform a big project
          > meeting before the planning - to discuss what was to be done, has
          > been done, and what to do next. And then after planning – a small 30-
          > min meeting to synchronize what we have planned (after the planning
          > and one-to-one meetings). This approach gives team members feeling of
          > being more involved into a process. And it also helps to do better
          > analysis of the tasks of each team member.
          >
        • Max Pendyschtschuk
          Vickydhiman schrieb: Hello Max: Is it possible to describe your process at a high level of detail rather than focussing on nitty
          Message 4 of 14 , Dec 1, 2006
          • 0 Attachment
            Vickydhiman <vickydhiman@...> schrieb:
            Hello Max:

            Is it possible to describe your process at a high level of detail rather than focussing on nitty gritty? What are guiding principles and values which drive your process?

            Thanks
            It is good request, but... After I sent my first post "I need your advice" I got feedbacks like:
             
            "...Sounds like traditional "I give you tasks, you do them" kind
            of project management, not self-organized and self-governed team..." (Petri Heiramo)
             
            "...The way I understood the main difference between his model and
            e.g. Scrum was the focus on numerically measurable goals.... I don't see that happening in
            what you describe..." (Petri Heiramo)
             
            "It sounds pretty agile, close to Scrum,
            but misses some fundamental practices (like working in a team, planning with
            the team, stand-up meetings, product owner role)" (Hubert Smits)
             
            So I want to check, that's why I described it so...
            "I need your advice" - it can be general description, but I think it is better to use cvurrent one.
             
            Thank you for interesting, Max


            Der neue Internet Explorer 7 in deutscher Ausführung ist da !

          • mpkirby
            Max, Nice post, I understand your pain. Some questions/comments. - It seems that your focus is on controlling the future. How can we get better estimates,
            Message 5 of 14 , Dec 1, 2006
            • 0 Attachment
              Max,

              Nice post, I understand your pain. Some questions/comments.

              - It seems that your focus is on controlling the future. How can we
              get better estimates, reviewing the estimates of team members, etc.
              Agile techniques aren't about predicting or controlling the future, but
              about being able to react to it.

              - Similarly we've found one of the most useful aspects of scrum is
              the demo. It's an opportunity for us to show off a bit, and to get
              feedback (yes, this is what I wanted, no it isn't). That feedback
              cycle, both in terms of a customer during planning, as well as a
              customer during the demo is really important. It seems that the project
              manager is serving in that role for your org, and perhaps that is okay,
              but it is suspicious.

              - Do you reward developers for individual performance, or group
              performance? In other words, if two developers are working on a
              deliverable, and each have tasks of their own, and one of them does an
              outstanding job on "his" tasks. And the other is much weaker and isn't
              as successful, do you consider both developers as "failing to deliver",
              or just the one that was having difficulty?

              We found as we went to scrum changing from the idea of individual
              accountability to team accountability to be one of the most difficult
              and important aspects of what we are doing. I even had to "ding" high
              performers in my organization because the team wasn't able to deliver
              (they had some behavioral issues), in spite of some outstanding personal
              performance of an individual.

              Good luck in your journey.

              Mike
            • Max Pendyschtschuk
              Hello, Steve stakeholders/customers - it isn t the only important thing. In my post I was rather talking about what developers feel by task implementation.
              Message 6 of 14 , Dec 1, 2006
              • 0 Attachment
                Hello, Steve
                 
                "stakeholders/customers" - it isn't the only important thing. In my post I was rather talking about what developers feel by task implementation. We (developers) seem to work under the constant pressure, and I want to find some better way for working with greater effictiveness in order to reduse the pressure.
                 
                Our results seem to be good now, our customers are satisfied. But in some time we will be tired off our job (burn out)
                 
                regards

                Steven Gordon <sgordonphd@...> schrieb:
                Max,

                The description is missing the most critical piece of information
                necessary to determined if there is even anything wrong with this
                process:
                - Is everyone who counts (i.e., the stakeholders/customers) satisfied
                with the results of this process?

                If there is concrete dissatisfaction, then we need to examine what
                outcomes people are dissatisfied with and do root cause analysis to
                see where the process is causing problems that the business people
                care about.

                If, on the other hand, the business people are currently satisfied
                with the outcomes, then there is not enough motivation to facilitate
                process change anyway.

                Steve


                NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.

              • Ron Jeffries
                ... Tell us more about this pressure , please. Who is providing it? How do they provide it? In a smoothly operating Agile project, pressure is not a very
                Message 7 of 14 , Dec 1, 2006
                • 0 Attachment
                  Hello, Max. On Friday, December 1, 2006, at 7:46:10 AM, you wrote:

                  > "stakeholders/customers" - it isn't the only important thing. In my post I was rather
                  > talking about what developers feel by task implementation. We (developers) seem to work
                  > under the constant pressure, and I want to find some better way for working with greater
                  > effictiveness in order to reduse the pressure.

                  Tell us more about this "pressure", please. Who is providing it? How
                  do they provide it?

                  In a smoothly operating Agile project, pressure is not a very useful
                  tool in my opinion. See, for example:

                  Doing the Impossible
                  Ron Jeffries
                  10/20/2006

                  Dogbert teaches us all a management lesson. He's even offering a
                  diploma. Is that better than a certificate?

                  http://www.xprogramming.com/xpmag/jatImpossible.htm

                  Making the Date
                  Ron Jeffries
                  11/10/2005

                  It seems like every development project begins with the date, and
                  we're held responsible for "making the date". Making the date is a
                  management responsibility, not a development responsibility.
                  Here's why.

                  Updated with cool cartoon from Simon Baker.

                  http://www.xprogramming.com/xpmag/jatMakingTheDate.htm

                  Ron Jeffries
                  www.XProgramming.com
                  The opinions expressed here /are/ necessarily those of XProgramming.com.
                  But I might change my mind.
                • Steven Gordon
                  ... My experience is that organizational cultures always resist change. Unless there is enough dissatisfaction or pain at the business or management levels,
                  Message 8 of 14 , Dec 1, 2006
                  • 0 Attachment
                    On 12/1/06, Max Pendyschtschuk <gotischerose@...> wrote:
                    >
                    >
                    >
                    >
                    >
                    >
                    > Hello, Steve
                    >
                    > "stakeholders/customers" - it isn't the only important thing. In my post I
                    > was rather talking about what developers feel by task implementation. We
                    > (developers) seem to work under the constant pressure, and I want to find
                    > some better way for working with greater effictiveness in order to reduse
                    > the pressure.
                    >
                    > Our results seem to be good now, our customers are satisfied. But in some
                    > time we will be tired off our job (burn out)
                    >

                    My experience is that organizational cultures always resist change.
                    Unless there is enough dissatisfaction or pain at the business or
                    management levels, there will not be sufficient motivation to overcome
                    resistance to change.

                    Where is the burn out coming from? When a feature is estimated to
                    take 100 hours and ends up taking 200 hours, are developers forced to
                    work twice as many hours a week to hide the issue from management and
                    customers? If so, what happens when developers refuse to hide the
                    issue any more?

                    One way to not hide it anymore is to stop working overtime and let
                    schedules slip. Another way would be to double estimates before
                    committing to a schedule. If either approach leads to pain for
                    management or customers, then there will be enough pain to get the
                    organization to consider Scrum/XP or any of the lighter weight, agile
                    processes.

                    Regards,

                    Steve
                  • Max Pendyschtschuk
                    Hello Steve, All planning is made by managers, with out developers. They don t ask (usual) – is it possible or not. What a customer wants – he will get it.
                    Message 9 of 14 , Dec 4, 2006
                    • 0 Attachment
                      Hello Steve,
                       
                      All planning is made by managers, with out developers. They don't ask (usual) – is it possible or not. What a customer wants – he will get it. Because «it's a real life»or «it's open market and we have to concur», we have a wild capitalism here so they will drink out your blood as long as you let them to. The questio it that if you want to live for work and to die «almost» rich before 40 or you want to work for living. Somethimes planning is very bad. Half year ago I got task to implement somethimg (web-application should show some message if server fault). I had two days for it, because on the third day we had project deadline. Problem here – we used new framework (Oracle ADF) on the server, I had no experience with it, another developers worked with ADF about 2 month, during project developing. When I tried to investigate server side interaction I sad that I have no idea, how to do it. I posted my question on Oracle Technical Support Forum and got no answers. My weekend I spent with developing, code investigation, books/issues reading, because on Tuesday would come deadline. I implemented it, I didn't find the best way, but it works. This messages I could implement on the start of project, there was no dependecies here, but manager thought this task is to lite. Conclusion – hard working. Later we analise this project, and manager asked us why we had such situation, and how to avoid it in the future.Funny isn't it?

                      My opinion about our management – they don't do their job. Everything they do – planning. And developers should implemented those plans of Napoleon. Maybe I have no right, just read my bi-i-ig description one more time and find here tasks of managers and tasks of developers.

                      Example above + description – developers should analise everything, previous cycle, his tasks implementation, and even planning, which was created by manager.

                      About overtime one more time. Core team for project, which I mentioned above worked sometimes on Saturday and finished their work-day at 20:00 (insteed of 18:00). Our general manager liked it, he sad it is plus of this team, their «responsibility», the «teeth of the team». Now part of this team develop another project, which seems to have Napoleon plans too. This project goes not so good, team doesn't want to work over-time. Maybe they are tired from it now. And you know what the general manager said about project progress? «It is a pity, but team didn't show it's spirit, it's teeth».
                       
                      regards, Max

                      Steven Gordon <sgordonphd@...> schrieb:
                      My experience is that organizational cultures always resist change.
                      Unless there is enough dissatisfaction or pain at the business or
                      management levels, there will not be sufficient motivation to overcome
                      resistance to change.

                      Where is the burn out coming from? When a feature is estimated to
                      take 100 hours and ends up taking 200 hours, are developers forced to
                      work twice as many hours a week to hide the issue from management and
                      customers? If so, what happens when developers refuse to hide the
                      issue any more?

                      One way to not hide it anymore is to stop working overtime and let
                      schedules slip. Another way would be to double estimates before
                      committing to a schedule. If either approach leads to pain for
                      management or customers, then there will be enough pain to get the
                      organization to consider Scrum/XP or any of the lighter weight, agile
                      processes.

                      Regards,

                      Steve




                      liebe Gruesse


                      Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail .

                    • Steven Gordon
                      ... This is the root of the problem. Under the current process, the developers pay for management mistakes instead of management or customers, so it is
                      Message 10 of 14 , Dec 5, 2006
                      • 0 Attachment
                        On 12/5/06, Max Pendyschtschuk <gotischerose@...> wrote:
                        >
                        > Hello Steve,
                        >
                        >
                        > All planning is made by managers, with out developers. They don't ask
                        > (usual) – is it possible or not. What a customer wants – he will get it.
                        > Because «it's a real life»or «it's open market and we have to concur», we
                        > have a wild capitalism here so they will drink out your blood as long as you
                        > let them to. The questio it that if you want to live for work and to die
                        > «almost» rich before 40 or you want to work for living. Somethimes planning
                        > is very bad. Half year ago I got task to implement somethimg
                        > (web-application should show some message if server fault). I had two days
                        > for it, because on the third day we had project deadline. Problem here – we
                        > used new framework (Oracle ADF) on the server, I had no experience with it,
                        > another developers worked with ADF about 2 month, during project developing.
                        > When I tried to investigate server side interaction I sad that I have no
                        > idea, how to do it. I posted my question on Oracle Technical Support Forum
                        > and got no answers. My weekend I spent with developing, code investigation,
                        > books/issues reading, because on Tuesday would come deadline. I implemented
                        > it, I didn't find the best way, but it works. This messages I could
                        > implement on the start of project, there was no dependecies here, but
                        > manager thought this task is to lite. Conclusion – hard working. Later we
                        > analise this project, and manager asked us why we had such situation, and
                        > how to avoid it in the future.Funny isn't it?
                        >
                        >
                        > My opinion about our management – they don't do their job. Everything they
                        > do – planning. And developers should implemented those plans of Napoleon.
                        > Maybe I have no right, just read my bi-i-ig description one more time and
                        > find here tasks of managers and tasks of developers.
                        >
                        >
                        > Example above + description – developers should analise everything, previous
                        > cycle, his tasks implementation, and even planning, which was created by
                        > manager.
                        >
                        >
                        > About overtime one more time. Core team for project, which I mentioned above
                        > worked sometimes on Saturday and finished their work-day at 20:00 (insteed
                        > of 18:00). Our general manager liked it, he sad it is plus of this team,
                        > their «responsibility», the «teeth of the team». Now part of this team
                        > develop another project, which seems to have Napoleon plans too. This
                        > project goes not so good, team doesn't want to work over-time. Maybe they
                        > are tired from it now. And you know what the general manager said about
                        > project progress? «It is a pity, but team didn't show it's spirit, it's
                        > teeth».

                        This is the root of the problem.

                        Under the current process, the developers pay for management mistakes
                        instead of management or customers, so it is unlikely that any other
                        process could yield better results from the narrow point of view of
                        management.

                        Unless there is a shortage of developers there willing to work this
                        way, there is no hope for change. My conclusion is that this is a
                        labor power issue rather than a process issue. Unfortunately, a
                        rational discussion of the process issues will have no practical
                        affect on your situation at all.

                        Steve

                        >
                        > regards, Max
                        >
                      • Brian Aherne
                        Hi Guys, I did a Scrum course this time last year and have tried it out for a year. It s nearly driven me and the boys here in the office half mad. Is this
                        Message 11 of 14 , Dec 5, 2006
                        • 0 Attachment
                          Hi Guys,

                          I did a Scrum course this time last year and have tried it out for a year.

                          It's nearly driven me and the boys here in the office half mad.

                          Is this really the way forward ????

                          Surely we need more structered development ?????

                          Why do we need managers and workers, sure we all on the same team aren't we
                          ??

                          Is there a better way ???

                          Brian Aherne
                          Product Development Manager
                          CombinedMedia
                          15 Irishtown Road
                          Dublin 4
                          Ireland
                          Phone : 00 353 1 6188932
                          Mobile 086 8041816

                          -----Original Message-----
                          From: scrumdevelopment@yahoogroups.com
                          [mailto:scrumdevelopment@yahoogroups.com]On Behalf Of Steven Gordon
                          Sent: 05 December 2006 12:37
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] What is wrong with this process


                          On 12/5/06, Max Pendyschtschuk <gotischerose@...> wrote:
                          >
                          > Hello Steve,
                          >
                          >
                          > All planning is made by managers, with out developers. They don't ask
                          > (usual) – is it possible or not. What a customer wants – he will get it.
                          > Because «it's a real life»or «it's open market and we have to concur», we
                          > have a wild capitalism here so they will drink out your blood as long as
                          you
                          > let them to. The questio it that if you want to live for work and to die
                          > «almost» rich before 40 or you want to work for living. Somethimes
                          planning
                          > is very bad. Half year ago I got task to implement somethimg
                          > (web-application should show some message if server fault). I had two days
                          > for it, because on the third day we had project deadline. Problem here –
                          we
                          > used new framework (Oracle ADF) on the server, I had no experience with
                          it,
                          > another developers worked with ADF about 2 month, during project
                          developing.
                          > When I tried to investigate server side interaction I sad that I have no
                          > idea, how to do it. I posted my question on Oracle Technical Support Forum
                          > and got no answers. My weekend I spent with developing, code
                          investigation,
                          > books/issues reading, because on Tuesday would come deadline. I
                          implemented
                          > it, I didn't find the best way, but it works. This messages I could
                          > implement on the start of project, there was no dependecies here, but
                          > manager thought this task is to lite. Conclusion – hard working. Later we
                          > analise this project, and manager asked us why we had such situation, and
                          > how to avoid it in the future.Funny isn't it?
                          >
                          >
                          > My opinion about our management – they don't do their job. Everything they
                          > do – planning. And developers should implemented those plans of Napoleon.
                          > Maybe I have no right, just read my bi-i-ig description one more time and
                          > find here tasks of managers and tasks of developers.
                          >
                          >
                          > Example above + description – developers should analise everything,
                          previous
                          > cycle, his tasks implementation, and even planning, which was created by
                          > manager.
                          >
                          >
                          > About overtime one more time. Core team for project, which I mentioned
                          above
                          > worked sometimes on Saturday and finished their work-day at 20:00 (insteed
                          > of 18:00). Our general manager liked it, he sad it is plus of this team,
                          > their «responsibility», the «teeth of the team». Now part of this team
                          > develop another project, which seems to have Napoleon plans too. This
                          > project goes not so good, team doesn't want to work over-time. Maybe they
                          > are tired from it now. And you know what the general manager said about
                          > project progress? «It is a pity, but team didn't show it's spirit, it's
                          > teeth».

                          This is the root of the problem.

                          Under the current process, the developers pay for management mistakes
                          instead of management or customers, so it is unlikely that any other
                          process could yield better results from the narrow point of view of
                          management.

                          Unless there is a shortage of developers there willing to work this
                          way, there is no hope for change. My conclusion is that this is a
                          labor power issue rather than a process issue. Unfortunately, a
                          rational discussion of the process issues will have no practical
                          affect on your situation at all.

                          Steve

                          >
                          > regards, Max
                          >


                          To Post a message, send it to: scrumdevelopment@...
                          To Unsubscribe, send a blank message to:
                          scrumdevelopment-unsubscribe@...
                          Yahoo! Groups Links
                        • Ken Schwaber
                          Brian ... everyone is on the same team and Scrum helps focus it. Can you tell me more about why you and the boys here are half-mad? Ken ... From:
                          Message 12 of 14 , Dec 5, 2006
                          • 0 Attachment
                            Brian ... everyone is on the same team and Scrum helps focus it. Can you
                            tell me more about why you and the boys here are half-mad?
                            Ken

                            -----Original Message-----
                            From: scrumdevelopment@yahoogroups.com
                            [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Brian Aherne
                            Sent: Tuesday, December 05, 2006 9:55 AM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: RE: [scrumdevelopment] What is wrong with this process

                            Hi Guys,

                            I did a Scrum course this time last year and have tried it out for a year.

                            It's nearly driven me and the boys here in the office half mad.

                            Is this really the way forward ????

                            Surely we need more structered development ?????

                            Why do we need managers and workers, sure we all on the same team aren't we
                            ??

                            Is there a better way ???

                            Brian Aherne
                            Product Development Manager
                            CombinedMedia
                            15 Irishtown Road
                            Dublin 4
                            Ireland
                            Phone : 00 353 1 6188932
                            Mobile 086 8041816

                            -----Original Message-----
                            From: scrumdevelopment@yahoogroups.com
                            [mailto:scrumdevelopment@yahoogroups.com]On Behalf Of Steven Gordon
                            Sent: 05 December 2006 12:37
                            To: scrumdevelopment@yahoogroups.com
                            Subject: Re: [scrumdevelopment] What is wrong with this process


                            On 12/5/06, Max Pendyschtschuk <gotischerose@...> wrote:
                            >
                            > Hello Steve,
                            >
                            >
                            > All planning is made by managers, with out developers. They don't ask
                            > (usual) - is it possible or not. What a customer wants - he will get it.
                            > Because <it's a real life>or <it's open market and we have to concur>, we
                            > have a wild capitalism here so they will drink out your blood as long as
                            you
                            > let them to. The questio it that if you want to live for work and to die
                            > <almost> rich before 40 or you want to work for living. Somethimes
                            planning
                            > is very bad. Half year ago I got task to implement somethimg
                            > (web-application should show some message if server fault). I had two days
                            > for it, because on the third day we had project deadline. Problem here -
                            we
                            > used new framework (Oracle ADF) on the server, I had no experience with
                            it,
                            > another developers worked with ADF about 2 month, during project
                            developing.
                            > When I tried to investigate server side interaction I sad that I have no
                            > idea, how to do it. I posted my question on Oracle Technical Support Forum
                            > and got no answers. My weekend I spent with developing, code
                            investigation,
                            > books/issues reading, because on Tuesday would come deadline. I
                            implemented
                            > it, I didn't find the best way, but it works. This messages I could
                            > implement on the start of project, there was no dependecies here, but
                            > manager thought this task is to lite. Conclusion - hard working. Later we
                            > analise this project, and manager asked us why we had such situation, and
                            > how to avoid it in the future.Funny isn't it?
                            >
                            >
                            > My opinion about our management - they don't do their job. Everything they
                            > do - planning. And developers should implemented those plans of Napoleon.
                            > Maybe I have no right, just read my bi-i-ig description one more time and
                            > find here tasks of managers and tasks of developers.
                            >
                            >
                            > Example above + description - developers should analise everything,
                            previous
                            > cycle, his tasks implementation, and even planning, which was created by
                            > manager.
                            >
                            >
                            > About overtime one more time. Core team for project, which I mentioned
                            above
                            > worked sometimes on Saturday and finished their work-day at 20:00 (insteed
                            > of 18:00). Our general manager liked it, he sad it is plus of this team,
                            > their <responsibility>, the <teeth of the team>. Now part of this team
                            > develop another project, which seems to have Napoleon plans too. This
                            > project goes not so good, team doesn't want to work over-time. Maybe they
                            > are tired from it now. And you know what the general manager said about
                            > project progress? <It is a pity, but team didn't show it's spirit, it's
                            > teeth>.

                            This is the root of the problem.

                            Under the current process, the developers pay for management mistakes
                            instead of management or customers, so it is unlikely that any other
                            process could yield better results from the narrow point of view of
                            management.

                            Unless there is a shortage of developers there willing to work this
                            way, there is no hope for change. My conclusion is that this is a
                            labor power issue rather than a process issue. Unfortunately, a
                            rational discussion of the process issues will have no practical
                            affect on your situation at all.

                            Steve

                            >
                            > regards, Max
                            >


                            To Post a message, send it to: scrumdevelopment@...
                            To Unsubscribe, send a blank message to:
                            scrumdevelopment-unsubscribe@...
                            Yahoo! Groups Links







                            To Post a message, send it to: scrumdevelopment@...
                            To Unsubscribe, send a blank message to:
                            scrumdevelopment-unsubscribe@...
                            Yahoo! Groups Links
                          • Max Pendyschtschuk
                            I m afraid it is really so. No chance to change something. It s a pity, but I got no advices about what is really bad in out system and how to improve it .
                            Message 13 of 14 , Dec 7, 2006
                            • 0 Attachment
                              I'm afraid it is really so. No chance to change something.
                               
                              It's a pity, but I got no advices about "what is really bad in out system and  how to improve it". So I'm going to give another questions. The first one seems to be very simple, but I don't think so now:
                               
                              what are the manager duties and what are the developer duties?

                              Steven Gordon <sgordonphd@...> schrieb:
                              On 12/5/06, Max Pendyschtschuk wrote:
                              >
                              > Hello Steve,
                              ...
                              > My opinion about our management – they don't do their job. This is the root of the problem.

                              Under the current process, the developers pay for management mistakes
                              instead of management or customers, so it is unlikely that any other
                              process could yield better results from the narrow point of view of
                              management.

                              Unless there is a shortage of developers there willing to work this
                              way, there is no hope for change. My conclusion is that this is a
                              labor power issue rather than a process issue. Unfortunately, a
                              rational discussion of the process issues will have no practical
                              affect on your situation at all.

                              Steve

                              regards,
                               
                              liebe Gruesse


                              Yahoo! 360° – Bloggen und Leute treffen. Erstellen Sie jetzt Ihre eigene Seite – kostenlos!.

                            • Max Pendyschtschuk
                              Thanks for wish to help. If you can t hekp yorself, nobody will do it - it s the trutsh of nowdays. This topic is closed. ... Was ist Glück? Schlafen Fische
                              Message 14 of 14 , Dec 9, 2006
                              • 0 Attachment
                                Thanks for wish to help. "If you can't hekp yorself, nobody will do it" - it's the trutsh of nowdays.
                                 
                                This topic is closed.


                                Was ist Glück? Schlafen Fische überhaupt? Die Antworten gibt’s auf Yahoo! Clever.
                              Your message has been successfully submitted and would be delivered to recipients shortly.