The concept of Agile Requirements Definition and Management (RDM) is not a new concept. However, the struggles to figure out how traditional requirements cycles fit within an Agile framework remains convoluted. For a system to work, an organization needs to think about the entire lifecycle and not just the software development portion. If you start at a high-level within your company and analyze what documentation is being produced in order to create finished code, you’ll most likely find that over 50% of the documentation created was not used. Why are we creating waste?

One theory relates to the complexity factor. As a system starts to mature it starts to move toward complexity. It becomes increasingly difficult to understand, organize, manage, and maintain these systems. People have a tendency to add more to the system to help fill gaps and create protocol to maintain and control it. As organizational turnover occurs and the rules, regulations, and business climate change, the system must also adapt. This causes the complexity of the system to grow exponentially until it gets to the point where it is difficult and/or prohibited from functioning properly. This is precisely why the best systems, or for that matter products, are simple and streamlined. This is exactly why Lean Thinking removes waste from the system. Requirements Definition and Management is no different in its vulnerabilities to the complexity factor. This is why companies sometimes end up with requirements specifications that are hundreds of pages long and extremely difficult to follow and manage.

If you’re looking to adopt Agile and want to run a leaner operation, you have to take a holistic view of the organization. Requirements definition in Agile has to be looked at through a separate lens, not strictly in conjunction with the development team. The same principles used in Agile software development can be applied to requirements definition and management as well. Let’s look at a quick example of how this works. There are various Agile frameworks out there, but the most popular is Scrum. Other frameworks include XP, Crystal, and Kanban to name a few, but Scrum is the most commonplace so we will use this for demonstration purposes. It is also important to mention that some of these frameworks can be combined. For example, portions of Kanban can be used within Scrum to control team capacity constraints by limiting work in progress (WIP).

Scrum allows development teams to build software incrementally over 2-4 week events called Sprints [see Figure 1]. Requirements are fed into a Product Backlog prior to Sprint inception, which gets decomposed into Sprint Backlogs Items through Sprint Planning. The development team starts by discussing what needs to be developed in a given Sprint based on the organizational needs and strategy. The work items are pulled from the Product Backlog and directed by a Product Owner, with the process being controlled and managed by a ScrumMaster. The goal for the business is to make sure they feed the Product Backlog and can support and describe what needs to be built by the development team prior to the Sprint starting. The problem is that most organizations struggle with keeping pace and/or don’t have the right level of detail defined in the Product Backlog to properly tie into the development Sprints.

Figure 1: Scrum / Sprint

Agile Requirements Definition and Management was specifically design to solve this problem by outpacing the development team. This is accomplished by feeding the Product Backlog faster than the development team can produce code. The framework can be used for just-in-time requirements definition or to build a repository of requirements for future use. In either case, if a team is using Scrum they are working from the Product Backlog. Since the Product Backlog is a “backlog” of work, the required pace of filling the backlog is driven by the designated Sprint timeframe. The goal is to make sure the business (i.e. Product Owner) can clearly articulate what needs to be built and that what is define is of high quality. To accomplish this the Requirements Cycle follows a Scrum-like process that mirrors the development cycle but stays two to three steps ahead [See Figure 2]. The goal is to create a process by which requirements can be thoroughly vetted, organized and communicated that is iterative, timely, and quality-focused.

Figure 2: Agile Requirements Definition and Management (RDM)

It all starts by identifying and filling a Requirements Backlog. This type of backlog is a list of items that need to be defined in order to fill the Product Backlog. The end goal could be User Stories, Visualizations, Functional Requirements, etc. The requirements team decides based on the business strategy and objectives what needs to be defined and built through requirements planning and prioritization. Like the development team, the requirements team would plan their Sprint, perform the work, and review the outputs. If the outputs meet expectations then they can be moved to the Product Backlog. In many cases, organizations will have documents that need to be created to pass certain tollgates or organizational milestones. These items can also be put in the Requirements Backlog but may not end up in the Product Backlog. Instead, these documents in many cases become reference material for the development team to pull from. This is where traceability from the Product Backlog to any external documents becomes important to establishing project continuity.

