The third thing that I want to stress is the importance of getting rid of software projects as a notion. Instead we want to switch to a product-oriented view of the world where instead of projects that you spin up, run for a while and then stop; you instead say, “Let’s focus on things that are much more long-lasting and organize a product team around that.” Another way of thinking about it is: what are the business capabilities that your organization has, and then organize the teams around those. These business capabilities will be long-lasting and will necessarily mean combining together technical people and the people who are on the business side of things into the same team.
Original source: The State of Agile Software in 2018
Brief, but some names of apps they’ve modernized and high-level thinking in the broader portfolio modernization.
Original source: USAF’s plans for agile, DevOps, cloud
It’s probably OK:
In any organisation that’s been around for a while, ways of doing things build up and often disconnect from the reasons they were put in place. Things are cited as “rules” which are really just norms. We had to get really good at working out the difference, and on pushing back on some of those rules to get to the core principles.
Get involved with the backend people:
I know of one government project where the digital team couldn’t even add one extra textbox to their address fields, something users were complaining about, because the backend IT teams were too busy to make the change.
Working with the end user changes staff for the better:
I’ve talked to a lot of teams in large organisations who have taken all the right steps in moving to agile but are still having trouble motivating their teams, and the missing piece is almost always being exposed directly to your users. Whether they’re end customers, or internal users, there’s nothing like seeing people use your products to motivate the team to make them better.
Original source: Lessons from the UK Government’s Digital Transformation Journey
At the topic of agile, lean, DevOps, and all that “digital transformation” stuff is a renewed focus on customers and figuring out what they want to give you money for, then making the product as good as possible for them:
VGZ decided to focus its efforts on improving the customer experience. The starting point was not a traditional customer segmentation — the leadership instead decided to focus on understanding and improving customer journeys, specifically the frequency of customer interactions and the impact on the life of customers.
Very “jobs to be done.”
Original source: Agile processes can transform companies from unexpected places: The VGZ success story
‘Here’s how to make the argument to a stakeholder on your team that really wants to see that end-to-end vision: If the idea is to get value out to customers as fast as possible, does it make sense to explore every customer touch point? The time spent doing that intensive research could’ve been spent building and delivering an MVP for customers and get them excited about. Repeating this cycle gets the team to “learn by doing” and is actually a faster way to truly understand the customer’s end-to-end journey. It’s also a lot more engaging work than research and makes the team stronger.’
Original source: Why Starting With End-to-End Customer Journeys Isn’t Good For The Customer
Creating the process itself is agile. Also, a chart with activities and a suggested timeline.
Original source: Taking Agile Transformations Beyond the Tipping Point
“We have a small team that was tired of working this way and tired of not being able to provide this capability to our warfighters,” said Adam Furtado (pictured), chief product officer at the U.S. Air Force. “Basically, Congress told us to figure something new out.”
“We’ve been designing a brand new system to modernize for about 10 years, and we just haven’t been able to get it to the field for a ton of Department of Defense, bureaucratic and acquisitions reasons,” Furtado explained.
Original source: Transforming the Air Force into a software company with more airpower
“Air Force acquisition leaders recognized the current acquisition strategy, in progress since 2009, will not deliver capability to the warfighter fast enough. Today, we terminated the current AOC 10.2 contract with Northrop Grumman in order to take a different approach.”
“Once we field this platform and establish the software pipeline, we will begin the iterative improvement process,” said Sanders. “That’s where this acquisition process really makes a difference. The customers, in this case Airmen at the AOCs, are able to communicate their needs directly to developers and see the changes they request within weeks.
Original source: Airmen given direct access to AOC development process
Good discussion of doing product management instead of project management. Also, discussion of user metrics to track design and usability:
“Defining success metrics helps you focus on what’s important in your product and how well it solves the problems you’ve identified. Defining key steps the user must take is also important in order to shine a spotlight on where in the process users are failing. With this data, you can conduct further in-person research to understand why they are failing and devise an even better solution.”
Original source: Project vs. product management, in government
‘That discussion starts with a very concise and useful distinction between project management (the world the government knows) and product management (the world it doesn’t). Project management, they write, is “focused on managing to a plan” — such as managing schedule, budget, risk, policy compliance and then reporting status to stakeholders. “Success for a project manager is delivering a defined scope of work on-time and on-budget,” Johnston and O’Connor note. Product management, meanwhile, “is focused on delivering a product a user wants or needs.” Success for a product manager “is delivering a product that users love — and use to complete tasks (or in the private sector — a product customers will pay for).”’
Original source: Project management vs. product management