For example, at Kessel Run, they tried different-sized teams before deciding that about eight people make up the ideal product team. They also learned not every big idea worked as planned.
Raytheon Systems Engineer Sam Sauers and her team spearheaded one of the latest DevOps transformations on the program, introducing Silicon Valley-like processes like paired programming and pipeline development to help the Air Soldier team rapidly develop the technology.
“We’re using commercial software best practices, including Agile and DevOps, to get new capabilities in days instead of years,” said Sauers. “We’ve also been implementing user-centered design: getting ahead of the users and figuring out the next thing they’re going to need. We then develop toward that rather than getting something out there and getting feedback that it wasn’t what they wanted.”
Most, if not all, teams I have worked with (in the capacity as the Agile Coach in The Lab) do not know what truly matters to their customers. Through numerous planning sessions with key stakeholders from ‘the business’, they gather requirements for their product development. These plans sound great until you start asking a few questions, for example: ‘What are the biggest problems facing your customers?’, ‘How have you validated the requirements with your customers?’, ‘Will the proposed solution actually work in their context?’. Upon asking these kinds of questions, they quickly understand that the proposed backlog of work is frequently what the business wants, not what their customers need. Using design thinking approach and applying techniques for user research and validation, the teams had the opportunities to understand the need of real customers. Talking to a real customer isn’t that hard, but the insights can be quite profound.
Ultimately, Waterfall’s biggest failing is that it puts its trust in a system, not the people working on a product.
The power of focus. Before the crisis, each team worked on its own backlog and specialized in its domain. In the backlog, there were finely decomposed tasks, the team selected several tasks for a sprint. But during the crisis, we worked quite differently. The teams did not have specific tasks, they had a big challenging goal instead. For example, a mobile app and API must handle 300 orders per minute, no matter what. It is up to the team how to achieve the goal. The teams themselves formulate hypotheses, quickly check them in Production and throw away. And this is exactly what we wanted to continue doing. Teams do not want to be dumb coders, they want to solve problems.
The power of focus manifested itself in solving complex problems. For example, during the crisis, we created a set of performance tests in spite we had no expertise. We also made the logic of receiving an order asynchronous. We have long thought about it and talked, and it seemed to us that this is a very difficult and long task. But it turned out that the team is quite capable of doing it in 2 weeks, if it they are not distracted and completely focused on the problem.
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
“In a high level, projects are local optimization efforts. We get a group of people who create new (or improve existing) functionality for our customers and then we pass that onto a team that has no idea why the change was made and how this change was solutioned/implemented. Very often, the quality is low and this Maintenance team needs to deal with the issues. This creates a culture of tolerating low quality, accepting that maintenance/operation teams will deal with problems created by delivery teams, not allowing delivery teams to learn from their mistakes and hence keep repeating them, allow budgets to be set without proper data, treat people like easy-to-replace objects, and so on. This culture is ok with low expectations and tends to increase debt in many aspects like technical, product, talent, innovation, etc. As such, these organizations often run in reactive mode and are constantly catching up with what the competition has brought to the market. Changes are expensive and take too long to get in the hands of the customers.”
Original source: Think in Products, Not Projects
A brief description of Pivotal Labs work to improve customer’s agile capabilities.
Original source: How Pivotal hopes to make cloud mavens of us all
“Getting feedback on the effectiveness of the initiatives, and acting on it quickly to refine the strategies and initiatives to ensure their alignment with the purpose is critical for sustaining the effectiveness of the organization towards fulfilling the purpose.”
Original source: Q&A on the Book Enterprise Agility
Kind of a good list of how to align short, agile cycles to longer, strategic planning. Key, I think, is understanding the stability and predictably needs of strategic planning and explaining how short agile loops increase the confidence the corporate can have in both it’s plans and better intelligence about the market and what works.
“In practice, the lack of continuous feedback loops between operational units and C-suite leaders leads to the misalignment of resources. Lack of communication makes course adjustment nearly impossible.”
Original source: Agile Strategy: Short-Cycle Strategy Development and Execution
‘“a lack of connection between innovation teams and their parent organization. Teams form/and are taught outside of their parent organization because innovation is disconnected from other activities. This meant that when teams went back to their home organization, they found that execution of existing priorities took precedence. They returned speaking a foreign language (What’s a pivot? Minimum viable what?) to their colleagues and bosses who are rewarded on execution-based metrics. Further, as budgets are planned out years in advance, their organization had no slack for “good ideas.” As a result, there was no way to finish and deploy whatever innovative prototypes the innovators had developed – even ones that have been validated.”’
Original source: How to make innovation programs deliver more than coffee cups