Corporate Agile Software Development

For those of you that don’t know, I am currently the software development manager for a fortune 500 financial company in the United States.  Because I work in the financial industry most agile coaches are shocked that we even practice agile development.  Most financial institutions are set in their ways when it comes to developing software.  Usually it is the traditional waterfall (BDUF) process that plagues these institutions.


The most important aspect of introducing agile practices is to make sure to include everyone. By everyone I mean every stake holder. Usually in a large corporation you have business analyst who act as advocates for the customers in the field. Then you have systems analysts who act as proxies between the development team and the business analyst. Then you finally have the development team who actually builds the system. When introducing agile you have to make certain not to exclude or take away from given responsibilities that have been there long before you came along.

 The information below is the beginning of a 6 part series on corporate agile development.

Corporate Agile Development Life Cycle Stage Overview 


Corporate Agile Development supports rapid iterative development with continuous learning and refinement. Product definition, development, and testing occur in the form of six phases resulting in the incremental completion of the project. These six phases form the foundation of a release. Different releases have different focus as the project approaches completion. One week iterations allow you to reduce the margin of error in your estimates and provide fast feedback about the accuracy of your project plans. The following list and illustration provide an overview of the process. The subsequent chapter will provide more guidance on how each phase is implemented.

Six phases of a release:


  1. Storming Phase
  2. Planning Phase
  3. Development Iteration Phase
  4. System Integration Testing (SIT) Phase
  5. User Acceptance Testing (UAT) Phase
  6. Closing Phase


The entire process is geared around collaboration and communication. Subtle variations have been added to expand upon on already proven process.


While in general practice agile methodologies encourage change and adaptation, certain changes have greater impact and require careful consideration and coordination. It is not a matter of control—who gets to make the decisions—as much as it is a matter of coordination—making sure the team understands the total impact of a change and which groups are affected. The Business Analyst partner along with the Systems Analyst and Development Architects collaborate around requirement goals. The result of this partnership is the determination jointly if the requirement goals are viable enough to make it into a release planning phase.


The purpose of the storming phase is to clearly identify what is to be modeled and to uncover any user goals that require additional information. The following artifacts will be the result of the storming phase:



  • Field Request
  • Requirement Goals
  • Feature Cards
  • Feature Skeleton
  • Planning Preparation Meeting

It is not a matter of control—who gets to make the decisions—as much as it is a matter of coordination—making sure the team understands the total impact of a change and which groups are affected. The Business Analyst partner along with the Systems Analyst and Development Architects collaborate around requirement goals. The result of this partnership is the determination jointly if the requirement goals are viable enough to make it into a release planning phase.


The purpose of the storming phase is to clearly identify what is to be modeled and to uncover any user goals that require additional information. The following artifacts will be the result of the storming phase:

What is a Field Request


Every day new ideas or concepts for a system are brainstormed or thought of. These epiphanies lead to enhancement to an existing systems or the creation of an entirely new system. A field request is nothing more than the culmination of these epiphanies manifested in a written, auditory or electronic medium.

Responsible Ownership

The Business Analysts are responsible for aggregating the entire queue of field request for their customers. The queue should be prioritized from a business value perspective that allows the Business Analyst manager to quickly determine what field request warrant further investigation in becoming a Requirement Goal.

Example of a Field Request

Field User Sally: (Drafting and short email)

I was wondering if you could please find a way for our clients to use some type of machine to draft money from their account and see their balances.

Thank you,

User Sally


What is a Requirement Goals


It seems so easy to think that if everything is written down and agreed to then there can be no disagreements, developers will know exactly what to build, testers will know exactly how to test Customers will get the developers’ interpretation of what was written down, which may not be exactly what they wanted.

Before we talk about what a requirement goal is let’s talk about what it isn’t.

Requirement Goals Are not IEEE 830 Mike Cohn: User Stories Applied

The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications (IEEE 1998). This document, known as IEEE Standard 830, was last revised in 1998. The IEEE recommendations cover such topics as how to organize the requirements specification document, the role of prototyping, and the characteristics of good requirements. The most distinguishing characteristic of an IEEE 830-style software requirements specification is the use of the phrase “The system shall…” which is the IEEE’s recommended way to write functional requirements. A typical fragment of an IEEE 830 specification looks similar to the following:


