What can a developer do to instill a practical team Agile mentality? [duplicate]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
-2
down vote

favorite













This question already has an answer here:



  • How can I get co-workers to buy into some of my ideas? [duplicate]

    4 answers



I have been at my new job as a contractor for about four months. Since I am very sensitive about workflow protocols and procedures, I made it a priority during the interviewing process to ask things like the SDLC culture, Agile, build processes, versioning, configuration environments, requirements gathering etc because, from personal experience, I find it easier to work in stiffer environments with a rigid structure rather than a loose, hectic one. I was told that the team was sort of Agile but not totally so I took the job hoping there is room for positive influence.



Part of the reason for my Agile inclination are my cognitive styles which partially revolve about my self-diagnosed attention deficit: I find it hard to grasp voluminous documents and requirements and instead focus on a single, atomic unit of work at a time, usually in a way that minimizes scope on the big picture. When I do something, I do one absolutely minimal thing at a time to get a sense of completion and I will usually split a task that others do all at once into many sub units. From my understanding of Agile, the methodology revolves around that concept exactly.



When I joined, it started becoming clear that most of the team members are in a complete waterfall mentality. The requirement documents are like book long whereas it is obvious they can be broken down into many atomic and almost independent sub tasks that build on top of one another. The whole requirement document is written before coding begins. I simply have a hard time reading a 50 page requirement document before I start coding because, by the time I am done reading, I will likely forget how it started. With smaller scope sub tasks, I do much better. Another example is that a functional module I have been working on contains many features that are not part of the core functionality (like "export data to Excel" and that kind of stuff) so I pushed those features in the next self-imposed sprint but requested that the QA test what has been done so far. The QA complained that I was not completely done yet so I had to explain Agile 101 to them and how things in the 21st century are done peacemeal in many different iterations to accommodate the finite nature of human cognitive and attentive powers, among other things, and make project management cleaner and more digestible, for the lack of a better term.



So, my question is, what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects? I am sure many companies that have existed more than 10-15 years have gone through this same transition and I would like to reuse their proven transition techniques, if any.




team project-management




share|improve this question














marked as duplicate by gnat, IDrinkandIKnowThings, jcmeloni, Wesley Long, DJClayworth Feb 20 '15 at 18:22


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • Does the team want to be agile, and they need help? Or do they want to do things the old way? Or do they completely not care and want to collect their paycheck?
    – Telastyn
    Feb 10 '15 at 21:13










  • everybody says they want to be Agile but it sort of sounds like a smoker saying they want to quit as they light up the next cigarette... because they are stuck in the present routine. I am asking for ideas how to kick them out of that comfort zone
    – amphibient
    Feb 10 '15 at 21:14











  • @gnat, i totally disagree this is a duplicate because my question is very specific on a certain subject as opposed to the one you linked to, which is rather vague
    – amphibient
    Feb 10 '15 at 22:04










  • meta.stackexchange.com/a/194495/165773
    – gnat
    Feb 11 '15 at 9:10






  • 1




    Honestly, you can't expect the company to change their working model because you can't comprehend 50 page document. You've written you have attention deficit, it's yours deficit, not your company. You should handle it, or expect your company to provide some accesibilites to you, but things are not simply bad only because you're unable to learn them.
    – user1023
    Feb 13 '15 at 12:33
















up vote
-2
down vote

favorite













This question already has an answer here:



  • How can I get co-workers to buy into some of my ideas? [duplicate]

    4 answers



I have been at my new job as a contractor for about four months. Since I am very sensitive about workflow protocols and procedures, I made it a priority during the interviewing process to ask things like the SDLC culture, Agile, build processes, versioning, configuration environments, requirements gathering etc because, from personal experience, I find it easier to work in stiffer environments with a rigid structure rather than a loose, hectic one. I was told that the team was sort of Agile but not totally so I took the job hoping there is room for positive influence.



Part of the reason for my Agile inclination are my cognitive styles which partially revolve about my self-diagnosed attention deficit: I find it hard to grasp voluminous documents and requirements and instead focus on a single, atomic unit of work at a time, usually in a way that minimizes scope on the big picture. When I do something, I do one absolutely minimal thing at a time to get a sense of completion and I will usually split a task that others do all at once into many sub units. From my understanding of Agile, the methodology revolves around that concept exactly.



When I joined, it started becoming clear that most of the team members are in a complete waterfall mentality. The requirement documents are like book long whereas it is obvious they can be broken down into many atomic and almost independent sub tasks that build on top of one another. The whole requirement document is written before coding begins. I simply have a hard time reading a 50 page requirement document before I start coding because, by the time I am done reading, I will likely forget how it started. With smaller scope sub tasks, I do much better. Another example is that a functional module I have been working on contains many features that are not part of the core functionality (like "export data to Excel" and that kind of stuff) so I pushed those features in the next self-imposed sprint but requested that the QA test what has been done so far. The QA complained that I was not completely done yet so I had to explain Agile 101 to them and how things in the 21st century are done peacemeal in many different iterations to accommodate the finite nature of human cognitive and attentive powers, among other things, and make project management cleaner and more digestible, for the lack of a better term.



So, my question is, what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects? I am sure many companies that have existed more than 10-15 years have gone through this same transition and I would like to reuse their proven transition techniques, if any.




team project-management




share|improve this question














marked as duplicate by gnat, IDrinkandIKnowThings, jcmeloni, Wesley Long, DJClayworth Feb 20 '15 at 18:22


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • Does the team want to be agile, and they need help? Or do they want to do things the old way? Or do they completely not care and want to collect their paycheck?
    – Telastyn
    Feb 10 '15 at 21:13










  • everybody says they want to be Agile but it sort of sounds like a smoker saying they want to quit as they light up the next cigarette... because they are stuck in the present routine. I am asking for ideas how to kick them out of that comfort zone
    – amphibient
    Feb 10 '15 at 21:14











  • @gnat, i totally disagree this is a duplicate because my question is very specific on a certain subject as opposed to the one you linked to, which is rather vague
    – amphibient
    Feb 10 '15 at 22:04










  • meta.stackexchange.com/a/194495/165773
    – gnat
    Feb 11 '15 at 9:10






  • 1




    Honestly, you can't expect the company to change their working model because you can't comprehend 50 page document. You've written you have attention deficit, it's yours deficit, not your company. You should handle it, or expect your company to provide some accesibilites to you, but things are not simply bad only because you're unable to learn them.
    – user1023
    Feb 13 '15 at 12:33












up vote
-2
down vote

favorite









up vote
-2
down vote

favorite












This question already has an answer here:



  • How can I get co-workers to buy into some of my ideas? [duplicate]

    4 answers



I have been at my new job as a contractor for about four months. Since I am very sensitive about workflow protocols and procedures, I made it a priority during the interviewing process to ask things like the SDLC culture, Agile, build processes, versioning, configuration environments, requirements gathering etc because, from personal experience, I find it easier to work in stiffer environments with a rigid structure rather than a loose, hectic one. I was told that the team was sort of Agile but not totally so I took the job hoping there is room for positive influence.



Part of the reason for my Agile inclination are my cognitive styles which partially revolve about my self-diagnosed attention deficit: I find it hard to grasp voluminous documents and requirements and instead focus on a single, atomic unit of work at a time, usually in a way that minimizes scope on the big picture. When I do something, I do one absolutely minimal thing at a time to get a sense of completion and I will usually split a task that others do all at once into many sub units. From my understanding of Agile, the methodology revolves around that concept exactly.



