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

Re: [scrumdevelopment] What is wrong with this process

Expand Messages
  • 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 1 of 14 , Dec 1, 2006
      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 2 of 14 , Dec 1, 2006
        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 3 of 14 , Dec 1, 2006
          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 4 of 14 , Dec 1, 2006
            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 5 of 14 , Dec 1, 2006
              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 6 of 14 , Dec 1, 2006
                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 7 of 14 , Dec 4, 2006
                  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 8 of 14 , Dec 5, 2006
                    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 9 of 14 , Dec 5, 2006
                      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 10 of 14 , Dec 5, 2006
                        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 11 of 14 , Dec 7, 2006
                          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 12 of 14 , Dec 9, 2006
                            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.