Programming Motherfucker
•Descargar como PPTX, PDF•
5 recomendaciones•5,984 vistas
The document discusses some unintended consequences of adopting agile practices, including generalizing specialists, extroverting introverts, and suppressing excellence. It provides remedies for each, such as code reviews to break down silos and having technical stories in sprints to prevent suppressing excellence. It also advocates for gradually introducing Scrum practices like starting with product backlog and retrospectives before daily standups and sprints.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Programming Motherfucker
Similar a Programming Motherfucker (20)
Más de Dusan Omercevic
Último
Último (20)
Programming Motherfucker
- 2. Of the Programmers, by the Programmers (signatories of agile manifesto) Kent Beck Ron Jeffries Mike Beedle Jon Kern Arie van Bennekum Brian Marick Alistair Cockburn Robert C. Martin Ward Cunningham Steve Mellor Martin Fowler Ken Schwaber James Grenning Jeff Sutherland Jim Highsmith Dave Thomas Andrew Hunt 160 years of programming experience!
- 3. The Unattended Side Effects of Agile Generalization of the Specialist Extrovertion of the Introvert Productivization of the Engineer Suppression of Excellence
- 5. Generalizing the Specialist Remedies: 1. Fix product development before introducing agile! Defined product owner, prioritized backlog and product roadmap are prerequisite for successful agile adoption. 2. Make sure the team internalizes company and product strategy! 3. Give additional responsibilities first!
- 6. Extroverting the Introvert (Breaking Down the Silos)
- 7. Extroverting the Introvert (Breaking Down the Silos) Remedies: 1. Code reviews 2. Sit together 3. Technical presentations
- 9. Productivizing the Engineer Remedies: 1. Make engineers feel the pain of users 2. Show engineers how their work improves user's lives in unexpected ways
- 11. Suppressing the Excellence Remedies: 1. 20+% of technical stories in every sprint 2. Pet/Open source projects 3. Hackdays
- 12. Gradual Scrum Introduction PM 101 1. Product Owner & Product Backlog 2. Retrospectives 3. Team & Scrum master 4. Daily stand-up meeting & Demos 5. Sprint planning, Sprint backlog SCRUM & Burndown chart Scrum introduces too many changes at once, so rather do it incrementally!
- 14. Thank you! Let's continue discussion @dusano and http://restreaming.wordpress.com/ Agile Slovenia 2012
- 15. Photos: http://www.flickr.com/photos/raster/3380860520/ http://www.flickr.com/photos/docsearls/5500714140/ http://www.flickr.com/photos/tef/3159937037/ http://www.auger-loizeau.com Special thanks to my coworkers. You're awesome!
- 16. Further reading: • Why I’m done with Scrum http://lostechies.com/jimmybogard/2012/09/12/why-im-done-with-scrum/ • “Dilbert” on Extreme and Agile Programming http://www.globalnerdy.com/2007/11/28/dilbert-on-extreme-and-agile- programming/ • Project Management 101 http://rodp.wordpress.com/2012/09/07/project-management-101/ • Relaxing Scrum http://restreaming.wordpress.com/2012/09/17/relaxing-scrum/
Notas del editor
- Youare all familiar with agile manifesto. But recently Zed Shaw presented anti-agile manifesto.We are programmers who have been humiliated by software development methodologies for years.We are tired of XP, Scrum, Kanban, Waterfall, and anything else getting in the way of...Programming.We are tired of being told we're autistic idiots without anytime to be creative because none of the 10 managers on the project can do... Programming.We must destroy these methodologies that get in the way of...Programming.Zed Shaw is not some teenage programmer. He's author of popular book series Learn Code The Hard Way.
- Kent Beck has been programming for 35 years! He's currently at Facebook developing a thrift server to handle all messaging traffic.What went wrong? Why are some programmers rejecting agile?- were they wrong in the first place?- has environment changed so much in the last 10 years?- agile does not scale to average programmersProblem => Solution
- - On the surface scrum looks trivial. But in reality it causes enormous changes. Nobody is helping people cope with the changes. This should be the main role of scrum master/coach- Hire "Agile Developers" in the first place. (a) don't hire one trick ponies, (b) check for team work capabilities, (c) check for the cultural fit- Firing people is neither the the right thing nor easy.- There's no silver bullet: Don't try to change people. Help people overcome small barriers, but don't waste time on people who just don't fit
- Introduction of agile changes development priorities.I've been here myself.Typical situation: You are building a recommendation engine for months or even years. A scrum is introduced and development priorities change.Programmers are expect to do also planning, designing, interviewing users, and making decisions outside of their technical expertizeProgrammers are forced out of their comfort zonesPeople who build their identify and self-esteem upon their expertize, lose groundsProgrammers consider only coding as creative.
- Ad 1) Building the right product is more important than building the product right!Ad 2) There's no such thing as too much communicationAd 3) - Don't expect people to be responsible as a team, if they don't know how to be responsible as individuals.- But don't make them responsible to the managers, but to the customers.
- - Around an introvert programmer a silo always forms. The silo took years to be built and it's quite often the critical piece of the system. Opening up the silo should be done very carefully.- Scrum forces introverts to communicate. This usually results in violent crashes.- Usually the introvert wants out of the silo himself (but only to build another silo)
- - Don't push the introvert too hard: - pair programming - shared code - collective planning - product demosAd 1) Instead of pair programming and shared codeAd 2) Instead of collective planning (he'll hear anyway)Ad 3) Instead of product demos
- - Engineers adore solving problems that nobody has.- We love solving problems with technology, even if non-technological solutions would be much more effective.
- Ad 1) There's no more humbling experience for an engineer than seeing his work being used by a real user. We recently showed to engineers a user interview that exposed naked technical problems of our service. The result was profound.Ad 2) Be on the look out for such cases at user interviews.Engineers feel omniscient and superior to the users. These two things break this notion and make them interested in actually listening to the user.
- - These days they say in Silicon Valley: "If you're not embarrassed of the first version of your product, you've shipped too late"- Engineers are proud people.- There are ways how to start learning fast while still keeping excellence in engineering.
- -Scrum won't fix your product development process. - separate product from people/process management.- Put people in the driver seat of changes.- You can delegate more responsibilities already today. - Cross-functional teams always make sense. One full expert is better than two halves. - Increase or decrease team size as required by the project/process at hand.- Every team needs a coach to help the team jell.- Iterations introduces pressure cooking. That's why things explode. Do this after fundamentals are in place.