4.6) The system shall allow a company to pay for a job posting with a credit card.


4.6.1) The system shall accept Visa, MasterCard and American Express cards.


4.6.2) The system shall charge the credit card before the job posting is placed on the site.


4.6.3) The system shall give the user a unique confirmation number.


Documenting a system’s requirements to this level is tedious, error-prone, and very time-consuming. Additionally, a requirements document written in this way is, quite frankly, boring to read. Just because something is boring to read is not sufficient reason to abandon it as a technique. However, if you’re dealing with 300 pages of requirements like this (and that would only be a medium-sized system), you have to assume that it is not going to be thoroughly read by everyone who needs to read it. Readers will either skim or skip sections out of boredom. Additionally, a document written at this level will frequently make it impossible for a reader to grasp the big picture.


Unfortunately, it is effectively impossible to write all of a system’s requirements this way. There is a powerful and important feedback loop that occurs when users see the software being built for them. When users see the software, they will come up with new ideas and change their minds about old ideas. When changes are requested to the software described in a requirements specification, we’ve become accustomed to calling it a “change of scope.” This type of thinking is incorrect for two reasons. First, it implies that the software was at some point sufficiently well-known for its scope to have been considered fully defined. It doesn’t matter how much effort is put into upfront thinking about requirements, we’ve learned that users will have different (and better) opinions once they see the software. Second, this type of thinking reinforces the belief that software is complete when it fulfills a list of requirements, rather than when it fulfills its intended users’ goals. If the scope of the user’s goals changes then perhaps we can speak of a “change of scope,” but the term is usually applied even when it is only the details of a specific software solution that have changed.


IEEE 830-style requirements have sent many projects astray because they focus attention on a checklist of requirements rather than on the user’s goals. Lists of requirements do not give the reader the same overall understanding of a product that stories do. It is very difficult to read a list of requirements without automatically considering solutions in your head as you read. Carroll (2000) suggests that designers “may produce a solution for only the first few requirements they encounter.” For example, consider the following requirements:


3.4) The product shall have a gasoline-powered engine.


3.5) The product shall have four wheels.


3.5.1) The product shall have a rubber tire mounted to each wheel.


3.6) The product shall have a steering wheel.


3.7) The product shall have a steel body.



Now imagine in your mind what type of vehicle this is and what it looks like. Is it red? How big are the tires? How fast does it go?


But suppose that instead of writing an IEEE 830-style requirements specification, the user told us their goals for the product:


As a landscaper I would like a product that makes it easy and fast for me to mow my lawn. I want to be comfortable while using the product.


By looking at the user’s goals, we get a completely different view of the product and realize that the customer really wants a riding lawn mower, not an automobile or what ever else you imagined. These goals are not user stories, but where IEEE 830 documents are a list of requirements, requirement goals describe a user’s goals. By focusing on the user’s goals for the new product, rather than a list of attributes of the new product, we are able to design a better solution to the user’s needs.


A final difference between user stories and IEEE 830-style requirements specifications is that with the latter the cost of each requirement is not made visible until all the requirements are written down. The typical scenario is that one or more analysts spend two or three months (often longer) writing a lengthy requirements document. This is then handed to the programmers who tell the analysts (who relay the message to the customer) that the project will take twenty-four months, rather than the six months they had hoped for. In this case, time was wasted writing the three-fourths of the document that the team won’t have time to develop, and more time will be wasted as the developers, analysts and customer iterate over which functionality can be developed in time. With requirement goals, an estimate is associated with each story right up front. The customer knows the velocity of the team and the story unit cost of each story. After writing enough stories to fill all the iterations, they know when they are done.


To help author a requirement goal please consider the following template.










Requirement Goal


Date  {Insert Date}


Desired Implementation Date {Insert Date}


Business Analyst {Business analyst name}


Executive Sponsorship {Executive name and title}


 


Goals


{User role} would like {feature(s)}, this {feature} should be able to {action}, when implementing this {action} please check {criteria}


 


