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

Transcript

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’t really trust the team to deliver something that is high‑quality the first go‑around.

I think people have been burned in the past, so they just assume that they have to go through all these layers. Whereas, maybe, if we can get some teams that are focusing on code quality and some of the more engineering professionalism stuff, where you get a few wins, and then it lowers all those barriers.

If you’re working on those lower cycles, you don’t necessarily have to have some huge risk plan for what happens in ten months, because it’s not a ten‑month thing anymore.

Jade:  But what happens when that’s the way we’ve always done it, and there’s entire departments of my organization that that’s their job.

Clayton:  Yeah, that’s the hard pill to swallow. It seems like, for a lot of places, where to adopt some of these things, that means that you’re going to have to make these big shifts and changes. Obviously, it’s very difficult for a company to restructure that many people or totally change their roles, even if they’re not necessarily needed in their existing capacity.

Jade:  I think it’s been easier for development teams to do that, because they’ve done it…I don’t want to say in isolation, but mostly in isolation. I can reorganize us as a development team, but put on the corporate face to the rest of the company and still interface at the expected levels.

I can still produce the right reports and all these things that the business needs to pacify them, and then have this really great, agile, self‑organizing team internally, but rolling that up to the organization is really difficult.

Derek:  I think it’s even difficult for software teams. We’ve seen software teams take the first crack at it because they didn’t have a choice, and what I mean by that is, the rate of technology change is so fast that, if you hadn’t changed your technology in the last 20 years, you’d still be running COBOL and the Mainframe.

So in order to just keep an organization running, teams have had to adopt new languages, new platforms. Some things stay the same, but it’s really to a point where they’ve had to deal with a large, wholesale change on a regular basis. If you’re a retail store, if you’re Walgreens, if you’re Wal‑Mart, what have been the significant changes in how you do business, short of adding some technology that has really changed?

In that space, if we looked at, say, Zappos or Amazon. Those are the real risks to the retail business, not other retail business, for the most part. At what point are we going to get to where 90 percent of business is technology‑driven, that it’s changing on a pace so quick that, if you do not change your organization to be adaptive, that the new guy will put you out of business on a much more regular basis.

Jade:  I think the Web was the first shot over the bow of this type culture that you’re talking about, where a competitor can crop up overnight and completely destroy you in no time and you haven’t even had a chance to react to that. We’ve seen that accelerate, especially for Web‑based businesses competing with each other.

I could be MySpace, and I’m king of the world, and six months later, nobody even knows who I am. We’re seeing that kind of change in those businesses because it’s survival of the fittest. If you go down to more traditional organizations, they’re not suffering at that level yet. I think some of the economic downturn is some of the first indicators of things have to change.

Things have to change with how we run our businesses, but that pain threshold still isn’t there. They’re still holding out hope that we’ve just got to suffer through this and things will get back to normal. It’s going to take something that completely changes the game for a lot of these people for them to be willing to endure the pain of making that type of organizational change.

Clayton:  Yeah, I think you look at banking, for instance. Pretty much every single online bank I’ve ever seen has been pretty much terrible. Even the best one is still pretty bad. There’s going to be one player in these markets where they can use the technology to, what you’re saying, Derek, to pivot enough.

You mentioned the younger crowd. As people are my age, younger, whatever, that are getting to the point where they consume certain services in a way, and they want to be able to use everything that way.

Finding the companies that are going to be able to make that organizational shift so that they can take advantage of all these things, which I don’t think are especially difficult. It’s organizationally difficult but not technologically difficult. People that can do that are going to have a huge impact.

Derek:  With that, I think we’re about out of time, even though Clayto worked in a pit for a Simple Bank and Square there, so those following along at home, those are a couple of startups you might want to take a look at that might be replacing your bank in the near future. With that, we’ll see you next time.