Why are there so many Agile Coaches?

Makes me wonder.

Agile development must be hard. Why else would there be so many Agile coaches? When people were doing waterfall, I don't think there were that many "Waterfall Coaches". Think about it. How many of your contacts in the software world were "Waterfall Coaches"? None of my personal contacts were coaching waterfall. On the other hand, I know of at least half a dozen who are in this business - either fulltime or part time. And I'm running into many strangers who are Agile coaches. Or at least want to become one.

For a methodology that is supposed to be simple, why are there so many coaches? Perhaps it is not simple. Agile is supposed to simplify but that's not the same thing as being simple. Perhaps the highly adaptive nature of agile methodologies necessitates a coach.

Essentially - what does an agile coach do? If you are a team that's already practicing an agile methodology, she'll probably take a look at your methods and suggest improvements. Should I use the word prescribe changes? Funny. We choose a methodology that's not prescriptive for its ostensible benefits and then we hire a coach to prescribe methods.

The Rise of the BAQA ("BaaKwaa")

The role of the Business Analyst (BA) and Quality Assurance Engineer (QA) as we know it is changing. As agile methodologies become prevalent, they appear to have an overlap. I think of a person performing this new role as a BAQA (pronounced BaaKwaa). The need for people in agile teams to wear different hats is spurring this development. In recent times, this has received a boost with the development of frameworks supporting Behavior Driven Development (BDD) and Acceptance Test Driven Development (ATDD).

Agile teams, and in particular teams following BDD/ATDD, write user stories in place of verbose software requirements. The user story captures the essence of the requirement expressed in a "Role/Feature/Benefit" grammar. Subsequently, acceptance criteria are written as "Givens/Events/Outcomes" to exemplify the requirement. Together, they completely define the business requirement.While the user story requires a Business Analyst's skill, the acceptance criteria requires a Quality Assurance Engineer's skill. Essentially, we now have a need for a person who can play both roles.

Enter the BaaKwaa.

Let us see the typical responsibilities of a Business Analyst and QA Engineer in a traditional methodology, such as waterfall.

A Business Analyst:

• Understands the business domain
• Analyzes weaknesses and strengths and helps define new features
• Writes software requirements specifications for the development team

A Quality Analyst:

• Writes test cases
• Performs tests on software programs and finds defects
• Ensures the quality of the software

Here's a brief role description for a BaaKwaa in an agile team:

• Write the user story (thus capturing business requirements)
• Write the acceptance criteria (thus further expressing the requirements through examples)
• Write the acceptance criteria in a BDD/ATDD framework in the language of the framework (example: Fitnesses, Cucumber, StoryQ, etc)
• Verify that the implementation meets the acceptance criteria preferably through automated means.

I'm not suggesting that we are witnessing the demise of the specialist BA and QA. There is a role for the specialist and there always will be, just as we continue to have architects, DBA's and user interface specialists in agile teams. However, they will be required to drop their BA or QA hat quite often, and instead wear the BAQA hat.

Please welcome the BaaKwaa.

Agile: The Preacher and the Practitioner

In an Agile conference, you will find two types of attendees - the preachers and the practitioners. The preachers are the speakers, the trainers and the agile "experts". They believe implementing an agile methodology in a text book like fashion is the only way to do it. The practitioners are those who have started an agile process in their company, are struggling to make it work and are dealing with real organizational and people issues.They see value in the agile process but do not think it can be done in a textbook fashion in their organization.

Here is what, for example, some of the agile preachers believe:

• SCRUM-But is evil. Not implementing an aspect of SCRUM points to an impediment that must be fixed.
• You must have teams co-located.
• Autotmated testing (TDD), continuous integration, etc. is a must.
• The Product Owner is always available to answer the team's questions. 
• Team resources are fully dedicated to the sprint. 
• Deadlines can and should be stretched to acommodate quality.

Here is what, for example, some of the agile practitioners have experienced:

• SCRUM-But is a reality for organizations dealing with legacy products.
• Co-location is a luxury in today's era. Often, even in the same geographic location, some team members work from home.
• Automated testing, continuous integration is often not possible for legacy applications.
• The Product Owner (Product Manager in the real world) is often managing multiple projects. It is an illusion to assume the Product Owner is dedicated and available.
• Team resources - especially QA, DBA, Architects often work on multiple projects or agile teams concurrently.
• Deadlines are real. They are often final and products must meet them and make compromises in the process.

The Agile Preacher often comes off as a white collar intellectual mostly used to working in laboratories, where things are largely under control. The Agile Practitioner, comes off as a blue collar worker, just interested in getting the job done in the real world with real people and real challenges to face.

The truth, as usual, is in between. Agile Preachers must temper their language to factor reality. Agile Practitioners must try to change reality. And in this tension between the two groups is where we'll see real value being added to the Agile Process.