Benefit


By implementing this {feature} the business will be able to {introduce business value}


 


Detriment


If we fail to implement {feature} the business will {introduce risk of failure to implement}


Example:


Date 01/01/2007
Desired Implementation Date 04/01/2007
Business Analyst Susie Que
Executive Sponsorship Jack Marshal Regional Director


Goals:


The user would like to log into the ATM by first swiping their personal ATM card issued from the branch office and then key in a 4 digit PIN.  When the user creates their pin we have to make certain that their pin does not match the last 4 digits of their SSN that we have in the system.


After the user logs into the ATM they should be presented with a home screen that displays a welcome message and their name.  The client should then be able to see a menu list with the following options.


         Balance Inquiry


         Withdrawal


         Transfer


Benefit:
By implement ATM machines in our branches our company will be able to offer a competitive advantage over our competitors.


Detriment:


If we fail to implement ATM machines in our branches our company will be forced to stay open till 10 PM increasing resource cost by 35% nationwide.


 


Responsible Ownership

The Business Analysts are responsible for authoring of a Requirement goal. If you refer to the field request section of this document you will notice that a field request does not always have a sufficient amount of detail to author a requirement goal. The business analyst will sometimes have to perform additional analysis to work toward drafting a more thorough requirement.


NOTE: The goal of the requirement goal is just that to convey a purpose. At no time should the requirement goal be treated as a concrete contract between ILS and the business. It is merely serves as a medium to convey information that helps in the creation of feature cards later in the process. During the feature card creation additional details may be uncovered that will require the business analyst to update the requirement goal.

What is a Feature Card


Discussion is critical to understanding, which in turn is critical to estimating. Features cards are used to identify and define features at a high level. Feature cards act as concords between product owners and project team members to discuss (and document, to the extent necessary) detail elemental data that can be later formulated into stories that are subsequently scheduled into iterations. Feature cards identify features that the product owner would desire to have in the product.


The purpose of feature cards is to provide a simple medium for gathering basic information about application or system specific features being requested from the business goals. This channel is intended to be a central conduit for all ILS activities to revolve around.


Feature cards are comprised of the following key items of information:


Key Items


  • Identifier: an alphanumeric or numeric identifier that serves as a unique identifier for the feature.
  • Name: a short name or description of the feature
  • Summary: a paragraph or two describing high level functionality and modules that may comprise this feature
  • Type: C = customer domain, T = technology domain

    • Customer domain – The customer domain are features that originate from the product owners of the project usually governed by more formal requirement documents.
    • Technology domain – The technology domain are features that originate from the development group or systems analyst within the ILS department.

  • Estimated work effort: Aggregate of the following factors

    • Estimated work effort for requirements gathering
    • Estimated work effort for wire frame design
    • Estimated work effort for coding and unit testing
    • Estimated work effort for testing
    • Estimated work effort for documentation
    • Estimated work effort for reporting

  • Planning Complexity: This is a weighted measurement to determine the resource allocation and duration that the feature will require during a planning week.

    • High – 8 hours of planning time. One entire day is needed to break down the feature into a model and relative stories.
    • Medium – 4 hours of planning time. Half a day is needed to break down the feature into a model and relative stories.
    • Low – 2 hours of planning time.

  • Requirements uncertainty (erratic, variable, regular, stable): an “exploration factor” for a specific feature. The requirements uncertainty is a subjective weight that is explored by both the Systems and Business Analyst to determine the viability of the feature being presented during a release planning session. The matrix below details the guidelines that can be used to determine the maturity of requirement being requested.

Requirement Uncertainty Guidelines


Erratic



  • The requirement contains minimal information and the contents remain in an erratic state where business owners and field stakeholder cannot agree on the concept or idea that is being presented.
  • Executive sponsorship has not been approved

Variable



  • The requirements contain more information than the erratic state
  • There may still be outstanding variables that are still in question as to how the requirement should function when integrated into the system.
  • A screen skeleton has been presented (if applicable)
  • Executive sponsorship has not been approved

