Interesting Articles from around the Internet

At OneSpring our employees often pass relevant articles around the company that they locate by way of Twitter or other news sources.

Here are four such articles that we believe are worth taking a look at, broken out by subject area:

Program Management

Agile Program Management
by ScrumAlliance

Requirements

Agile Analysis, Agile Testing: Synergies for Successful Software Solutions
by ebgConsulting

Requirements for the App – Tips and Tricks for the iPad World
by Remzil Kulkarni for businessanalysttimes

Visualization

A Taxonomy of Visualization Techniques
by Jeffrey Heer, Ben Shneiderman for acmqueue

Enjoy!

About the Author

Chris Staufer is a Sr. Visualization Analyst with OneSpring. When he’s not developing innovative ways to document requirements for federal and corporate customers, he enjoys practicing martial arts and spending quality time with his wife. Chris lives in Atlanta.

Agile Requirements Definition and Management (RDM)

One of the myths of Agile software development is that documentation is not required or useful. It is true that one of the core values within the Agile Manifesto is Working Software over Comprehensive Documentation. However, note the word “over” in this statement. The Manifesto is not saying “no” documentation, it is saying there is a preference for working software over documentation. The goal is to remove impediments from the system and leave things that add value. If your organization is creating lengthy documents to produce software and you are still struggling to release software on time and within budget then ask yourself this question, “What value are the documents adding?” The value question is an essential part of Agile as well as Lean Thinking. Lean Thinking was popularized by Toyota and has been widely adopted across many industries. Its premise is to eliminate waste from the system and to get down to the essence of what it takes to drive value to the customer. It also focuses on self-organizing and self-correcting teams to drive quality and efficiency in the system.

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).

One issue with prioritizing Features

Within most software requirements definition phases, priority is established at the Feature level (usually high, medium, low). Requirements are then developed but not necessarily based on the priority established by the business. What teams usually find is that most requirements are interconnected, so the team may start with a high priority feature but inadvertently move into low priority areas out of association. This causes the team to misalign with the business objectives over time. What typically happens in this case is the team misses expectations by veering off course during the project.

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.

Agile Development Workshop

OneSpring is co-hosting an event on Agile Software Development in Washington DC on January 31, 2012. The event will outline key topics within Agile, Scrum, and Agile Requirements Definition and Management (RDM). Software Visualization will also be discussed and its impact on Agile. OneSpring will be joined by other industry experts with knowledge in Agile adoption and implementation.

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)

OneSpring discusses Agile Development with Federal Computer Week

OneSpring’s own Jason Moccia contributed to a debate on the value of Agile development in a Federal Computer Week article written on the topic. The full article can be viewed at Federal Computer Week.

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.

Agile in the Federal Government

Agile is a value driven software development philosophy that is lightweight, fast and highly iterative. Agile has been around for over 10 years but has recently emerged in the federal space as a result of the governments 25 Point Implementation Plan which highlights modular software develop to control cost and scope. This realization has made Agile more popular than ever in DC. I am currently evaluating several federal agencies attempting to adopt Agile and have seen patterns emerge that require further analysis and reflection. One such item relates to how requirements are captured and managed within an Agile framework, not only at the development level but also across the organization. Traditional requirements definition and management does not fit well into an Agile model, however, this is the norm for how most large-scale software projects operate, especially if organizations have been following a Waterfall methodology for years.

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.  

So What’s This iRD Thing Anyway?

We’re working hard to overcome the status quo in software requirements. I truly believe there are many out there that have resigned themselves to just having to “deal with” the challenges of ambiguous requirements, slipping deadlines, reduced feature sets, and the like. There are reams of documentation that is expected to be read, understood, and approved.

Most of the time, the project team needs to seek this documentation from a central repository, such as SharePoint. While all the documentation may be there, it’s often left to each team member to determine what needs to be downloaded and read. Documents that support other documents are referenced, but the team member is left with the daunting task of trying to keep it all together.

What if there was one “document” that provided all of the information stakeholders needed? What if this document was delivered on a mobile device such as a phone, tablet or e-reader that could be taken anywhere? What if stakeholders, development, QA and others had a customized version with just the documentation they needed? What if the documentation was interactive with software visualizations, walkthrough videos, and collaboration?

Introducing the iRD™ or Interactive Requirements Document™.

Instead of disparate Word & Excel documents, Visio diagrams and other document types uploaded to some sort of repository, the iRD encapsulates everything in a very easy-to-use and very portable format that is targeted to each set of stakeholders. Because no two projects are exactly alike, the iRD is customized for the client, the project and the technology the iRD will be used with.

For example, we are currently delivering an iRD™ for the Department of Homeland Security which will be delivered via Apple iPads. Stakeholders will be able to view and comment on all project documentation, experience a high fidelity visualization of their software, watch walkthrough videos and much more all within a single experience. They will be able to take the entire project with them wherever they go. The feedback so far is nothing short of amazing.

Why settle for the status quo on your next project?

Introducing Agility into Requirements Definition

Executive Summary

Much focus has been paid in recent years to the introduction of Agile methodologies into the overall software project space. The bulk of these methodologies focus on quickly generating ‘code’ that can be tested. However that alone does not fully accomplish all the business goals, of a project. This is because not as much consideration has been given within Agile methodologies on traditional ‘Requirements’ stages, or if in fact ‘Requirements’ even belong in the discussion.

