SGT’s Approach to Agile Software...

SGT’s Approach to Agile Software Engineering

7701 Greenbelt Rd., Suite 400

Greenbelt, MD 20770

(301) 614-8600

(301) 614-8601 (Fax)

http://www.sgt-inc.com

June 1, 2014

The SGT Team — Achieving Results … Exceeding Expectations

Agile Engineering Approach

ii LEGAL TEXT

TABLE OF CONTENTS Table of Contents ............................................................................................................................ ii

About SGT ..................................................................................................................................... iii

Introducing SGT’s Agile Engineering Approach ........................................................................... 1

Why Agile? – A Brief History .................................................................................................... 2

Current Issues with Traditional development methods .................................................................. 3

Agile Software Development Methodologies ................................................................................. 5

Fundamental Best Practices ........................................................................................................ 5

Agile Methodology Practices ...................................................................................................... 7

SGT’s Agile Engineering Practices .............................................................................................. 10

Scrum: Introduction .................................................................................................................. 10

SGTs Approach to Scrum ......................................................................................................... 11

Core SGT Agile Development Principles ............................................................................. 12

The Continuous Improvement of SGT’s Approach .............................................................. 14

Best Practices: Organization and Planning ........................................................................... 15

Introducing Agile Practices to Your Organization ............................................................... 16

Agile Project Management ....................................................................................................... 17

Agile Engineering Lab .................................................................................................................. 20

Standard Lab Configuration ...................................................................................................... 22

Summary ....................................................................................................................................... 24



iii LEGAL TEXT

ABOUT SGT

Stinger Ghaffarian Technologies, Inc. (SGT) was founded in 1994 by Mr. Harold Stinger and Dr. Kamal

Ghaffarian, each with over 20 years of experience working on complex information technology (IT),

space and earth science and engineering programs. SGT graduated from the 8(a) program in August

2005, and today is the 19th largest privately-held federal contractor (2012 Washington Technology Top

100) with more than 1,650 employees in 26 locations across the United States. Our 40-fold growth since

2002 attests to a corporate culture dedicated to quality, customer satisfaction and the development of

customer-focused business processes of national significance.

Currently, we have 30 active contracts with the Department of Transportation (DOT), Department of In-

terior (DOI), Department of Commerce (DoC), NASA, and the Department of Defense (DoD). SGT’s core

competencies across these contracts encompass IT, science, engineering and program management. SGT

has an excellent history of exceeding customer expectations and has received exceptional Contractor Per-

formance Assessment Ratings (CPARs) for our service delivery. We understand the balance between

budget, technology insertion, compliance, and customer satisfaction. Our experience provides us with the

opportunity to develop customer-centric solutions that can be tailored to meet USCIS objectives. We have

performed in a variety of contract environments including fixed price, time and materials and cost-plus

both at the contract level and at the task order level. We consistently score in the 95+ percent range on

award fee evaluations and earn incentive fees above 100 percent. We have never had a contract terminat-

ed, nor have we ever defaulted on a contract. Our corporate infrastructure provides: DCAA approved

property and purchasing systems; Capability Maturity Model Integration (CMMI) Level 3 and

AS9100:2009 certifications, ISO 9001:2008/SAE AS and ISO 20000 registrations; DCMA approved ac-

counting system; and a Top Secret Facility clearance and the ability to perform in a Sensitive Compart-

mented Information (SCI) environment.



1

INTRODUCING SGT’S AGILE ENGINEERING APPROACH

SGT’s Approach to Agile Software Engineering contains the sum of many years of agile software engi-neering experience, and many more years using other methodologies. We attempt to be as realistic as possible throughout – for example, nearly all of our development efforts using other methodologies were successful by the metrics applied to them at the time. Agile methods represent an substantial, in-cremental improvement that has been developed over many years, that derives from successful con-cepts applied to software and other industries, and, when applicable and correctly implemented will definitely provide real positive impact on software cost, quality, and development time while greatly improving end user or customer satisfaction.

There are, however, organizations and projects for whom undertaking agile development would be a significant risk. We hope to provide risk avoidance strategies for these, and general experience-based guidance regarding how to pick the right first project, what needs to be done organizationally and oth-erwise to prepare for such a project and to maximize its chances of success, and how to objectively measure factors that will allow an empirical determination as to the relative success of the effort.

This white paper begins by describing traditional software development methods that were developed over many decades by expert, thoughtful professionals to address a set of increasingly problematic is-sues with software of all types and across all industries. As the traditional methodologies became wide-spread and were rigorously studied and improved worldwide, it became clear that the problems were not being solved and were in fact getting worse. We suggest that a broad understanding of the relevant history is useful, in that it details the issues which agile methods were developed to address. If your or-ganization is experiencing these issues agile methods might be the answer, and learning from (and avoiding) the historical mistakes of others is always valuable.

It is also necessary to adequately define what we are fixing – the term traditional methods cover a lot of ground. An exposition of the characteristics of traditional methods therefore follows, and issues that arise from applying them to modern development projects are discussed. A subsection is included high-lighting issues specific to US Government development efforts, as various mandates, practices, and or-ganizational characteristics can complicate government space development in general and agile practic-es specifically.

The concepts and practices central to agile methodologies as a class are discussed next, followed by de-tails regarding the most widespread and successful of these, Scrum. SGT’s specific approaches to devel-oping software via Scrum practices follows, and includes numerous best practices, lessons learned, or-ganizational issues and possible solutions, recommendations for agile adoption project selection, project and program management, and many other useful information categories. A strong commitment to con-tinuous process improvement is a core agile principle, and we detail how this can be done by using our internal practices as a successful example.

SGT’s Agile Engineering Lab is next described. Why it exists, what it is used for, its contents and capabili-ties, and examples of successful application of the Lab in the solution of real-world, complex engineering problems are all provided. We thank you for taking the time to read this document, and hope that it will be of value to you and your organization in your adoption and application of agile engineering principles.



2

WHY AGILE? – A BRIEF HISTORY

The Software Crisis became the common term to describe the problem over 40 years ago, and most of the current practices and broad disciplines related to software development are in direct response to it. Software Engineering itself, as a discipline, was named and has evolved in the attempt to address the seemingly unavoidable fact that good software is difficult to create: development projects take too long, cost too much, and deliver too little. Some projects don’t deliver at all; many more deliver the wrong thing. This all continues in spite of the application of formal processes designed to maximize quality.

When software systems began to approach one billion lines of code in the 1980s, two critical develop-ments emerged: object-oriented programming (OOP) methods and associated methodologies. While ‘Object Oriented Analysis and Design’ and similar methods are now obsolete, they are the direct ances-tors of today’s lightweight methods. Similarly, the growth of other formal methods (Structured Devel-opment) and processes (Capability Maturity Model – CMM), standards, Computer-Aided Software Engi-neering (CASE) tools, software component based development, and many other solutions to the ongoing ‘crisis’ were attempted. C++, then C# and Java became dominant development languages as the internet age progressed; leaving little doubt that object-oriented programming was a viable solution, while the methodologies were not.

Today’s Agile methods descend from initial attempts to develop appropriate methodologies to take best advantage of OOP, specifically via the use of modeling tools used to automate various steps of the de-velopment processes. Object Modeling Technology (OMT), Objectory, and the Booch OO methods evolved into today’s Rational Unified Process (RUP, an IBM offering, formerly Rational Software), and it’s lighter weight version, IBM’s Agile Unified Process (AUP). The first Rational Software version named RUP was offered in the mid-1990s. Additional methods appeared at the same time: Extreme Programming (XP) and Scrum have expanded and persisted across a wide range of development efforts, while Adap-tive Software Development, Crystal Clear, and many others that appeared in the 1995-1996 timeframe are still practiced to varying degrees of success. In 2013, Scrum and RUP / AUP are clearly the most prac-ticed agile methodologies, with many Agile and traditional shops using XP or some of its concepts. As RUP/ AUP is still considered proprietary, it is a distant second to Scrum, and the remainder of this Capa-bilities Statement will be Scrum specific.