Regular (can be scheduled during a release planning week)



  • The requirements may contain more information than the variable state
  • The general requirement concept or idea is understood and can be talked to in a group setting to finalize greater details
  • A screen skeleton has been presented and general concepts annotated (If applicable)
  • Executive sponsorship has been approved

Stable (can be scheduled during a release planning week)



  • The requirements have been completely documented
  • All ideas and concepts are thoroughly understood and can be easily communicated in a written and verbal medium
  • The screen skeleton has evolved to a more thoroughly documented wire frame that explicit details or references business rules
  • Executive sponsorship has been approved


  • Dependencies: A list of other external dependencies that could influence implementation sequencing.

NOTE: You should strive to get the feature to a state where it can exist on its own without having a dependency on other features. Dependency on other features should be an exception a not a rule.


  • User Acceptance Tests: Criteria the product owner will use to accept or reject the feature

NOTE: It is important not to confuse feature cards with stories. The details captured in the feature cards serve as a launching pad for future planning sessions that uncover customer stories that can be instituted into release iterations. The feature cards form a conduit for all information to flow through and are weighted against the Requirement Goal.

Acceptance Test


A features behavior is simply its acceptance criteria – if the system fulfills all the acceptance criteria, it’s behaving correctly; if it doesn’t, it isn’t.


Describe the acceptance criterion in terms of scenarios, which take the following form:  Influenced by Dan North


Given some initial context (the givens),
When an event occurs,
Then ensure some outcomes.
This is a (Positive, Negative, Dimensional) aspect.


The aspect of the acceptance test helps to discern the overall test coverage that the feature has. It is important to touch on at least two different aspects for every feature.


To illustrate, let’s use the classic example of an ATM machine. One of the requirement goals might look like this:


Customer withdraws cash


As a customer,


I want to withdraw cash from an ATM,


so that I don’t have to wait in line at the bank.


So how do we know when we have delivered this feature? There are several scenarios to consider: the account may be in credit, the account may be overdrawn but within the overdraft limit, the account may be overdrawn beyond the overdraft limit. Of course, there will be other scenarios, such as if the account is in credit but this withdrawal makes it overdrawn, or if the dispenser has insufficient cash.


Using the given-when-then template, the first two scenarios might look like this:


Scenario 1: Account is in credit


Given the account is in credit


And the card is valid


And the dispenser contains cash


When the customer requests cash


Then ensure the account is debited


And ensure cash is dispensed


And ensure the card is returned


This is a positive aspect


Notice the use of “and” to connect multiple givens or multiple outcomes in a natural way.

Scenario 2: Account is overdrawn past the overdraft limit


Given the account is overdrawn


And the card is valid


When the customer requests cash


Then ensure a rejection message is displayed


And ensure cash is not dispensed


And ensure the card is returned


This is a negative aspect


Both scenarios are based on the same event and even have some givens and outcomes in common. We want to capitalize on this by reusing givens, events, and outcomes.


The following is an example of a feature card based on the previous requirement goal.








Requirement Goal


Example:


Date 01/01/2007
Desired Implementation Date 04/01/2007
Business Analyst Susie Que
Executive Sponsorship Jack Marshal, Regional Director


Goals:


The user would like to log into the ATM by first swiping their personal ATM card issued from the branch office and then key in a 4 digit PIN.  When the user creates their pin we have to make certain that their pin does not match the last 4 digits of their SSN that we have in the system.  If the PIN does not match then store the PIN in the system and associate it with the ATM card.  If it does match then display an error message with the following text “You may not use a PIN that matches the last 4 numbers of your social security number”


 


After the user logs into the ATM they should be presented with a home screen that displays a welcome message and their name.  The client should then be able to see a menu list with the following options.


          Balance Inquiry


          Withdrawal


          Transfer


 


Benefit:
By implement ATM machines in our branches our company will be able to offer a competitive advantage over our competitors.


Detriment:


If we fail to implement ATM machines in our branches our company will be forced to stay open till 10 PM increasing resource cost by 35% nationwide.


 










Feature Card


Card No: 052205


Name: Branch 4 Digit PIN number creation


Summary: The client will create a 4 digit pin number in the branch.