When I joined, it started becoming clear that most of the team members are in a complete waterfall mentality. The requirement documents are like book long whereas it is obvious they can be broken down into many atomic and almost independent sub tasks that build on top of one another. The whole requirement document is written before coding begins. I simply have a hard time reading a 50 page requirement document before I start coding because, by the time I am done reading, I will likely forget how it started. With smaller scope sub tasks, I do much better. Another example is that a functional module I have been working on contains many features that are not part of the core functionality (like "export data to Excel" and that kind of stuff) so I pushed those features in the next self-imposed sprint but requested that the QA test what has been done so far. The QA complained that I was not completely done yet so I had to explain Agile 101 to them and how things in the 21st century are done peacemeal in many different iterations to accommodate the finite nature of human cognitive and attentive powers, among other things, and make project management cleaner and more digestible, for the lack of a better term.



So, my question is, what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects? I am sure many companies that have existed more than 10-15 years have gone through this same transition and I would like to reuse their proven transition techniques, if any.




team project-management




share|improve this question















This question already has an answer here:



  • How can I get co-workers to buy into some of my ideas? [duplicate]

    4 answers



I have been at my new job as a contractor for about four months. Since I am very sensitive about workflow protocols and procedures, I made it a priority during the interviewing process to ask things like the SDLC culture, Agile, build processes, versioning, configuration environments, requirements gathering etc because, from personal experience, I find it easier to work in stiffer environments with a rigid structure rather than a loose, hectic one. I was told that the team was sort of Agile but not totally so I took the job hoping there is room for positive influence.



Part of the reason for my Agile inclination are my cognitive styles which partially revolve about my self-diagnosed attention deficit: I find it hard to grasp voluminous documents and requirements and instead focus on a single, atomic unit of work at a time, usually in a way that minimizes scope on the big picture. When I do something, I do one absolutely minimal thing at a time to get a sense of completion and I will usually split a task that others do all at once into many sub units. From my understanding of Agile, the methodology revolves around that concept exactly.



When I joined, it started becoming clear that most of the team members are in a complete waterfall mentality. The requirement documents are like book long whereas it is obvious they can be broken down into many atomic and almost independent sub tasks that build on top of one another. The whole requirement document is written before coding begins. I simply have a hard time reading a 50 page requirement document before I start coding because, by the time I am done reading, I will likely forget how it started. With smaller scope sub tasks, I do much better. Another example is that a functional module I have been working on contains many features that are not part of the core functionality (like "export data to Excel" and that kind of stuff) so I pushed those features in the next self-imposed sprint but requested that the QA test what has been done so far. The QA complained that I was not completely done yet so I had to explain Agile 101 to them and how things in the 21st century are done peacemeal in many different iterations to accommodate the finite nature of human cognitive and attentive powers, among other things, and make project management cleaner and more digestible, for the lack of a better term.



So, my question is, what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects? I am sure many companies that have existed more than 10-15 years have gone through this same transition and I would like to reuse their proven transition techniques, if any.





This question already has an answer here:



  • How can I get co-workers to buy into some of my ideas? [duplicate]

    4 answers





team project-management





share|improve this question













share|improve this question




share|improve this question








edited Feb 10 '15 at 21:10

























asked Feb 10 '15 at 21:04









amphibient

3,20772441




3,20772441




marked as duplicate by gnat, IDrinkandIKnowThings, jcmeloni, Wesley Long, DJClayworth Feb 20 '15 at 18:22


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






marked as duplicate by gnat, IDrinkandIKnowThings, jcmeloni, Wesley Long, DJClayworth Feb 20 '15 at 18:22


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.













  • Does the team want to be agile, and they need help? Or do they want to do things the old way? Or do they completely not care and want to collect their paycheck?
    – Telastyn
    Feb 10 '15 at 21:13










  • everybody says they want to be Agile but it sort of sounds like a smoker saying they want to quit as they light up the next cigarette... because they are stuck in the present routine. I am asking for ideas how to kick them out of that comfort zone
    – amphibient
    Feb 10 '15 at 21:14











  • @gnat, i totally disagree this is a duplicate because my question is very specific on a certain subject as opposed to the one you linked to, which is rather vague
    – amphibient
    Feb 10 '15 at 22:04










  • meta.stackexchange.com/a/194495/165773
    – gnat
    Feb 11 '15 at 9:10






  • 1




    Honestly, you can't expect the company to change their working model because you can't comprehend 50 page document. You've written you have attention deficit, it's yours deficit, not your company. You should handle it, or expect your company to provide some accesibilites to you, but things are not simply bad only because you're unable to learn them.
    – user1023
    Feb 13 '15 at 12:33
















  • Does the team want to be agile, and they need help? Or do they want to do things the old way? Or do they completely not care and want to collect their paycheck?
    – Telastyn
    Feb 10 '15 at 21:13










  • everybody says they want to be Agile but it sort of sounds like a smoker saying they want to quit as they light up the next cigarette... because they are stuck in the present routine. I am asking for ideas how to kick them out of that comfort zone
    – amphibient
    Feb 10 '15 at 21:14











  • @gnat, i totally disagree this is a duplicate because my question is very specific on a certain subject as opposed to the one you linked to, which is rather vague
    – amphibient
    Feb 10 '15 at 22:04










  • meta.stackexchange.com/a/194495/165773
    – gnat
    Feb 11 '15 at 9:10






  • 1




    Honestly, you can't expect the company to change their working model because you can't comprehend 50 page document. You've written you have attention deficit, it's yours deficit, not your company. You should handle it, or expect your company to provide some accesibilites to you, but things are not simply bad only because you're unable to learn them.
    – user1023
    Feb 13 '15 at 12:33















Does the team want to be agile, and they need help? Or do they want to do things the old way? Or do they completely not care and want to collect their paycheck?
– Telastyn
Feb 10 '15 at 21:13




Does the team want to be agile, and they need help? Or do they want to do things the old way? Or do they completely not care and want to collect their paycheck?
– Telastyn
Feb 10 '15 at 21:13












everybody says they want to be Agile but it sort of sounds like a smoker saying they want to quit as they light up the next cigarette... because they are stuck in the present routine. I am asking for ideas how to kick them out of that comfort zone
– amphibient
Feb 10 '15 at 21:14





everybody says they want to be Agile but it sort of sounds like a smoker saying they want to quit as they light up the next cigarette... because they are stuck in the present routine. I am asking for ideas how to kick them out of that comfort zone
– amphibient
Feb 10 '15 at 21:14













@gnat, i totally disagree this is a duplicate because my question is very specific on a certain subject as opposed to the one you linked to, which is rather vague
– amphibient
Feb 10 '15 at 22:04




@gnat, i totally disagree this is a duplicate because my question is very specific on a certain subject as opposed to the one you linked to, which is rather vague
– amphibient
Feb 10 '15 at 22:04












meta.stackexchange.com/a/194495/165773
– gnat
Feb 11 '15 at 9:10




meta.stackexchange.com/a/194495/165773
– gnat
Feb 11 '15 at 9:10




1




1




Honestly, you can't expect the company to change their working model because you can't comprehend 50 page document. You've written you have attention deficit, it's yours deficit, not your company. You should handle it, or expect your company to provide some accesibilites to you, but things are not simply bad only because you're unable to learn them.
– user1023
Feb 13 '15 at 12:33




