Object Partners, Inc. approach with agile methodology

What brought us to Agile?

The most common software management technique in the past and today is called “waterfall” Software Development. As defined by Wikipedia, the definition for Waterfall development is a sequential development process, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. With this approach, all requirements are gathered up front. Gathering of requirements in this fashion can take many months to complete.

waterfall

The waterfall model is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible, for any non-trivial project, to get one phase of a software product’s lifecycle perfected before moving on to the next phases and learning from them. For example, clients may not be aware of exactly what requirements they want before they see a working prototype and can comment upon it; they may change their requirements constantly, and program designers and implementers may have little control over this. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of time have been invested in Big Design Up Front.

Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and that does not account for the newly discovered problem areas.

One of the major pitfalls in this approach is the fact that so much time and effort must be exerted before the team is able to identify potential problems, such as a design issue. Frequently issues found at implementation have a ripple effect back into previously completed phases, which require the team to revisit requirements specs and or design documentation. When this ripple occurs, the impact to the project schedule and cost estimates is often dramatically impacted, almost always in a negative way. And most unfortunate of all is the lateness of this information in the development lifecycle.
Historically, waterfall forecasts are notoriously wrong; no one is shocked by projects forecast to release in 18 months that took 36 months. Companies can achieve bankruptcy this way; developers can lose their jobs and careers. There is an alternative…

General Observations

To solve this common problem, reconsider some assumptions. If project requirements obtained upfront are likely to radically change over the course of the project, a system that adapts rapidly to change would likely work better. If developer work estimates are unreliable, find a way to map developer work estimates into actual developer time to fine-tune the estimates. If expensive advance planning results in marginally better or worse results than no planning at all, then plan over shorter horizons rather than longer.

Object Partner’s agile approach is a software management, planning and implementation guideline that balances these goals:

  • Communication with team-members is emphasized. The spoken word is valued over the written documentation,
  • Outsiders can experiment with partial implementations first hand periodically, for example monthly,
  • Stakeholders can re-prioritize developer efforts periodically,
  • Developers can measure their productivity empirically,
  • Stakeholders can forecast release dates based on feature set,
  • Developers can refine their processes and work activities through feedback loops and self-organization.

People (or at least roles)

A Project Team comprises a Product Owner, a Project Manager, a Technical Lead/Architect and between three and seven Developers. The Project Team is jointly responsible for the product, not only functionality, but architecture, quality, releasability, documentation, etc. Keep in mind that the roles described in this section may be performed by many team members in a one-to-one manner or several roles may be performed by a single team member. For instance, the Project Manager and the Technical Lead role may be performed by the same individual on a small project.

OPI Base Guideline

OPI has done many agile projects successfully over the past years. Each of these projects has differed slightly in their implementations, while at the same time followed similar steps to success. Many of these steps are common sense approaches to software development. This document describes those common steps that almost every project can follow to help ensure success. As with past projects, this document puts the ultimate flexibility into the hands of the Project Team with regard to how to put this guideline into practice on individual projects.

Guideline Overview

In summary, the OPI agile process focuses on developers attempting to produce a Feasibly Testable Product in a fixed time-period, called an Increment. Each Increment contains a number of work cycles called Iterations. Iterations are 2-4 weeks in duration, and each Increment is approximately 6 weeks in duration. Using the same duration for successive Increments provides for easier planning and more reliable release forecasting. Using the same duration for Iterations improves predictability of achievable work and a shorter window into project progress which increases project transparency. The following section will breakdown the different activities recommended in our OPI Base Agile Process.

****click image to enlarge****

coreagileprocess

Please note this is a high level overview. If you want more details, contact us.

About the Author

Ehren Seim profile.

Ehren Seim

Chief Operating Officer
    I started with Object Partners at a very early stage in the creation of the brand, culture, and identity. My focus has been around talent, culture, communication, community, consultants, and brand. Throughout the years as the company has grown and evolved, I’ve worn many hats to fill in the gaps to continue to move the company forward. I’m very fortunate to be able to work with some of the best and brightest individuals in the business and to watch the company experience significant growth and success throughout the 10+ years I’ve been here.
    My strengths are around creating successful customer and employee experiences by building entrepreneurial cultures, improving and scaling operations and processes, designing/building great product and service lines, and most importantly, recruiting and hiring the right people. I’m a visionary who excels in high performing teams that have an appetite for growth and big ideas. I believe hiring on capability and work ethic, creating cultures of learning and accountability, and executing based on data and analytics
    Object Partners’ success is based on a shared vision, the right core values, the right people, an open and honest leadership style, true accountability across EVERYONE in the organization, and by building the right internal culture that believes in continuous learning and growth.
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Using Conftest to Validate Configuration Files
Conftest is a utility within the Open Policy Agent ecosystem that helps simplify writing validation tests against configuration files. In a previous blog post, I wrote about using the Open Policy Agent utility directly to […]
SwiftGen with Image & Color Asset Catalogs
You might remember back in 2015 when iOS 9 was introduced, and we were finally given a way to manage all of our assets in one place with Asset Catalogs. A few years later, support […]
Tracking Original URL Through Authentication
If you read my other post about refreshing AWS tokens, then you probably have a use case for keeping track of the original requested resource while the user goes through authentication so you can route […]
Using Spring Beans in a Kafka Streams ExceptionHandler
There are many things to know before diving into Kafka Streams. If you haven’t already, check out these 5 things as a starting point. Bullet 2 mentions designing for exceptions. Ironically, this seems to be […]