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.

Photo credit: Techwire

By Dave G. Cornejo, MBA, CSM

For over 30 years, Sacramento has been home to some of the largest and most-anticipated government technology conferences on the west coast. This year’s Digital Government Summit was no exception.

About the Event

Hosted by Government Technology/e.Republic, the summit included key state and local government executives, technologists, and industry specialists to address the most important policy, management, and technology issues surrounding the future of digital government in the State.

This year’s event included an impressive line-up of guest speakers like Governor Newsom’s Advisor on Innovation and Digital Services, as well as representatives from the Department of Technology, the Government Operations Agency, and more.

Key Takeaways

Some of the most interesting topics from the breakout sessions included:

• Re-inventing Customer Services
• AI (machine learning and predictive analytics)
• Census 2020
• Autonomous vehicles
• Design Thinking in Action (putting focus on people when designing new services and products)

The overall theme for this year’s summit was on customer-centered technology, so it was not surprising that a large crowd gathered to hear the latest chapter on the Governor’s plan for the Office of Digital Innovation (ODI).

Governor’s Goals

Summit attendees learned that Governor Newsom wants the State to be more innovative on how it interacts with clients. He believes government is not focused on customers like private industry and he wants that to change.

Some of ODI’s innovation goals include the following:

1. Encouraging agile and modular approaches to project management, rather than “waterfall” models.
2. Bridging silos, not blowing them up.
3. Developing talent, creating a community, and investing efforts in a culture change.

Final Thoughts

Working for a private sector consulting firm that supports many state public sector agencies to digitally transform, it was encouraging to hear the innovation-focused message from the Governor’s office and other guest speakers and summit attendees—and to know that we are on the same page when it comes to using technology to better serve Californians.

About the author

Dave G. Cornejo is a retired State executive having served as an Assistant Executive Director over Administration and Information Technology, Chief Financial Officer, and a Fiscal Division Chief. In these capacities, Dave successfully oversaw the implementation of multi-million-dollar technology projects. Dave has also taught Computer Information Science and Business courses as an Adjunct Professor with the Los Rios Community College District and served as a loaned executive to the California Performance Review team. Dave currently serves as a Financial Analyst for one of our public sector health care clients.

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.

Did you know KAI Partners provides comprehensive Agile services? Check out this infographic to see what Agile is, why your organization should think about going Agile, and how KAI Partners can help.

By Denise Larcade, CSM, CSPO, LSSGB, Prosci

I recently took the Certified Scrum Product Owner course through the KAIP Academy. As you may remember, I also recently took the KAIP Academy’s Lean Six Sigma Green Belt course and have found use for both methods on the project I currently consult on.

Over the years, I have assumed multiple agile/scrum roles on several different teams. I’ve taken on the role of ScrumMaster, Product Owner, and Team Member.

Having been in multiple roles on all kinds of teams, I’ve seen the waters get muddied when it comes to agile. Agile can get watered down or manifest into something unrecognizable. An organization that has managed projects using a waterfall methodology often makes a shift to agile and without proper training and established roles, the methodology can turn into something like “Water-Scrum-Fall,” “Scrum Falls,” or “WaterScrumming.”

Something that was covered in this course was, as a Product Owner, what to do when your stakeholder(s) don’t review the work the team is completing in each sprint. If the stakeholder identifies what they want and gives support for development, then they must be willing to take the time to see the results. As a Product Owner, it is your responsibility to communicate requests of the stakeholder and support the team as they share and present the results. It is difficult for the Product Owner to gain team trust if the stakeholder(s) don’t review the products delivered at the close of each sprint.

As a Product Owner, you have the ability to maximize business outcomes—a key skill for this role is communication. Whether it’s communication with stakeholders or communication with the team, communication is essential to success.

True agile can result in success, but manipulating roles and responsibilities in agile can result in a diminishing return or results. Ultimately, the CSPO training provided both a refresher to CSM and a clear understanding of roles and responsibilities related to scrum. This course helped me to better understand what I know about each role and where I have an opportunity to learn more.

Interested in taking the KAIP Academy’s next Certified Scrum Product Owner course? A list of all our upcoming courses can be found here. Remember, there is no exam associated with becoming a Certified Scrum Product Owner. The 2-day course with Certified Scrum Trainer (via the Scrum Alliance) is all you need to get your CSPO!

About the Author: Denise Larcade is an Organizational Development Consultant and Merger and Acquisitions Expert. She has over 25 years of experience in training, development, and leading companies through organizational change management. Denise has worked in corporate retail, technology, and government healthcare and most recently has experience with large-scale implementations nationwide. She currently works as an Executive Consultant with KAI Partners, Inc., providing client support to one of KAI Partners’ state clients. Denise grew up in the Silicon Valley and relocated to Utah and Idaho before recently returning to her native California roots.