Guild Blogs

Agile QA Reality or Fantasy: A Conversation

Agile software development processes such as Extreme Programming (XP), Scrum, Feature Driven Development (FDD) and Crystal have become mainstream in many organizations. Do these methodologies directly address the kinds of things QA professionals care about? Unit and acceptance testing might be a good start, but what about the rest of the QA profession? Come join a conversation about QA topics with agile expert Wayne Allen.

Indeed it has been "a little while" since my last post, nearly a year in fact. Where did the time go? I have been busy (surprise, surprise).

• I spoke at SAO in Portland
• I was a guest lecturer at WSU Vancouver
• I spoke at XP2007 in Como, Italy
• I was an experience report shepherd for Agile2007
• Agreed to write a book for Addison-Wesley on Agile Anti-patterns
• And accepted a job as VP of Software Engineering for ISI

I've been giving some thought to changing the tone of my blog from some time now as I don't have as much time to dedicate towards polished entries. I'm going to give it a go for a while and see how it feels.

Agile methodologies are just as prone to mistakes, deviations and subversion as any other methodology. This workshop is intended to discover and share agile antipatterns then discuss and present creative solutions. Anti-patterns, also referred to as pitfalls, are classes of commonly-reinvented bad solutions to problems. They are studied, as a category, in order that they may be avoided in the future, and that instances of them may be recognized when investigating non-working systems. This workshop focuses on participants’ (less than perfect) experiences in the workplace and mines the collective wisdom of the group to come up with creative solutions via a brainstorming process followed by breakout sessions and then group presentations.

https://www.cmpevents.com/SDe7/a.asp?option=C&V=11&SessID=5358

Agile Development: An Introduction to Scrum

Agile software development is a conceptual framework for undertaking software engineering projects. There are a number of agile software development methodologies, such as those espoused by the Agile Alliance, a non-profit organization.

Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team reevaluates project priorities.

One commonly used agile method is Scrum. Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Using Scrum techniques such as backlog, release planning, sprint planning and sprints, we will be delving into Scrum itself using you the attendee to direct the discussion so that maximum value is achieved.

The international patterns & practices Summit showcases the official Microsoft "patterns and practices" for developers, designers, and solutions architects who need to learn how to integrate architectural design patterns and procedures with the technology provided by Microsoft's .NET platform.

The patterns & practices Summit packs into four full days unique presentations offered by many of the industry's best speakers. An evening reception sponsored by Infragistics will give attendees an opportunity to meet with Microsoft personnel. Attendees will come away with a strong foundation in the architectural principles underlying Microsoft's .NET technology, which will prepare them to construct the next generation of enterprise-scale applications.

http://www.pnpsummit.com/west2006.aspx

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Acceptance testing is either not done or done at the end

Forces:
Excessive belief in unit testing
No testers involved
Insufficient awareness of how to “agilize” old habits
No acceptance test criteria
Excessive time/resources to run
Lack of hardware/understanding of economic issues
Perfectionism – 100% must be testable
Reliance on manual work

Consequences:
Systems that don’t work
Release bugstorms
Projects canceled
Loss of trust

Example:
1,000 unit tests, but the system is broken

Better solution:
Insist on acceptance test criteria
Buy hardware
Training on iterative testing
automation
Exceptions:
Trivial systems
Internal tools
Prototypes

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Unable to take responsibility
Cannot say no to developers/stakeholders

Forces:
Authority problems
Inappropriate personality in key role
Unclear roles/decision rights

Consequences:
“bedazzlement” – confusion – “rabbit in headlights”
Time wasted
Poor prioritization

Example:
Developers talk excessively at daily meetings
Multiple customers cause constant re-prioritization

Better solution:
Certain roles need certain personalities

Exceptions:
Better than having a “nasty” guy in charge.

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Manager prioritizes stories, tells how to do them, developers don’t have a say (because of manager’s authority)

Forces:
Customer absent
Managers want to stay in control
Manager knows product and thinks he knows what users want
Organization doesn’t trust developers

Consequences:
Customer doesn’t get what he wants/needs
Team is disempowered/alienated
Creates dependency situation

Example:
Product owner manages the whole team. He discourages the team to come up with better solutions so that they depend on him.

Better solution:
Separate product owner from other roles on the product
Onsite customer
Train manager as coach (so that he has a role outside of owning product and can drop that role)

Exceptions:
Very small company
Temporary replacement if product owner on planned/unplanned absence

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Not switching pairs

Forces:
High productivity of pair
Pair is happy
“never change a winning team”
Inability to pair with others

Consequences:
Pair does not improve
Pair will get bad habits (we always do it like this)
No knowledge sharing
Pair might get bored with each other
Needed split up impossible

Better solution:
Pairing schedule
Encourage pairs to switch

Exceptions:
Crisis
2 person team
Siamese twins