Day 2 at Agile 2010 in Orlando kicked off with the conference overview and keynote. Jim Newkirk reported that the conference had 1,400 attendees from 38 countries to attend a selection of 227 sessions. Here are my notes from the day.

Keynote – Agile 2010 – An Unplugged Retrospective on the Agile Decade “Mirror Mirror on the wall are we really the most beautiful of all?”

Dave Thomas presented the conference keynote:

• testers were getting drowned at the bottom of the waterfall, developers and analysts were in the clean water
• only answer you can give as an estimate is the wrong answer
• if you only do one thing, put continuous integration in place
• agile has delivered improved productivity – some, but not the 5x as some were hoping
• software is still built by people, business analysts have been missed largely by agile, the product owner role is overloaded
• sprint zero – the original scrum paper said it may take 3 months, innovation can’t be done in a single timebox
• collective ownership – no piece of code should have one owner, use four eyes, not always 2 people holding the mouse, don’t be religious because pairs don’t always work but use four eyes even if traditional development
• TDD – was originally test driven design, most significant piece of engineering this decade, has solved some amazing problems, acceptance tests worth much more money than unit tests if you have to make a trade off, parametric / random testing to test hard things like compliers
• an XP manager is an unemployed smalltalk programmer
• agile is successful because the methods and tools people are here!
• your method is the set of practices that work for your business – practice first
• if you can’t beat the card, you will only do it worse with tools
• shut down the laptop in meetings, should be about people and interactions not talking to a machine
• certification – important that people acquire bodies of knowledge, but is only the starting point, favor concept of apprenticeship because it is about confidence
• return to craftsmanship – cooperative education programs in universities, passion for programs that look good, practice the kata to retain your confidence, learn the keyboard chart before you pair
• hire them young , they don’t know what can’t be done
• clean code removes technical debt at it’s source
• big ball of mud design pattern – it’s our mess, we create the garbage and assets we cannot fix
• refactoring is a wizards work, the tools are toys, often we are tied to the data not the code
• lean – so simple it is so hard, all you need is the ability to think, if you can’t measure it you can’t improve it , need to measure whole value chain, bottlenecks usually not where you think they are
• cumulative flow much better than burndown, see where bottlenecks are
• it’s about the practices stupid
• read “The Mythical Man Month” (Fred Brooks) – you ship your organization
• need a technical ladder alongside your management ladder – recognize distinguished engineers, don’t have to have people reporting to them, they become the coaches and walk around, they may make as much as a senior executive and get access to the executive team
• communities of practice – best way to learn, done in own time, mark of a professional that gets off their butt and learns in their own time, reward these people
• scrum and agile does not make the difference in the large, lean thinking makes the difference
• automated tests are an investment
• employ smart people who have failed before (they have seen the movie)
• if you have a bad backlog it does not get better, have tangible testable requirements, without an acceptance criteria you have a wish not a requirement, non-functional requirements are nonsense as they are all requirements, if you can’t measure or test it they are not requirements
• envisioning – build requirements through design to make it tangible, many good requirements are not expressed in text
• Apple spends more on envisioning than any company in the world
• estimates – stupid questions that managers ask, answer should be “buzz off, here’s some points”
• always respond to an estimate question with a range, want the manager to be responsible for the risk, can do an activity estimate to get a risk window, play the estimate game frequently and early
• architecture – we all do this, it is not a job, architecture should be an interface and let the code draw the diagrams
• customers buy features, but components keep the code base alive, rank component backlog on feature level

Beyond Agile

• it is still perceived as an expense, learn about teams pain, agile is fragile as it depends on sustainable leadership and discipline, good leaders have magic powers
• software is hard and there is too much of it
• skills are in short supply, good luck finding a crack graduate, have processes that are not dependent on anyone, teach six hats early, give people reasonable tools (Google App Inventor for building Android applications)
• need to get away from low level languages (Java is just a VM language), need higher level expressive languages (read structured interpretations of computer programs), make applications data driven
• adopt better business practices – pair business and programmers, we spend months on budgeting without blinking an eye so improve this
• winning cultures and teams work well and do not follow a process

Agile Business Intelligence – 12 Critical Steps to Success

Ken Collier presented this session. This was a good session, unfortunately the good stuff was at the end and Ken ran out of time at the end for the a-grade material and the myriad of awesome questions.

Ken started by getting people to stand in the room on x and y axis – x (across the room) for agile experience and y (fromt to back) for amount of business intelligence knowledge.

