I always like his focus in speeding up the release cycle as a forcing function for putting continuous integration in place, both leading to improving how an organization’s software:
I try not to get too caught up in the names. As long as the changes are helping you improve your software development and delivery processes then who cares what they are called. To me it is more important to understand the inefficiencies you are trying to address and then identify the practice that will help the most. In a lot of respects DevOps is just the agile principle of releasing code on a more frequent basis that got left behind when agile scaled to the Enterprise. Releasing code in large organizations with tightly coupled architectures is hard. It requires coordinating different code, environment definitions, and deployment processes across lots of different teams. These are improvements that small agile teams in large organizations were not well equipped to address. Therefore, this basic agile principle of releasing code to the customer on a frequent basis got dropped in most Enterprise agile implementations. These agile teams tended to focus on problems they could solve like getting signoff by the product owner in a dedicated environment that was isolated from the complexity of the larger organization.
You can hide a lot of inefficiencies with dedicated environments and branches but once you move to everyone working on a common trunk and more frequent releases those problems will have to be address. When you are building and releasing the Enterprise systems at a low frequency your teams can brute force their way through similar problems every release. Increasing the frequency will require people to address inefficiencies that have existed in your organization for years.
On how organization size changes your managerial tactics:
If it is a small team environment, then DevOps is more about giving them the resources they need, removing barriers, and empowering the team because they can own the system end to end. If it is a large complex environment, it is more about designing and optimizing a large complex deployment pipeline. This is not they type of challenges that small empowered team can or will address. It takes a more structured approach with people looking across the entire deployment pipeline and optimizing the system.
The rest of the interview is good stuff. Also, I reviewed his book back in November; the book is excellent.
From an interesting sounding panel on government IT:
“We do discovery on a small chunk and then development, and then while that’s going on, we’re starting discovery on the next small chunk, and so on and so forth,” Smith said. “And then when the development is done, we loop back and we do user testing on that piece that’s done. But we don’t release it. That’s … one of the differences between agile and the way we did it. At the end of the phase we release everything.”
Also, some fun notes on consolidating legacy systems and resistance to going agile.
[A]fter pairing, I realized how much of my time I spend staring into space when I program alone.
Source: On Pair Programming and the Myth of the 10x Developer.
Companies commonly make one of two mistakes when selecting a product owner. Often they tap a junior employee with limited experience and therefore a limited understanding of how the project fits into the larger mission. Product owners need enough seniority to inspire and motivate peers across multiple business units. By earning the respect of teams in customer experience, enterprise architecture, and risk and compliance, for example, the product owner can help ensure that projects move smoothly without costly bottlenecks. Other companies err in the opposite direction, selecting a senior executive who is too harried to devote adequate time and may not adapt well to the highly responsive, iterative nature of agile development.
So what should companies look for when appointing product owners? In our view, the key is to find people who think and behave like entrepreneurs.
Much of the advice here falls under the category of “if you do good things, good things happen”:
success comes from simply managing a sound process: conducting market research, understanding the customer’s needs, identifying where the product will create the most value, prioritizing the most important features, testing ideas, capturing customer feedback, and continuously refining their vision over time.
The tasks is setting up and environment, processes, even “culture” that encloses and rewards good behavior like this. And the protecting that structure from corporate barbarians. That’s a job – and the responsibility – of management. So, perhaps it’s good to get some management consulting advice on what good looks like.
Source: Agile Development’s Biggest Failure Point—and How to Fix It
Diego Lo Giudice, vice president and principal analyst with Forrester Research, is one of those who thinks that companies haven’t really adopted Agile as they should have done. “I would say that we’re going to see more Agile because we haven’t done it well enough yet,” he told The Reg. “Organisations say they’re doing it, but they’re struggling to scale it.”
One of the more shocking “turns out” to most of my talks is just this: just under 20 years later, the industry still doesn’t do that much agile.
Source: The dev-astating truth: What’s left to develop? Send in the machines
Instead, it has created a great divide, said Pucciarelli. “This siloed, divided approach brings frustration, disappointment and failure in multiple ways.” For one thing, it doesn’t support healthy team spirit, he said, and the innovation side tends to operate fast to deliver business solutions without the accountability around reliability, quality and security that is expected from the traditional IT side. “It leads to redundancy and inefficiency.”
Source: Bimodal IT leads to technical debt that must be paid, with interest
“Waterfall” comes up a lot in my line of work: talking with orginizations about how to do software better. People like myself take the definition of “waterfall” for granted and usually don’t spend too much time talking about it, let alone when it might be a good idea of how to do it well.
Someone asked me the simple question “what is waterfall?” as a follow-up to one of my talks recently. Here’s what I typed back:
Continue reading What is “waterfall”?
The primary measure of progress for the Scrum Team is working software, but the primary measure of progress for the Product Owner is user stories that are “ready,” which is a very nebulous concept.
a Kanban board can make a cross-functional team feel more like a reality. In a large organization, where there are specialist systems, software, hardware, and test engineers, the various disciplines are usually not going to start performing work in each other disciplines, no matter whether or not they are on the same agile team. But by working off the same board, at least they are in the position of being able to visualize each other’s work and see how what they are doing contributes to the success of the whole program.
the advantage of lean and Kanban approaches is that they make explicit and visible the full state of a program in a way that encourages people to make good decisions for improvement to the process as a whole rather than optimizing for one part of the process. This includes the poor product owner, whose work is finished before most agile boards start.
From: “The Case for Lean: Capturing Business Work”
I’m giving a 90 minute overview of agile for an agency later this month. Here’s my slides, so far. As ever, “government” is just an extra layer of sprinkles on-top of advice for all large organizations.
There’s some extensive (for me) talking points in the slide notes if you’re into that kind of thing.