October 3, 2012

In This Issue



Sticky ToolLook Interview
Agile Requirements Management
with Derwyn Harris 

What's Happening at StickyMinds.com

Featured Tool
Jama Contour
Jama Software

Outside the Toolbox
Olly: The Web-connected Smelly Robot 

Jama Contour
Vendor: Jama Software
1060 NW 9th Avenue, Portland, OR 97209
Phone: (800) 679-3058    
Fax: (877) 665-8476

Tool URL:  Click here to learn more



Description: Jama Contour is a specialized collaborative requirements management solution that manages the details, decisions and ongoing discussions that revolve around the requirements and test cases of a project. Delivered through a lightweight, flexible and easy-to-use Web application, Contour provides the core functionality needed for project collaboration, requirements management, change management and test management—including traceability, coverage, change control, test plans, reporting and its unique Review Center for gaining buy-in with stakeholders. Its main function is to connect everyone together—from product executives and project managers to business analysts, QA specialists and developers—and keep them in sync through real-time discussions, revisions and collaborative decision making. Contour ensures that plans and specifications are properly managed and, when modified, communicated across distributed teams and stakeholders instantly.

@StickyMinds
on Twitter
Want a daily dose of what's new and popular on TechWell and StickyMinds and in Better Software magazine? Follow @StickyMinds
on Twitter for regular updates. 

Sticky ToolLook Interview
Agile Requirements Management with Derwyn Harris

Derwyn Harris is a co-founder at Jama Software, where he also serves as a senior solutions architect. In this interview with the Sticky ToolLook, he discusses how requirements management (RM) fits into agile software development.

Sticky ToolLook: What does poor RM look like on an agile project? Is it easy to spot early on, or does it sneak up on you as the project progresses?

Derwyn Harris: Actually, the most common indicator of poor RM in agile is the lack of requirements. Many agile projects continue to operate under the myth that requirements are too heavy and slow for agile and that agile replaces RM altogether. They perceive RM as traditional, waterfall, and outdated and, to be honest, they are not 100 percent wrong. The problem is that the term "requirements management" needs to be redefined. In many respects, RM is a broader view and should include agile as part of the whole process.
 
It boils down to the social interaction between people and the data. What we've seen in the past twelve years, since the creation of the Agile Manifesto, is an evolution in how we interact. Social tools such as Facebook have enhanced and expanded our ability to interact, which is one of the main tenants of the Agile Manifesto. This visibility and connection is the first step in recognizing the quality of your RM. Once this is in place, you can better determine poor versus good RM and adjust accordingly.

STL: How detailed should requirements be at the start of an agile project? How malleable should they be from iteration to iteration, or even within an iteration?

DH: Great question! It highlights the exact thought process a team should go through as part of integrating the overall RM process with agile. The trick—and, oftentimes, the rub—is how heavy this process becomes. There is no mathematical theorem that proves the exact level of detail necessary. It depends greatly on the situation and type of project. For example, some organizations receive an RFP that must be answered completely before development begins at all. This requires a much heavier level of effort around the requirements early on, especially if the contract isn't even won yet.

On the other end of the spectrum, where the organization has complete control over the requirements, there is a lot more flexibility. In either case, the requirements should clarify the vision, helping the engineering team understand the overall purpose of the project.
 
In my opinion, what is most important is that the requirements are readily accessible, well communicated, and easily modified. Therefore, if later in the project an event occurs that changes the initial vision of the requirements, it is simple to see its impact and initiate a conversation or notify those downstream of the change so that they can react accordingly. This way, the requirements become more malleable without becoming a burden.

STL: How is communication important to the requirements process, and how can project members make sure that their interactions are clear?

DH: Communication is extremely important to every step of the requirements process. Agile's biggest contribution to this idea is that communication and interaction are critical to success. For this reason, many books and methodologies have promoted the “one room” concept, where everyone physically resides in the same room, thus encouraging immediate communication and forcing immediate reaction. However, this situation isn't always possible, especially with larger projects or as we begin to expand the process to a larger audience, such as product, marketing, business analysts, customers, interested executives, and other stakeholders.
 
To accommodate this broader audience, it's important to understand how communication has evolved. As I mentioned earlier, about a decade after the Agile Manifesto, we now have many more acceptable means of communication that don't require face-to-face meetings. This is incredibly liberating and enables teams to properly understand both the requirement itself and the context surrounding the requirement. Once these information silos and organizational fences are broken down, clarity can be accomplished through the requirements visibility, along with the [social] tools' ability to facilitate the conversation through approvals, commitments, and decisions. Said another way, interactions are clear when the outcome is a decision that everyone agrees on, is aware of, and can execute on. In addition, a historical record must exist to avoid any rehashing of the same conversation.

STL: What are some other ways that you recommend for developing agile requirements and keeping them agile throughout a project?

DH: Better communication. The concepts are simple: Make requirements available to more people, connect them to upstream and downstream artifacts, enable collaboration in and around those artifacts, and help ensure that decisions and commitments are made by the right people.
 
Implementing this is another story. As you may have gleaned, I'm a huge fan of leveraging tools. I try everything I can to manage tasks, news, posts, photos, and music with the appropriate tool, but I find that there is still a lot of work to be done to streamline the information to my liking. I would say that my life has significantly improved because of this, though many may balk at this statement.

Regardless, some romanticize a life devoid of technology and social sharing, but with product development and RM there is no success when users are isolated and independent. The most successful projects I've been on were successful simply because we communicated well together. While technology and tools can't guarantee better communication, they can certainly help break down barriers and speed up the process of communication, ultimately making teams more efficient and therefore more agile.

Advertisement
Better Software Conference and Agile Development Conference East
November 4-9, 2012 | Rosen Shingle Creek | Orlando, FL

Two Conferences, One Registration, One Location

Don't miss the Early Bird discount ending THIS Friday, October 5, to receive up to $200 in savings! Register for one conference and receive full access to BOTH events! You get double the value, more content and subjects to choose from, and the freedom to attend both conferences at your convenience. Seventy-eight speakers, forty-eight concurrent sessions, thirty-six tutorials, four keynotes, a combined EXPO, and much more!

*Register by this Friday, October 5, and receive up to $200 in savings. Call our Client Support Group at 888.268.8770 and ask about our group discounts to save even more!*

Register Now

You are receiving this issue of StickyToolLook as part of your www.StickyMinds.com membership, Better Software magazine subscription, or StickyToolLook subscription. We hope this publication will be a useful and enjoyable benefit. To ensure optimal receipt of these emails, please add StickyToolLook@lists.StickyMinds.com to your address book or all messages from your email white list.