At the founding of SGT, our principals had extensive experience in the application of the forerunner technologies and methods that evolved into the modern, lightweight, agile approach. The Aerospace industry that was then our focus continually required more powerful technology systems and software that was mission critical and absolutely had to work. As our firm has grown, we have experienced the innovations that have affected software engineering. Our Agile Engineering Lab allows us to continually exercise and improve our internal processes and thereby apply principles that work to our customers’ development projects.

Agile methods are mature and knowledge of them is widespread. The methodologies that are widely used are served by worldwide communities of practice charged with ensuring that lessons learned in the field are available to all and, potentially, eventually become part of the formal method. Any large-scale innovations that are generally applicable and known to work are inherent in the current versions of the methodologies themselves. Scrum, a successful modern agile methodology, is theoretically fully open,



3

with several non-profit organizations1 offering themselves as information clearinghouses. Given the wide acceptance of agile methods over many years of practice, there shouldn’t be any significant secrets that would give a significant advantage to any service provider. The reader is well advised to be wary of any claimed major departures from fundamental Scrum or other agile method best practices offered by any party. Real innovations will typically be small in scope and characterized as methods to achieve small improvements in consistency and efficiency in practicing this approach across the process. Eventu-ally, when proven to be widely applicable, such improvements would typically become part of Scrum itself if they are indeed true best practices. It should also be stated that agile methods are not universal-ly accepted as the ‘silver bullet’ to solving the current state of the software crisis, and there can be real disadvantages to applying them without taking advantage of lessons learned or without adequate prep-aration.

CURRENT ISSUES WITH TRADITIONAL DEVELOPMENT METHODS

Agile engineering methods describe a broad category of methodologies that share certain characteris-tics, generally accepted to conform to the Agile Alliance’s 2001 Manifesto for Agile Software Develop-ment2, which reads in total as (emphasis ours):

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more” In practice, these engineering values represent a significant divergence from the development ap-proaches that have been historically applied. Before we examine the resulting methods in detail, we shall attempt to understand the issues inherent in traditional development methodologies that agile methods attempt to address. The majority of the lifecycle processes, quality control steps, designed methodologies and visual model-ing approaches, standards, and tools that are familiar to development professionals and their customers were developed to address a pervasive fundamental issue: it is very difficult to write good software. It has been noted that software users have become conditioned to accept defects in quantities and de-grees of severity that, in any other product type, they would simply refuse to endure. Major releases of consumer software are routinely sold with tens of thousands of known defects, with the expectation that many more will be discovered by user communities; this is after significant effort and capital is ex-pended for quality assurance and internal testing, formal beta tests often involving many thousands of power users and followed by efforts to repair the discovered bugs. The problem pervades the discipline – the world’s largest, most respected technology firms cannot create defect free software.

1 And quite a few for-profit firms as well. Scrum isn’t ‘owned’ by anyone or any firm, but there are multiple organizations whose

principals were involved in initially formalizing Scrum, and remain involved in its ongoing growth and codification. 2 Manifesto for Agile Software Development, Agile Alliance, 2001



4

These issues have existed since the beginnings of the multipurpose digital computer. Early responses led to the gradual formation, beginning in the late 1950s, of the academic discipline Computer Science and attempts to examine and systematize software applications. Software Engineering followed about a decade later, which has as its objective the definition and practice of a systemat-ic, disciplined, quantifiable and measura-ble approach to designing, building, op-erating, and maintaining software. Early proponents of software engineering had begun to see Computer Science as an abstract, academic discipline, where they needed a practical approach to making real software work for real users. Concurrent to these developments, the term The Software Crisis gained widespread acceptance. It was intended to convey the idea that processing power would continue to increase, creating extensive addi-tional demands on the development profession: more software programs would be required, they would be larger and more complex, and would al-ways be subject to change as computing capacity leapfrogged current software. Early prognosticators did not foresee the growth of data networking, which adds its own dimension of complexity. In sum, it’s always been hard to write good software. Ever increasing systems’ computing power, explosive growth in the number and types of computer users, the advent of widespread distributed computing, and many other factors contribute to making it ever more difficult to develop good software. The solution to these issues was what we today call traditional software engineering methods. They in-cluded the concept of software standards, various specific standards, development and organizational processes (like the capability maturity model), Computer-Aided Software Engineering (CASE) tools, lifecycle management techniques, formal methodologies, and many other concepts and tools. Central to these are the various versions of top-down, structured software development, often called the waterfall approach. Waterfall methods can be characterized as those that:

Progress through a series of well-defined project phases (such as requirements specification / analysis, design, development, testing / debugging / acceptance, implementation, and operation / maintenance. This approach can be characterized as top down, where a large problem is de-composed into smaller, more manageable parts. Once this process of functional decomposition is complete, in theory, the small solutions can be reassembled into a cohesive whole solution to the original problem.

Require each phase to have specific entry and exit criteria; in most cases, activity should only occur in one phase at a time.

Follow a Big Design Up Font (BDUF) concept. A fundamental tenet of traditional methods is that expending significant time and effort ensuring that all of the requirements are specified proper-ly and that the entire design of the system is correct will result in reduced or eliminated need for rework later. Phase exit criteria are typically designed to ensure 100% completion of phase tasks prior to commencing the subsequent phase. An example would be the requirement for formal

A Software Issue Software costs too much and takes too long to

build. Long lists of known defects and often

egregious workarounds are expected by users of

both commercial packaged and custom soft-

ware. Stakeholders are frustrated that their ap-

plications are slow to adapt to changing market-

place, strategic, or other business realities. Rates

and degrees of change are not expected to de-

crease, exacerbating the delta between what we

need our software applications to deliver now

and what we can realistically expect them to

deliver after long cycles of analysis, design,

documentation, phase exit and entry criteria,

testing and other quality assurance methods, and

other traditionally claimed best practices.

Other types of engineering do not take so long

to deliver so little, nor would they tolerate even

a small percentage of the defects software users

have come to expect. A better way is necessary.



5

design reviews, often in a progressive format – team-internal peer design reviews would be fol-lowed by a larger group of reviewers, eventually leading to a formal sign-off after which all de-sign work would cease. At that point coding would begin, with design phase documentation used to measure the quality of the ultimate result.

Requirements are typically frozen, meaning that new requirements (or those that existed at the beginning but were not selected for inclusion into a series of project phases) are deferred until those currently being developed have been satisfied via analysis, design, coding, testing, and implementation steps. New requirements can be accepted and documented, but they will not be addressed until the full current cycle is completed.

Significant emphasis is placed on documentation in traditional models – design specifications, formal coding standards that include code annotation requirements, and other phase artifacts are created and maintained, and typically used in the phase review activities. This is generally a response to the problem of reproducibility, and the fact that personnel tend to be lost over the course of long development projects.

Implied mandates to follow the prior phase’s decisions exist in traditional projects. Programmer personnel are expected to implement the design as given. Designers are expected to design a solution to the requirements they were given.

Traceability is another important concept in successful traditional projects: testing phase activi-ties will attempt to demonstrate that the requirements as given have been met.

In general, the ‘measure twice, cut once’ approach characterizes the overall philosophy of traditional software development. Design, programming, and their validation through formal testing are considered very difficult and costly activities, so great care is taken to perform each set of tasks correctly, in a re-producible manner, and to ensure that they are comprehensively documented. Most of the criticisms of traditional methods can be found in the Agile Manifesto. A key principle is that agile methods assume that change is inevitable. Those of us with significant experience managing or contributing to traditional development projects would find it difficult to argue this point – no matter how committed to the requirements freeze we may be at the beginning of any significant effort, there always seem to be late critical additions that negatively affect our carefully planned schedules and esti-mates. Agile methods prioritize responsiveness to inevitable change over the original plan and any con-tractual arrangements that derive from the plan. One reason that change is deemed unavoidable by agile methodologists is their assumption that all of the requirements cannot be successfully collected in full at the beginning of any effort. Experience seems to bear this criticism out. A common occurrence is the submission of new requirements or changes to old ones during acceptance testing phases, for example, where end users first see the final product. The concept of rapid prototyping or other approaches that attempt to get the user community involved early in software look and feel and functionality (early proof of concept approaches that focus on the user interface, etc.) can be seen as ancestors to today’s full agile methods.

AGILE SOFTWARE DEVELOPMENT METHODOLOGIES

Fundamental Best Practices Multiple specific named methodologies can rightly claim to be agile. Those that have been demonstrat-ed to actually work share some basic characteristics, with the following being the most important driv-ers of project success:



6

Incremental approach – Building smaller pieces of software than typical in a traditional project. They are supposed to be ‘production ready’ when complete, i.e., at the end of each iteration. Whether or not they are actually launched into production then depends on multiple factors, but the principle of development being ‘done done’ at the end of each increment is commonly held.

Iterative approach – Smaller-length cycles of increments, that ‘add layers to the onion’ – what was created previously is assumed to remain ready for production and only new mate-rial is ‘exercised’. Short cycles can make the overall effort more re-sponsive to change by minimizing the amount of material affected by a late mandate, addendum, etc.

Self-organized teams –comprised of personnel with a cross-functional set of skills, complete to the task. All team members “do actual work” and are responsible for delivering completed product at the end of each cycle.

Co-location – Everyone involved in a cycle works at the same place, during the same hours, for the duration of the effort.

Adaptive planning and feedback loops – Objective measurements are used to make decisions. This means that we have to collect valid metrics throughout the process. Real data is required for successful feedback loops, while adaptive planning is the alteration of plans to current objec-tive reality.

Time- and budget-boxed cycles – Cycles have fixed durations and fixed budgets. The specific length of a cycle is not mandated, but they should be short (3 weeks is typical), and will always have an objective method to measure productivity. The budget will be calculated by the hourly cost of the development team multiplied by cycle length. Input (requirements) must be accu-rately and consistently estimated in some way to make this all work. Something as simple as ‘easy, medium, hard, extra hard’ typically works well, as long as they are always consistent with each other across iterations, and as long as it is possible to specify how much time any of them will take to complete. A related best practice is to measure estimating efficiency and attempt to improve it at all times.

Continuous improvement – A real across the board commitment. All phases are always exam-ined and identified opportunities for efficiency always exploited. It will take time for any team and organization to develop the skill to do agile development; metrics-based decisions will make that process more efficient, repeatable to other projects, etc.

Knowledge sharing – Progress reports based on objective measurements, lessons learned, tips and techniques, and all other knowledge developed during a cycle or project or set of projects is valuable. It must be made available to all, in easy to use form. It must be accurate and verifiable.

Adoption support – developers and organizations do not already know how to do this. It takes time to get it right. Carefully select the first proposal projects so that they are winnable and achievable without mandatory heroic levels of effort.

Process Automation / Tooling – This is critical. We have not seen an agile adoption initiative succeed without it. A key reason automation is important is that we can build in metric collec-tion points and automate report generation. The daily, cycle, and per-project burn down report is the key to success in a software project – it displays operational tempo (“velocity”) to all in-terested parties, and enables tractability from requirements to production solution

Critical Success factors

This list of principles and practices should

all be in place for your agile initiative.

They are the most common drivers of

successful agile projects, in SGTs experi-

ence.



7

Organizational commitment – and proper support. If agile adoption is to be attempted, those affected personnel and organizational components that will be affected should be aware of it, supportive of it, and empowered to make it succeed.

Agile Methodology Practices The Agile Alliance expanded its Agile Manifesto with the publication of these core principles3:

1. Customer satisfaction by rapid delivery of useful software 2. Welcome changing requirements, even late in development 3. Working software is delivered frequently (weeks rather than months) 4. Working software is the principal measure of progress 5. Sustainable development, able to maintain a constant pace 6. Close, daily co-operation between business people and developers 7. Face-to-face conversation is the best form of communication (co-location) 8. Projects are built around motivated individuals, who should be trusted 9. Continuous attention to technical excellence and good design 10. Simplicity- The art of maximizing the amount of work not done - is essential 11. Self-organizing teams 12. Regular adaptation to changing circumstances

Organizations desiring to apply them should generally select a proven, existing agile methodology that already adheres to these principles. In general, agile software development was formalized in 2001, and differs significantly from traditional methods. The agile principle that most often confounds developers, managers, and stakeholders used to traditional methods are the fixed budgets and fixed length of development cycles, which are relatively of short duration. These short devel-opment cycles are called iterations when refer-ring to general agile principles, but perhaps an-other methodology-specific name when used in the context of an agile method. Scrum, for ex-ample, calls them sprints. The meaning is the same – a very short cycle of development that results in completed software that works and could be immediately placed into production. Large tasks (overall project objectives, for ex-ample, or requirements that cannot be actual-ized in the span of one iteration), are still de-composed into smaller parts in all effective agile methods. The goal of such decomposition is to break the large requirements into portions that can be implemented in one single fixed length iteration, and for which the results could be put into production immediately. If that is not possible, agile methods are adaptive in nature. Development and project managers would have to figure out the ‘most agile’ method to deal with the current issue, and would

3 “Principles behind the Agile Manifesto”, Agile Alliance; Beck, Kent; et al. (2001)

Lightweight Development Methodologies Criticizing traditional methods as overly regulated, mi-

cromanaged, and unresponsive, the class of lightweight

methods began to appear in the 1990s. They are character-

ized as having a minimized set of rules and practices,

which are seen as obstacles to adapting to changing re-

quirements, environments, technologies, or other factors.

These early attempts to address the planning paradox,

which states that it is more likely that early attempts to

define a systems mission or requirements are likely to be

wrong to some degree, emphasize management flexibility

and the ability to adapt to change are emphasized in this

class of methods. Examples include eXtreme Programming

(XP), Adaptive Software Development (ASD), ICONIX,

Feature-driven Development (FDD), and others. Most of

the modern agile methods are also lightweight, with some

lightweight methods (FDD) also being agile. (FDD is rep-

resented in the Agile Alliance, publishers of the Agile

Manifesto).



8

immediately revert to strict adherence to agile principles when work on the anomalous development was complete.

Agile development teams are fully self-contained, meaning that they have the capability to do any anal-ysis, design, coding, and testing tasks necessary to create new working software and move it into actual production. Larger or more complex projects will typically have multiple self-contained, cross-functional, empowered teams working concurrently.

Development teams are necessarily cross-functional – they have the ability to do each of the above-listed traditional lifecycle activities and are charged to complete them quickly. They are also empowered to do all of them. The end result of each iteration is a demonstration of working software to stakehold-ers. The underlying philosophy is that risk is minimized by making the cycles short, and by making them truly short by eliminating any post-coding processes that would otherwise delay production launch.

Change is expected by agile developers. Shortening the length of time between a requirement being formalized and it’s enablement in working software both reduces the chance of change to the require-ment itself, and reduces the amount of rework or other wasted resources required if the requirement itself is faulty in any way – it takes three weeks to identify a mistake, not months or years, and the mis-take is isolated into a single, small, most recent version of the working code base. Short cycles is the sin-gle most important factor in the success of agile development.

The objective to place working code in production after each iteration is not necessarily a hard and fast rule. An iteration’s output is always new working code, but the results of a group of iterations may be necessary to justify a major release of, for example, commercial packaged software. Early iterations of most new development projects will not have made enough overall coding progress to make an entire launchable application, but the goal will still always be code that could be launched and the stakeholder demo always occurs. Projects where new features and functions are added to existing code bases or those where existing defects are to be fixed typically attempt to actually launch what is produced at each iteration. Service-Oriented Architectures (SOA) are particularly well suited to this aspect of agile development, as well-written web services tend to be small, generally useful atomic units of code.

Collaboration is emphasized in agile methods, both within the development team and without. For this reason, co-location of the development team is almost always required4. Face-to-face communication is the preferred method, with written design and development documentation either minimized or com-pletely abandoned5. Supporting full fact-to-face communication is one of the most important reasons that agile development teams are relatively small, typically comprised of 5 or no more than 10 mem-bers. Agile teams work best in a single, open workspace, and the bullpen arrangement is common to the vast majority of successful agile shops.

Small, high-performing teams producing working code every few weeks accelerates development pro-gress in general. Projects that are too large to be completed by one team in a reasonable amount of

4 Mature agile development shops successfully virtualize co-location, with development team members geographically dispersed

but in constant communication via electronic means. SGT does not recommend attempting this until all other aspects of agile

development are mastered to the degree that they become routine. 5 Requirements are fully, formally documented and managed by successful agile development shops. The most common forms

are the Use Case and the User Story, but multiple other formats have achieved consistent success over time.



9

time are addressed by the application of multiple development teams. Formal methods for team-to-team collaboration are inherent in each of the successful agile methodologies. A small but meaningful (and growing) percentage of the largest, most complex classes of commercial software applications are currently developed via multiple concurrent high performance teams using agile techniques. For exam-ple, a significant percentage of the most popular computer games are developed using agile methods, as were major components of Sun Microsystem’s later release of various Java environments. IBM, Oracle, and Microsoft all use agile methods to some degree on some of their products.

Automated processes and the tools to enable them are required for successful agile development6.

A value driven development strategy is inherent in the majority of successful agile methods. Require-ments begin with the stakeholders, who are charged to submit or prioritize their requirements by real, objective business value and to be able to justify their requirements in comparison to others. Every de-velopment activity begins with a requirement, and they will all be (eventually) prioritized via the busi-ness value that they would deliver if actualized.

Requirements management terminology and methods vary enough in the different agile methods that the following description will use terminology specific to Scrum. A development project’s desired result is called the product. The set of requirements that have not yet been actualized for a product is the product backlog. A Scrum-specific role, product owner, continually orders and maintains the product backlog, assigning objective numeric values whenever possible to aid decision making. Business value, events (needed by a certain date for a specific business reason, etc.), dependent requirements or re-quirements that depend on the current one, risk of not actualizing the requirement, risk of actualizing it, and any other factors relevant to the organization or the product can be maintained for each require-ment. The act of continual maintenance is called backlog grooming.

Estimates of development effort7 are always provided by the development team only, and their contri-bution is also backlog grooming. A simple, repeatable method of difficulty ranking is typically recom-mended, with a simple clothing size metaphor (XS, S, M, L, XL, XXL) being used by multiple successful teams. What matters is that the method is self-consistent, meaning that a requirement ranked ‘Small’, ‘Easy’, or ‘2’ actually requiring the same amount of effort as subsequent requirements with the same ranking. Teams do not begin agile development being very skilled at estimating accurately, so stake-holders and managers are encouraged to plan for early iterations being less efficient overall than later ones. The eventual goal of every agile team is consistent, accurate estimation. Other agile methods will use significantly divergent requirements management terminology but very similar processes and nearly identical underlying principles.

The final main characteristic of agile methods is the set of formal, routine meetings and project roles. Each specific methodology will again use different specific names, with very similar purposes. Roles will always include a representative of the stakeholders, fully empowered to make decisions on their behalf, speak for them, etc. Actual stakeholders are allowed to attend the open meetings, but are assumed to

6 SGT’s Agile Engineering Lab is detailed in a subsequent section, which provides examples of the various necessary tools, their

functions, integration points, available measurements and reports, and how to use them 7 Various ranking methods have been shown to work; common to scrum is Planning Poker, aka Scrum Poker, first formalized in

Agile Estimating and Planning, by Agile Alliance founding member Mike Cohn (2005, Prentice-Hall)



10

have other duties that would preclude them from being always present. It is also assumed that decisions need to be made at each of these meetings, so the stakeholder’s empowered representative is typically a full time member of an agile project with no other duties.

The daily ‘stand-up’ meeting (daily scrum, etc.) fosters direct effective communication – team members report on what they have completed since the previous meeting, what they plan to accomplish before the next one, and examine any roadblocks that may impede progress toward their objectives (and any that their activities might cause other team members or other teams). Rigorous adherence is common in successful shops: the meeting is held every day, in the same place and at the same time. They are inten-tionally kept very short – fifteen minutes is the common rule. Solutions to issues raised that take more than the allotted fifteen minutes are devised and enacted by the affected team members outside of the meeting.

SGT’S AGILE ENGINEERING PRACTICES

SGT has significant experience with multiple specific agile development methodologies, and has demon-strated the capability to deliver high performance development results in all of them. The remainder of this white paper will focus on Scrum, however, as it is the methodology that we recommend to custom-ers who do not have a preexisting preference.

The main reasons for selecting Scrum all have to do with its popularity. Qualified Scrum personnel for all project roles are more widely available than those with experience in any other fully agile method. This wide and deep talent pool benefits our customers and partners as well as SGT. More practitioners equal more projects, so Scrum is exercised in challenging field conditions more often and more rigorously than the other agile methods. This results in better process improvement over time – Scrum is the least risky methodology from that perspective. It should remain strong and continue to evolve and improve longer than any current competitive method. It is definitively the current strongest method.

SGT’s agile development professionals comprise the most important component of our agile develop-ment practices. Our experience and ability to develop software using agile methods is embodied in our practitioners – developers, development team and project managers, process experts, requirements professionals, tooling and systems personnel, and our corporate Agile Engineering Lab team. The Lab contributes to our success by allowing us to train SGT, partner, and customer personnel, supporting pro-cess and tooling experimentation, and supporting outsourced agile development.

Scrum: Introduction In part due to high unemployment and recession in the early 1980s, Japanese management techniques and manufacturing strategies were in vogue in the United States and elsewhere. Harvard Business School professor Hirotaka Takeuchi co-authored a Harvard Business Review article8 detailing a then-new method of product development called The Rugby Approach. The key principle differentiating this method was that a single, empowered, cross-functional team would perform every product develop-ment task from conception to production, diverging significantly from the then standard approach of phase-specific teams performing and documenting their work and then handing it off to another group.

8 The New Product Development Game, Takeuchi and Nonaka, Harvard Business Review January-February 1986, available at:

http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG

http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG



11

The Rugby Approach was based on earlier Defense Advanced Research Projects Agency (DARPA) and American Institute of Aeronautics and Astronautics Value-Driven Design systems engineering strategies, the origins of which date to the late 19609s. Rugby was far-reaching and influential, and remains widely read and applied today. During the nine years after its publication of Rugby, significant experimentation into the application of its principles oc-curred across multiple industries. Subsequent experiences applying Rugby methods to software development eventually became the first version of the Scrum development methodology that was presented10 at the 1995 Association for Compu-ting Machinery’s (ACM) Object-Oriented Pro-gramming, Systems, Languages and Applications (OOPSLA) conference by Dr. Jeff Sutherland and Ken Schwaber (currently CEOs of Scrum, Inc. and Scrum.org, respectively). Further collaboration and growth that led to the addition of many addi-tional contributors, experiences, and resulting lessons learned and best practices resulted in what is today known as Scrum. It is unfortunately impossible to accurately state the breadth of acceptance of Scrum and related meth-ods (Kanban, Scrum-ban11, etc.). Claims that Scrum “dominates” the marketplace, represents “80% of all development”, and the like are obviously not true. There are valid criticisms of Scrum, especially those that attempt to classify project types that are appropriate for Scrum methods. What can be said is that it is a very successful methodology when applied correctly and to proper development initiatives, and that it is very popular and growing rapidly.

SGT’s Approach to Scrum Each customer is unique. Varying levels of maturity in the adoption of agile principles, environments and systems, organization and place within other organizations, development needs and schedule, and mul-tiple other factors determine the ‘best’ method for each client and each development initiative. Flexibil-ity is an agile hallmark, and agile methods are, overall, a conceptual framework that should be fit to the specific initiative. Organizations early in their adoption of these practices are best served if they attempt to avoid thoughtless adherence to perceived rules that do not make sense in the context of what they are attempting to accomplish. For customers without a preexisting preference, SGT recommends Scrum, because it is a mature agile methodology with wide acceptance in industry and the Government. Our internal development is per-formed using the Scrum methodology, and we have demonstrated significant success internally and with our customers using Scrum. SGT additionally practices additional agile methods for customers who re-quire them.

9 Value-Driven Design in turn has its roots in the 1947 Utility Theory work of mathematician John von Neumann, who first con-

ceptualized the architecture of modern digital computers and many of the core concepts of what became computer science. 10 ACM OOPSLA 95 Workshop Proceedings, Business object design and implementation, University of Michigan. 11 Kanban is a another software development method based in Japanese Just-In-Time (JIT) manufacturing production methods;

Scrum-ban merges what its proponents see as the best features of each that specifically pertain to software maintenance projects.

The Broad Applicability of Agile Methods

We’ve only briefly noted the systems engineering roots

and manufacturing applications of agile principles be-

cause software development is the primary focus of this

white paper. The Agile Manifesto is very general, how-

ever, and its ideas have been applied to a wide range of

disciplines. SGT offers agile-based services in a wide

range of areas: the administration and management of

systems, systems software, applications, and networks;

maintenance of both software and non-software com-

plex systems, the management and analysis of data, and

many others. We further continually examine new ap-

plications and ways to improve current ones in our Ag-

ile Engineering Lab. Significant economic and perfor-

mance improvements reliably result from these ap-

proaches. Please contact SGT for more information.



12

Core SGT Agile Development Principles

The core principles of SGT’s approach that apply to all agile development projects include:

Self-organized development teams – Scrum development teams are comprised of personnel with a cross-functional set of skills. A fixed set of people with different expertise working toward a common goal, they all “do actual work”, meaning that they develop of code, perform analysis and design tasks, test their results, and provide documentation and other technical communica-tion. They are responsible for delivering working, tested code at the end of each Sprint. Subject matter or domain expertise can be made organic to the development team, or such personnel can be used as consultancy resources as necessary, depending on the specific initiative, the con-tents of a Sprint, or similar factors.

Sprint-based development – Software is built in smaller pieces (increments) than that of a tradi-tional, ‘waterfall’ project. These smaller portions comprise a Sprint. Sprints build software that is delivered complete, tested, and ready to put into production (this approach is especially appli-cable against a modern Service-Oriented Architecture (SOA), where Services are typically smaller than full applications, and can often be built much faster). Incremental development is designed to increase the amount of actionable information available to developers: As a subset of the re-quirements is built first, developers learn via the building process and by what the users report. Repeating the process of incremental development in Sprint cycles adds the concept of itera-tion. Sprint-based development is a repeated set of cycles (iterations) of smaller software prod-uct (increments). Short time frames allow the development team to be more responsive to change of any kind. For example, Sprint-based development is key to the solution of the ‘moving target’ issue that has historically plagued developers, testers, and application users. Require-ments can be quickly satisfied. If they were interpreted incorrectly, become outdated, or other-wise require change, the issue is known early and can be addressed with minimized overall im-pact. This contrasts with the traditional ‘waterfall’ method, where requirements are frozen at some point, followed by a relatively long period of development and testing. The users whose requirements started the process see the results in usable software after a very long time. Itera-tive approaches shrink this period in the attempt to be more responsive.

Adaptive planning and feedback loops – Objective measurements are used to make decisions in Scrum. Tools used to automate development and management processes (below) will each have metrics collection and reporting features. Selecting a valid set of these tools12 will ensure their integration and ability to pass measurement data to the Agile Project Management system, which will calculate and publish burn down charts for specific Sprints and projects, and multiple other pertinent aggregated reports with drill-down to detail capability. Real data is required for successful feedback loops, while adaptive planning is the alteration of plans to current objective reality. A common example would be regular inspection of project velocity, i.e., the rate at which requirements become production software. Management decisions would be made based on historical versus current velocity. Actionable velocity reports are possible if measure-ments are made of the rate of new requirement creation, the estimated relative difficulty of in-dividual requirements, the priority of each requirement selected to build, pass/fail rates of au-tomated tests performed against the software units that correlate to specific requirements, time elapsed per Sprint, and/or time elapsed after Sprint completion until the new software is actually in production. Each of the many small measurements possible throughout a Scrum ef-

12 SGT is tooling agnostic, as long as the development tools selected are known to work and interoperate. We have several sets of

tools that our experience shows to be good choices, most of which are ‘open source’ and have large user bases.



13

fort have significant potential value when aggregated, but would be very difficult to consistently and accurately collect without automated processes.

Time- and budget-boxed cycles – Sprints in Scrum have fixed durations and fixed budgets. Methods to ensure adherence include rigorous maintenance of requirements (User Stories) de-tail (Product Backlog grooming, performed by the Product Owner role), especially the method of estimating the effort required to enact each individual requirement and the techniques used by the development team to break large requirements into component parts to facilitate more ac-curate estimation and to ensure that the time box need not be adjusted. The length of a Sprint is usually between one and five weeks. The budget will be calculated by the hourly cost of the de-velopment team multiplied by Sprint length.

Process Automation/Tooling – Multiple methods are available to ensure overall efficiency and repeatability, with making the appropriate development tools available to the team and ensur-ing that they interoperate, fully integrate, and automate all of the relevant process being among the most important to success. Continuous Integration (CI) and Continuous Test (CT) systems, for example, allow developers to concentrate on development and rely on automated processes to integrate and evaluate their recently checked in code against the latest production code base in (a usually virtualized exact copy of) the production environment. SGT’s innovative Continuous Code Inspection (CCI) process performs automated quality inspections against all checked-in source code, enforcing adherence to development standards, protecting against the introduc-tion of low-level bugs, and performing a full range of configurable functional, performance, memory leak, regression, and other test types.

Organizational commitment – Successful adoption of agile methods does not occur, in our ex-perience, without firm commitment and support from the organization. Adequately forewarned about the potential issues to expect and using SGTs recommended initial minimized objectives and longer Sprints, the prepared new adopter builds into its plans the time needed to learn the processes and its tempos. Sprints will successively shorten and become more ambitious as skill and confidence is built, after which a fully mature, high performing agile development shop re-sults.

These core principles represent the minimum set that should be applied to a development effort in or-der to truly make it Agile. They are all included in every implementation of SGT’s approach. Our ap-proach, and any agile method, should typically be tailored to the realities that pertain to specific pro-jects and organizations. Less mature Agile shops should incrementally adopt the methodology, in our experience, adding more complex or difficult processes after mastering the core principles in practice. A minimum set of keys to success that apply to all SGT Agile projects are shown in Figure 1.



14

Figure 1. Lessons Learned: SGT’s Keys to Successful Agile Adoption and Sustainment

Automate key pro-cesses

Dramatically reduce process errors, deployment issues; Increases quality; Saves time; Keep developers developing!

Consider Open Source tools

Many are as good or better than proprietary; Often ‘standard’, with wider acceptance and knowledge; proven for mission critical applications Selected tools must support process automation and direct integration

Controlled culture shift Start small and prove success; Apply incremental and iterative approaches to changing expectations, attitudes, and behaviors

Development team adoption support

Set achievable but meaningful initial objectives; allow development team(s) time to adapt. Early Sprints should allow more time and/or include smaller sets of requirements, must collect and report on all relevant metrics. Disci-pline is essential in process automation and tool usage.

Team-wide commit-ment to continuous improvement

Communicate the need and processes for achievement. Support all sugges-tions. Commit and follow through on objective measurement collection, anal-ysis, reporting. Strive for transparency.

Co-location Do not attempt Scrum project if all developers are not in the same location! Distributed teams can work, but it is difficult and not appropriate for early attempts.

Knowledge sharing Share, manage, and retain knowledge; Publish reports, announcements, ob-jectives, and project documentation via JamWIki or similar.

The Continuous Improvement of SGT’s Approach

SGTs involvement in agile development techniques predates Scrum by many years. Early OO analysis, design, and coding methodologies did not, in practice, deliver appreciable improvements over the ‘structured’ methods then current. Most of our customers who attempted these then-new methodolo-gies soon reverted to the familiar waterfall. Over the last decade, more of our customer’s development efforts have required or entertained sugges-tions to use agile methods. Scrum has become a de facto standard during this period, at least among our client base. SGT has continually studied Scrum and other agile projects, taken measurements and per-formed analysis, and when possible compared results to traditional projects. We can develop hypothe-ses and test them in our Agile Engineering Lab, furthering our knowledge of which measurements are most important, and most likely to improve our delivery processes and our customers’ success. Each customer’s mission is unique. Scrum is adaptable and configurable. We continually seek actionable information, based on objective metrics that can be applied to ensuring the best result for each individ-ual client and project. Many of the key concepts we have developed are presented in this Capabilities Statement, but our commitment to continuous process improvement results in an approach to Scrum that continues to evolve. The largest efficiencies and risk avoidance strategies already exist in Scrum it-self, but we continue to inspect and analyze each appropriate initiative. One class of efficiencies, for example, exists in the classification of customers and projects. Those with common properties—size, maturity, similar objectives, relationships to other parts of an organization, externally mandated ‘non-Agile’ lifecycle components, or multiple other factors—can be grouped ac-cordingly. A hypothesis is developed: techniques used to successfully address issues common to the groupings can later be applied to new initiatives or organizations in a controlled manner. Further meas-



15

urement and analysis test the hypotheses and, once proven, they become standard toolkit items availa-ble to agile project managers. SGT applies agile and continuous process improvement techniques to its implementation of Scrum and maintains a portfolio of successful plans, methods to address specific types of issues, and similar knowledge items.

Best Practices: Organization and Planning

SGT recommends that most clients incrementally adopt agile practices. Extensive organizational experience in traditional methods does not ensure success of Scrum projects without careful preparation. Mature Scrum shops routinely execute and deliver their development commitments within their time boxes and budgets, but we are not aware of any shop that consistently performed initially. It takes time for an organization to adequately support Scrum development. Incremental adoption of Scrum is a key to success. Limiting initial objectives or planning for longer early Sprints allow successful achievement of objectives and delivery. Development teams become conditioned to succeeding, a subtle but important factor that fosters team confidence and the larger organization’s confidence in the team. Even the most committed organizations will include personnel with varying degrees of assurance that a new agile initiative will achieve success. The skeptic can be won over via a series of smaller successes in the actual environment much more effectively than with case studies or other proof-based claims. SGT advises clients embarking on new Scrum projects to lengthen at least the first three Sprints (when they are in the standard 3-4 week range). The development team will need to adapt to the new process-es and sets of meetings, and especially the Sprint Planning session and estimating. SGT typically recom-mends the widely accepted Planning Poker13 estimating method, but has successfully used multiple oth-er methods when our customers prefer them. It is essential that estimates are accurate, and this is a skill that takes time to perfect. crum adoption plans should incrementally improve Sprint performance. If the eventual objective is three week Sprints, if possible, allow six weeks for the first Sprint, five for the second, four for the third, and begin the fourth Sprint with the standard cycle length that is intended to be permanent. Developers should be cautioned to not over estimate. Mission critical, time sensitive development efforts are usual-ly not appropriate for first attempts at Scrum development. Allow the development teams to develop expertise and to become efficient by making initial assignments less time critical. Eventually, these scrum teams will take the most difficult jobs. One of the main reasons any organization should consider Scrum is the principle that developers are almost constantly productive doing development work. While agile project managers may also have to acclimate14 to the new processes, they should endeavor to take meaningful measurements immediately upon project commencement. If it is determined that the initial Sprints were planned too cautiously and that developers will be out of work for a meaningful period, the Sprint should be ended as soon as de-velopment is complete instead of adding new requirements to the cycle. This will reinforce desired de-velopment team behavior going forward with respect to estimating accuracy and Sprint discipline.

13 A specific estimating methodology common among successful Scrum and Extreme Programming organizations. 14 We strongly recommend experienced Scrum development project managers, but recognize that this is not always possible

when projects are staffed with existing incumbent personnel.



16

All desired development metrics should be gathered in the earliest Sprints possible. As we manage by objective measurements, we also improve performance with them. A team-wide commitment to con-tinuous process improvement is also key to long term success, and this needs to be supported from the beginning. Set objectives and estimates, measure relevant aspects of the process, and aggressively seek efficiencies. Charter and empower all team members to participate in continuous improvement. Always apply agile principles to the development process and thereby discover the small improvements that are available in the specific environment and projects. Support enactment and rigorous use of knowledge management and the application of lessons learned, initially via case studies and eventually based on analysis of objective measurements taken against your local projects and programs.

Introducing Agile Practices to Your Organization

First attempts to use agile techniques do not typically occur in a vacuum. If a truly standalone project that also meets the criteria for a proper first agile initiative exists, SGT typically recommends learning how to Scrum via the isolated effort as a risk minimization strategy. The usual case is that an early Scrum effort will be related to other projects and programs. This set of best practices discusses how to select early agile projects in the more typical real world case when no meaningful but relatively small, fully iso-lated initiative can be found.

Selecting the Right First Project Our experience results in the broad project classification categories listed below. They will not cover every possible case, but the groupings are a useful example of the use to which measurements can be put, and that allows us to emphasize the importance of disciplined commitment to metrics. We have not seen a fully successful agile project that did not rely on them. Analysis of objective metrics is how we demonstrate that we are doing Scrum ‘right’, how we uncover opportunities for improvement, and how we can objectively assess the relative success of a Scrum project against a comparable traditional effort.

Separate pilot – If a small, standalone development effort can be located, it often makes the best choice for agile introduction. In the real world, development dollars must yield tangible ROI. Additionally, there are often unconvinced observers requiring real demonstration that the methods are successful. Select the separate pilot project carefully, because it must be meaning-ful and the results must be useful.

Separate functionality – This is the more likely case, and all of the caveats from separate pilot apply. Isolate a set of functionality – a set of related web services, a specific application feature, workflow, etc. – from an existing larger project. Set up your selection criteria to result in a pro-ject subset that is as close to standalone as possible, in order to minimize complexities inherent in the relationship between the Agile and traditional efforts. An advantage is that it is more like-ly you’ll be able to meaningfully compare Scrum metrics to portions of the larger project.

Maintenance phase15 – This is a cautious approach to the introduction of Agile methods that has achieved good results. A Scrum team takes over O&M development for a software system that is in production. Integrating any existing defect reporting or change request processes into the Scrum model typically requires some effort, but the Scrum model does not change – a Prod-uct Owner will receive approved changes or reported bugs from external sources, groom the Backlog, and the Development Team selects Sprint contents from it. There are many advantages to this approach, but a few drawbacks, mostly related to severe defects: In a ‘pure’ Scrum situa-

15 Note that Kanban and Scrum-Ban methods are designed specifically to address maintenance phase projects. Discussion of the

relative merits of the three methods can be deferred here, because the objective is to support a development team’s learning

Scrum.



17

tion, code is thoroughly exercised continuously against an exact virtualized copy of the produc-tion environment, and theoretically launched without major bugs. An existing system will have bugs, some of which must be repaired immediately. The solution would be to assign ownership of a fairly mature product to the Scrum O&M team, in which the major severe defects have al-ready been identified and repaired. Existing processes of defect identification and prioritization, as well as those related to maintenance-phase enhancements or other development would typi-cally be used with as little modification as possible, with the User Story requirement format adopted in order to minimize or eliminate any disruption to O&M operational tempo while mi-grating toward full adoption of all of the relevant Agile processes.

Delayed production – Our final example category is a common response to the most typical is-sue with introducing Scrum to a US Federal development16 shop: Mandates external to the pro-ject do not allow code to be launched into production immediately upon completion of each Sprint. Eventually, the successful Government customer will achieve production software re-lease every 2-6 weeks (depending on their specific optimal Sprint length), but it usually takes time and often proof to disengage the downstream processes. In the beginning, Sprint results are promoted to a virtualized copy of the production environment that is under the develop-ment team’s control. At some point, the entire contents of that production environment are re-leased to the external processes for formal testing and approval to launch into the actual pro-duction environment. Key to success is always ensuring that the development team’s copy of production is actually identical to the real target environment – systems software patch levels, new code releases from other groups, operating system tune state, and multiple other factors could affect functional or nonfunctional performance of Scrum-sourced software. If delayed production is elected, the development team must add at least one systems specialist, charged with complete synchronization of environments.

Agile Project Management Most of what the experienced engineering project manager already knows is applicable to agile devel-opment projects. The project management discipline has embraced agile methods and attempted to incorporate them into their practices. For example, the Project Management Institute (PMI), publisher of the Project Management Body of Knowledge (PMBOK), has certified hundreds of thousands of Project Management Professional (PMP) credential holders since its inception in 1984. PMP earned Internation-al Standards Organization (ISO) accreditation17 in 2007, and PMI is the clear worldwide leader in the dis-cipline, holding standards in program management, portfolio management, project management organ-izational maturity and capability, and several other fundamental areas. PMI publications relevant to agile project management are more recent, but represent significant expe-rience managing projects across several organizational and industry classes. Scrum Project Manage-ment18, for example, details planning, scope control, and schedule management methods specific to successful Scrum projects while maintaining a concurrent focus on maximizing the use of the PM’s exist-ing traditional project management skill set. PMI’s 2011 Global Conference paper Agile Project Man-agement with Scrum19 is another valuable resource, which details a general framework for managing Scrum projects. Several other PMI publications exist that are generally cited as actionable, current refer-ences regarding PM best practices and how to enact them for your agile efforts. SGT would direct the

16 The issue is also possible, but less common, in private firms. The solution principles would be the same in either case. 17 ISO / American National Standards Institute (ANSI) standard PMI-99-001-2008 18 2010, Kim H. Pries, Taylor and Francis, Inc. 19 2011, Michelle Sliger, PMI Global Congress Proceedings



18

interested organization to these PMI resources first – there are hundreds of books currently available, thousands of papers, and tens of thousands of web resources, and it is not possible to read them all nor to assess their quality or relevancy. An exception would be Agile Estimating and Planning20, considered by many the essential reference on the subject. It details methods used to ‘stay agile’ through all phases of the project, how to select the appropriate estimating method for specific requirements or projects, feature prioritization approaches, iteration planning, predicting and improving progress, scheduling projects with widely varying risk pro-files, and management and estimation of more complex multi-team development efforts. This work is recommended without reservation. Current members of PMI should take advantage of their resources, and SGT recommends that customers planning initial agile projects consider arranging our project man-agement services, which range from initial consulting focused on developing full internal capacity to PM outsourcing. Project planning, Scrum planning, change management, risk, estimating, team construction, and multi-ple other relevant courses and associated certifications are available through scrum.org, and these are approaching general industry standard levels of acceptance. Other organizations also offer certifications and associated courses. Agile development project management can be broken into two main types of activities: Those internal to the development team(s) and those that interface with the stakeholders. Development team internal management is performed by the development team, as they are designed to be fully self-contained. When properly set up and operating in a high performance fashion21, report-ing functions are fully automated. Scrum roles pertinent to project management include: Product Owner – The stakeholders’ representative, empowered to make decisions as the voice of the customer. This role creates (writes in agreed-upon documentation format) requirements and adds them to the product backlog. Product backlog grooming activities are all performed by the product owner, which are essentially requirement prioritization steps. If the product backlog is properly maintained at all times, the development team’s selection of requirements for the next sprint is relatively simple – the highest priority items that can be created in a single sprint. ScrumMaster – Not a member of the development team, the Scrum Master’s job is to remove impedi-ments to progress. The role is critical to project success, but is not the manager or of the development team or the overall effort. Essentially an enforcer of rules, in place to protect the development team from outside distractions and anything that can be identified by anyone that can or does impede pro-gress in any way. Project Manager – Typically focused on personnel management, this person is never the ScrumMaster. Managers – from the perspective of the Scrum team, these are people who control their environment: systems owners, whoever controls their work location, etc. This terminology can be confusing, and it is okay not to use it.

20 2005, Mike Cohn, Prentice-Hall 21 The objective of SGT consulting services is often to xxx



19

Scrum project management includes scheduling and ensuring the occurrence of several critical recurring meetings, the pace of which comprise the project’s overall schedule: Daily Scrum – aka the Daily Standup, this meeting includes all members of the development team and occurs every working day. Strict adherence to the ground rules is a best practice, once that most suc-cessful organizations rigidly enforce: The meeting starts on time, every time, no matter who may be late, and does not stop to allow stragglers22 to catch up. Time-box discipline is also strictly enforced, with fif-teen minutes the usually accepted best practice. Anyone interested may attend the meeting, but only those members who hold core roles can speak23. Each team member answers three questions at every Daily Scrum:

1. What have you done since yesterday? 2. What will you do today? 3. What impediments or roadblocks impact your progress?

The latter are documented and assigned to the ScrumMaster for resolution. He/she may report progress in subsequent Daily Scrum meetings, if necessary. Scrum of Scrums – Every work day, immediately after the Daily Scrum, these meetings only occur when there are multiple development teams working concurrently. They are also time boxed and follow Daily Scrum discipline. A single designated member of each team attends, and the others return to their de-velopment. Discussion centers on technical areas of overlap and code integration. Four questions are added:

1. What has your team done since the last Scrum of Scrums meeting? 2. What will your team do before the next meeting? 3. What impediments or roadblocks impact your progress? 4. What impediments or roadblocks is your team about to create that will impact another team’s

progress? Sprint Planning – The development teams and product owners are required attend (others may ob-serve) these meetings, which are held at the beginning of every Sprint. The purpose is to select from the product backlog the contents of the Sprint backlog – the work that is to be done in the upcoming Sprint. This meeting is limited to one work day, typically eight hours, and is broken into two half day sessions:

1. Selection of Sprint backlog contents – The entire team discusses as necessary the priority of items in the product backlog.

2. Finalizing the Sprint backlog – The development team only determines the detailed internal plan for the Sprint, which results in the Sprint backlog.

Sprint Review – Held at the end of each Sprint, attended by all team members, the development team presents their completed work to their stakeholders. This is called the Sprint Demo, and typically has a

22 Enforcement of this discipline is a PM duty – consistent lateness would impede project progress and require resolution. 23 Best practice: Set up another meeting specific to the need if information needs to be imparted that is not directly relevant to the

Daily Scrum and its purpose.



20

half work day time limit. Completed work is production ready, though it may not be launched if tech-nical or project reasons dictate. Incomplete work is not demonstrated in any way, and it is a best prac-tice to not spend time discussing progress. The purpose of the meeting is to obtain concurrence that the work that has been done is ready for production. Incomplete work is the result of poor Sprint planning, or perhaps personnel or development skills issues, and should be addressed as part of the team’s con-tinuous improvement process. Sprint Retrospective – an open discussion of the prior Sprint, focused on continuous improvement. What went well and what went wrong are the key topics, centered on actions that can be taken to im-prove the next Sprint. This meeting is facilitated by the ScrumMaster, and has a half work day time limit. The overall goal of Scrum project managers is the development of a high performance team (or set of teams), who consistently execute scrum processes on time and within their budget boxes. Full visibility automated reporting of progress eliminates the need for much formal reporting, but provides actionable information that the successful PM will use to identify opportunities for process improvement. Identi-fied opportunities that are acted upon will result in new measurement data, so each change should be viewed as an experiment – if it works and is worth the effort, consider making the change permanent. Eventually, the successful Scrum shop will have developed their own internal procedures and practices that allow them to, within the overall framework of Scrum, consistently perform at a high level in their specific environment and while creating their specific software. Real commitment to openness, measurement-based decision making, and comprehensive continuous improvement of processes and individuals is the definitive quality of a successful agile development Pro-ject Manager. Initial iterations should typically be designed to recommended standards, but opportuni-ties to improve, continuously sought and rigorously applied, will eventually result in a shop-specific ver-sion of any agile method.

AGILE ENGINEERING LAB

Senior SGT technicians initially conceived what has become out Agile Engineering Lab organically, as a set of virtualized systems that could be used to test installation and integration of various combinations of tools used to support customers’ agile software development. It has since evolved into an actualiza-tion of the standard tool set and configuration that we recommend to clients about to adopt agile prac-tices. The standard configuration of our Agile Engineering Lab is depicted in Figure 2, below. It serves as a reference platform, comprised of specific tools and configurations that are known to work, effectively integrate and interoperate, and to have performed so in a wide range of real world agile development initiatives. Virtualization is used extensively throughout the lab. This allows experimentation with every class of component that could be used in a customer’s development or production environment. Hardware plat-forms, operating systems and patch levels, system tune state and other configuration parameters, data-bases and other systems software, each of the actual development tools, tool configurations, tool inte-gration, metrics collection, reporting, and all aspects of process automation can be supported and re-configured. We use these features to allow our customers to begin their agile projects with a proven, optimized environment configuration that automatically produces all relevant reports. Additionally, is-sues with their environments can be debugged without delaying their development efforts, and optimal tune states can be determined to maximize performance.



21

There are many options for each category of development tool. While SGT remains ‘tool agnostic’, it is important that our customers select tooling that functions well. Our Lab also allows us to test functional-ity and integration of new software tools, and to verify integration and interoperability of proposed cus-tomer environment configurations. SGT uses the Lab to perform our own internal development activities, develop and test innovative pro-cesses and tools, experiment with measurement and reporting processes, and continually improve our methodology, internal processes, and delivery skills. Training for developers and systems management personnel occurs frequently, ranging from complete end-to-end process education for our newest em-ployees to innovation-specific courses when we have finalized proof of the efficacy of a new concept and need to roll it out to our entire community of practitioners. Standard training courses are also conducted for partner personnel and our customers, ranging from short manager’s overviews to in-depth technical edu-cation for practitioners. Accelerated courses spe-cific to experienced devel-opers and managers new to agile methods or a spe-cific method are also pro-duced. Customers who cannot for whatever reason locally support their own co-located development team can access the Lab in a range of ways. Full out-sourcing services are available, and are typically recommended to custom-ers who do not wish to develop agile develop-ment capabilities of their own. SGT typically rec-ommends that clients who do develop software and have the perceived need to have specific software developed via agile means expend the effort to develop their own agile capacity. Clients who do not typ-ically develop their own software are our most likely candidates for full outsourcing. Government agen-cies, for example, who require custom software and want it delivered as quickly as possible with mini-mal defects and at reasonable cost are typical examples. Customers with space problems, preferably temporary, are also common Lab users. We can support the typically sized Scrum development team and supporting team members during periods of increased de-velopment activity, for example. Experienced high performing teams can access Lab systems securely

Continuous Code Inspection (CCI) NASA selected SGT to develop their Java PathFinder (JPF) core, a developer-

configurable Java bytecode execution environment designed to find a wide array

of code defects. This powerful, extensible “Java verification” system was de-

signed to enable the use of java-language programs for truly mission critical ap-

plications. JPF detects defects that cannot otherwise be found before the code is

executed in its target environment. Code performance, memory leaks, overflow

conditions, memory access / freeing issues and similar subtle low-level error con-

ditions are detected before they put personnel or expensive equipment at risk.

Code coverage and multiple other test vectors are supported, and the program has

been deemed so successful that NASA has made JPF available as Open Source.

Significant enhancements, extensions, and additional unplanned uses for JPF con-

tinue to be produced across the Open Source community.

SGT’s innovative solution: SGT’s Agile Engineering Lab is intended to support

process innovation experimentation and testing in addition to more traditional

uses such as the introduction of new tools and integration methods, training, and

outsourced development. Extensive effort was applied to the design, develop-

ment, and testing of our Continuous Code Inspection (CCI) automated, configu-

rable agile process. All code, upon check-in, is exercised by pre-configured JPF

verifications relevant to the needs of the project. These automatic processes are

completely transparent to the developer at check-in time, with workflow-routed

test results automatically delivered. Code units can be tested for any verification

type supported by JPF or any JPF extension. CCI integrates with Scrum-standard

standard Continuous Integration and Continuous Test processes, and records a

full set of development manager configurable metrics for individual reporting or

aggregation to larger-scale reports and burn-down charts. SGT recommends and

uses CCI for all agile development efforts using the Java language for mission

critical applications.



22

and remotely, if desired, to perform geographically distributed development. This is typically supported by internet based voice and video conferencing to enable constant communication.

Standard Lab Configuration

The base configuration of our Agile Engineering Lab is depicted below. This is the standard setup that we recommend to customers building a new development environment, and has been developed based on experiences performing hundreds of development projects. This combination of open source tools and proprietary environment software is known to work, to interoperate and seamlessly integrate, and to fully support all aspects24 of agile development.

Developer’s workstations house Integrated Development Environments (IDEs), which automatically in-teract with configuration management tooling in a virtualized code repository server. Continuous code inspection, an SGT innovation, is applied to each unit of checked-in code, verifying its compliance with programming standards, exercising and inspecting code for low-level programming is-sues such as memory leaks, and performing a full suite of automated tests that pertain to functionality and performance. Also upon check-in, automated build management processes kick off. When they are complete, continu-ous integration software places the new code into a virtualized version of the latest code base, then alerting the automated testing system.

24 A J2EE development environment is depicted. .NET development would require Microsoft’s proprietary Visual Studio prod-

ucts to be installed on the developer’s workstations. Agile methods are language independent, so any development environment

is possible.

Figure 2. SGT Agile Engineering Lab basic configuration



23

Automated tests exercise the new code base entirely, fulfilling functional, integration, performance, re-gression, and any other testing function desired. Results are sent to the project management application, which are merged with data supplied by other sources to produce daily burn down charts, traceability information for each relevant requirement, and other reports. Developers populate knowledge management systems with relevant design information, and it is also used as the general information gateway for the project. The requirements management system is the primary tool of the Product Owner, who will use it to groom the Product Backlog from which the devel-opment team selects the contents of a Sprint based on priority and the number of highest priority items that they can complete in the next time-boxed Sprint. Process metrics are recorded at each stage of the described process, but some are more useful than others when compiling pertinent reports. Burn-down and velocity charts, for example, are typically al-ways automatically published to the knowledge management server and available to a wide audience25. Generally, the most useful metrics include:

Code check-out / check-in – atomic elements of developer progress and activity.

All automated integration and code exercise steps – ensure that the steps occurred in the right order are necessary for eliminating process issues from code defect repair activities. This saves significant time when defects are detected.

Agile PM processes and measurements – These are generally aggregates or higher-level metrics, with the burn-down chart being the most common example. This report relates requirements to working software, the pace of which defines the development team’s velocity. Drill-down and reach-through capabilities are a best practice, in that they allow stakeholders to progress from the report to the requirement they created.

Backlog(s) management via Jira – The product backlog is all of the requirements for the product that have not been actualized and are not currently under development. The sprint backlog is the set of requirements under current development. Various reports are useful for each of these backlogs, with individual metrics about the progress of requirements form origination through to production necessary to compile all of them.

Knowledge sharing – Metrics could be useful and reported on that pertain to the publication of externally visible reports, knowledge articles by developers or managers, etc.

Developer workstation – The integration between this and the configuration management sys-tem provides atoms relevant to developer productivity and the progress of solutions through the process.

Code repository / configuration management – measurements relevant to ensuring that the right versions of code, executables, documents, and other files are progressing through the sys-tems properly are the most important.

Build automation – Similarly, it is critical to always be able to verify that the intended code units are part of a specific build.

Continuous Integration – When code is checked in, it is immediately integrated to the latest code base. Measurements about the process are also necessary for debugging, requirements traceability, and process management.

25 Security considerations may make this impossible for specific customers or projects.



24

Continuous Quality Assessment – With continuous quality assessment using SonarQube, the code is tested for quality against the SQALE26 methodology and assigned a quality grade

Continuous Code Inspection – When continuous code Inspection is necessary, process meas-urements are equally critical. Mission critical applications require code to be exercised at various low levels in order to ensure that memory leaks or other low-level issues are not possible in the production environment. Specific CCI reports are always recommended in these circumstances, and atomic metrics are collected for use in other reports.

Continuous Testing – Each developer’s day begins with a report of the tests conducted against the code they checked in the previous evening. Managers monitor developer progress and abil-ity with roll-up reports base on these atomic measurements.

Agile Project Management and Reporting – All regularly used measurement atoms are funneled to this system, which generates all of the roll-up and widely visible reports. It additionally com-pares real progress to plans and objectives. This is especially critical when Earned Value Man-agement is enacted for an agile development project.

Requirements Management – New requirements, modifications to existing requirements, re-quirement priority, risk metrics, time sensitivity, and all atomic measurements necessary to support requirements traceability are sourced from this system.

SUMMARY

SGT’s approach to agile software engineering is based on experiences gained from many years of soft-ware development using a myriad of methodologies. This document describes Agile best practices as applied to software engineering and follows up with SGT’s recommended approach in bringing agile practices to your environment. The document finishes up by describing Agile Lab, an SGT innovation in integrating multiple agile development tools in a cloud-based infrastructure.

26 http://www.sqale.org/

Date post:	27-Jun-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

SGT’s Approach to Agile Software...

Documents