• why don’t we hear stories about how business intelligence has turned a company around – have done a lousy job of getting business value to customers
• data modellers love to model data – overbuilding of systems as they model for future or unperceived needs
• core values and principles apply – envision –> speculate –> explore –> adapt –> close
• TDWI (The Data Warehouse Institute) – lots of buzz about scrum but it is not the complete picture
• highly recommended reading – Agile Project Management (Jim Highsmith)
• shared community of planners, doers and users – responsibility shared
• business intelligence customers – don’t often know what these systems do, so we need to show them features early (eg. OLAP reports, visualization dashboard)
• iteration zero – opportunity to get infrastructure in place, logical/conceptual data models in place, explore user stories with customers, system discovery and understanding source system data
• advocate 60-90 day release cycles – should not be all needs, focus on a division or goal and create a bounding box
• in database development historically work in a shared environment and when we think it is ready we migrate into production – cannot experiment, explore, do good unit testing
• sandbox development – need to check in artifacts into version control, use continuous integration, use virtual servers to mitigate cost
• with 4GL tools for continuous integration – recently used Hudson, as long as the tool supports a command line API to run the modules that are created by the tools, AnthillPro has plugins that help
• DDL/DML to keep in sync with developers – build from the metal up using the continuous integration server, try to move toward push button deployment that will build the server, need to be able to smoke everything on a regular basis (scorch the earth build) to keep in sync
• what about production systems? – can’t recreate the data, customers have reports, it holds the data and is the one point of truth, need to maintain consistency, read Scott Ambler’s Refactoring Databases, use continuous integration to build and rebuild, practice deploying using your technique of choice, blue/green deployment, run parallel until confident
• think creatively on how to deliver value in short iterations – feature spike and then build
• a story is done when it adds value to the customer and goes all the way back to source system data – stories quickly become epics in business intelligence
• customer collaboration is usually poorly done – don’t just rely on the business analyst, need real user stories
• if you are proud to show your customers features, you have waited too long to show your customer features
• data modellers argue they need months up front – wrong headed, nothing unique, model in increments and prove in code
• agile is not a substitute for technical excellence
• should always be able to deploy into production
• automate everything
• unit testing – look at DbFit, fixtures for fitnesse, previously used SQLUnit using Ant, test data not features, write tests first and then ego

Improving Customer Conversations

Esther Derby delivered this session:

• not so much how to have a conversation but how to interview
• open and closed questions – closed questions are yes/no but open questions invite conversations
• 5W questions – ff asked in the past, you get how customers are using the system, what problems, etc… whereas present questions give different perspectives such as who else should I talk to, etc… and discover possibilities (would and could questions)
• try and go and see your customers where they work and how they use your software
• points are questions that are used to confirm a specific piece of information- yes and no closed questions
• priorities and preferences – confirm information using multiple choice
• probes – probe more deeply, follow up questions to get below the surface, interviewers are usually good at this
• always asking questions to understand why, but why questions often put people on the defensive
• alternative to ask something like what was the thinking behind this, what are the reasons, etc…
• meta questions – questions about the questions, are there questions that I am not asking that I should be asking, useful when customer assumes you have domain knowledge but you don’t
• 3 cardinal rules – never argue with the customer (if you win you lose the customer and if you lose you look like a dummy), don’t turn an interview into a training session (you will never come back to the interview and looks like it is about you and your vast knowledge) and don’t talk more than the customer (no more than 30% of the time)
• always write questions in priority order so you get through the important questions
• make some connection with the customer so it doesn’t feel like you are just mining for information – ask how long they have been with company, etc…
• preparation helps and builds confidence for the interview – makes good use of your time and theirs and show you value their time
• useful to test questions before you take them on the road – our minds work in different ways, make sure that you are asking understandable questions
• customers do not know what they want and don’t know how to speak in requirements and stories, questions can give the customer ideas
• when a customer starts leaning back in chair or shows body language, ask if asking to many questions and who else might be able to answer questions
• set what you are going to achieve when you are making the appointment
• if the customer is technical and tries to tell you how to design, ask questions about what this will gain, need to understand how their world works
• questions not to ask – leading questions (obvious), bias questions (of the interviewer, feel manipulated, wouldn’t it be better to use .Net), wouldn’t you agree, compound questions (questions in questions, interviewee does not know where to start, one question at a time)
• start with more general questions, most familiar and most important to your goal and then drill down
• 10 kinds of people (2 kinds of people in binary) – think outloud (extravert – will keep talking until you interrupt) and those who like time to consider an answer (introvert – looks for a break in the conversation) – mixed pairs are tricky, if not answering your question directly, give them time to think (8 seconds)
• over the phone give people time to answer
• when asking a question, never be the next person to speak
• after the interview take notes and review them to see what you are learning about the features
• almost never do transcripts for interviews because human language is full of useless words, may paraphrase for later
• get somebody to takes note if possible
• what else is a useful question
• if they don’t something like ask them what they would like instead

Life’s not a Beach, it’s a Game: Innovation Games® for Agile Teams

Luke Hohmann and Cory Foy led this workshop to introduce a new innovation game.

• companies play games
• fuel innovation – what you know, know what you don’t know (requirement gathering) and don’t know what you don’t know (innovation games)
• Prune The Product Tree – branches are features and releases radiate up the tree, prune the apples off the tree
• the new game – Draw your nightmare scrum master, product owner or developer

Project Management Stage

Throughout the day I made sure that I dropped in on the sessions that were happening on the Project Management stage that I co-produced with Greg Smith. All of the talks were well received by the audiences:

• Building a More Accurate Burndown: Using Range Estimation in Scrum (Arin Sime) – it was great to meet Arin and the parts of this presentation that I attended covered this topic well
• Scrum and Kanban – Like Chocolate and Peanut Butter (Damon Poole) – the presentation is available here, it was great to meet Damon before the talk as well as at the AccuRev stand, they got me hooked on Reese’s Peanut Butter Cups however (I wish you could get them in Australia!)
• Fixed-Bid, Fixed-Feature, Fixed-Time Agile Development (Dan Rawsthorne) – it was great to meet Dan, his presentation is available here
• Agile for the Practical Project Manager (Greg Smith) – Greg has presented a version this talk to rave reviews across the USA, and watching the audience and questions at the end of this session, this version of the talk was no exception