Type: Customer


Requirements Uncertainty (erratic, variable, regular, stable): Regular


Dependencies: None


User Acceptance Tests:


 


Given that the client is creating a 4 digit PIN number


When the client has keyed in a 4 digit pin that does not match the last 4 digits of their SSN


Then the PIN is stored in the clients account profile.


This is a Positive aspect


 


Given that the client is creating a 4 digit PIN number


When the client has keyed in a 4 digit pin that does match the last 4 digits of their SSN


Then the client is presented with an error containing the text “You may not use a PIN that matches the last 4 numbers of your social security number”.


This is a Negative aspect


 


 







Feature Card


Card No: 052206


Name: Welcome Screen


Summary: After the user is authenticated to the system they should be presented with a welcome screen


Type: Customer


Requirements Uncertainty (erratic, variable, regular, stable): Regular


Dependencies: 052207


User Acceptance Tests:


 


Given the user has just left the login screen


And they are authenticated


When the welcome screen is presented


Then  the welcome message on the screen should be presented


And the user’s full name be presented in the following format {first name} {mi} {last name}


And a menu list be displayed with the following options: Balance Inquiry, Withdrawal, Transfer


This is a Positive aspect










Feature Card


Card No: 052207


Name: Login Screen


Summary: The client would like to log into the system using a login screen


Type: Customer


Requirements Uncertainty (erratic, variable, regular, stable): Regular


Dependencies: 052205


User Acceptance Tests:


 


Given the user trying to log into the ATM


When the user swipes his ATM card


And the user inputs the correct PIN


Then  the system should log the time the user logged in


And the screen should go to the welcome screen


This is a Positive aspect


 


Given the user trying to log into the ATM


When the user swipes his ATM card


And the user inputs the incorrect PIN


Then  the login screen should display the following message “The PIN is incorrect, please try again”


This is a Negative aspect


 


Given the user trying to log into the ATM


When the user swipes his ATM card incorrectly for the 3rd time


Then  the login screen should display the following message “Your card is no longer active, please call 1800-555-5555”


And the system should lock the account ATM privileges


This is a Dimensional aspect


 


Responsible Ownership

The Systems Analysts are responsible for authoring of a Feature cards. While the systems analysts are responsible for authoring the feature this engagement must not be done in vacuum. It is critical that the documentation of the feature be agreed upon by business and all other stakeholders. Remember all artifacts in the ILS software development lifecycle are living documents and are subject to change at any time pending the appropriate stakeholders all agree on the changes.


What is a Screen Skeleton


Sometimes requirement goals may not capture the idea or concept that the business is trying to convey. Often a simpler medium of communication may be a sketch, diagram or picture. Pictures often speak volumes of information over written text. It is imperative that everyone understand that these forms of communication are acceptable at conveying an idea. Often the greatest ideas are thought of over lunch and quickly jotted down on a napkin. Let’s not limit creativity or the medium that it is conveyed in.


The purpose of screen skeletons is to provide a simple pictorial representation of the intended layout of how the requirement goal should take form as a graphical user interface. The screen skeleton will later be used as that foundation for the more detailed wire frame that is the result of a planning week.


This is a rather crude example of a screen skeleton but shows to reason what can be used as a screen skeleton.


{Figure 4: Screen Skeleton }

Responsible Ownership

The Business Analysts are responsible for the creation of the screen skeletons.


NOTE: The screen skeletons are one of the optional artifacts of the ASDLC. They are not required in order to call a requirement goal complete.

What is the Planning Preparation Meeting


The final activity of the storming phase is preparing for the planning phase. To facilitate this goal the planning preparation meeting takes place.


This meeting is designed to be a collaborative engagement between the business analyst, systems analyst and development architects. The planning preparation meeting results in a schedule of events for the planning phase. This schedule will contain modeling session engagement and resources that have been assigned to each session.


Each feature card contains a “planning complexity” rating. This rating of High, Medium or Low are used determine the amount of time that will be required to adequately model and understand the business feature.


