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.

By Todd Wallace, PMP, CSM

Agile methodologies.
Scrum projects.
Continuous and rapid improvement.

These are all phrases you would expect to hear in a Silicon Valley startup, while attending a morning huddle in a shared space office.

You would not expect to hear these phrases while attending a quarterly all staff meeting in “the large conference room on the 6th floor” at a government office.

However, times are changing, and the way work is being done is changing with those times.

What was once a radical new way to manage projects, or “work efforts,” is now seen as a reasonable, efficient, effective, and adoptable methodology to bring into new areas, such as state government.

As opposed to the historically applied Waterfall method to manage projects in state government, using an Agile method allows for earlier customer feedback and course correction.

This helps increase the chances that your project meets the customer’s needs and isn’t outdated before it’s even completed.

While a juggernaut such as a government agency may not be able to pivot as quickly as a small startup, there are still very real gains that a government agency can realize through adopting Scrum into their day-to-day operations.

With the support and understanding from leadership, a group within a government agency can form into a Scrum team, with a Product Owner, a Scrum Master, and a working group.

By breaking up the work that needs to be done into correctly written user stories and a backlog maintained by the Product Owner, the team can accomplish recognizable progress every two weeks.

While Agile was originally created for software development and rapid releases of code, achieving success with Scrum doesn’t rely on being in a software development group.

Notice that that previous paragraph said nothing about technology or software.

Scrum can be applied to any work effort, from process improvement efforts, to reconfiguring the physical assets of a floorplan.

The overarching goal of Scrum is to “chunk up the work,” or break the work down into tasks that can be completed in a timely manner, with value added at their completion.

Scrum projects may seem like tech world jargon, but there is real value in knowing how to manage Scrum efforts within the government sector and there is a real push for government agencies to adopt Scrum in daily operations.

If you work in a government setting, either as a government employee or a contractor, Scrum is a very real change coming to you soon.

If you want to be ahead of the 8-ball and able to walk the walk when your department’s leadership implements Scrum methods, the Certified ScrumMaster course, offered by KAIP Academy, will teach you everything you need to know to get up to speed. You’ll be able to confidently raise your hand in a “fist to 5” saying that you can coach the team to succeed with Scrum!

About the Author: Todd Wallace is a Senior Project Manager with KAI Partners, Inc. He started his professional career as a student assistant in the special projects department of a state agency and worked as a state employee for over 7 years before transitioning to private sector and consulting to state agencies. He has a BS from CSU, Sacramento in Small Business Operations and an MBA from UC, Davis in Entrepreneurship and Strategy. In his free time, Todd loves tinkering on cars and motorcycles and has a passion for innovation.

By Jamie Spagner, PMP, CSM, CSPO

As a PMP, I have nearly a decade of traditional project management experience. I’ve worked on several projects and helped implement solutions into production using the standard waterfall methodology. With a very scripted plan, traditional projects have pre-defined scope and a definitive end.

Something I’ve recently started to work on is Product Management. In my current role, I am helping to plan the modernization efforts for a legacy system in the health care industry. The idea of Product Management is a relatively new concept for the public sector—it shifts the traditional way of thinking and is less prescriptive and more flexible.

You may be wondering how Product Management works, so I wanted to share my thoughts on Product Management in general, as well as some of its challenges.

1. Product Management doesn’t stop. Product Management is customer-driven by nature—there is no fixed schedule or end date by which to release a product or system. Features are continuously added or tweaked to make the system or product function better for the end-user.
2. Product Management is centered around the Agile approach. (Also true of some traditional projects.) Teams are self-motivated to determine how and when they’ll do the work. Product Management is not done in a vacuum—the development of the product is still structured using typical scrum tools like daily stand-ups and sprint planning.
3. Product Management is not perfect. As with any new way of doing things, implementing a Product Management approach is not without its challenges. The idea of a product never being truly “finished”—because the product is continually improved to make sure it meets and exceeds customer needs—can be a tough concept.
4. Product Management requires buy-in. Product Management often requires a culture change, as well. Coaching of executives and leadership is common—instead of directing their team, leaders should empower their teams to self-organize.
5. Reporting Product Management’s progress. Another challenge of Product Management is reporting and being able to show progress against a plan. Since these are inherently waterfall tasks, there is a challenge in how to measure and show progress with a continuous process like Product Management. I believe using the tools of Agile can help in reporting and measurement. Developing a product roadmap, building a backlog, holding daily standup meetings, and overall accountability—you should trust in the agile process to develop and improve a great product.

