The Failure of the Agile Model: Accountability

Benjamin Franklin once quipped, “He that is good for making excuses is seldom good for anything else.”  Placing blame is always easier than taking responsibility.

The Agile Manifesto precepts of “Individuals and interactions over processes and tools” as well as “Customer collaboration over contract negotiation” leave responsibility and accountability, in the hands of the organization.

Defining Responsibility

Responsible – answerable or accountable, as for something within one’s power, control or management (ref: dictionary.com)

Accountability around direct management is obvious, but being within your power or control to do something implies accountability beyond the bullets of a job description.  And it’s in the cross-functional, collaborative and transparent morning discussions where the Agile methodology shines…or else utterly fails.

Before moving on, it is helpful to note other glossary terms common to an Agile vernacular:

Bugs – development code defects, also called issues; the goal of Agile is to have an available release of software with minimal bugs, though bugs still need to be managed appropriately.

Tasks – small increments of work requiring minimal planning/management, which combine to create product features, or stories.

Stories – sentences written to explain the goal of the end user; in an Agile methodology a story is written as follows: “As a <role> I want/need to <define objective> so that <define goal>”. An example for eCommerce might look like this: “As a consumer I want to be able to have Facebook ‘wants’ added to my shopping cart wish list so that I can manage my wish list through Facebook.”  Stories should be simple and boundaries around how a given story is further defined should be noted in Acceptance Criteria.

Acceptance Criteria – requirements which must be met in order for a story to be complete, and varying in detail based on the Product Owner, for example (borrowing from our last story):

• Facebook ‘wants’ user authorization through same method as Facebook account authorization

• Facebook ‘wants’ auto-added to wish list each time Facebook account authorized

• Facebook ‘wants’ removed from want list on Facebook auto-removed from wish list each time Facebook account authorized

• Wish list items removed also auto-remove Facebook ‘wants’ each time Facebook account authorized

The Acceptance Criteria then provides a checklist for a Demo.

Demo – at the end of a development cycle, or Sprint (defined next), a working example of the system developed is demonstrated to all stakeholders in order to measure progress and elicit feedback.  The Demo should go through, at a minimum, all Acceptance Criteria for all Stories developed, and can take the form of a very scripted, loose, or in between process (depending on your business).

Sprint – a “timeboxed” duration of development in which a set of tasks are identified to be completed which are preceded by a Sprint planning meeting and conclude in a Demo.

Daily Standup – also known as a “daily scrum,” a short meeting (typically 15 minutes) where the developers of a Sprint discuss three key items: 1) what they accomplished yesterday, 2) what they’re planning to do today, and 3) any ‘blocks’ in the way of completing tasks.

Though the list is far from comprehensive concerning Agile practices (not to mention missing role definition), and I’ve made broad generalizations concerning the process (which are necessarily different from one organization to another), the definitions are useful for what’s next: forming a culture of collaborative accountability.

Stop, Collaborate and Listen

Staying away from the more Agile terms of Scrum Master, Product Owner and Team (you can Google those on your own!), for the sake of role clarity we’ll stick with the traditional roles of Operations Manager, Product Manager and Project Manager.

An easy way to handle what is commonly referred to as User Stories in the Agile methodology, an organizational Product Manager can work with a Project Manager to identify new features and work on Acceptance Criteria within such User Stories.  The Product Manager would have the consumer and business goals in mind, while the Project Manager would have the development team resources and work tasks and activities in mind.

Operations Managers traditionally handle issue and bug fixes, working a prioritized punch list of items depending on resources available.  Operations Managers also traditionally collaborate with Product Managers to prioritize and develop stories based on bugs and issues, and this is where Functional Stories can easily be identified and prioritized into Sprints.  As an example where the Facebook ‘want’ to wish list might fail, “As a consumer I want my wish list to not be repopulated with my Facebook ‘want’ list so that once I remove an item from my wish list, it does not show up again.”

Finally, as Technical Debt seeps into an organization or is identified through normal operations, it is helpful to have Operations and Project Managers work on prioritizing Technical Stories into Sprints, cleaning up backend systems and processes iteratively.  As an example of a Technical Story within our Facebook ‘want’ to wish list example, we might see, “As a Merchandiser I need to have access to a consumer’s entire wish list (including Facebook ‘wants’) so that I can effectively market via email campaigns.”  In this case, perhaps the original User Story showed the Facebook ‘want’ adding to a wish list for the consumer, but a developer took a short cut in only showing the Facebook ‘want’ on the front end, and didn’t add the item to a database table on the back end.

Each of the above roles and collaborative Stories is more easily shown through a Venn diagram where collaborative accountability drives the User, Functional and Technical Stories into Sprints.

Hopefully, as an organization evolves into an Agile methodology, Product Managers or business leads become Product Owners while Project Managers become Scrum Masters, but that’s for the next entry of the series…

• Agile
• Scrum
• Iterative Development
• Vanilla Ice
• Project Methodology