By Sid Richardson, PMP

Raise your hand if you’ve run a software project using the Agile Methodology and have run a software project using the more traditional waterfall project management methodology? I’m sure there are many of you!

Having worked in project management for nearly 30 years, I have run software projects using a variety of different methodologies and I can certainly appreciate the benefits that they all bring to the table.

One true constant in life—and in software development—is change, and I’ve seen my fair share. Here’s what I’ve learned along the way.

The ‘80s were RAD

In the mid-1980s, a software development methodology called Rapid Application Development (RAD) began to take off.

James Martin developed the RAD approach at IBM and formalized it in 1991 by publishing a book called Rapid Application Development. The RAD approach was based on working closely with the customer and prototyping solutions quickly to deliver a final product. The intention was that there would be less effort placed on the planning aspects and more on the customer collaboration aspects.

While RAD was not necessarily a true project methodology for software development, I believe it led to an easier buy-in to the Agile project methodology many of us use now.

Meeting the Requirements

When I was working in Europe in the early-to-mid 1990s, there was a heavy emphasis on formal approaches to project management and software projects. This may sound strange—or it may provide flash-backs for some of you!—but I remember a time when absolutely no analysis or design work was allowed to begin until the user requirements (typically volumes of paper in large bound files) were received in hardcopy form with sign-off by senior company executives.

Can you imagine working in that type of environment?

The traditional waterfall approach to software development projects was rather rigid, but I can understand the reasoning—the leadership wanted to have a high level of confidence in what would be delivered.

Fragile Agile

Fast forward to almost 20 years ago and many organizations encountered internal pushback and some challenges with the adoption of Agile as a software development methodology. The common joke thrown around in the middle of an Agile rollout was that it was “Fragile.”

Since the requirements in an Agile methodology are more dynamic, things eventually settled down and as someone said to me recently, “I guess we’ve come into an age of sticky notes and Sharpies.”

Design on My Mind

At KAI Partners, we have recently started using Design Thinking. Design Thinking provides a creative, solution-based approach to solving problems and is also sometimes known as human-centered design or user-centered design. It’s on the side of creative problem solving, which—being a creative type of guy—is why I gravitate toward it.

Design Thinking encourages organizations to focus on the people or the customer—and it’s the people-centered focus that leads to better products, services, and processes.

While it’s not a software development methodology, Design Thinking can be used as a problem-solving tool to accompany almost any software development methodology you choose to use.

Is there a Perfect Approach?

So, with all these different methodologies, is one better than another? Well, it depends on the project at hand!

One of the common drawbacks to the RAD approach of the 1980s was the lack of scalability. RAD typically focused on small to medium-sized projects and teams. Then Agile came along in the early 2000s and, as a lean philosophy, could certainly be applied at an enterprise level.

What I think works best is a blended methodology that combines the best features of a variety of different approaches.

If the last 30 years in project management and software development have taught me anything, it’s that there are components and approaches of many different methodologies that—when combined—can make a robust and flexible way to deliver high-quality, timely products to the customer.

And, considering that a new methodology will likely make its way to the surface soon, we can’t get too comfortable. Luckily, as project managers and agents of change, we are used to the continual cycle of change and it will be up to us learn the new methodology, prepare our teams, and adapt our work accordingly.

Need support on your next project? KAI Partners can help your organization implement the software development methodology that works best for you and your needs!

About the Author: Mr. Richardson’s passion is Data Warehousing, Business Intelligence, Master Data Management and Data Architectures. He has helped Fortune 500 companies in the US, Europe, Canada, and Australia lead large-scale corporate system and data initiatives and teams to success. His experience spans 30 years in the Information Technology space, specifically with experience in data warehousing, business intelligence, information management, data migrations, converged infrastructures and recently Big Data. Mr. Richardson’s industry experience includes: Finance and Banking, government, utilities, insurance, retail, manufacturing, telecommunications, healthcare, large-scale engineering and transportation sectors.

By Barbara Hill

“If you always do what you’ve always done, you’ll always get what you’ve always got.”

Self-help gurus have been asserting this for years—and it is no less true for software development.

In software development, we try to not repeat the pattern of projects costing too much, taking too long, and not delivering what customers really need or want. This is no doubt why we’ve seen so much advice offered on how to do things differently.

As an Enterprise Architect, I take a holistic view of an enterprise by focusing on collaboration, facilitation, coordination, and integration.

Over the years, I’ve seen a lot of different approaches to software development.

…Early on, there were claims that formal project management methods would solve this problem by reining in costs through managing schedules and ensuring requirements were clearly stated and met.

…We’ve seen the Agile Manifesto, which, among other values, emphasizes individuals and interactions over processes and tools, as well as responding to change over following a plan.

…Then came the DevOps movement, which noted that simply focusing on software development and “throwing work over the wall” to operations was part of the problem. Instead, developers and operations staff should work together to produce better results.

…From there we’ve experienced DevSecOps, which involves security from the outset.

…And then there’s BizDevOps, in which business teams actively engage with the development and operations teams to build new products and services.

No matter which approach you use, in order to deliver a quality product or project, you need to understand the why, the how, the who, the when, the where, and the what of how your business fits and works together.

Of these six questions, the essential one is “Why?” and yet it is often the one left unanswered.

The next time you start a technology project like rebuilding or modernizing a legacy system, or creating a new one, start, as Simon Sinek says, by asking “why?”.

Why does your business or government entity exist? What is the essential value offering you make to your customers or constituents?

Asking “why” determines one of the key components of business architecture—the value stream—and it is also key to Agile and DevOps approaches that emphasize user involvement in determining what is built and how it is tested.

Once you know your value offerings and have some ideas on strategies to deliver your products and services, you can explore what capabilities you need. An analysis and assessment of your business capabilities will help highlight early on where your strengths and weaknesses are and will help you prioritize where to spend your time and resources to achieve the greatest benefits.

By architecting your business, you can think about the information architecture necessary to support the data vital to your success.

Enterprise Architecture work can be done in parallel with your DevOps teams to help ensure that all parts of your enterprise (business, information, technology, applications, security) work together, as noted Enterprise Architect Tom Graves says, “with clarity, with elegance, on purpose.”

About the Author: Barbara Hill is a Senior Enterprise Architect with KAI Partners. With over 20 years of experience working with both California state government and private sector companies, she has been instrumental in helping clients address the complexity and volatility of change, while ensuring alignment between strategic goals and operational realities. Barbara has held Enterprise Architecture certifications from Zachman International and Pragmatic Enterprise Architecture (PEAF and POET) and is currently working on certification from the Business Architecture Guild. Her Enterprise Architecture practitioner’s bag includes considerable knowledge and experience with organizational change management, quality improvement practices (such as LEAN and Six Sigma), knowledge management, data management, and data governance. Barbara’s wide-ranging work interests reflect her nomadic early days, having resided in a number of different U.S. locations, as well as Mangla, West Pakistan and London, England.