Hiring for an Agile Team – Johanna Rothmann
- Have high collaboration skills
- Bring a BA/Product Specialist/Project Manager into the interview, to see how the interviewee will work with the team
- Look for someone who take initiative
- People on the team have to respect and like each other
- Look for skills in the following order: 1) Functional knowledge, 2) Product domain expertise, 3) Technology, and 4) Industry Expertise
- The order above may change for specific jobs
- Get people who have had at least 2 years of work experience, so they have the basics of ’showing up on time’ down
- Look for developer who understand combinatorial testing
- Ask behavior questions (How did you …), instead of hypothetical questions (What would you do if …)
- Apply the same process when selecting vendors, not just individuals
- When you are interviewing, you are also auditioning the company for the candidate
- Questions:
- Tell me about a time you introduced a new technology or technique, and how did it go
- Tell me about a time you had a learning breakthrough
- Tell me what you do to re-invest in your technical skills
- How do you know when you’re done with a task?
- Tell me about some work you are proud of, and why you’re proud of it
- What is the most recent technical thing you’ve read, and what did you learn from it?
- The most recent behavior is the best predictor of future behavior
- “Influence Without Authority”
- Test your candidate auditions within the company first
Since I went out to dinner Thursday night, and flew home Friday afternoon (to start on a deployment that went until 3:30 Saturday morning), I haven’t been able to post the rest of my conference notes until tonight. Here the are.
Smells in Agile Software Development – Jutta Eckstein
- Include a risk list from deployment team (a detailed one, instead of a vague one that can’t be tested against).
- Start recording historical statistics of our agile projects.
- Practices over Values – people tend to be dogmatic about practice
- Values > Principles > Practices
- Not making use of retrospective information (focus on a few things, create an action plan).
- Ask: What’s the problem, how is it caused, who is affected?
- Determine: How to avoid it, how to solve it, who needs to do something about it.
- The biggest smells we had: Pain points not prioritized, insufficient refactoring, definition of done, planning beyond capacity, unclear acceptance criteria, and working in silos.
Investigate ‘world cafe’ method of problem solving.
Presenter First – TDD for Complex GUI (Scott Miller – Atomic Object)
- Repeatability of the manual UI testing is difficult
- Michael Feathers “The Humble Dialog Box” (initial MVP pattern)
- Separate GUI from business and separate business from flow control
- Delay the development of the model to as late as possible
- Start writing your code at the presenter level
- Presenter constructor take the model and the view, then registers event handlers
- Get ReSharper
- Use properties on the model, use methods on the view.
- Generally use events with no parameters. They are just event triggers that notify the class that it must get updated information.
- The presenter typically has just one test per user story.
- If the code for the UI becomes complex, create an adapter with its own model and view.
- Communications is generally handled by raising events.
- Spring – tool to let you define your object hierarchy in .Net projects.
- Multiple MVP triples communicate with each other through the models, or through another presenter that treats one model as a view and the other as a model. Having the external presenter is cleaner, since it reduces coupling between the models.
- For legacy code: pull out the view first, create multiple presenters, and one main model (eventually breaking out into multiple models).
- Create interfaces to handle file browser object and JavaScript popup dialog boxes, to make them mockable and testable.
- When firing an event, always copy the delegate and fire against that.