The Agile Analyst

Traditional software development has many roles – architects, systems analysts, quality assurance, developers, project managers, the list goes on. Agile development doesn’t define nearly as many roles, simply that teams are cross-functional groups of five to nine people with some type of facilitator role. Most Agile variants assume that most of the team will act in a developer role. What then becomes of those other people that aren’t developers?

The Analyst Role

I’ll get to the other roles another time. For now, I’m going to focus on the role of the Analyst. Prior to Agile, Systems Analysts did a lot of talking, listening and writing. In a Waterfall world, they produced copious amounts of documentation, primarily in the form of gripping requirements. These would clearly spell out what the software would do if only those reading could stay awake long enough to make it through all those pages of directives with a clearly defined numeric scheme. You see headings like Requirement 6.7.4.1.3. How we produced anything beyond a collective sleep-over remains a mystery.

Enter Agile

Agile is theoretically lighter in documentation than earlier approaches. Where then do the analysts go? Typically back to the keyboard to write User Stories. If the Agile process is being misapplied, these frequently look a lot like requirements, especially for analysts that have done waterfall. Sure, the numbering scheme might have dropped a couple subsections, but they’re still writing requirements. User stories are not requirements, they are indefinite placeholders for discussion and understanding. Furthermore, they should be written by the customer (not the analyst) as the primary influence mechanism for the project.

False Separations

In some organizations, you frequently end up with two types of analysts. Business Analysts and Systems Analysts. I don’t appreciate this dichotomy because there is only one type of Analyst that we should care about and that is the Problem Analyst. The Problem Analyst works ahead of the developers in an effort to find the problem that needs to be solved. This is harder than it sounds, because while your users might be able to go on at length about ‘A’ problem, even they may not know what ‘The’ problem is.

The Agile Analyst

The Agile (Problem) Analyst should:

Ask why. Ask it five times in fact. Users know they need something but they may not really know what the heart of the problem is. Asking why in an iterative fashion can reveal the true problem and it may have a simpler solution. The Five Whys is a powerful technique for enabling this discovery. It is usually applied to root-cause analysis of a defect but it is a problem solving technique and software development is about solving the right problem.

Answer questions. Given the depth of their knowledge, analysts will know and understand the business better than anyone in the room (including the users in some cases). Developers will have questions and the Analyst should be able to answer them or be able to quickly find the answer.

Work with the onsite customer, developers and testers to identify and maintain the acceptance criteria. If these tests can be formalized in automated integration tests, even better. There are tools that make these types of tests maintainable by non-developers and such maintenance may fall to the Analyst. If so, embrace it because this can be an exceptionally powerful tool.

Act as the loudest user experience advocate in the room. The final product should solve the problem in the best way possible given the project constraints. The analysts knows the needs of the user and how they work day to day and should make certain the customer will find the final deliverable usable and effective. Just remember, most developers interface with computers in ways that most users will find incomprehensible (I know, I’m a developer and most of us would probably deliver command line applications with esoteric control languages if left to our own devices).

Work with the team and the customer to control scope and find acceptable compromises. In a way, this is the flip side of user experience advocacy. Some of this work may fall to the team facilitator (assuming that isn’t already the Analyst), but the Analyst is the natural axis point for this conversation given their work with the users.

Work with the Product Owner or Onsite Customer to develop and maintain high level functional specs with UI mockups or story boards. Don’t worry about how code will work internally, just how it is expected behave in the hands of the user. The functional spec is a living document. It is also not a technical requirements document. Joel Spolsky of Joel on Software discusses his take on functional specs in four parts here. While some of it may be overkill for the Agile process, it is a good starting point.