Another important portion of RDM is called Decomposition. Decomposition is the process by which the Product Backlog Items are communicated and refined in collaboration with the development team. Decomposition can be used in several ways. One such way is to setup a culture of collaboration where the development teams are brought into the requirements phase to refine the Product Backlog. In Scrum, this is commonly referred to as grooming the backlog. Another way to use Decomposition relates to procurement and/or timing delays. Some projects experience gaps in time between when requirements are defined and when development starts. There are many reasons why this happens but it is important to note that this occurs on a regular basis. The larger the gap in time between definition of requirements and development, the more risk that occurs with developing the right product. Loss of vital team members, knowledge and overall team availability all are at risk the longer the gap. Decomposition in this case is used as a way to pick up where things left off by using the Product Backlog to communicate and share requirements.

Agile is quickly becoming the most popular way of developing software because it fosters continuos improvement, time-boxed development cycles, and delivering value to the end users faster. That value will be driven to a large extent by the quality and clarity of requirements that feed the software development process. An agile, lean, and timely approach to requirements as the starting point will help to ensure that your process is optimized.

There are many flavors of Agile on the market today, I’ve discussed but a few of them in this article. The key is to figure out what works for your organization and to start experimenting. The faster you dive into trying to be more Agile, the faster you will start seeing the benefits it brings.

About the Author:

Jason Moccia has over 14 years of experience in the software development field and is a co-founder and managing 
partner of OneSpring LLC (www.onespring.net), where he oversees the Federal business practice as well as Operations. OneSpring helps companies to work smarter by providing an entirely new approach to software requirement definition.  

In addition to Mr. Moccia’s leadership role within OneSpring, he has also worked as a senior business analyst with numerous Fortune 1000 companies—including, but not limited to, Ernst & Young, General Electric, SAIC, Florida Power & Light, InterContinental Hotels, Deloitte, and SunTrust. Mr. Moccia is a Certified ScrumMaster (CSM) and holds a Bachelor of Science degree in Business Administration from the University of Florida with a focus in Management Information Systems (MIS).

The use of Agile Requirements Definition and Management (RDM) solves this problem by going through several prioritization cycles during each project. RDM follows a lean thinking philosophy of waste reduction and continuous improvement, therefore, each iteration or Sprint allows the team to pause and reflect on whether they’re aligned with the business objectives, or not. It also insures that the requirements defined at the end are properly organized and prioritized for development consumption. This helps reduce cycle times and any project lag that may occur between requirements and development.

About the Author
: Jason Moccia has over 14 years of experience in the software development field and is a co-founder and managing 
partner of OneSpring LLC (www.onespring.net), where he oversees the Federal business practice as well as Operations. OneSpring helps companies to work smarter by providing an entirely new approach to software requirement definition.

Key topic areas include:
-The basics of Agile (terminology, roles, sprints, backlogs and more)
-The variations of Agile (XP and SCRUM)
-The difference between Agile, Waterfall, RUP, and more
-How government agencies are attempting to adopt Agile
-The pros and cons and strengths and weaknesses of Agile
-Approaches to implementation in the Government environment
-How software visualization is becoming an integral part of the Agile process

The goal of the session is to share knowledge and bring individuals together to discuss what they’ve learned around Agile development in the Federal government.