Honestly, you can't expect the company to change their working model because you can't comprehend 50 page document. You've written you have attention deficit, it's yours deficit, not your company. You should handle it, or expect your company to provide some accesibilites to you, but things are not simply bad only because you're unable to learn them.
– user1023
Feb 13 '15 at 12:33










3 Answers
3






active

oldest

votes

















up vote
4
down vote













Clarity



First thing I'd like to clarify Agile is not necessarily better than Waterfall, and waterfall is not necessarily better than agile. Depending on your projects sometimes one methodology just makes more sense than the other.



The Problem



The problem they are dealing with is actually more they don't understand what agile is. Likely they consider themselves "kinda agile" because don't know what agile is, but do one or two things that agile companies do like hold daily scrum meetings.



First Step, Respect



You can't force change on anyone, people will only change if they see it as benefitting them. This is almost always the hardest sell in any change to a company culture. (And what you're proposing is a HUGE culture change, one we both agree is worth making, but I warn you now this will be a VERY slow process.)



Before you can really influence any sort of change in your company you need to earn a certain level of respect by those this would effect. This doesn't mean they have to like you or be your friend, only that they respect if you're taking the time to do this it's with good reason. Until you have this your chances of success are negligible. (you might already have earned this, but it's pretty rare for someone new to a company to have this sort of pull)



Second Sell It!



In this case you're a salesman, you're selling an idea / concept. The key to making sales is making the customer want your product. If they don't really want it, they won't buy it.



So how do you "Sell" Agile. This depends on the individuals and the company culture at large. Each person has their own drives, needs, and desires in regards to how they work. Some people want to receive their working order and just disappear for a week or two before turning it in and repeating this. Others like to vet out every little detail and nuance of a task in advance as a group. Both of these extremes can be very happy under agile, but how you sell them agile will have very different approaches.



The quiet worker



Agile has some social expectations that may not be present in the company as it stands. Daily Scrum meetings for example. Trying to sell the quiet working with this will only make them run kicking and screaming. That's literally the opposite of what they want.



On the other hand they HATE their boss constantly asking is their work done, what's the status on this, scheduling meetings to address that task that's ten steps later because it needs to be adapted due to an issue found at the current step, etc.



The Scrum board handles the lion's share of this! Once the boss is comfortable with the board they'll only bother the quiet developer when needed, and just skip to the board for the other stuff.



Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once.



That will make the quiet worker happy. They can get their work and do it without constant interruptions!



The Collective Worker



For the other extreme their are people who prefer to work in teams and favor pair programming and working in tandem with others over isolation. Agile works for them too! If you describe what you just said to the quiet worker they might like it, or it might completely disinterest them. Not that they'd hate it, just it's not very exciting.



For these people the sprint planning and daily scrum can be big sells! No more running people down to check on things! no more bothering people when you need that second pair of eyes. Collective brainstorming of something particularly troublesome needed? No problem! bring it up in the daily scrum meeting and take it offline right afterwards!



Being able to readily access the necessary people to get your work done is a huge sell to the collective worker.



Many many people



There are literally limitless variations in personalities. Some will be easy to sell on agile, others will be very difficult. You need to figure out what a person likes and dislikes work wise to figure out how to get them on your team. Note, you DO NOT need everyone on board, you just need to have the overall momentum in support of implementing proper agile.



Lead by example



Okay, so you've got a good amount of support now. They people want agile... but where do you start? This is where things get tricky. Very few managers will just go off and change their processes, but here's a fun fact you do NOT need your manager to change most of your processes, only a select few.



In this case you should start leading by example. You want to get a proper scrum board? set one up for yourself that is publicly visible. Once some of the other pro agile teammates see it they'll want one. This will naturally lead you to consolidate this into a single board. Once most of the team is already on the board you can start to win get management in on it which can help get those you weren't able to win over into using it. (expect resistance as well, try to win them over, but if you can't management can bring them in line once they're sold on the idea, hopefully though you can win everyone over, or at the minimum get them to reluctantly tolerate it)



Once you've got that board in place you move on to the next process, overtime you slowly convert to being closer and closer to true agile. As you convince management they want what you're selling you can start selling them on breaking things down into more manageable pieces and walla! you're agile!



Cautionary Note



As stated before. Agile isn't necessarily right for everyone / everything. In some cases resistance to true agile will be unmovable. Perhaps the CEO likes planning everything from A to Z and has no interest in breaking it down. In such a case the switch to agile is likely doomed from the start. (At best grim)



If there is a clear resistance to agile practices you need to be careful to not get yourself branded as uncooperative, a trouble maker, etc. Sometimes being the person who swims against the flow to create change is the best thing that can happen to a company. Other times it's a fast track to a pink slip. Make sure people overall want this change and aren't having it forced on them. One is a good thing, the other is going to be messy at best.



Good luck. I've converted three departments I've working in to agile/scrum. It's a long road, and there is no guarantee of success, but it can be worth it.






share|improve this answer






















  • one of my favorite sentences above is: Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once. which summarizes my love for Agile/Scrum
    – amphibient
    Feb 10 '15 at 21:51











  • @amphibient Yeah, replanning time is a great counter agreement for if management they show concern with all the meeting agile adds to the table. Overall the planning time is actually similar, but waterfall typically has a lot more back tracking than agile.
    – RualStorge
    Feb 10 '15 at 22:02










  • yes but it's almost impossible (unless you are clairvoyant) to plan step 10 while you are in step 1. step 7 or 8 maybe
    – amphibient
    Feb 10 '15 at 22:08






  • 1




    Actually there are some companies who excel at waterfall and planning things absurdly far down the line, but they are EXTREMELY rare. This is know as "clear room development" and only a handful of teams through out the world work in this manner. (they tend to have near zealot depth of both planning and code quality enforcement) The best known of these teams was the team that worked NASA's space shuttle's life support systems. They can't work in agile where adaption occurs as you go. When someone presses launch it either works, or hundreds of millions of dollars and several lives are lost.
    – RualStorge
    Feb 13 '15 at 15:32










  • i understand their case. also, building/construction projects are pretty much always waterfall, you need to have the whole building drawn out down to a power receptacle before you dig the first lump of dirt for the foundation (or is done like that). however, that is not our case...
    – amphibient
    Feb 13 '15 at 16:00

















up vote
3
down vote














what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects?




As a peer? Not much in my experience.



You can inform them about this new stuff. You can say how awesome it was. But at this point, if they've not migrated it's not because they've somehow not heard that there's this agile thing that is awesome. There is likely apathy or organizational impediments to changing. There might even be real business reasons to do waterfall, but that's unlikely.



