Agile BAs… Don’t Go in without TOOLS!

In my last post I discussed the role of BA as it relates to working within agile teams and tried to explain what you can and should do as part of your team. One of the comments I received related to the role of User Interface Designer in agile. I had implied a complementary role in the post and the reader was looking for a bit more information. I thought it was a really good question and it’s led to this follow-up post…

Applying user interface design in agile methods is one of the leading challenges right now within the agile community. Since it’s an early-on activity, as is any design activity, the notion of sprinting till your done-continuously delivering working software iteratively doesn’t seem to engender much in the way of design.

Thus the challenge…

What design practice has done is encourage the agile folks to slightly reconsider their models. For example, within the design space, it is often quite reasonable to do design work within an iteration, that will only be ‘used’ in subsequent iterations-say the next one or two. This sort of look-ahead from a design perspective is required as the team can rarely implement the work within the same iteration where the design was explored and defined.

The trick is to not look-ahead too far. If you do, you fall into the waterfall trap of designing everything in advance, before you’ve actually gotten a few lines of code to work. (Something we agilists describe as BDUF – or Big Design Up Front and a common anti-pattern of agile development).

So this creates a need to oscillate or balance activities within your agile teams between some look-ahead tasks such as architecture, analysis, and design and then transitioning to coding and testing. I think the best agile teams ‘get’ this balancing act early on and understand that they have to work on both sides of the equation.

There are a couple of tools within the agile arsenal that foster look-ahead. I’m going to speak to a few. While they’re often ignored by the more purist-focused agile methodologists and teams, they are indeed a quite viable tool-set for looking before you leap into iterations.

• Chartering. In the same spirit as traditional project chartering, agile chartering focuses on developing the why behind the project. Usually it targets the business case for the project including: target customers, vision for the project, ROI information, budget details, high level scope targets, team and capabilities information, and definitions for success – usually including a schedule or date target. The charter should serve to energize the team by sharing the why it matters behind the project or effort.
• Research Spike – User Story. At times you really don’t know enough to write a solid user story. Usually the gap is in technical or design experience and what you really need is a little time to “play around” with things to gain a better clue. The output of a research spike isn’t working code. Instead it’s knowledge – usually in the form of architectural design details and a refined set of user stories destined for implementation in a later iteration. As a rule of thumb, I usually see 20% or so of stories in my backlogs that warrant a spike to gain more clarity.
• Iteration #0 or Sprint #0. Quite often agile teams simply dive into their work, iterating before they have a clue to where they’re going. For some projects, this seems to work and the team figures out their direction along the way. For many others, this is a disaster. Jim Highsmith coined Iteration 0 as a term in his Agile Project Management book. It’s defined as a first/early set of iterations that are focused more towards getting ready to begin building a product than on the actual construction. A wide variety of work can be encompassed in a Sprint #0 including, architectural definition, requirement analysis and backlog preparation, design work, setting up office space and building the team, training, project chartering, group planning activities, etc. The caution is not to allow your Iteration/Sprint #0 to extend too long.
• Blitz Planning. Alistair Cockburn defines Blitz Planning as part of his Crystal agile methodology. Crystal hasn’t achieved much popularity, so you probably haven’t heard much about it. However, there are techniques within Crystal that are quite powerful and this is one of them. In Blitz Planning you engage the entire team and key stakeholders in defining the overall plan of attack for the project. This includes developing the overall feature set, work tasks, dependencies, identifying key milestones, and such. At the end of a day or more of collaborative planning, you end up with a detailed, end-to-end mapping of the work. This includes when and how you’ll be doing analysis and design in order to effectively drive your agile iterations during construction.
• Story Mapping. Jeff Patton is one of the champions of this technique and is actively refining it. What often happens in agile product backlogs is that the individual stories often obscure the big picture and overall direction a product is taking. Story mapping strives to connect individual stories into the themes and feature interactions that your real customers will be using. Typically, it’s a low-fidelity technique where story 3×5 cards on a way are elaborated and refined from the customer workflow and user interaction points of view. It often identifies gaps and helps to prioritize what should be implemented in what order.

For those of you who thought that agile did little in setting the stage in advance of the work, I hope this post and the tools open your eyes to a different perspective. While the agile methods do take a lean, iterative view towards software construction, many projects need some initial vision setting. I also think these techniques can be mapped, to good effect, to the more mainstream methodologies. Happy exploring!

Don’t forget to leave your comments below

---

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].