To learn more and/or register, go to PotomacForum.org (http://potomacforum.org/?view=476)

2011 brought with it several accolades. OneSpring made the Inc. 5000 list in 2011 and was also a Finalist for the Spirit of Endeavor award presented by the Technology Association of Georgia (TAG) and TechAmerica. We’ve been recognized for our top-notch design work for Godspell.com and appeared in Federal Computer Week (FCW.org) magazine. We also celebrated our 6th year anniversary in August.

This recognition is great but what I’m most proud of is our team. OneSpring has some of the most dedicated, brightest and hardworking people I’ve ever met. Growing a company is hard work that requires patience, persistence, and passion. Having a team that believes in the same qualities is critical to our future growth.

I want to thank everyone for making 2011 a wonderful year and wish you all a healthy and prosperous 2012.

Jason Moccia
President and COO
OneSpring LLC

Happy Holiday Site

OneSpring was selected as a finalist for the “Emerging Technology Business” category because of its innovative consulting practice and techniques. OneSpring has changed the way organizations of all sizes define and manage requirements for large software applications.

“Companies such as OneSpring are one of the reasons Georgia has been ranked first in the nation for entrepreneurial activity,” said Tino Mantella, president and CEO for the Technology Association of Georgia and TechAmerica Georgia. “We are proud to recognize some of Georgia’s most exciting new technology companies through our Spirit of Endeavor Awards and we look forward to hearing much more from them in the future.”

All winners and finalists of the 2011 Spirit of Endeavor Awards were recognized at a special ceremony on December 9, 2011 at TWELVE Atlantic Station in Atlanta. A portion of the proceeds from the event will benefit the TAG Education Collaborative.

For more information and to see a complete list of nominations, please visit: http://www.tagonline.org/Spirit-of-Endeavor.php.

About TechAmerica Georgia
TechAmerica is the largest and strongest voice and resource for technology in the United States and is the industry’s leading trade association. TechAmerica Georgia, formerly TechAmerica Southeast, was created in late 2009 under a unique partnership between TechAmerica and the Technology Association of Georgia (TAG), which provides operational management for the organization. TAG is the leading technology industry association in the state, serving more than 14,000 members and hosting over 170 events each year. TAG’s mission is to educate, promote, and unite Georgia’s technology community to foster an innovative and connected marketplace that stimulates and enhances a tech-based economy. For more information visit the about TechAmerica Georgia and TAG, visit www.tagonline.org .

About The Technology Association of Georgia (TAG)
The Technology Association of Georgia (TAG) is the leading technology industry association in the state, serving more than 14,000 members and hosting over 170 events each year. TAG serves as an umbrella organization for 30 industry societies, each of which provides rich content for TAG constituents. TAG’s mission is to educate, promote, and unite Georgia’s technology community to foster an innovative and connected marketplace that stimulates and enhances a tech-based economy. The association provides members with access to networking and educational programs; recognizes and promotes Georgia’s technology leaders and companies; and advocates for legislative action that enhances the state’s economic climate for technology. Additionally, the TAG Education Collaborative (TAG’s charitable arm) focuses on helping science, technology, engineering and math (STEM) education initiatives thrive. For more information visit the TAG website at www.tagonline.org or TAG’s community website at www.TAGthink.com. To learn about the TAG-Ed Collaborative visit http://www.tagedonline.org/.

We’ve all been told that you should define the story first then choose the technology. Well this is a tale of the exact opposite. It all started in early summer of 2011 when the first parallax scrolling websites began to appear. Although not the first, NIKE was by far the most publicized of sites and many can argue they deserve credit for bringing parallax scrolling to the masses. As slick as the NIKE site is I must admit it wasn’t the site that sparked my interest in this design, in fact it was a little unknown consulting firm. They designed a site that really took the use of parallax and creatively applied it to their service offering (the story).

Over the summer I started compiling a list of my favorite parallax sites and even created a short post highlighting several of them. During this time I kept searching for a client and project that would allow us at OneSpring to implement this new style. Eventually we found a project for one of our commercial clients and it was more or less a proof of concept in which we took static text and images of their 125 year history and produced a very rich and graphically stunning presentation using a vertical parallax implementation. It was a great first attempt and truly beautiful I’ll admit, however we didn’t have enough material to create what I was hoping would be our parallax pièce de résistance. Around this time I was having a separate discussion with Ken Davenport, the Executive Producer of GODSPELL about their existing site and how we’d love to turn it into a parallax experience. Ken being one of the most innovative producers on Broadway was quick to notice an opportunity of differentiation amongst the other sites promoting plays and musicals.

I sent Ken and his marketing team several design examples of what we could do and how this technology would be perfect. It not only works on traditional browsers but it would also work equally well on mobile and tablet devices without having to recode or download a bulky plug-in. They approved the concept and it was time to get busy as opening night was only weeks away.

The marketing team started sending us materials from background images and fonts to audio clips and cast bios. I then met with Mitch Moccia, OneSpring’s lead designer and interactive developer to discuss the first iteration. We discussed how we could include what they had given us and really play up the wall and the main character. The character in the story is the “blonde guy”, who doesn’t officially have a name yet remarkably resembles Hunter Parish and as story has it, the photo was shot nearly two years before Hunter was cast as the role of Jesus.

Version One was purely focused on getting the technology working and stubbing out the initial scenes that would eventually tell the entire story. We used static images from the existing GODSPELL site and Mitch started to overlay the first of the foreground images (the tree and Group Sales placeholders). Albeit rough, we knew right away the design had the makings of something amazing and truly unique for the Broadway community.

Version One
View the working iteration of Version One

Versions Two and Three focused on refining the parallax scrolling, smoothing out the speed of each foreground object, matching the velocity of our main character to other items, browser compatibility and creating what we called the scene transitions. The scene transitions at this stage are the tree, sign post, taxi and phone booth. During this iteration, Mitch started adding transparency to the windows of the cab, the panels in the phone both and the negative space of the street sign.

Version Three
View the working iteration of Version Three

Versions Four thru Six introduced many new elements while finalizing the story. As the story grew so did the canvas size. The initial width of all scenes in Version One was 3,000 pixels and by the time we reached Version Five we were pushing 6,000 pixels. The marketing team at GODSPELL provided additional assets like ring tones, videos, posters and other elements that were integrated on and into the wall.

Version Five
View the working iteration of Version Five

“The creative process was an iterative approach, one in which we went back and forth with the GODSPELL marketing team to craft the story of our character who walks through each scene looking at visual and interactive elements on the wall. Most of the objects you see on the wall and sidewalk were taken from actual New York City photos. In conjunction with the creative design we optimized the technology to ensure a smooth experience for each browser and device.” – Mitch Moccia, Senior Web Developer and Parallax Designer

In the diagram below we deconstruct the various layers that create the three-dimensional effect of walking along side the wall and seeing foreground objects in front of our main character. Each element was carefully timed to enter and exit the viewing window at the appropriate time to achieve the desired experience. In order to accomplish this, each element or object is set to a different speed at which it travels across the viewing window.

As you scroll, the main character proceeds from left to right through the urban cityscape and the user can view a video message from Stephen Schwartz, meet the GODSPELL cast, sample hit songs from the show and find an easy way to buy tickets online. Combine all of this with interactive design best practices, HTML5/CSS3/jQuery parallax code and precisely timed motion graphics and the new GODSPELL parallax site becomes a site worthy of the hottest ticket on Broadway.

View the final site and enjoy the show!

Check out the new GODSPELL website! It’s pretty awesome! @georgesalazar

OneSpring collaborated with the amazing marketing team at Davenport Theatrical Entertainment to redesign and implement the first ever Parallax Scrolling website on Broadway.

Parallax is a technique used to create an illusion of 3D space by moving layered objects or images at varying speeds in relation to one another. Although it was originally constructed for the gaming arena, it is a growing trend for web design. With the advancement in HTML5 and CSS, designers can now achieve experiences that were only reserved for Flash projects in years past.

Ok.. The new GODSPELL website RULES! Click on each individual cast member to see footage of their song!! @CelisseMusic

The new GODSPELL parallax site contains several layers of carefully selected and prepared motion graphics each of which moves faster the closer you get to the user. Complex foreground objects, such as the tree in scene one, the taxi in the cast scene and the bus in the subway scene, are designed with detailed transparencies so you can see the main character through the leaves of the tree and through the vehicle windows. The background is a seamless red brick wall that spans the entire piece and contains show information, interesting imagery and several areas of interaction.

If you click on the bios at Godspell.com, you’ll see clips from the show (ie. a snip of me singing ALL GOOD GIFTS). Pretty cool! @tellyleung

“The creative process was an iterative approach, one in which we went back and forth with the GODSPELL marketing team to craft the story of our character who walks through each scene looking at visual and interactive elements on the wall. Most of the objects you see on the wall and sidewalk were taken from actual New York City photos. In conjunction with the creative design we optimized the technology to ensure a smooth experience for each browser and device.” – Mitch Moccia, Senior Web Developer and Parallax Designer

As you scroll down, the main character proceeds from left to right through the urban cityscape and the user can view a video message from Stephen Schwartz, meet the GODSPELL cast, sample hit songs from the show and find an easy way to buy tickets online. Combine all of this with OneSpring’s interactive design best practices, HTML5/CSS3/jQuery parallax code and precisely timed motion graphics and the new GODSPELL parallax site becomes a site worthy of the hottest ticket on Broadway.

Visit www.godspell.com to experience the new website.

Scott McDowell, Chief Innovation Officer for OneSpring says “The GODSPELL story provided us with an assortment of great content and imagery therefore we knew we had to choose a technology that would provide the right medium for delivering the message. A number of factors led us to a horizontal parallax scrolling technique accomplished by using HTML5, this enabled a richer, almost three-dimensional experience that works across multiple browsers and devices.”

Agile development is becoming more and more prevalent in the Federal space with many agencies mandating its use. Agile is a fast and highly iterative process which requires new skill sets and disciplines. One key challenge is adapting and/or modifying current processes within this new framework. Government and industry alike are currently working on Agile adoption strategies with many companies developing their own hybrid models. Most of these models follow a similar path with slight variations throughout. However, the goal remains the same for the government, which is to develop software in shorter increments thus reducing cost, development time, and risk. If the plan works, everyone will benefit because the government will be able to start releasing software far faster. That means that critical systems that help insure our nations security will be developed in value driven increments as opposed to long drawn out software development life-cycles. We all benefit by making this work.

There are two groups within organizations that must cooperate in order for Agile to work properly. The two groups are Business and IT. The business is primarily responsible for building the business case for a proposed software application, funding, organizational goals, and objectives. IT is responsible for building the application within the defined budget, time, and scope. The problem is that there’s a misalignment occurring between IT departments attempting to implement Agile and the business side that defines what needs to be built as well as internal processes that must be adhered to. In government software development, the business side of a federal agency is still responsible for producing the same artifacts they have always produced as well as passing the same Software Lifecycle Management (SLM) tollgates.   Organizations cannot successfully adopt Agile at the IT level without changing their mindset of how the business side functions. This paradigm has created a disconnect between organizations looking to adopt Agile within traditional business operations.

If you take a holistic approach to the problem then you will start to see patterns and processes emerge at all levels of the organization. One immediate opportunity occurs at the hand-off between the business and IT. The hand-off is when the business passes over their requirements specification for a software application to the IT team to build. If an agency passes traditional requirements specifications to an Agile team the results are typically negative. Most Agile teams will usually want to start over by creating a list of User Stories that covers the requirements specifications delivered to them. This creates a tremendous amount of rework and churn, which usually leads to frustration by the business because they have to rehash what they’ve already spent a lot of time putting together.

The solution is to come up with a decomposition model during the hand-off period. Decomposition is the process in which the business and IT decompose the requirements specifications together to convert requirements into the proper format for Agile. The goal should be for the business to get the requirements 70% complete, then use the decomposition phase to finish off the requirements together with IT. This does several things to improve the odds of a successful outcome while reducing risk. First, it allows the business to further analyze and synthesis the requirements they’ve defined thus far with technical experts. Second, it gets the developers engaged in the requirements discussion earlier as opposed to doing a single hand-off at the end of the requirements phase. Third, it allows team members to build relationships with one another. Fourth, it allows the team to address usability questions and requirements before development begins.

Agile cannot be rolled out in a silo; it must be woven into the organization at all levels. This won’t happen overnight but as long as we can start to identify and address these challenges, the closer we will get to producing more value for the organization and its user community. Bridging the gap between business and IT has been around for decades, however, the advent of Agile has escalated the issue. Change needs to occur at all levels of the organization in order to accomplish the benefits of adopting Agile.

About the Author
: Jason Moccia has over 14 years of experience in the software development field and is a co-founder and managing 
partner of OneSpring LLC (www.onespring.net), where he oversees the Federal business practice as well as Operations. OneSpring helps companies to work smarter by providing an entirely new approach to software requirement definition.