Agile Soup
OK obviously something happened to get me back into the blogosphere. That “something” is actually two things. First, I spent the whole summer hunched over my table saw building a fireplace and that project is finally done. I am proud of that sucker. I spent a lot of time on the phone with my dad figuring out what I was doing, but we made it happen and that room is damn toasty.
Second, as I recently mentioned, I went to the Higher Ed WebDev conference in Cincinnati. The conference itself wasn’t totally amazing or eye opening, but it did help re-enforce some motivators I had just stewing in my head. We will call it the catalyst.
We will also call these stewing ideas “Agile Soup.” Agile is a model for a software development life cycle. You might even call it a project management methodology. The old, most accepted method was called a Waterfall. There’s also an IBM version of waterfall called RUP, which is what I followed religiously for years. I recently started reading about these crazy developers though in California who were trashing the idea of requirements and actually developing on site with clients instead. Gone were requirements documents. In came user stories and use cases and note cards. It sounded like fairy tail land… until I started reading up on it. Agile sounded like it could be a legit model for small projects so I tried it.
Now I’m not only drinking Agile Kool-Aid, I’m serving up some Agile Soup. This article will serve as a quick intro on how Agile can be thought of as more than just an SDLC and how you can use the principles to run your whole business.
First off, let’s review the AGILE Manifesto. If you’re familiar with Agile, then you’ve seen this before:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I love every part of that. That manifesto is sort of the creed that drives a software development life cycle, but nowhere in it do you see any detail about how exactly the process works. It’s minimalist. The actual Agile process (or at least the one I use, called SCRUM) involves prioritizing client needs, figuring out how many of these needs can be accomplished in a 2 week development “sprint,” and then delivering, regrouping, and re-prioritizing every 2 weeks until the client decides, “hey, this is good enough.” A colleague of mine at Ohio State, Beth Snapp developed her own version called “Rapid Iterative Development.” Her idea is very similar to SCRUM, where we have this software development paradigm that is based on quick, well coordinated, flexible delivery. It focuses on developing working software in small chunks rather than working on abstract documentation followed by long development periods. I like this quote:
The problem with abstractions (like reports and documents) is that they create illusions of agreement. A hundred people can read the same words, but … they’re imagining a hundred different things. That’s why you want to get to something real right away. – Rework
So the goal is to develop these small chunks rather than spend a bunch of time writing documentation and then disappearing into a cave for months building a monster. This way, you’ll be able to change direction easily. The more expensive it is to make a change, the less likely you are to make it. It’s also a lot easier to completely scrap everything you’ve done in a 2 week sprint than it would be to scrap an entire project. So if you screw up or miscommunicate something, you catch it before you become attached to it and you can scrap or change course before it’s too late. The concept is pretty simple, really.
My first light bulb moment piecing Agile into a business philosophy wasn’t really an “agile” moment at all. It came while listening to someone talk about the right approach to social media. His point was that you have to be authentic. These days people don’t value press releases as much as they value customer comments. A facebook or twitter account that is maintained on behalf of a company by a nameless, faceless PR firm or communications office will get exposed and ignored. But if Bill Gates or Steve Jobs get real, people will listen. So the idea is to embrace who you are as a company and be authentic if you want a successful social media campaign.
Rework
- Planning is guessing
- Ignore the details early on
- Good enough is fine
- Your estimates suck
- Make tiny decisions
- Speed changes everything
After reading that great book, listening to people tell me how being authentic is hot, and really embracing the Agile SDLC, I came up with my own Agile Soup… also known as the Home Base Web Solutions manifesto:
Fostering relationships over volume and efficiencies
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Personal attention over following protocols
OK two of those didn’t change. Get over it. I thought about it for a while and realized that I was just rewording the original Agile Manifesto. The end result is the same though. My business is unique. Each of my clients are unique. Every project I work on is unique. If I stay lean and focus my efforts on rapidly deploying software that meets my core requirements and continually improving both product and process, I can’t go wrong. If I’m focusing on building relationships and collaborating with clients to help their businesses grow rather than negotiating terms and conditions to put money in my pocket, I think everyone is better off because if my clients are successful and they like me, not only will they use me again, but they will recommend me to their friends.
AGILE / SCRUM Project Management in under 10 minutes
I found this excellent video that wraps up AGILE in a nutshell.
Hamid Shojaee covers all the SCRUM bases: product back logs, release back logs, team roles, burndown charts, and more.
Software Development Life Cycle
Overview
This document covers the Software Development Life Cycle (SDLC) for Home Base Web Solutions. Home Base implements a RUP methodology. We know that Agile is the new hot thing, but if you really look at Agile, the processes within each SCRUM can and should closely resemble those of a RUP process. Since Home Base is a smaller shop, no project passes the initiation phase of project management if the estimated time to completion is over a month. We may create a program that consists of several smaller projects, each of which is about a month in duration, but no project can last longer than a month. So if you are really a die hard SDLC nut, you can technically call our process AGILE if you want. Our ideas are the same: Clients want to see results, requirements inevitably change over time, we really like getting paid, and big long processes get confusing. So without further ado:
SDLC Phases
The SDLC phases have been derived from the Rational Unified Process (RUP), the Project Management Institute’s Project Management Body of Knowledge (PMBOK), and Home Base Web Solutions best practices. The following phases cover all the major components of the SDLC while identifying the goals, roles, and deliverables. Each phase will be completed in order as it appears in figure 1.
The Home Base Software Development Life Cycle
Figure 1: The phases follow a modified Unified Process.
Inception
Using business process analysis, Unified Modeling Language (UML) techniques, stakeholder interviews, and collaborative definition of application functionality, the Inception phase produces Scope definition for the project as well as a Functional Specification defining what functions the application must be able to perform. Use Cases, an outcome of Inception, are used to determine functional requirements. Figure 2 shows a diagram of the flow of events utilized during Inception to capture the scope of what the solution will deliver. Inception is a collaborative process working with the customer.
Inception Phase Flow
Figure 2: The steps that take part in the inception phase are depicted in order to produce the final functional specification.
The objective for inception will cover defining the customers need. Once this objective is complete the following conditions should be met.
- A clear understanding of the problem that needs to be solved.
- The current processes that are in use today to solve the problem.
- The benefits of solving the problem and their value.
Deliverables
Once the requirements gathering process is completed the following will be delivered.
- Scope Definition – The original requirements usually created by the client that defines the action items.
- Use Cases (Started) – A document that contains each of the application processes and what each step the application can take after each command. In the inception phase these should end up around 15 percent complete and will be finished in the elaboration phase.
- Functional Specification – A detail specification that entails what is going to get done.
Team Involvement
During the inception phase the following roles will need to participate in the inception process.
- Development Staff
- Product Management
- Project Stakeholders
Elaboration
During Elaboration the project team continues to collaborate with your to create a Technical Design Specification that defines how the solution will complete features defined in the Functional Specification. Figure 3 shows the flow of events to produce a Technical Design Specification.
Elaboration Phase Flow
Figure 3: The elements of the elaboration phase are shown in detail in order to produce the final technical specification.
The objective for elaboration covers taking the captured requirements and further defining them into design documentation that can be used by the development staff to write the end software product.
Industry standard UML diagrams are used to communicate the system to be built. For example, users (Actors) interact with functionality in the system (Use Cases) and are subsequently depicted in a Use Case Diagram (see Figure 4 below).
Example Use Case Diagram
Figure 4: An example use case diagram is shown with the actors and processes. (Adapted from UML Distilled)
The flow of events is depicted as a UML Partition Diagram which is sometimes referred to as a Swimlane diagram (see Figure 5 below). The advantage to this exercise is that it encourages parallel processing of the system and lends itself to multithreaded development and effectively communicates how a system flows.
UML Partition “Swim lane” Diagram
Figure 5: The flow of events depicted as a UML partition diagram. (Adapted from UML Distilled)
Once this objective is complete the following conditions should be met.
- Designer / Developer will be able to take the supplied requirements and determine if enough information has been captured to create an application design.
- A process for gathering additional requirements if information is missing.
- Process for capturing design documentation so developers can create the requested functionality.
- Design documentation will solve the captured requirements and nothing more.
- Completed User Interface designs or Prototypes.
Deliverables
Once the analysis and design process is completed the following will be delivered.
- Technical Specification – A detail document containing how the application is going to be built.
- Completed Use Cases – A document that contains each of the application processes and what each step the application can take after each command.
- User Interfaces – A document or developed prototype that contains example screen shots and details how the application is to be laid out.
Team Involvement
During this stage the following roles will need to participate in the elaboration process.
- Project Management
- Development staff
Construction
During the construction the team builds application components or infrastructure elements per the approved Functional and Design specifications. Sets of milestones are defined to allow project stakeholders to establish checkpoints that ensure adherence to both requirements and schedule.
Once this objective is complete the following conditions should be met.
- Developers have completed coding the application.
- Quality Assurance has tested the application.
Deliverables
Once the software development process is completed the following will be delivered.
- Completed Application.
- Document containing test cases based on the use cases.
- Installation and deployment guides.
Team Involvement
During this stage the following roles will need to participate in the construction process.
- Project Management
- Development staff
- Quality Assurance
Transition
In the transition stage the team supports the client’s execution of their User Acceptance Testing (UAT) plan. Once the UAT is complete the project is promoted to production.
- Quality Assurance has confirmed the production application is working.
- The client has completed User Acceptance Testing (UAT). UAT will be performed in a staging environment prior to production deployment.
- The developed application has been deployed to a production environment.
Deliverables
Once the deployment process is completed the following will be delivered.
- Updated Functional specification, Technical specification, User Interface, Use Cases, and Test Cases.
Team Involvement
During this stage the following roles will need to participate in the transition process.
- Project Management
- Development staff
- Quality Assurance
- Support Staff
- Project Stakeholders
Support and Maintenance
In the support and maintenance phase the application will be monitored to ensure it runs at the intended level of quality.
Deliverables
Once the maintenance process is completed the following will be delivered.
- Documented process for identifying and escalating bug reports. In this will be the validation process and escalation process.
- Documented process for bug assignment and prioritization.
Team Involvement
During this stage the following roles will need to participate in the support and maintenance process.
- Support Staff
- Quality Assurance
Appendix A: Use Case Template
Business Requirements
Business requirements describe the functionality that the envisioned system will provide. The next section provides a short description of the methodology used herein to document requirements this is followed by the requirements. We will provide samples of Use Cases that will be developed in the next phase before application construction begins.
Documentation Methodology
Our experience indicates that a combination of business process workflows and Use Case descriptions provides a highly effective and efficient form of communicating business requirements.
Actors
Actors are considered to be any person or system that interacts with the system being documented. The following sections describe the key Actors (roles) within the system, and how they interact with one another.
| Name | Description |
|---|---|
Use Cases
Use cases provide a detailed business description of how significant actions within a business process are accomplished. They include detailed descriptions of any business rules associated with a function, the expected workflow surrounding an action in cases of success and failure.
Developing Use Cases is an iterative process that involves more detail as new scenarios are discovered and described. Early iterations of Use Cases may contain a very high-level, low-detail view of how an Actor interacts with the system. In some cases, early Use Cases may only contain a Summary and a preliminary list of Actors involved. As more information is gathered, and a better understanding is established, Use Cases begin to mature and details are added to accurately reflect the processes involved.
Use Case Descriptions
Use Case Descriptions contain a written account of the way that Actors interact with the system. Use cases are split into three logical segments, the use case description, the expected workflow description, and the alternate workflow description(s).
Use Case Description Format
For the purposes of this document each topic in a Use Case Description is defined below:
| Topic | Description |
|---|---|
| Summary | The Summary contains a very short description of the Use Case | Business Events | Business Events are triggers that stimulate activity within the business. Business Events must be atomic and observable | Actors | At least one or more of the Actors defined in the system is involved in every Use Case. This topic tells which ones apply. | Assumptions | Any assumptions made in the creation of the Use Case. As details of the Use Case are refined, assumptions begin to disappear. When assumptions are removed or are not present, this topic will contain a simple “N/A” for Not Applicable. | Preconditions | Preconditions identify what must be in place before the Use Case carries out its duties. | Description | The description contains an account of the details in a Use Case. It contains more information than the Summary and describes the aspects of the process not covered by other topics in the Use Case. | Associations | A list of other use cases that this use case is extended by or is used by | Inputs Summary | Summary level listing of data input by the actor(s). Note that inputs in this document will be expanded upon / altered during the development process of the application. | Outputs Summary | Summary level listing of data output by the system. | Alternatives Paths and Exceptions | An alternative path is a sequence of actions in a Use Case that only happens in special circumstances.
An exception occurs when the system forces an Actor through an alternative path rather than the Actor choosing the path voluntarily. |
Post conditions | Post conditions identify what must be in place after the Use Case carries out its duties. | Termination Outcomes | The conditions and results for unsuccessful completion of the use case. | Notes | Information that is not directly part of the use case but arises while working on the use case. |
Events
This section describes the events that occur as part of the fulfillment of the use case detailed in the Use Case Description. The following format is used to describe both the flow of events and any alternate flow(s) that may exist.
| Flow Name | Description |
|---|
The “Flow Name” column is used to group the flow or portions of the flow being described. In the case where a use case has several segmented flows that make up the main workflow, each segment would be named in this column for clarity. The “Description” column contains a description of what will happen at the prescribed point in the workflow.
Appendix B: Quality Assurance Process
To improve the quality assurance process, a set of testing principles should be defined and followed. A Quality Assurance Analyst could help define this process.
There are generally 4 main levels of software testing carried out:
- Unit Testing in which the basic components of the software system are tested to verify that the detailed design for the unit has been correctly implemented.
- Integration testing in which progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a whole.
- System testing in which the software is integrated to the overall product and tested to show that all requirements are met. Since the Quality Assurance area is not well developed, it is recommended that System Testing be a manual process. Once the area matures automated test tools can used for regression testing. At the moment, it is suggested to have the regression testing done manually by following the defined test scripts.
- Acceptance testing is a further level of testing in accordance with requirements. Occasionally, Acceptance testing, upon which the acceptance of the complete software is based. The clients often do this.
Juggling stakeholders, vendors, and complex internal integration points
I am in the middle of a 2+ year program at Ohio State implementing a third party housing application. Our program originally consisted of two major phases and many sub projects. The goal was to replace an old mainframe system that manages housing assignments with a very new, very slick COTS software that would bring our housing department into the current century. One major challenge, however, is that the central IT department at Ohio State is also moving from a mainframe student information system (SIS) to a new sort of COTS version of PeopleSoft. In order to mitigate risk of simultaneous Go-Lives with the Housing and central SIS system, we implemented the housing system in two phases. Phase 1 was implementing the new housing system and Phase 2 is currently under way, which is converting all of our interfaces to work with the new SIS system. I will not go into too much detail in this post, but I am sure you can imagine the undertaking of converting 10,000+ bed spaces from a mainframe application to a SQL Server powered web application. The application also manages campus dining plan selections, additional monies deposited on campus debit cards, and door access privileges. We have since expanded to manage summer conferences services. I could probably write a solid book on everything we have done and what we have learned, but the purpose of this post is to introduce a presentation that I submitted to ACUHO-I. Below is the extract. Hopefully it is accepted. Once we get the green light, I will be sure to post updates here. I plan to actually perform a juggling act during the hour long presentation… so I have a few months to learn how to juggle. 
Title: How to juggle stakeholders, vendors, and integration for a housing system deployment.
Participants will: listen to the pros and cons of moving to a third party housing application from a home grown system.
Participants will: learn about some of the complex integration challenges between a third party application and internal systems such as other home grown mainframe applications, PeopleSoft, and BlackBoard.
Participants will: learn how to balance the difficult juggling act of managing stakeholder expectations with vendor and technical constraints.
This program will be an overview of Ohio State’s journey from using a home grown mainframe application to managing housing assignments with a third party system. We will briefly cover where we came from and what we are capable of doing today. Ohio State offers a unique perspective on some of the pros and cons of both a home grown application that has been customized over the past 30 years and also using a powerful third party application. The presentation will include hurdles we have overcome and challenges we continue to face including vendor management, stakeholder expectations, and some complex integration points with various university systems. We will also touch on the massive undertaking of migrating over 10,000 bed spaces from one system to another and how business processes and personnel have adjusted to a new way of doing things.
Presentation Outline: This presentation will be a standard Power Point delivery, with some comic relief to keep the audience engaged. Time permitting, we will have a brief question and answer session at the end.
- Overview of existing mainframe application
- Vendor selection method
- Benefits of and decision to move to StarRez
- Hurdles we overcame moving to StarRez
- Challenges we continue to face
- Vendor management
- Data integration management
- PeopleSoft
- BlackBoard
- Mainframe Applications
- Meeting stakeholder’s expectations, including students
MCF Solutions project kicks off new Home Base design
MCF Solutions
To kick off the new website, Home Base would like to showcase one of our current projects. We are working with Urban Fox Design on a complete web redesign for a dental equipment sales company. One of our strategic initiatives this year is to incorporate industry standard project management methodologies and a formal software development life cyle into small web development projects.
I will be quick since this is our first post and I obviously have a lot more work to do on the website. The idea behind the project management methodology is to take the Project Management framework used on Ohio State’s Student Life enterprise level projects and scale it to an appropriate level of management on smaller web app projects. I just got my PMP in December 2008 so all of the knowledge areas and process groups are fresh on my mind. When you’re a small company and you’re dealing with projects that require less than 50 man hours and maybe four resources, you don’t want to over-manage. I think this is the dilemma many process oriented managers face in a small business environment. With MCF, and with all of our current projects, we focus on the following:
- Set, Manage, and Meet client expectations
- Frequently communicate status and progress
- Keep metrics to improve future projects and processes
All three focus areas above are applied to the project management triple constraints, which I think are worth another set of bullets:
- Cost
- Scope
- Schedule
Clearly communicating how much a project is going to cost, when it is going to get done, and exactly what a client can expect their new website to do up front is a huge part of our process. It is very difficult to define scope and come up with accurate estimates early in projects, especially when you’re working with a client who doesn’t really know what they want, but the more time you spend early on defining and documenting scope, the better. It is much better to frustrate a client by telling them something can’t be done up front than it is to tell them it can be done, have them spend a bunch of money on you, and then fail to deliver. It also just straight up sucks when you have vague requirements and then you can’t justify charging more for scope creep. Before I really embraced implementing project management methodologies, that happened to me more often than I’d like to admit.
This ties into our SDLC. Home Base follows sort of a modified RUP/Agile Software Development Life Cycle. We go through several iterations similar to Agile, but each iteration follows RUP-like process. I think I will save the specifics for a dedicated post, but we try to break each project into smaller parts, and then have clear phases with phase gate meetings within each mini-cycle. For example, the MCF project has a bunch of static content and several dynamically driven components. The project is broken into the following cycles:
- Graphic Design – Site Template and Static Content
- Admin Framework
- Slide Show, events, contact us (dynamic content)
- Case Studies
Each cycle essentially passes through requirements elicitation, design, development, quality assurance, and release to production. I have fancy names for these phases, but I’ll save them for the longer post with plenty of pictures and diagrams. In any case, we spend a lot of time on requirements and once Mark at MCF approves them, each cycle will enter development phase. Progress can be monitored at http://dev.mcf-solutions.com. The caveat is that there are no promises that anything in development will actually work. It’s my playground, and I can do what I want in there, damn it!
When I think I’m done with development for a cycle, I copy everything to QA at http://qa.mcf-solutions.com. At Home Base, the lovely Brittany Baron will hopefully agree to be our Quality Analyst. Once she finds all of my major bugs (and I fix them), we ask the client to review and approve that the QA version of the site matches what they asked for in their requirements. THIS IS IMPORTANT!! At this point, I often have clients say things like, “well I kind of thought the site should do this and not that.” That’s great, and we can accomodate, but if we had good requirements and we can basically check off that the site meets them, these new requests equal change requests that we can charge for. Not that I’m looking for new and improved ways to make money. The later you make changes in a project, the bigger the impact. I also don’t enjoy working for free. Communicating this part of the puzzle up front usually causes clients to think a littly harder when coming up with their requirements. Then I come closer to getting what they want the first time around, so they get their site done sooner and cheaper and everybody is happy! If they really want to implement those changes, we can start the cycle over or decide to postpone changes for later.
If the client approves of what is in QA, we simply copy straight to production.
And that’s it! Somehow I just wrapped up the process I’ve been thinking about for years in a nutshell! With MCF, the design cycle is currently moving from dev to QA. While Brittany, Mark from MCF, and George from Urban Fox nit pick all of my minor design flaws, I am going to start work on filling in some of the admin framework in dev. Hopefully this article gives some insight into our process. I look forward to updating here as much as I can.