Andrew Fuqua began developing software professionally in the mid ’80s using an iterative and incremental approach. After a few years of working in not-so-agile environments, Andrew got iterative and incremental again with a Smalltalk team in ’96, and then began using eXtreme Programming in 1999. For the last few years, Andrew has been involved in agile transformations in larger organizations, which brings us to his current role as an Enterprise Agile Coach with LeadingAgile. Andrew has previously held positions in management, product management and software development at companies like Internet Security Systems, Allure Global, and IBM.
Andrew is the president of the Agile Atlanta user group, which he helped start in 2001, as well as the Atlanta Limited WIP Society. He has also been active in other groups around town. Andrew earned a BS and MS in computer science and has an MBA from Duke University.
Agile works great, when it works. It tends to be most successful in small companies, with small teams that can work completely independently of others. It tends to fail when more teams are involved, when there are dependencies between them. Even though we’re “doing Scrum”, it still just doesn’t yield the promised benefits. When agile fails it can be disappointing and costly. People get blamed, agile gets blamed, the training gets blamed, and the organizational culture gets blamed. Yet companies keep trying. Many companies make multiple attempts to transition to agile because they’ve bought in to the underlying principles of agile and see it as a solution to their problem hitting dates, their long time to market, their slow return on investment, and their quality problems.
In this talk we’ll examine 8 causes for Agile’s failure in large enterprises, and why starting a transformation with culture or even practices isn’t the solution. We’ll examine why the ultimate solution begins with putting in place the certain organizational structures and planning a journey through predictability on our way to adaptability. Specifically, to begin we need a thoughtful mix of product or feature teams and component or service teams, as cross functional as practicable in each instance; agile structures above the team; and appropriate agile governance at the portfolio and program management layers. This creates an environment in which agile can begin to stick, can begin to deliver value, and creates a platform from which we can move on to increased agility.
Adding examples to your acceptance criteria will improve clarity and reduce misunderstanding. In this session, we’ll discuss a couple ways to approach this. We’ll also have a light introduction to Acceptance Test Driven Development, Behavior Driven Development, Specification By Example, Cucumber, Gherkin, and Fitnesse.
This workshop is geared especially towards Product Owners, Business Analysts, and Testers, but is also of interest to technical team leads and managers.
For some background reading material, here are a couple nice articles from @testobsessed:
- http://testobsessed.com/2011/02/the-atdd-arch/
- http://testobsessed.com/wp-content/uploads/2011/04/atddexample.pdf
Here are the related books I really like:
- Bridging the Communication Gap by Gojko Adzic
- Specification by Example by Gojko Adzic
If you buy the second, you can get a pdf of the 1st for free. Another book I’ve read that is okay, but a bit tool specific for my tastes: ATDD by Example, Markus Gartner.