A better approach would be to convince the boss. They (or you, if you're the boss) can then work with their boss to work with project management and QA and... you need to get high enough that some person can say - we shall be agile and has enough clout to do the education/correction/punishment necessary to make it work.



How to do that? In my experience, (and perhaps because I'm an overly critical person) I focus on the pain. Why is your current process painful? Do big requirements lead to slow development time? A lot of wasted time in meetings?



Explain how your solution will make this pain better. In my experience, people put more credence in the pain they feel every day than the hopeful future of some fad.






share|improve this answer



























    up vote
    2
    down vote













    Companies, departments and teams have inertia, just like physical moving objects. You need to change the direction of this inertia. The challenge lies in determining if they are a rolling ball or a tank. Seems like the latter to me.



    Do you have management buy-in? If you do, I would suggest setting up some mini-training sessions to better expose them to what Agile really is, sounds like they know the name but not the process. When they have had a chance to digest that, try to run a single project with the Agile model and let them slowly experience the difference.



    If you don't have buy-in, the best you can do is gently point out some of the benefits and try to work as Agile-ly as you can for your work so they can see how it can improve the process. Hopefully they will be convinced of the difference and begin adopting.



    This is not going to be an easy transition even if they are fully on-board, there is plenty to "un-learn" and lots to learn. Give it time and be gentle, if you make it a battle, human nature is likely to make them fight you automatically. You also need to understand that this may never work out. Not every group is adaptable and willing to change.






    share|improve this answer



























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      4
      down vote













      Clarity



      First thing I'd like to clarify Agile is not necessarily better than Waterfall, and waterfall is not necessarily better than agile. Depending on your projects sometimes one methodology just makes more sense than the other.



      The Problem



      The problem they are dealing with is actually more they don't understand what agile is. Likely they consider themselves "kinda agile" because don't know what agile is, but do one or two things that agile companies do like hold daily scrum meetings.



      First Step, Respect



      You can't force change on anyone, people will only change if they see it as benefitting them. This is almost always the hardest sell in any change to a company culture. (And what you're proposing is a HUGE culture change, one we both agree is worth making, but I warn you now this will be a VERY slow process.)



      Before you can really influence any sort of change in your company you need to earn a certain level of respect by those this would effect. This doesn't mean they have to like you or be your friend, only that they respect if you're taking the time to do this it's with good reason. Until you have this your chances of success are negligible. (you might already have earned this, but it's pretty rare for someone new to a company to have this sort of pull)



      Second Sell It!



      In this case you're a salesman, you're selling an idea / concept. The key to making sales is making the customer want your product. If they don't really want it, they won't buy it.



      So how do you "Sell" Agile. This depends on the individuals and the company culture at large. Each person has their own drives, needs, and desires in regards to how they work. Some people want to receive their working order and just disappear for a week or two before turning it in and repeating this. Others like to vet out every little detail and nuance of a task in advance as a group. Both of these extremes can be very happy under agile, but how you sell them agile will have very different approaches.



      The quiet worker



      Agile has some social expectations that may not be present in the company as it stands. Daily Scrum meetings for example. Trying to sell the quiet working with this will only make them run kicking and screaming. That's literally the opposite of what they want.



      On the other hand they HATE their boss constantly asking is their work done, what's the status on this, scheduling meetings to address that task that's ten steps later because it needs to be adapted due to an issue found at the current step, etc.



      The Scrum board handles the lion's share of this! Once the boss is comfortable with the board they'll only bother the quiet developer when needed, and just skip to the board for the other stuff.



      Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once.



      That will make the quiet worker happy. They can get their work and do it without constant interruptions!



      The Collective Worker



      For the other extreme their are people who prefer to work in teams and favor pair programming and working in tandem with others over isolation. Agile works for them too! If you describe what you just said to the quiet worker they might like it, or it might completely disinterest them. Not that they'd hate it, just it's not very exciting.



      For these people the sprint planning and daily scrum can be big sells! No more running people down to check on things! no more bothering people when you need that second pair of eyes. Collective brainstorming of something particularly troublesome needed? No problem! bring it up in the daily scrum meeting and take it offline right afterwards!



      Being able to readily access the necessary people to get your work done is a huge sell to the collective worker.



      Many many people



      There are literally limitless variations in personalities. Some will be easy to sell on agile, others will be very difficult. You need to figure out what a person likes and dislikes work wise to figure out how to get them on your team. Note, you DO NOT need everyone on board, you just need to have the overall momentum in support of implementing proper agile.



      Lead by example



      Okay, so you've got a good amount of support now. They people want agile... but where do you start? This is where things get tricky. Very few managers will just go off and change their processes, but here's a fun fact you do NOT need your manager to change most of your processes, only a select few.



      In this case you should start leading by example. You want to get a proper scrum board? set one up for yourself that is publicly visible. Once some of the other pro agile teammates see it they'll want one. This will naturally lead you to consolidate this into a single board. Once most of the team is already on the board you can start to win get management in on it which can help get those you weren't able to win over into using it. (expect resistance as well, try to win them over, but if you can't management can bring them in line once they're sold on the idea, hopefully though you can win everyone over, or at the minimum get them to reluctantly tolerate it)



      Once you've got that board in place you move on to the next process, overtime you slowly convert to being closer and closer to true agile. As you convince management they want what you're selling you can start selling them on breaking things down into more manageable pieces and walla! you're agile!



      Cautionary Note



      As stated before. Agile isn't necessarily right for everyone / everything. In some cases resistance to true agile will be unmovable. Perhaps the CEO likes planning everything from A to Z and has no interest in breaking it down. In such a case the switch to agile is likely doomed from the start. (At best grim)



      If there is a clear resistance to agile practices you need to be careful to not get yourself branded as uncooperative, a trouble maker, etc. Sometimes being the person who swims against the flow to create change is the best thing that can happen to a company. Other times it's a fast track to a pink slip. Make sure people overall want this change and aren't having it forced on them. One is a good thing, the other is going to be messy at best.



      Good luck. I've converted three departments I've working in to agile/scrum. It's a long road, and there is no guarantee of success, but it can be worth it.






      share|improve this answer






















      • one of my favorite sentences above is: Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once. which summarizes my love for Agile/Scrum
        – amphibient
        Feb 10 '15 at 21:51











      • @amphibient Yeah, replanning time is a great counter agreement for if management they show concern with all the meeting agile adds to the table. Overall the planning time is actually similar, but waterfall typically has a lot more back tracking than agile.
        – RualStorge
        Feb 10 '15 at 22:02










      • yes but it's almost impossible (unless you are clairvoyant) to plan step 10 while you are in step 1. step 7 or 8 maybe
        – amphibient
        Feb 10 '15 at 22:08






      • 1




        Actually there are some companies who excel at waterfall and planning things absurdly far down the line, but they are EXTREMELY rare. This is know as "clear room development" and only a handful of teams through out the world work in this manner. (they tend to have near zealot depth of both planning and code quality enforcement) The best known of these teams was the team that worked NASA's space shuttle's life support systems. They can't work in agile where adaption occurs as you go. When someone presses launch it either works, or hundreds of millions of dollars and several lives are lost.
        – RualStorge
        Feb 13 '15 at 15:32










      • i understand their case. also, building/construction projects are pretty much always waterfall, you need to have the whole building drawn out down to a power receptacle before you dig the first lump of dirt for the foundation (or is done like that). however, that is not our case...
        – amphibient
        Feb 13 '15 at 16:00














      up vote
      4
      down vote













      Clarity



      First thing I'd like to clarify Agile is not necessarily better than Waterfall, and waterfall is not necessarily better than agile. Depending on your projects sometimes one methodology just makes more sense than the other.



      The Problem



      The problem they are dealing with is actually more they don't understand what agile is. Likely they consider themselves "kinda agile" because don't know what agile is, but do one or two things that agile companies do like hold daily scrum meetings.



      First Step, Respect



      You can't force change on anyone, people will only change if they see it as benefitting them. This is almost always the hardest sell in any change to a company culture. (And what you're proposing is a HUGE culture change, one we both agree is worth making, but I warn you now this will be a VERY slow process.)



      Before you can really influence any sort of change in your company you need to earn a certain level of respect by those this would effect. This doesn't mean they have to like you or be your friend, only that they respect if you're taking the time to do this it's with good reason. Until you have this your chances of success are negligible. (you might already have earned this, but it's pretty rare for someone new to a company to have this sort of pull)



      Second Sell It!



      In this case you're a salesman, you're selling an idea / concept. The key to making sales is making the customer want your product. If they don't really want it, they won't buy it.



      So how do you "Sell" Agile. This depends on the individuals and the company culture at large. Each person has their own drives, needs, and desires in regards to how they work. Some people want to receive their working order and just disappear for a week or two before turning it in and repeating this. Others like to vet out every little detail and nuance of a task in advance as a group. Both of these extremes can be very happy under agile, but how you sell them agile will have very different approaches.



      The quiet worker



      Agile has some social expectations that may not be present in the company as it stands. Daily Scrum meetings for example. Trying to sell the quiet working with this will only make them run kicking and screaming. That's literally the opposite of what they want.



      On the other hand they HATE their boss constantly asking is their work done, what's the status on this, scheduling meetings to address that task that's ten steps later because it needs to be adapted due to an issue found at the current step, etc.



      The Scrum board handles the lion's share of this! Once the boss is comfortable with the board they'll only bother the quiet developer when needed, and just skip to the board for the other stuff.



      Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once.



      That will make the quiet worker happy. They can get their work and do it without constant interruptions!



      The Collective Worker



      For the other extreme their are people who prefer to work in teams and favor pair programming and working in tandem with others over isolation. Agile works for them too! If you describe what you just said to the quiet worker they might like it, or it might completely disinterest them. Not that they'd hate it, just it's not very exciting.



      For these people the sprint planning and daily scrum can be big sells! No more running people down to check on things! no more bothering people when you need that second pair of eyes. Collective brainstorming of something particularly troublesome needed? No problem! bring it up in the daily scrum meeting and take it offline right afterwards!



      Being able to readily access the necessary people to get your work done is a huge sell to the collective worker.



      Many many people



      There are literally limitless variations in personalities. Some will be easy to sell on agile, others will be very difficult. You need to figure out what a person likes and dislikes work wise to figure out how to get them on your team. Note, you DO NOT need everyone on board, you just need to have the overall momentum in support of implementing proper agile.



      Lead by example



      Okay, so you've got a good amount of support now. They people want agile... but where do you start? This is where things get tricky. Very few managers will just go off and change their processes, but here's a fun fact you do NOT need your manager to change most of your processes, only a select few.



      In this case you should start leading by example. You want to get a proper scrum board? set one up for yourself that is publicly visible. Once some of the other pro agile teammates see it they'll want one. This will naturally lead you to consolidate this into a single board. Once most of the team is already on the board you can start to win get management in on it which can help get those you weren't able to win over into using it. (expect resistance as well, try to win them over, but if you can't management can bring them in line once they're sold on the idea, hopefully though you can win everyone over, or at the minimum get them to reluctantly tolerate it)



      Once you've got that board in place you move on to the next process, overtime you slowly convert to being closer and closer to true agile. As you convince management they want what you're selling you can start selling them on breaking things down into more manageable pieces and walla! you're agile!



      Cautionary Note



      As stated before. Agile isn't necessarily right for everyone / everything. In some cases resistance to true agile will be unmovable. Perhaps the CEO likes planning everything from A to Z and has no interest in breaking it down. In such a case the switch to agile is likely doomed from the start. (At best grim)



      If there is a clear resistance to agile practices you need to be careful to not get yourself branded as uncooperative, a trouble maker, etc. Sometimes being the person who swims against the flow to create change is the best thing that can happen to a company. Other times it's a fast track to a pink slip. Make sure people overall want this change and aren't having it forced on them. One is a good thing, the other is going to be messy at best.



      Good luck. I've converted three departments I've working in to agile/scrum. It's a long road, and there is no guarantee of success, but it can be worth it.






      share|improve this answer






















      • one of my favorite sentences above is: Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once. which summarizes my love for Agile/Scrum
        – amphibient
        Feb 10 '15 at 21:51











      • @amphibient Yeah, replanning time is a great counter agreement for if management they show concern with all the meeting agile adds to the table. Overall the planning time is actually similar, but waterfall typically has a lot more back tracking than agile.
        – RualStorge
        Feb 10 '15 at 22:02










      • yes but it's almost impossible (unless you are clairvoyant) to plan step 10 while you are in step 1. step 7 or 8 maybe
        – amphibient
        Feb 10 '15 at 22:08






      • 1




        Actually there are some companies who excel at waterfall and planning things absurdly far down the line, but they are EXTREMELY rare. This is know as "clear room development" and only a handful of teams through out the world work in this manner. (they tend to have near zealot depth of both planning and code quality enforcement) The best known of these teams was the team that worked NASA's space shuttle's life support systems. They can't work in agile where adaption occurs as you go. When someone presses launch it either works, or hundreds of millions of dollars and several lives are lost.
        – RualStorge
        Feb 13 '15 at 15:32










      • i understand their case. also, building/construction projects are pretty much always waterfall, you need to have the whole building drawn out down to a power receptacle before you dig the first lump of dirt for the foundation (or is done like that). however, that is not our case...
        – amphibient
        Feb 13 '15 at 16:00












      up vote
      4
      down vote










      up vote
      4
      down vote









      Clarity



      First thing I'd like to clarify Agile is not necessarily better than Waterfall, and waterfall is not necessarily better than agile. Depending on your projects sometimes one methodology just makes more sense than the other.



      The Problem



      The problem they are dealing with is actually more they don't understand what agile is. Likely they consider themselves "kinda agile" because don't know what agile is, but do one or two things that agile companies do like hold daily scrum meetings.



      First Step, Respect



      You can't force change on anyone, people will only change if they see it as benefitting them. This is almost always the hardest sell in any change to a company culture. (And what you're proposing is a HUGE culture change, one we both agree is worth making, but I warn you now this will be a VERY slow process.)



      Before you can really influence any sort of change in your company you need to earn a certain level of respect by those this would effect. This doesn't mean they have to like you or be your friend, only that they respect if you're taking the time to do this it's with good reason. Until you have this your chances of success are negligible. (you might already have earned this, but it's pretty rare for someone new to a company to have this sort of pull)



      Second Sell It!



      In this case you're a salesman, you're selling an idea / concept. The key to making sales is making the customer want your product. If they don't really want it, they won't buy it.



      So how do you "Sell" Agile. This depends on the individuals and the company culture at large. Each person has their own drives, needs, and desires in regards to how they work. Some people want to receive their working order and just disappear for a week or two before turning it in and repeating this. Others like to vet out every little detail and nuance of a task in advance as a group. Both of these extremes can be very happy under agile, but how you sell them agile will have very different approaches.



      The quiet worker



      Agile has some social expectations that may not be present in the company as it stands. Daily Scrum meetings for example. Trying to sell the quiet working with this will only make them run kicking and screaming. That's literally the opposite of what they want.



      On the other hand they HATE their boss constantly asking is their work done, what's the status on this, scheduling meetings to address that task that's ten steps later because it needs to be adapted due to an issue found at the current step, etc.



      The Scrum board handles the lion's share of this! Once the boss is comfortable with the board they'll only bother the quiet developer when needed, and just skip to the board for the other stuff.



      Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once.



      That will make the quiet worker happy. They can get their work and do it without constant interruptions!



      The Collective Worker



      For the other extreme their are people who prefer to work in teams and favor pair programming and working in tandem with others over isolation. Agile works for them too! If you describe what you just said to the quiet worker they might like it, or it might completely disinterest them. Not that they'd hate it, just it's not very exciting.



      For these people the sprint planning and daily scrum can be big sells! No more running people down to check on things! no more bothering people when you need that second pair of eyes. Collective brainstorming of something particularly troublesome needed? No problem! bring it up in the daily scrum meeting and take it offline right afterwards!



      Being able to readily access the necessary people to get your work done is a huge sell to the collective worker.



      Many many people



      There are literally limitless variations in personalities. Some will be easy to sell on agile, others will be very difficult. You need to figure out what a person likes and dislikes work wise to figure out how to get them on your team. Note, you DO NOT need everyone on board, you just need to have the overall momentum in support of implementing proper agile.



      Lead by example



      Okay, so you've got a good amount of support now. They people want agile... but where do you start? This is where things get tricky. Very few managers will just go off and change their processes, but here's a fun fact you do NOT need your manager to change most of your processes, only a select few.



      In this case you should start leading by example. You want to get a proper scrum board? set one up for yourself that is publicly visible. Once some of the other pro agile teammates see it they'll want one. This will naturally lead you to consolidate this into a single board. Once most of the team is already on the board you can start to win get management in on it which can help get those you weren't able to win over into using it. (expect resistance as well, try to win them over, but if you can't management can bring them in line once they're sold on the idea, hopefully though you can win everyone over, or at the minimum get them to reluctantly tolerate it)



      Once you've got that board in place you move on to the next process, overtime you slowly convert to being closer and closer to true agile. As you convince management they want what you're selling you can start selling them on breaking things down into more manageable pieces and walla! you're agile!



      Cautionary Note



      As stated before. Agile isn't necessarily right for everyone / everything. In some cases resistance to true agile will be unmovable. Perhaps the CEO likes planning everything from A to Z and has no interest in breaking it down. In such a case the switch to agile is likely doomed from the start. (At best grim)



      If there is a clear resistance to agile practices you need to be careful to not get yourself branded as uncooperative, a trouble maker, etc. Sometimes being the person who swims against the flow to create change is the best thing that can happen to a company. Other times it's a fast track to a pink slip. Make sure people overall want this change and aren't having it forced on them. One is a good thing, the other is going to be messy at best.



      Good luck. I've converted three departments I've working in to agile/scrum. It's a long road, and there is no guarantee of success, but it can be worth it.






      share|improve this answer














      Clarity



      First thing I'd like to clarify Agile is not necessarily better than Waterfall, and waterfall is not necessarily better than agile. Depending on your projects sometimes one methodology just makes more sense than the other.



      The Problem



      The problem they are dealing with is actually more they don't understand what agile is. Likely they consider themselves "kinda agile" because don't know what agile is, but do one or two things that agile companies do like hold daily scrum meetings.



      First Step, Respect



      You can't force change on anyone, people will only change if they see it as benefitting them. This is almost always the hardest sell in any change to a company culture. (And what you're proposing is a HUGE culture change, one we both agree is worth making, but I warn you now this will be a VERY slow process.)



      Before you can really influence any sort of change in your company you need to earn a certain level of respect by those this would effect. This doesn't mean they have to like you or be your friend, only that they respect if you're taking the time to do this it's with good reason. Until you have this your chances of success are negligible. (you might already have earned this, but it's pretty rare for someone new to a company to have this sort of pull)



      Second Sell It!



      In this case you're a salesman, you're selling an idea / concept. The key to making sales is making the customer want your product. If they don't really want it, they won't buy it.



      So how do you "Sell" Agile. This depends on the individuals and the company culture at large. Each person has their own drives, needs, and desires in regards to how they work. Some people want to receive their working order and just disappear for a week or two before turning it in and repeating this. Others like to vet out every little detail and nuance of a task in advance as a group. Both of these extremes can be very happy under agile, but how you sell them agile will have very different approaches.



      The quiet worker



      Agile has some social expectations that may not be present in the company as it stands. Daily Scrum meetings for example. Trying to sell the quiet working with this will only make them run kicking and screaming. That's literally the opposite of what they want.



      On the other hand they HATE their boss constantly asking is their work done, what's the status on this, scheduling meetings to address that task that's ten steps later because it needs to be adapted due to an issue found at the current step, etc.



      The Scrum board handles the lion's share of this! Once the boss is comfortable with the board they'll only bother the quiet developer when needed, and just skip to the board for the other stuff.



      Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once.



      That will make the quiet worker happy. They can get their work and do it without constant interruptions!



      The Collective Worker



      For the other extreme their are people who prefer to work in teams and favor pair programming and working in tandem with others over isolation. Agile works for them too! If you describe what you just said to the quiet worker they might like it, or it might completely disinterest them. Not that they'd hate it, just it's not very exciting.



      For these people the sprint planning and daily scrum can be big sells! No more running people down to check on things! no more bothering people when you need that second pair of eyes. Collective brainstorming of something particularly troublesome needed? No problem! bring it up in the daily scrum meeting and take it offline right afterwards!



      Being able to readily access the necessary people to get your work done is a huge sell to the collective worker.



      Many many people



      There are literally limitless variations in personalities. Some will be easy to sell on agile, others will be very difficult. You need to figure out what a person likes and dislikes work wise to figure out how to get them on your team. Note, you DO NOT need everyone on board, you just need to have the overall momentum in support of implementing proper agile.



      Lead by example



      Okay, so you've got a good amount of support now. They people want agile... but where do you start? This is where things get tricky. Very few managers will just go off and change their processes, but here's a fun fact you do NOT need your manager to change most of your processes, only a select few.



      In this case you should start leading by example. You want to get a proper scrum board? set one up for yourself that is publicly visible. Once some of the other pro agile teammates see it they'll want one. This will naturally lead you to consolidate this into a single board. Once most of the team is already on the board you can start to win get management in on it which can help get those you weren't able to win over into using it. (expect resistance as well, try to win them over, but if you can't management can bring them in line once they're sold on the idea, hopefully though you can win everyone over, or at the minimum get them to reluctantly tolerate it)



      Once you've got that board in place you move on to the next process, overtime you slowly convert to being closer and closer to true agile. As you convince management they want what you're selling you can start selling them on breaking things down into more manageable pieces and walla! you're agile!



      Cautionary Note



      As stated before. Agile isn't necessarily right for everyone / everything. In some cases resistance to true agile will be unmovable. Perhaps the CEO likes planning everything from A to Z and has no interest in breaking it down. In such a case the switch to agile is likely doomed from the start. (At best grim)



      If there is a clear resistance to agile practices you need to be careful to not get yourself branded as uncooperative, a trouble maker, etc. Sometimes being the person who swims against the flow to create change is the best thing that can happen to a company. Other times it's a fast track to a pink slip. Make sure people overall want this change and aren't having it forced on them. One is a good thing, the other is going to be messy at best.



      Good luck. I've converted three departments I've working in to agile/scrum. It's a long road, and there is no guarantee of success, but it can be worth it.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Feb 10 '15 at 21:51

























      answered Feb 10 '15 at 21:45









      RualStorge

      9,5372231




      9,5372231











      • one of my favorite sentences above is: Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once. which summarizes my love for Agile/Scrum
        – amphibient
        Feb 10 '15 at 21:51











      • @amphibient Yeah, replanning time is a great counter agreement for if management they show concern with all the meeting agile adds to the table. Overall the planning time is actually similar, but waterfall typically has a lot more back tracking than agile.
        – RualStorge
        Feb 10 '15 at 22:02










      • yes but it's almost impossible (unless you are clairvoyant) to plan step 10 while you are in step 1. step 7 or 8 maybe
        – amphibient
        Feb 10 '15 at 22:08






      • 1




        Actually there are some companies who excel at waterfall and planning things absurdly far down the line, but they are EXTREMELY rare. This is know as "clear room development" and only a handful of teams through out the world work in this manner. (they tend to have near zealot depth of both planning and code quality enforcement) The best known of these teams was the team that worked NASA's space shuttle's life support systems. They can't work in agile where adaption occurs as you go. When someone presses launch it either works, or hundreds of millions of dollars and several lives are lost.
        – RualStorge
        Feb 13 '15 at 15:32










      • i understand their case. also, building/construction projects are pretty much always waterfall, you need to have the whole building drawn out down to a power receptacle before you dig the first lump of dirt for the foundation (or is done like that). however, that is not our case...
        – amphibient
        Feb 13 '15 at 16:00
















      • one of my favorite sentences above is: Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once. which summarizes my love for Agile/Scrum
        – amphibient
        Feb 10 '15 at 21:51











      • @amphibient Yeah, replanning time is a great counter agreement for if management they show concern with all the meeting agile adds to the table. Overall the planning time is actually similar, but waterfall typically has a lot more back tracking than agile.
        – RualStorge
        Feb 10 '15 at 22:02










      • yes but it's almost impossible (unless you are clairvoyant) to plan step 10 while you are in step 1. step 7 or 8 maybe
        – amphibient
        Feb 10 '15 at 22:08






      • 1




        Actually there are some companies who excel at waterfall and planning things absurdly far down the line, but they are EXTREMELY rare. This is know as "clear room development" and only a handful of teams through out the world work in this manner. (they tend to have near zealot depth of both planning and code quality enforcement) The best known of these teams was the team that worked NASA's space shuttle's life support systems. They can't work in agile where adaption occurs as you go. When someone presses launch it either works, or hundreds of millions of dollars and several lives are lost.
        – RualStorge
        Feb 13 '15 at 15:32










      • i understand their case. also, building/construction projects are pretty much always waterfall, you need to have the whole building drawn out down to a power receptacle before you dig the first lump of dirt for the foundation (or is done like that). however, that is not our case...
        – amphibient
        Feb 13 '15 at 16:00















      one of my favorite sentences above is: Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once. which summarizes my love for Agile/Scrum
      – amphibient
      Feb 10 '15 at 21:51





      one of my favorite sentences above is: Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once. which summarizes my love for Agile/Scrum
      – amphibient
      Feb 10 '15 at 21:51













      @amphibient Yeah, replanning time is a great counter agreement for if management they show concern with all the meeting agile adds to the table. Overall the planning time is actually similar, but waterfall typically has a lot more back tracking than agile.
      – RualStorge
      Feb 10 '15 at 22:02




      @amphibient Yeah, replanning time is a great counter agreement for if management they show concern with all the meeting agile adds to the table. Overall the planning time is actually similar, but waterfall typically has a lot more back tracking than agile.
      – RualStorge
      Feb 10 '15 at 22:02












      yes but it's almost impossible (unless you are clairvoyant) to plan step 10 while you are in step 1. step 7 or 8 maybe
      – amphibient
      Feb 10 '15 at 22:08




      yes but it's almost impossible (unless you are clairvoyant) to plan step 10 while you are in step 1. step 7 or 8 maybe
      – amphibient
      Feb 10 '15 at 22:08




      1




      1




      Actually there are some companies who excel at waterfall and planning things absurdly far down the line, but they are EXTREMELY rare. This is know as "clear room development" and only a handful of teams through out the world work in this manner. (they tend to have near zealot depth of both planning and code quality enforcement) The best known of these teams was the team that worked NASA's space shuttle's life support systems. They can't work in agile where adaption occurs as you go. When someone presses launch it either works, or hundreds of millions of dollars and several lives are lost.
      – RualStorge
      Feb 13 '15 at 15:32




      Actually there are some companies who excel at waterfall and planning things absurdly far down the line, but they are EXTREMELY rare. This is know as "clear room development" and only a handful of teams through out the world work in this manner. (they tend to have near zealot depth of both planning and code quality enforcement) The best known of these teams was the team that worked NASA's space shuttle's life support systems. They can't work in agile where adaption occurs as you go. When someone presses launch it either works, or hundreds of millions of dollars and several lives are lost.
      – RualStorge
      Feb 13 '15 at 15:32












      i understand their case. also, building/construction projects are pretty much always waterfall, you need to have the whole building drawn out down to a power receptacle before you dig the first lump of dirt for the foundation (or is done like that). however, that is not our case...
      – amphibient
      Feb 13 '15 at 16:00




      i understand their case. also, building/construction projects are pretty much always waterfall, you need to have the whole building drawn out down to a power receptacle before you dig the first lump of dirt for the foundation (or is done like that). however, that is not our case...
      – amphibient
      Feb 13 '15 at 16:00












      up vote
      3
      down vote














      what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects?




      As a peer? Not much in my experience.



      You can inform them about this new stuff. You can say how awesome it was. But at this point, if they've not migrated it's not because they've somehow not heard that there's this agile thing that is awesome. There is likely apathy or organizational impediments to changing. There might even be real business reasons to do waterfall, but that's unlikely.



      A better approach would be to convince the boss. They (or you, if you're the boss) can then work with their boss to work with project management and QA and... you need to get high enough that some person can say - we shall be agile and has enough clout to do the education/correction/punishment necessary to make it work.



      How to do that? In my experience, (and perhaps because I'm an overly critical person) I focus on the pain. Why is your current process painful? Do big requirements lead to slow development time? A lot of wasted time in meetings?



      Explain how your solution will make this pain better. In my experience, people put more credence in the pain they feel every day than the hopeful future of some fad.






      share|improve this answer
























        up vote
        3
        down vote














        what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects?




        As a peer? Not much in my experience.



        You can inform them about this new stuff. You can say how awesome it was. But at this point, if they've not migrated it's not because they've somehow not heard that there's this agile thing that is awesome. There is likely apathy or organizational impediments to changing. There might even be real business reasons to do waterfall, but that's unlikely.



        A better approach would be to convince the boss. They (or you, if you're the boss) can then work with their boss to work with project management and QA and... you need to get high enough that some person can say - we shall be agile and has enough clout to do the education/correction/punishment necessary to make it work.



        How to do that? In my experience, (and perhaps because I'm an overly critical person) I focus on the pain. Why is your current process painful? Do big requirements lead to slow development time? A lot of wasted time in meetings?



        Explain how your solution will make this pain better. In my experience, people put more credence in the pain they feel every day than the hopeful future of some fad.






        share|improve this answer






















          up vote
          3
          down vote










          up vote
          3
          down vote










          what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects?




          As a peer? Not much in my experience.



          You can inform them about this new stuff. You can say how awesome it was. But at this point, if they've not migrated it's not because they've somehow not heard that there's this agile thing that is awesome. There is likely apathy or organizational impediments to changing. There might even be real business reasons to do waterfall, but that's unlikely.



          A better approach would be to convince the boss. They (or you, if you're the boss) can then work with their boss to work with project management and QA and... you need to get high enough that some person can say - we shall be agile and has enough clout to do the education/correction/punishment necessary to make it work.



          How to do that? In my experience, (and perhaps because I'm an overly critical person) I focus on the pain. Why is your current process painful? Do big requirements lead to slow development time? A lot of wasted time in meetings?



          Explain how your solution will make this pain better. In my experience, people put more credence in the pain they feel every day than the hopeful future of some fad.






          share|improve this answer













          what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects?




          As a peer? Not much in my experience.



          You can inform them about this new stuff. You can say how awesome it was. But at this point, if they've not migrated it's not because they've somehow not heard that there's this agile thing that is awesome. There is likely apathy or organizational impediments to changing. There might even be real business reasons to do waterfall, but that's unlikely.



          A better approach would be to convince the boss. They (or you, if you're the boss) can then work with their boss to work with project management and QA and... you need to get high enough that some person can say - we shall be agile and has enough clout to do the education/correction/punishment necessary to make it work.



          How to do that? In my experience, (and perhaps because I'm an overly critical person) I focus on the pain. Why is your current process painful? Do big requirements lead to slow development time? A lot of wasted time in meetings?



          Explain how your solution will make this pain better. In my experience, people put more credence in the pain they feel every day than the hopeful future of some fad.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 10 '15 at 21:42









          Telastyn

          33.9k977120




          33.9k977120




















              up vote
              2
              down vote













              Companies, departments and teams have inertia, just like physical moving objects. You need to change the direction of this inertia. The challenge lies in determining if they are a rolling ball or a tank. Seems like the latter to me.



              Do you have management buy-in? If you do, I would suggest setting up some mini-training sessions to better expose them to what Agile really is, sounds like they know the name but not the process. When they have had a chance to digest that, try to run a single project with the Agile model and let them slowly experience the difference.



              If you don't have buy-in, the best you can do is gently point out some of the benefits and try to work as Agile-ly as you can for your work so they can see how it can improve the process. Hopefully they will be convinced of the difference and begin adopting.



              This is not going to be an easy transition even if they are fully on-board, there is plenty to "un-learn" and lots to learn. Give it time and be gentle, if you make it a battle, human nature is likely to make them fight you automatically. You also need to understand that this may never work out. Not every group is adaptable and willing to change.






              share|improve this answer
























                up vote
                2
                down vote













                Companies, departments and teams have inertia, just like physical moving objects. You need to change the direction of this inertia. The challenge lies in determining if they are a rolling ball or a tank. Seems like the latter to me.



                Do you have management buy-in? If you do, I would suggest setting up some mini-training sessions to better expose them to what Agile really is, sounds like they know the name but not the process. When they have had a chance to digest that, try to run a single project with the Agile model and let them slowly experience the difference.



                If you don't have buy-in, the best you can do is gently point out some of the benefits and try to work as Agile-ly as you can for your work so they can see how it can improve the process. Hopefully they will be convinced of the difference and begin adopting.



                This is not going to be an easy transition even if they are fully on-board, there is plenty to "un-learn" and lots to learn. Give it time and be gentle, if you make it a battle, human nature is likely to make them fight you automatically. You also need to understand that this may never work out. Not every group is adaptable and willing to change.






                share|improve this answer






















                  up vote
                  2
                  down vote










                  up vote
                  2
                  down vote









                  Companies, departments and teams have inertia, just like physical moving objects. You need to change the direction of this inertia. The challenge lies in determining if they are a rolling ball or a tank. Seems like the latter to me.



                  Do you have management buy-in? If you do, I would suggest setting up some mini-training sessions to better expose them to what Agile really is, sounds like they know the name but not the process. When they have had a chance to digest that, try to run a single project with the Agile model and let them slowly experience the difference.



                  If you don't have buy-in, the best you can do is gently point out some of the benefits and try to work as Agile-ly as you can for your work so they can see how it can improve the process. Hopefully they will be convinced of the difference and begin adopting.



                  This is not going to be an easy transition even if they are fully on-board, there is plenty to "un-learn" and lots to learn. Give it time and be gentle, if you make it a battle, human nature is likely to make them fight you automatically. You also need to understand that this may never work out. Not every group is adaptable and willing to change.






                  share|improve this answer












                  Companies, departments and teams have inertia, just like physical moving objects. You need to change the direction of this inertia. The challenge lies in determining if they are a rolling ball or a tank. Seems like the latter to me.



                  Do you have management buy-in? If you do, I would suggest setting up some mini-training sessions to better expose them to what Agile really is, sounds like they know the name but not the process. When they have had a chance to digest that, try to run a single project with the Agile model and let them slowly experience the difference.



                  If you don't have buy-in, the best you can do is gently point out some of the benefits and try to work as Agile-ly as you can for your work so they can see how it can improve the process. Hopefully they will be convinced of the difference and begin adopting.



                  This is not going to be an easy transition even if they are fully on-board, there is plenty to "un-learn" and lots to learn. Give it time and be gentle, if you make it a battle, human nature is likely to make them fight you automatically. You also need to understand that this may never work out. Not every group is adaptable and willing to change.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Feb 10 '15 at 21:25









                  cdkMoose

                  9,29822042




                  9,29822042












                      Comments

                      Post a Comment

                      Popular posts from this blog

                      Long meetings (6-7 hours a day): Being “babysat” by supervisor

                      Image
                      Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote 31 down vote favorite 4 I hold a PhD in mechanical engineering with a 7 year background in self-guided, self-paced research including 2 years as a graduate level course instructor and a subject matter expert for various engineering projects in a university setting in the United States. For the last 10-11 months, I am working in a research industry in France where my task is to debug C++ spaghetti code written over a period of several years by my current supervisor. It is a team of 2: just I and my supervisor. Diurnally, I am posed with a "bug of the day" to get out of this C++ code. My supervisor generally gives me about 15-30 minutes to solve it and then accosts me about whether or not the task is completed and then rinses and repeats this until the end of the day. Off-late, my supervisor has been holding 6-7 hour long "meetin
                      Read more

                      Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

                      Image
                      Clash Royale CLAN TAG #URR8PPP up vote 2 down vote favorite Many fantasy worlds have multiple humanoid species (elves, orcs, humans, etc) living in the same world, in addition to that, they often have the ability to interbreed. And I can't help but question their believability... fantasy-races reproduction interspecies-relations share | improve this question edited Aug 9 at 14:46 Michael Kjörling ♦ 21.1k 10 85 161 asked Aug 9 at 13:13 Chlodio 118 6 closed as unclear what you're asking by MichaelK, Gryphon, John, Vincent, Frostfyre Aug 9 at 15:25 Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question. 3 Stack Exchange exist to
                      Read more

                      Confectionery

                      Image
                      Prepared foods made with a lot of sugar or other cabohydrates "Sweetmeat" redirects here. For the racehorse, see Sweetmeat (horse). Not to be confused with Sweetbread. This Kransekake is a traditional Scandinavian baker's confection. Confectionery is the art of making confections , which are food items that are rich in sugar and carbohydrates. Exact definitions are difficult. [1] In general, though, confectionery is divided into two broad and somewhat overlapping categories, bakers' confections and sugar confections. [2] Bakers' confectionery, also called flour confections , includes principally sweet pastries, cakes, and similar baked goods. Sugar confectionery includes candies ( sweets in British English), candied nuts, chocolates, chewing gum, bubble gum, pastillage, and other confections that are made primarily of sugar. In some cases, chocolate confections (confections made of chocolate) are treated as a separate category, as are sugar-free versions of
                      Read more