Continuous Deployment and Project Management

Episode 11

April 13, 2011




The Agile Weekly Crew discuss continuous deployment.

Episode Notes

Clayton Lengel-Zigich, Derek Neighbors and Jade Meskill talk about continuous deployment and what it means to project management.  The by product being a change in organizations.

Historically products were projects

Release planning

Lean methodologies

Team management

Organizational changes

Overnight competitors

Things have to change


Derek Neighbors:  Welcome to another episode of the ScrumCast. I’m Derek.

Clayton Lengel‑Zigich:  I am Clayton.

Jade Meskill:  I’m Jade.

Derek:  Today, I wanted to talk a little bit about continuous deployment, but I wanted to talk about it in a little bit different of a viewpoint. That is, as we see products like Facebook, like Twitter, where you can’t really tell what version of Twitter are you running, what version of Facebook are you running. You don’t know when the last feature was deployed.

You just hear people talking about the “new Facebook,” or the “new Twitter,” and when is it going to show up for you it’s already shown up for me. What does that mean to what we would call right now, “project management”? Are the concepts of projects starting to die? Is software deployment happening so continuously that we can’t really tell where something begins and something ends? What does that mean to agile processes and how we think about projects as organizations?

Jade:  I think some of the trick here to what you’re getting at is historically we treat products as projects, and I think that’s really where we’re seeing the shift. The Facebook product itself is not a project in and of itself. The Facebook project will never be complete. But I think there are people engaging in project‑oriented work around that product.

So there’s some scope of work that has a beginning and an end. It needs to be measured and tracked throughout that work, but that project is just a means to an end. It’s not the end goal itself. Finishing up implementing the new photo layout or photo uploader for Facebook is a project. But that’s not the Facebook project itself.

Clayton:  Yeah, I think that any agile methodology, too, seems like would be pretty well‑adapted for this where you have something that’s out there, say, or even if you don’t, but you’re incrementally improving. You’re deploying something, getting feedback, incrementing on that, inspecting/adapting.

It seems like that would be really well‑suited for continuous deployment and not having the concept of, “Well, we have to get all these features in, and then we can deploy. Then we’ll wait six months, and then we’re starting another project and then we’ll deploy it a year from there” and that kind of deal. It seems like it’s well‑suited for any agile methodology.

Derek:  Yeah, I think we definitely went through a phase where the actual product shipping itself was the project, and then I think we narrowed it down to a new version of the product was a project. Then we went down to a minor release version, but now that we have this ability to continuously deploy I guess the crux of what I’m getting at is are we really looking at, “projects are almost features”?

Are we really getting to the point where we’re talking for the most part, when we talk about projects in these type of environments, the photo uploader to the new version of the photo uploader is more of a project? Or even more minute than that, a little subset feature within the photo uploader is really how I measured?

Do we see people maybe leaning more towards Lean principles or Kanban or other things? What does release planning look like in this type of environment?

Jade:  Clayton and I are staring at each other. I think you’re right, and I said that earlier. I think that the feature itself, the photo uploader, becomes the project that we need to manage. We need to look at the scope, look at what is the possible return on investment for adding this particular feature. We need to create a plan of implementation around that.

As far as moving towards a Lean methodology, I think a lot of that’s going to depend on the organization itself and how it handles risk assessment and a lot of these things that are not code‑related at all but really more about engaging in that feature. Is it viable for us to try this? Or what is the minimum viable project that we can do for this particular feature to test it out and see how that goes?

I think, whether you take a Scrum or a Lean approach, that’s going to depend a lot on your team, the personalities involved, the amount of unknowns that there are out there.

Clayton:  Yeah, I think it’s interesting, the idea of features as projects. I think one thing that’s really powerful about Scrum I guess, that concept of potentially shippable software. I think that’s personally too soft of a word.

But if your development team is able to treat every feature as if, at the end of that feature when it is done ‑‑ done is done ‑‑ it’s going to be shipped to production and people are actually going to be using it, I think that changes the mindset when you’re developing something, that a lot of times people let things get away. It’s easy to be sloppy. But if you have this concept of, “When this feature’s done, I’m deploying it to production, and wrapping that up”

I think it’s interesting. If you were to ask some people that may be at the VP level in terms of, you have this project manager that is running this project, they probably think, “I need someone that is going to manage all these different things.”

But on a feature‑by‑feature level, if you said, “What if your development team was responsible enough and mature enough to manage themselves for a feature”? I think there probably are a lot of teams that could do that on a feature‑by‑feature basis. If you got to a point where you could do that pretty consistently, it wouldn’t be necessarily one person to manage this whole project, but it would just be the team managing themselves from feature to feature.

Derek:  I guess that ‑‑ segueing into where I really want to take the conversation ‑‑ is, we see all the time, when we work with product owners who are not used to a high‑performing team or not used to agile principles and methodologies, that we find ourselves, basically, working so far ahead of where they’re at that they have a hard time keeping up. That they, in essence, become the bottleneck to delivery of software, because they are not able to work at the speed that the team is.

I really question, as part of moving towards continuous deployment, are we really seeing pushback? Not from developers, because I’ve really not met a whole lot of developers that don’t like the concept of working on a feature‑level basis and deploying really, really often. Sometimes, you’ll see some, but for the most part, at least younger developers, I don’t see this. This is part of how they’re already wired, because that’s how they consume software.

But what challenges do organizations face? When you talk about a PMO office and having to plan out products potentially years in advance, are we going to get to a point where they’re unable to compete with organizations that are embracing agile philosophy not at a development level, but at an actual organizational, cultural level, where a CEO says, “I’m not worried about the 10‑year plan. I’m worried about, are you continuously adapting to what’s happening in the marketplace”?

Jade:  I think that’s a really good question. I was talking to a group of people. They were talking about how they were adopting Agile in a very large enterprise and how the biggest roadblock they had was that their risk management software couldn’t calculate the potential financial risk based on doing it in an Agile manner.

They just didn’t have a way to understand and represent that to the business, of, what is the potential financial outcome of this thing? They could prove it from a return on investment, that, “Yeah, this is a good product to build, and we should invest in doing that.”

But the risk calculations they just couldn’t do, because they couldn’t plug in the made‑up project plan that most people have to get them there. I think that’s going to be the next major roadblock, is looking at the organization’s ability to respond to change.

I think as software developers, we’re really leading the way for that type of mentality. I think it’s going to be a really difficult transition for the business itself to make.

On an organizational level, to be able to respond to change, to have that tight feedback loop, to have that transparency with the rest of your team, that, “Maybe we don’t know what we’re doing right now. Maybe we’re going to have to figure some of this out, but now, it’s readily apparent that we don’t know how to solve this problem. We’re not the guys with all the answers.” I think that’s going to be really difficult.

Clayton:  There’s definitely a lot of cruft in this status quo, I think, with a lot of people, in how they view the life cycle of a project, where there’s some development, and then there’s testing, and there’s QA, and all this other stuff.

I think that because that’s the accepted…that’s the norm for how things go, the idea of being able to say, “My team is going to develop this feature, and we’re going to quickly get it to market,” I think that’s a foreign thing, partly because I would guess that a lot of people don’t feel that their development team…they don&#8