The figure below depicts a simple illustration of a planning meeting. A typical modeling team consists of five stake holders: one Modeler, one business analysts, one systems analyst and two developers. Utilizing everything we have done with the feature cards during the storming phase we will now use the planning complexity rating in conjunction with the dependency field to determine how we should plan the week.


Considering that the “Branch 4 digit PIN # creation” feature as at the top of the dependency tree it make logical sense to start with this feature first. You will notice that the planning complexity rating is a HIGH for this feature. This is a quick indication that the probability of this story lasting all day is great. Therefore we should not schedule any other features for this modeling team for the remainder of that day. The “Login Screen” and “Welcome Screen” planning complexity rating are MEDIUM. Since the medium rating tells us that this modeling session should last know longer than four hours, we can easily place both these stories into the next day and lower the risk of over taxing the modeling team.



Responsible Ownership

The Business Analysts are responsible for the final schedule of the Planning Phase. The Systems Analyst are responsible for scheduling the Planning preparation meeting.


The next post will be on the Planning Phase.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Joe Ocampo

My personal philosophy is simple: "Have a good strategy that sets the environment for success through the enablement of the whole. Be agile but with a mind towards pragmatism. Delegate to the best qualified individuals, but don’t be afraid to involve yourself in all parts of a job. Treat everyone with respect, humility, and with a genuine pursuit towards excellence." Respected business and technical leader with expertise in directing organization towards effective results driven outcomes. Proven ability to perform and communicate from both technical and business perspectives. Strong technical and business acumen developed through experience, education and training. Provides the ability to utilize technology, harness business intelligence and execute strategically by optimizing systems, tools and process. Passionate about building people, companies and software by containing cost, maximizing operational throughput and capitalize on revenue. Looks to leverage the strengths of individuals and grow the organization to their maximum potential by harnessing the power of their collective whole and deliver results. Co-Founder of LosTechies.com
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

5 Responses to Corporate Agile Software Development

  1. jmeridth says:

    Excellent Post.

  2. Franck says:

    This is not a post, but a excellent article. I hope that all these references to documentation will not lead you to be excommunicated by some agile purists.

  3. agilejoe says:

    Not really, or shall I say not yet! :-) A majority of my fellow Agillians have not had great success in instituting agile in large corporations, especially financial.

    I do want to point out though that this is overkill for a small development team as it is engineered around minimizing not ELIMINATING communication points in the corporate arena.

    I love to talk to other developers and ask them, “So how long did you stay to maintain the software after you put it into production?” “Was the software as maintainable as you predicted?” “What was the ramp up time for new developers to the team that had to come into a maintenance role?” I would say a majority of them left, right after the project was completed and couldn’t answer the remainder of the questions honestly.

    I have been with this company for the past 3 years. The ONLY reason why I believe this works is because we made ALL the mistakes and presumptions of taking the small agile software development shop approach and expecting it to work in corporate America. It is only through learning from our mistakes that we can persevere in the end.

  4. Kelly Waters says:

    Fascinating article. I do sometimes wonder, what is the real difference between a “corporation” and a small company if the corporation is broken down into small multi-disciplinary product-focused teams? In theory not so much. However I guess there are some very significant aspects like culture, governance, and the feeling of not wanting to duplicate anything across teams. These aspects can potentially create such complexity that they become major barriers that prohibit the corporation from competing with smaller players and startups, whereas really the corporation should benefit from its relative size.

    Kelly Waters
    http://www.allaboutagile.com | Blog
    http://www.groups.google.com/group/allaboutagile | Forum

  5. agilejoe says:

    “These aspects can potentially create such complexity that they become major barriers that prohibit the corporation from competing with smaller players and startups, whereas really the corporation should benefit from its relative size.”

    I couldn’t agree with you more Kelly. Bureaucracy kills process, at least when software development is concerned, large corporation form barriers between department entities by instituting documentation and bureaucracy as a means of communication between entities. The entities form defensive postures around their documentation as a safety net and comfort zone to protect them from retaliation from other entities and management. Customer focus and quality are always preached upon as being paramount but tend to take a second seat to heavy weight documentation.

    My goal in outlining this process was to break down those barriers and instill trust and communication as the primary focus of all the stakeholders.