Agile Jeopardy–Not as Easy as You’d Think

Last month we played Agile Jeopardy, and the questions and answers related directly to the Agile Manifesto. Four values and twelve principles—how bad could it be? Turns out most people don’t have them memorized, and our teams had a rough time.

Should we know the Agile Manifesto by heart? Quote it in the office? Recite it when we wake up and before we go to bed each day? Unless you’re playing Agile Jeopardy on a frequent basis with me as the judge, you probably don’t need to go to such extremes. But there is tremendous value in reviewing the Agile Manifesto periodically (a couple of times a year) and revisiting the significance of the values and principles. What does each piece contribute? What if it were written differently? Just how agile is your team?

I worry sometimes as an organizer that I’m not doing enough to serve the community’s needs, and I feared that our game of Agile Jeopardy might have been too much for some folks. Games bring out competition, and our teams were struggling to respond with just the right answer. Thankfully our teams took it in stride, and Chris Murman even wrote his own blog post on what he learned from the evening’s activity. We all need a good reminder now and then of “the basics.”

A strong finish to 2013

We had a great year in 2013.  Thank you to our members for suggesting the topics, facilitating and presenting, and participating in DFW Scrum month after month.  Our goal is to help you do better today than you were doing yesterday, and the best way to do that is through the collective wisdom and experience of the crowd (sprinkled with some industry experts).  Our last three meetings of the year exemplified our goal and values.

September: DEV+QA in the same sprint – how’s it possible?

Dave Nicolette led the group in a discussion of how the magic of getting dev and QA to work close together and complete their work within the sprint happens.  Challenges can come from large stories, unclear or missing acceptance criteria, multiple product owners, and a lack of automated testing.  These challenges are quite common, and the beauty of our user group is that we can rely on the wisdom of the folks in the room to share their experiences and successes!  Spending time refining or grooming the backlog so stories are smaller, the requirements and acceptance criteria are better understood, and even writing the acceptance criteria to be testable can be helpful.  Teams that move to behavior driven development (BDD) do all of that while also building automated tests.  The magic is that QA spends time helping to clarify or reveal the acceptance criteria, which the developers need to know in order to write the software—the relationship between dev and QA becomes closer with this mutual need, and the delivery of stories within a sprint becomes easier.  That’s the magic.

October: The Science Behind High-Performance Teams

Peter Saddington, CST, visited us from Atlanta to talk about the behavioral science, neuroscience, and psychology behind high-performance teams.  Self-organizing teams are made up of individuals, and each individual has certain behavioral patterns.  These behavioral patterns can be identified using various assessment tools, and knowing the behavior patterns of individuals can be extremely helpful in forming teams because they contribute to the team dynamics.  What does someone love to do?  What types of problems do they enjoy solving?  How do they know they’ve done a good job at something outside of work?  The answers provide insight into a person.  A strong team includes diversity.  Teams should also have fun together.  Executives don’t ask to increase fun in their organizations, but happier people are more productive and innovation increases.  The biggest obstacle to fun in most organizations is multitasking or context switching.  And if you require your team members to work on more than one project at a time, you put quality, speed, and value at risk.  Leaders should be “lovers of people” and “inspiration starters.”  Slides are available here.

November: Using Agile Outside of IT

We had 3 of our user group members share stories of how they use agile frameworks and practices outside of IT—Jennifer Nusbaum in an educational registrar environment, Tony Akins at home to write a book and mow his lawn, and Ty Crockett at home with his family to do household chores and his son’s school project.  Each presentation reminded us of some of the core concepts behind agile and scrum: how a backlog provides visibility and focus, how iterative and incremental work can get the job done, and the importance of reflecting back on how we can improve for future projects.  It was our first time having multiple presentations at one meeting, and it was quite successful!  We would love to have more members volunteer to share their experiences like this.

What did we forget to say about these meetings?  Comment and let us know.

Sail or Fail? Navigating Test Automation Pitfalls

Paul Grizzaffi joined at DFW Scrum last night to go over the topic above. Too often, automation has to be justified and bought into before we spend resources on it. I like how Paul compared it to an Insurance Policy. No one likes to pay for insurance unless of course the tornado takes your house down or the car is totaled. Look at automation in that it will save us from potential catastrophes and customer implications of bad software. However, unlike insurance, automation can make us more efficient and “Agile” at the same time.

I like to say that being “Agile” in software development, simply means that you can ship software when you want. If a feature was demo’d and thought it was good to release to customers, could you do it? Or is it a lengthy / painful process to push code from our developers’ machines to production?

Automation is definitely a specialized skill set at this time, we all know it would be better and a good idea to do, but how do we go about doing it? Paul’s message was clear that you can’t template an approach to automation, but he can share with you some good practices / questions to ask. Other valuable lessons are what NOT to do.

Quality is everyone’s job, automation is everyone’s job. How do we fit it into our development processes? Paul’s presentation is available for download, check it out and  hit him up for questions if you have any.

Quick take-aways

• Don’t try to automate a broken process (garbage in and garbage out)
• Must know your process and job before you can automate
• Think of your automation as a safety net / alarm system (confidence in making changes)
• Test cases are your contract between the requirements and the interface
• Try not to change Test Cases for your automation unless the contract changes
• Automation is an insurance policy, you want a high deductible you get low cost (risky)
• Discuss automation in context of opportunity cost (not ROI)
• A human used to do x now its automated they can go to y
• Exploratory testing is opportunity cost, computers are good at repetitive tasks, humans are not