This paper sets out to recap the business value of Agile, and then express how the same benefits that Agile provides to the overall lifecycle can and must be introduced and implemented specifically within the Requirements Definition function.

Agile, at the conceptual level
In 2001 the Agile Manifesto was launched, whereby 17 “organisational anarchists” defined four values for better ways of developing software:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The result of many years of Agile methods momentum has produced flavors such as Scrum, Crystal Clear, XP, ASD, FDD, DSDM, etc. Additional entries have included OpenUP / RUP, Lean, EVO, and The Eclipse Way. Collaborative practices are key in them, and many have jumped on the opportunity to be what they think is “faster and cheaper.” In some cases this led to fragilism.

A good definition of Agile at its highest level is: an iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce project deliverables in a cost effective and timely manner which meets the changing needs of its stakeholders.

Core principles of this therefore include:

• “Fits just right” process – Do the simplest thing possible, Self-correcting teams
• Continuous testing and validation
• Consistent team collaboration – De-emphasize ‘meetings’
• Rapid response to change
• Ongoing and useful customer involvement – active customer involvement is imperative! – find a champion, Nothing counts until you deliver software
• Frequent delivery of working product – Weeks rather than months; days rather than weeks

In a traditional lifecycle of a project, risk is delayed. Much activity occurs “up front,” whereby design and construction occur in a vacuum. Architecture and functionality is not “seen” until near the end of the lifecycle. Contrast that with Agile, where candidate architectures are revealed earlier, serving to expose potential problems. The gap between these two approaches can be seen as the amount of risk reduction that can be salvaged.

Finally, there are some concerns to face, regarding Agile. Many of these are misconceptions, however:

• Uncontrolled Change
• Chaos – No process
• Develop with insufficient requirements
• Developers run the show
• Process itself becomes the goal
• Placebo effect
• Key point gets missed

So what should be the fit, with Requirements Definition?
As Agile increases in popularity, there can be a belief that stringent Requirements processes can be seen as overhead. A mistake can occur whereby there is the feeling of a need to ‘rush’ almost directly to development, and Requirements only serve to slow things. This misses, however, the need for business side users to (still) connect with their external development partners/organizations. So regardless of Agile’s speed to market benefits, business subject matter experts still have to play an important role; which dictates that they must have a place at the table along with development providers.

The problem with traditional ‘Requirements’ activity
The underlying problems with traditional Requirements Definition are distilled into three main causes:

• Misunderstood product requirements due to ambiguity of written specifications
• Lack of sufficient information to support complex applications/systems
• Inability to “test drive” a product design with customers and stakeholders before development

One can easily see that the above issues are not Agile, in philosophy.
Additionally there exists a desire by project teams to always minimize ‘change.’ This desire leads to an attempt to define everything up front. Agile methods can improve on this through iterations that stagger ‘commitment.’

After years of experience at OneSpring, we feel we’ve learned a better way.

We call this approach the Stream Process™. The Stream Process™ is a methodology that offers companies a collaborative and highly-visual approach to creating superior products and solutions in less time, with reduced project re-work. This helps companies dramatically improve productivity, quality and customer satisfaction.

Stream’s core process is made up of three areas: Insight, Clarity and Focus. Each of these areas are performed in a Realization Cycle. The output of a Realization Cycle is the Definition. Each time a full Realization Cycle is performed, an iteration of the Definition is achieved.

The output of each Realization Cycle is “delivered” to the stakeholders. Unlike a SDLC (Software Development Lifecycle), however, this output is not delivered to the development team with the intention to code from, but rather delivered to the consumers of the requirements definition (e.g. business, customers, IT).

The purpose is to achieve a common understanding before beginning to code. Once this common knowledge is achieved by the team of stakeholders, the Definition may be used for IT architecture/development. In other words the inputs for development – user stories, use cases, etc. – are now stronger. Visualization has mitigated the risk of missing out on the real business goals.

This scalability and flexibility therefore allows StreamTM to easily be integrated within any organization using Agile based methodologies, or to in fact introduce Agility into an organization who has not yet taken this path.

Some Agile proponents might argue that there is no Requirements Definition ‘stage’ with an Agile approach. We find that stance to be unrealistic at best, and foolish at worst. Defining requirements is where it all begins. Without that, what are you designing/negotiating/working for? An aimless, amorphous goal? How will you know once you get there? How will you know if you don’t?

Others will focus on ceremony, and state that since visualizations do not automatically turn into working ‘code’ they aren’t of value. This is naïve, for a Visualization prototype that all stakeholders agree on and take ownership of does provide a detailed blueprint that can provide immediate value, without need for ‘translation.’
Therefore and in conclusion, we propose the following analogy:

• Agile approaches, regardless of the flavor, apply to the development lifecycle as a whole
• The Stream Process™ introduces the concepts of Agility via a specific set of activities, to the Requirements discipline of the lifecycle

General Sources:
http://agilemanifesto.org/ http://en.wikipedia.org/wiki/Agile_software_development#Agile_methods http://www.ibm.com/developerworks/rational/rationaledge/ http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf