Recommandé
Contenu connexe
Tendances
Tendances (19)
En vedette
En vedette (17)
Similaire à Stupid human tricks for agile
Similaire à Stupid human tricks for agile (20)
Dernier
Dernier (20)
Stupid human tricks for agile
- 1. Stupid human tricks for Agile behavioral therapy for software makers
- 3. Never say “resources” when you mean “people”
- 4. Take blame Say, “I was wrong. You were right.” Say, “I was wrong. You were right.”
- 5. Assume competence Notice what people do Ask dumb questions Ask for help
- 6. Eat together once in a while
- 8. You are not in charge People define their own roles; be explicit People define their own roles; be explicit
- 9. Multitasking is a joke
- 10. Wear giant headphones Train people not to interrupt you Group chat is good Group chat is good Group chat is good
- 11. Don’t check your email Learn to live with unread email Learn to live with unread email
- 12. Meetings sap your will to live sap your will to live
- 13. Write an agenda Ask for an agenda Decline Decline Decline
- 14. Be on time Start on time Don’t recap for latecomers Don’t recap for latecomers Don’t recap for latecomers
- 15. Make all meetings optional and maximum one hour Encourage walking out Always take notes Always take notes Always take notes
- 16. Good luck
Notes de l'éditeur
- Introduction Heard it before, but helps to hear it again doesn’t matter which flavor Pragmatic tricks that I learned by doing things terribly wrong No philosophy
- insidious
- Don’t be disingenuous, but if you have a part of responsibility, take blame. Once you do, everyone will want a piece of your delicious blame pie. Taking blame makes you seem important, as a side benefit We all have terrible character defects
- There is almost nothing as demotivating as the feeling that your work and your decisions are constantly being second-guessed by people around you. trick: Instead of saying, "You should have done it this way instead," try, "Have you thought about the problem from this angle? It's your call in the end, but it's something to think about." People do what others around them do. Publicly notice good stuff. Peer pressure works. Privately notice bad stuff. Don’t accuse. Just notice. "I saw you managed to fix that bug." "You were late to stand up yesterday." Just show that you are paying attention. Be the one who asks the dumb questions. Acronyms!!!! What do they mean?!!! Admit when you aren’t qualified. Say, "I need your help with this because I am not qualified to make this decision." People like to be needed. Say, “I have a problem and I need your help.” Don’t be the kind of person who asks people to do things for you that you can do yourself (if someone else can google it, so can you) but
- Mary Roach interview, international space station Eating together is powerful Think of the vegans
- Good people are attracted to a project where they believe that they can make a difference, that they will be useful, that they will be respected. If you can help create a culture where every member of a team feels that they are important, you will attract the right people.
- If you are the PM or the team lead, or whatever, keep reminding yourself that you are not in charge. If your agile process is working, the team decides what goes into the next sprint, not you. It's not my product, it's our product. Take solace in the fact that you might well be the least important person on the entire team. If you are the team leader, your most important jobs are taking blame, spreading glory, and defending the decisions your team makes. Good teams have fluidity in roles, that way people can go on vacation. Spend an hour at the beginning of the project with the dev lead, the error manager, the scrum master, the UX lead, and the product manager (If you are working in a start up this might be a two-person meeting!) Have each person say what they think their job is. Whenever a person says something concrete, write it on the board. Make people get specific. If there are things that need to be done which nobody claims for himself, start haggling. This doesn't mean that the scrum master can't step in for the error manager or that the dev lead must refuse to write testing scripts. It's not about staking out territory, it's about being open on expectations and making people feel accountable.
- Task lumping, not multitasking Switching between one kind of thing and another is a great way to get nothing done
- Late money jar beer fund Get s.o. to be your enforcer (scrum master, error manager, dev lead)