Don't Do Agile, Be Agile

Editor's Notes

• #2: Motivations --> vent (not really…)“Why” is very important, bc that understanding becomes the justification for decision making.Over the years, my intuition was always pretty good, but the understanding wasn’t there. -- Which has made it hard for me to make strong arguments for or against certain practices.
• #3: Small teams, close to businessCut teeth on XP, watched as Scrum became popularPFP
• #4: CIO managing company objectives to projects, how teams get requirements, report status, measure success, etc.He tells me problems, and I start talking about conceptsHe says, “You haven’t said agile. Do you practice agile?”Not alone… “Agile”
• #5: Everybody is adoptingAddress misconceptions: design, big (product) picture, avoid coding yourself in a corner if you don’t think about tomorrow, set goals, marketing and documentationAgain, good questions. But the premise that agile doesn’t address these things, in fact has made it worse, bothers the heck out of me.Big A or little a
• #6: So many things wrong with the development process:Wrong thing gets builtCustomer can’t describeTechnical folks can’t estimate itBusiness wants to know how much it will cost and when they’ll have itContracts to define and then fix scope, which tells the customer what they’ll get the technical folks what to build, and then you can create a “resource plan” to deliver it in the required time.I recognized this problem very early – from the consultant side; then on the customer side
• #7: PRODUCT: will anybody buy this? How will we know when we are successful?ANALYSIS: requirements, prioritization, lo-fi prototyping, spikes. Ideally, lots of customer interactionEXECUTION: coding, testing, devops, etc.In any org, effectiveness matters. In a large org, it matters moreAgile coaching: have good success effecting testers and programmers, but the businesses don’t change
• #8: CustomerBoR: overall plan, set priorities weekly, see progress in a running system, …Programmer BoR: know what is needed, do quality work at all times, have estimates respected, know what the next thing to work on it, …Business people make business decisions, technical people make technical decisions.Big Visible Charts: passive radiator, communicate candidlyBUFD / YAGNI  Avoid creating software that isn’t used or needed; and applies to ALL those circles!
• #9: Some aren’t controversial (perhapsconsidered mandatory).Some are good ideas, but can be taken a la carte.Some have been taken and made awesome.Some, people think they understand but, don’t….Some, people truly don’t getThe rest are either taken for granted, or ignoredOut of all of these practices, which one would you guess that I think most important?
• #10: Courage: this ain’t easy. Your shortcomings are exposed. We don’t have all the answers. We do need help
• #11: “craftsmanship” is about honing a practice, using your tools better, finding better tools to conduct your practices.“agile” is about this, too! It’s incredibly important to building great software.Practices and tools are “what” and “how”Values and principles are “why” principles based on values will shape what practices you choose to do, and how you do them
• #12: Means: understand the end, decide if software is the best solutionCustomer:Even when they are wrong. They simply didn’t know yet: “You gave me what I asked for, not what I wanted”We only know the software isn’t right because they tell us!Communication Gap… “Metaphor”. The language of the business in the code “BDD”
• #14: The deeper part of simplicity – tough conversations – challenge decisions we have made.Warm Fuzzies: I’m not estimating anything you can’t describe, or anything we might not doDesign and architecture: ?!?!? Don’t let technology get in the wayMaking something simple takes time. Your organization has to understand that.If one person spends a lot of time working on something, they will defend that ting because of the effort they put in.“How Do Committees Invent”: http://www.melconway.com/research/committees.html
• #15: Dollar - it’s not cheap to write software. Want to know what they are going to get for their money; and whenEvolution design, never quit;accept that you will have better costs as we learn moreyou will get what you have (in the form of a workable system) whenever you want itDoggedness – “I can figure this out”Not ask for help, going down paths that maybe don’t need to be gone downDo more than is askedEstimate low, creating deadline (instead of quality) pressureDogmatism – practices and tools Nothing is more unproductive!THIS is where agile fails:Business has to trust that the tech folks will be good stewards of their dollar- By putting the business in charge: showing them what they are getting as frequently as possible, and allowing them to adjust their priorities as often as necessary- We do that by being vested in the vision of the software; so that we are sure that the best decisions are made all the time
• #16: Remember the valuesSIMPLICITY: you’ll throw away designs, you’ll play devil’s advocate, you’ll find other ways to skin those cats.FEEDBACK: you’ll iterate quickly, you’ll prototype, you’ll be open to criticismCOURAGE: you’ll follow through on these things when times are toughest. You’ll voice unpopular opinions, You’ll back them up with data.COMMUNICATION: you’ll be open with the business, and demand they be open with you. You’ll give good news and bad news.RESPECT: you will listen, you will show candor, you will follow through on decisions that were made