Product Management is starting to be used more widely in public sector technology and innovation endeavors because it focuses on the people, processes, and technology. Product Management is a team effort to make sure a product thrives and meets the needs of the end-user community it supports.

Have you used a Product Management approach before? How is it working for you? Leave a comment and let us know!

About Jamie: Jamie Spagner is an Executive Consultant for KAI Partners, where she works as a Project Manager for a public sector health care client. She graduated from California State University, Sacramento with the Bachelor’s Degree in Communication Studies/Public Relations. She is a loving mother of a teenage son named Wyatt. In her spare time, she enjoys shopping, spending time with family/close friends, and working out.

By Tim Townsend, CSM, CSPO

Creating effective teams capable of working together toward a common mission is one of the most important goals of any organization. Whether it’s software development or how to bring a new product to market, no large project can succeed without collaboration from an organization’s employees.

Knowing how important this is and making it happen are two very different things.

One of the trainings offered by the KAIP Academy teaches a framework that allows a team to put Agile product development practices into action.

“Scrum” has been around since the early 2000s and traces its origins towards looking at organizations that are able to develop products quickly and respond more deftly to change. Most importantly, it’s a framework instead of being a prescriptive process. This allows Scrum to be adapted to any organization or situation.

I completed both KAIP Academy’s Certified Scrum Master® (CSM) and Certified Scrum Product Owner® (CSPO) classes. In the process, I learned a lot of useful strategies to maximize the effectiveness of teams in the workplace. Each class focused on the role of a particular team member in Scrum.

Through the CSM class, attendees are taught through a series of interactive exercises and lectures what Scrum is, the tools it utilizes, and the team events needed to carry it out. The role of the Scrum Master is to facilitate the use of the Scrum framework and help resolve any impediments that arise while a team is working on a project. It’s a role that requires strong soft skills and a high degree of emotional intelligence—things that cannot be learned in a two-day training program. However, taking the Scrum Master class will certainly give someone the tools to develop these skills.

One of my favorite elements of the CSM class was the freeform it took. Instead of learning a linear curriculum in a predetermined order, the class was asked to set the agenda and the order of the topics. This was true to the Scrum method where teams determine how to best accomplish their goal and how their work will be completed.

The second class I took was the Certified Scrum Product Owner® (the person in charge of delivering the highest business value from the product). Being a Product Owner is arguably the most difficult role in the Scrum framework. Unlike a traditional project manager, a Product Owner in Scrum doesn’t rely on a hierarchical authority to direct a team towards their goal. Instead it’s about collaboration and negotiation with the team while keeping an eye on the ultimate objective.

I found it particularly helpful to learn how to refine a large project into small actionable items and how this is a constantly evolving process as the project moves forward. We were even able to put these principles into practice during the training through a team exercise where we planned, built, and refined our own product (in our case, a new type of cell phone holder).

Going forward, I will be using many of the skills and strategies taught through the CSM and CSPO courses and would highly encourage others to further their professional development through these courses.

Interested in taking the CSM or CSPO course through the KAIP Academy? Click here for all our KAIP Academy course information!

About the Author: Tim Townsend is an Associate Consultant for KAI Partners and a communications specialist with on IT project developments. Prior to joining the company, he was a Chief of Staff in the California State Legislature, where he worked for eight years. He enjoys snowboarding with his wife and is a parent to two rescue dogs.