All right, everybody. Welcome back to OpenShift Commons. And today, as we like to do on Fridays, we're going to talk about transformational things, organizational, cultural, very dev-oppish things as well. And today we have with us Jeff Susna from Susna Associates, but you may know him as the author of Designing Delivery, Rethinking IT and the Digital Service Economy, which came out in 2015, I think. Yes. Yes. And it's, it's a great combination of a lot of things we've been talking about from dev ops to systems thinking to new things like promise theory and that. So last week we did a great talk with Kevin Beard around raging against silos and Jeff stepped up and said, hey, I got to talk for you. So, I'm going to let Jeff introduce himself and then talk for as long as you'd like, because it's always a pleasure. And then we'll have a conversation with some of the members from the global transformation office who are here with us today and take questions from the audience. So please, Jeff, take it away and show us what you do with silos versus raging against them. Thanks, Diane. Thanks for having me. It's great to be here. So yeah, I'm Jeff Susna, founder and CEO of Susna Associates. We are a Minneapolis based consulting agency and we are very much hunkering down for winter here. So far it's been fairly pleasant and we've been able to survive the pandemic by going for lots of walks. But the weather forecast for the next five to seven days is that it's not supposed to get above zero Fahrenheit. So it'll be very much walking on the treadmill. Anyway, our clients are cloud software teams and executives that are struggling to meet the demand for software delivery that is not just continuous, but also customer center. And they typically engage us when they are doing some form of agile and or DevOps and not getting the results they expect or hope for. And they say things to us like, well, we did the scrum training. We do standups. We do retros. We have an SRE team. We're running Kubernetes. What are we doing wrong? And what we find often particularly in the area of DevOps is there's a great deal of confusion about this idea of breaking down silos. You know, it's right at the heart of DevOps. It's right in the word. But unfortunately, the details, the practicalities of how you do it still remain something of a mystery. And the reality is that in any kind of complex organization, which to be honest is anything more than about 30 people in engineering, a literal approach doesn't really work. On the one hand, you can't just put everyone on one team. You know, otherwise you end up with 50 or 100 or 500 people in a standup every day. And on the other hand, if you look at one of the DevOps ideas of these cross functional self-sufficient teams where you have everything you need in order to build and run an application, that doesn't scale either. You know, the idea of having a network expert and a database expert and a security expert on every team, it doesn't scale and it starts to bloat your two pizza teams. And I was thinking about this and suddenly I realized something, which is that sort of the early approaches to DevOps made an assumption that they didn't tell anyone about. And that assumption was that there's a cloud. There is something that abstracts away enough of the low level infrastructure and operations details that it actually becomes feasible to have these self-sufficient teams that can run and build applications on their own. And that's incredibly ironic because the public cloud is the biggest silo in the history of IT. You don't know exactly where their data centers are. You don't know exactly how they do change management or what tools they use. You have this very, very opaque interface between you and them. And on the one hand, DevOps was telling us, well, stop treating IT like a commodity, bring it in-house, stop outsourcing and offshoring things because that's your competitive advantage. But at the same time, there was this assumption that we would engage in the biggest outsourcing arrangement ever. But even aside from that, the cloud still doesn't solve all of your problems. Public cloud providers are very careful to make it clear that they provide building blocks, but you still own things like scalability and resilience and security and compliance. So if cloud is an enabler, what's different about it? Why isn't it just another silo? Well, it's different because it focuses on being an enabler instead of a controller. So instead of making you fill out forums and ask permission in order to get access to scarce resources like servers or VMs, the public cloud approach is, well, you want servers, let's figure out how to give you as many as you want for as long or short a time as you want as fast as you can ask them, ask for them. Secondly, and this is a really important point, is there focused more on helping you than on what it is they do? Public clouds don't really care whether their infrastructure is a service or platform is a service or software is a service. Their approach is helping you solve your problems with whatever expertise they have they can contribute. And that leads to them not just being helpful, but being continuously more helpful. So I remember the first consulting project I ever did about 10 years ago or so, where I was helping a small company migrate a fairly straightforward lamp application from a bunch of failing hardware and a colo onto AWS. And it was a pretty straightforward lift and shift kind of thing. We wanted to take advantage of some of the basic public cloud capabilities like multiple availability zones and elastic load balancing and so on and so forth. But one thing we couldn't figure out was how to deploy a high availability memcache server. And after kind of futzing around and looking at products and struggling for a while, we decided not to bother. It's just a cache that falls over. It's not the end of the world. Let's go on finish the project go on with our lives. So we did. And literally about three weeks after we finished the project, AWS announced a new service, which was elastic cash. In other words, on demand, high availability memcache. And I remember seeing this and thinking, well, they must have been reading our emails. But whether they were or not what they were definitely doing was watching their customers struggle with things on top of their platform and figuring out how can we use our expertise to make that struggle simple. So we can we can see an example of how this idea of focusing on helping and not just doing is important. A lot of organizations I work with, we help them with some sort of platform team. They're operating something like OpenShift and they think that their job is to tip up and run an OpenShift farm. But what they figure out fairly quickly is in order to recoup that investment, you know, somebody has gone to the CIO or the CTO or the CFO and said, well, we invest in OpenShift, it will make things better in all of the following ways. But to actually use that, it also means that in addition to the platform application teams need to be able to consume it. And they need things that they may not have. They probably don't because they haven't had an environment to do them in before. You know, they need to understand and have expertise in CI and CD. They need a modular architecture that fits in containers and Kubernetes and microservices, which they probably don't have. They need the skills and tools and even just the mindset to think about monitoring applications for themselves. And what these platform teams start to figure out is that their job isn't just to operate the platform, but to actually function as a mentoring organization, to help application teams with onboarding and mindset change and tool migration and so on and so forth. So to understand where this is leading, I think we need to take a step back for a minute and understand the underlying business driver. I had an epiphany one day when I was reading a marketing website from an early software as a service company. It might even have been Salesforce. And right on their homepage, they were talking about things like multiple data centers and offsite backup and advanced security practices. And I realized that they were spending marketing dollars talking about IT operations. And then they said something really interesting, which was, we update the software so you don't have to. And the epiphany was that was my recognition that part of what this company was selling, part of what their customers were paying for was operations. And what happens is that software as a service transfers the cost of change from the customer to the service provider. You know, it used to be with on premise software that the customer was always serving as a break on the rate of change. Well, we can't deploy your new version because we have to go through a three month change management process or it needs an OS upgrade which we're not doing until next year. But when software moves into the cloud, the conversation is completely different. It becomes, well, why is it taking so long to give us this feature? Where is this bug fix? Why haven't you made stability better yet? And what happens is that customers begin to demand not just value but continuously increasing value. On the one hand, they become very impatient with delay and taking too long to deliver improvements can actually lose you customers. But at the same time, what they're asking for is not just random change, not just this spray of features but evolution of continuous improvement in value. And what value means in the cloud is, first of all, usefulness that your software helps them get something done. But secondly, usability in the largest sense. Can I adopt it? Can I migrate to it? Can I get help with it? Can I navigate through outages? And finally, dependability, which is not just technical operability but also things like how quickly and how successfully you respond to support calls. And the thing we have to understand is that this demand for what we could call customer center delivery doesn't end with the customer space and product team because they can't deliver it on their own. One of the things that we hear is the idea of creating teams that map to some value stream or customer journey as opposed to a functional silo. But if you think about complex customer journeys, it's pretty hard to fit them into a single team. Imagine that what you want to do is you want to buy supplies to renovate your bathroom. There's a whole bunch of things that have to happen that are involved. A website, a store, multiple departments in the store. You know, you're going to need lumber and you're going to need plumbing and you're going to need electrical and you're going to need to check out and deal with the checkout team and the cashiers and all of the back end systems that support all of that. So that's something that you're not going to fit into a single small agile team. And one of the questions we have to address is agile and DevOps are very much about decomposing things into smaller and smaller pieces, whether it be user stories or deployments or microservices or microservice teams. But we still have to figure out how to put them back together because customers buy services. They don't buy microservices. And what this tells us is that these customer facing product teams need customer centered delivery. They need continuous evolution from the rest of the organization as well. So what they need is not just performance and scalability and resilience, etc. But they need all of those things to be continually improving in terms of their usefulness and their usability and their dependability. So how do we do that? Well, the answer is by mutual service of each part of the organization treating other parts of the organizations as customers, just like paying customers. And this has the effect of turning silos inside out. You know, the problem with silos isn't that things are separate. It's that they're sealed off from each other. So what we have to do is figure out how to kind of flip them inside out and connect them in to each other in some way that delivers coherent service but also maintains agility and autonomy. And we can do that by asking free deceptively simple questions. The first is how are we promising to help each other? How am I promising to help my internal customers? Second, how well are we fulfilling those promises?  And we can use that as a driver for continuous value evolution and continuous service to each other. So let's look at some simple examples of what it means to think in terms of making promises to each other. If you're in support, you make a promise to end users which is that you will help them solve problems with using the application. And more and more support organizations are thinking about their promises, not just in terms of how many tickets can we close, but how often can we help the customer solve their problem on the first phone call. But you also make promises to application teams which is that you will amplify the customer's voice. One of the best ways to understand how your system is working and how people are using it and how it isn't working is from support. If you're in networking, what are you promising? Well, what you're promising is high performance, secure and compliant data flow so that I can connect my application to my database and get high throughput, low latency, but also be sure that I'm not violating PCI or HIPAA requirements. If you're on the platform team, what promises are you making? Well, you're promising to minimize the friction associated with delivering code to production. And you're also promising to maximize the ability of application teams to observe the behavior of their applications. And the interesting thing here is we haven't said anything about features. We haven't said anything about switches or routers or Kubernetes or not Kubernetes or ServiceNow or JIRA or anything like that. It's all about who we are helping and how we're helping them. So how do we do this? How do we put it into practice? Well, DevOps has an acronym which is CAMS, which stands for Collaboration, Automation, Measurement, and Sharing. And it's a set of kind of high level practice areas to think about when you are implementing DevOps. The problem with it is particularly collaboration is kind of vague and it sort of throws us back to where we started at the beginning of, well, how do we collaborate? How do we organize to do this? It's this old, what is this silo breaking thing? So we haven't really made any progress. And in our work with practical sort of day two DevOps tuning and repair, if you will, we've developed our own acronym at Susano Associates, which is CHARC. And it's really about a set of principles for understanding how to organize yourself and how to interact with your surroundings. If you're going to be a mutual service provider, how do you actually do that? So the first principle is making the customer your compass, which means aligning your team with your customers' goals, going back to this idea of promises, and centering your work around what they need, not what you built. So if you're AWS, what they need is high availability memcache without a lot of manual work on their part. What they need is not a set of VMs and a set of templates. And the critical thing here is that this principle leads us to organize ourselves for end-to-end service as opposed to feature delivery, so that we think about some coherent set of promises, some coherent value that we can offer, and think about everything that's needed in order to build and test and document and support it altogether. So imagine as an example a data warehousing team inside of an enterprise that is siloed along functional lines. So you have a business analysis team, you have a development team, you have a test team, you have a documentation team, you have an operations team, and there are handoffs and delays and misunderstandings and bugs every step of the way. And then what you do is you realize that there are some coherent sets of data and some coherent different customer bases for that information. And so you organize around those almost like products. One way to think about all of this is that it's kind of everything as a product. So you take all of the pieces of the puzzle, the business analysis, the development test, the documentation, the ops, and you put that in one cross-functional team around that product area, and you have them all in stand-ups together every day. And what happens is that friction and delay and errors starts to melt away because people talk to each other. As another example, one that is very deep in the legacy world, which supposedly is not really the domain of DevOps, is electronic medical record systems. They tend to be large, complicated, very old architectures, proprietary databases, very specialized hardware requirements. It's not the kind of thing that you can easily port to Docker containers. And this is an area where it makes a lot of sense. You have sufficient complexity and sufficient specialized needs that it makes a lot of sense to have all of the low-level and high-level expertise you need together in one team, so that you have networking and database and hardware and storage and application software all working together, deploying together, debugging, dealing with outages together. Again, when you do that, you start to melt away this friction and delay and waste that tends to plague functionally organized teams. The second principle is to see the horizon, which means focusing your work on fulfilling your promises, so that what you're delivering is value, not just work. I see a lot of agile teams that have this kind of heads down tunnel vision approach, is I'm working on this user story, I'm working on this user story, and there isn't any understanding of, well, what are we actually delivering? Who cares? You know, maybe we are on our way towards continuous delivery, but delivering why? What's the actual benefit and does everybody understand that benefit? And we can use that principle to improve the way we do classic agile ceremonies. And I've done this both with development teams and infrastructure teams. I see too many stand-ups where everybody goes around and says, this is what I'm working on today. Well, on the one hand, that's nice to know, but on the other hand, the what? It's more interesting to talk about what promise are we fulfilling today? What value are we delivering to our customers today or not delivering that we have to adapt to? In retros, I like to talk about something I call the not enough muffins effect, where you have a team and there's a tradition that somebody brings in muffins for the whole team every Monday morning, a problem that there are never enough muffins. So you have your retro and you talk about what didn't go well and somebody says, well, we still don't have enough muffins. You should bring in twice as many as you think you'll need. Now, on the one hand, that's a good problem to solve, right? It's good for everybody to get muffins on Monday morning, but it doesn't really have anything to do with how effectively your agile process is working. And it's more interesting and more useful to ask questions about how well did we deliver on our promises? How do we improve them? How do we repair them? Are we making promises that we shouldn't because we have no hope of fulfilling them? And then when you look at things like planning and sprint goals, instead of saying, well, our sprint goal is we're going to do five stories that add database indexes. No, your sprint goal is to make search 15% faster. And it's funny, one of the things I watch a lot is friction between agile teams and DevOps teams and executives and leadership teams. And the executives are always saying, well, this is great. You did 15 stories, but so what? What's the benefit to the business? And you should be able to say everyone should understand the benefit to the business. And when I work with engineers and I ask them, what are you promising to deliver? They say, well, I'm promising to deliver this Kubernetes port. And one of the things I'll say sometimes is, well, if the CEO walked over to your desk and said, why am I paying you to do this work? Typically, there's a really good answer. Well, it's going to make it much easier for engineers to test their changes quickly and easily against the whole application. Well, that's great, but we need to learn to talk in those terms. The next principle is applying small frequent inputs. I often joke that I should offer a fixed fee consulting service where all I do is I walk around your organization and I say one sentence over and over and over again. Which is make your work smaller, make your work smaller, make your work smaller. It's amazing how flow and quality start to improve, simply when you start thinking in terms of what's the smallest next piece of value I can deliver. And it's ironic because engineers deal in decomposing problems. That's what code is, right? You want to accomplish something, you have to break it down into its algorithmic steps. But they seem to have a really hard time thinking about that, about their own work. I had an experience with a storage team that I was coaching. And I was helping them make their user stories smaller. And one engineer said to me, well, I can't do that. My task is we're changing backup software. So I have to decommission the old software and install the new software on 200 servers. I can't break that down. And I said, okay, what are you doing today? And he said, well, I'm doing the first 10 servers. Boom, there you go. And why is that valuable? Because either he comes back at the end of the day and says, I did the first 10 servers and you know everything is on track and everything is going well. Or he says, well, I only got five servers done. I got stuck with this problem. And someone else on the team says, oh, I know how to fix that. I'll help you after the stand up and we'll get back on track. Or he says, well, I only got five servers done. It turns out that this is harder and slower than I thought. We're only going to be able to do five servers a day, not 10. In which case you know that you have to adapt your plan. Maybe you need to deprioritize something else or allocate more resources. The point is that you are able to make decisions about your work more frequently. It means doing lean optimization of always looking for ways to bring excess work in progress and handoffs and toil out of it. Again, if you go back to that data warehousing example, it was as simple as getting the right people in a room together every day that waste started to disappear. And one of the challenges I see that particularly operational groups struggle with one of the things about lean optimization is shifting unplanned to planned work. And they say, well, we can we can never get out from under our unplanned work. We're always having these things come in that's the nature of being in operations. How are we supposed to become more agile or more strategic or more proactive when we're constantly being bombarded with things? And what I teach them is a way of slowly digging their way out. How can you spend 20 minutes today that will give you 40 minutes back of free time? And next week you can invest that 40 minutes to get yourself 80 minutes back and you sort of slowly dig out from under the dirt. A database group as an example, which was they were trying to automate database provisioning, but they were constantly being interrupted by user questions. And they realized that part of the reason for that was that there was confusion about how to use their services. And if they took a couple of hours to write some better documentation, instead of being interrupted, they could just refer people to the documentation and get themselves back between the whole team several hours a week, which they could then start to invest in more strategic things. The fourth principle is to respond to your surroundings, which means making feedback the heart of your process. One of the misunderstandings we have with agile and DevOps and things like continuous delivery is that the purpose is to deliver things, right? Working code is the measure of progress. But really in an adaptive organization that's continuously evolving, the most important thing is not what you're delivering now. It's figuring out where you want to go next. And part of the point of continuous delivery is it allows you to make that decision more frequently and more continuously. So what you want to do is on the one hand you want to maximize your own visibility into, we did this thing. Did it work? Did it fulfill the promise? Did it help us deliver the value that we wanted to deliver or not? And based on how people are using it and based on its effect, where do we want to go next? But the more interesting bit is when you start enhancing visibility for others. I worked with a team where I asked the product owners to start going to the weekly operations meetings. And they stopped going because they were bored out of their minds. And the reason was that the operations meetings were talking about, well, this server crashed and this is why it crashed. And the PO said to me, this is really a irrelevant dose. And then I sat down with them and I showed them a Splunk graph. They had these nice dashboards on monitors up on the walls around the building that showed Splunk graphs. And I said, you see this graph? What it means is that this morning from 10 to 11, on average, it took 15 seconds to load the login page. And the POs went, ooh, that's really bad. And this other graph, this shows that between 9 and 10 this morning, 10% of the page responses were 500 hours. And they went, ooh, that's really bad. And this was suddenly they understood something technical in terms of its impact on the business and the customer experience. And the manager of the PO group said something to me in response. That was one of those moments where you go, okay, I've actually added some value here. I can feel good about myself. She said, well, maybe we should go to these weekly meetings and maybe we should be the ones reporting on these graphs. So where you really start providing mutual service inside an organization is when you start giving other teams visibility into what you're doing that allows them to do what they need to do better. Now, one of the funny things about feedback is it's really hard. And I think these sort of agile feature factories and continuous delivery factories tend to get us into a trap where we're so focused on delivering the next thing that we forget to actually ask ourselves, well, how did that thing work? I did a workshop in Germany a few years ago for an organization that actually had a very sophisticated agile and DevOps practice. And going in I was unsure as to how much was actually going to be able to help them. And during the morning I asked them to do an exercise which was to take one of their linear processes and reimagine it as a circular feedback driven process. And they all kind of smiled and nodded and winked and one of them raised his hand and said, well, we don't really have any linear processes anymore. We've made them all feedback driven. I said, okay, well, indulge me, let's go ahead and do the exercise. It may be very brief and then we can go on with the rest of the day. And I'd broken them into four teams. And at the end of the exercise, three of the four teams independently came to the same conclusion which they very sheepishly reported to me. They realized that they were really good at collecting feedback and then they didn't do anything with it. They didn't actually change based on what they heard back from their customers or their infrastructure or whatever the case may be. And they realized that they were wasting a tremendous amount of time, energy and money gathering all of this information but not using it. So the final principle is that when you put these four practices into play, they give you the ability to turn with confidence so that your process becomes a matter of asking, well, are we still headed where we want to go? Are we fulfilling our promises effectively or do we need to adapt in order to achieve our aims? And do we still want to go there? And what this allows you to do is to start to pass the puck where your customers are skating. Sorry about that. I'm using my iPhone as my webcam and I thought I had do not disturb turned on but somebody is trying to make a spam call to my phone. So if there was an interruption there for a moment, I apologize. Anyway, talk about responding to change in interruptions. So what this allows you to do is to start to flip the equation. Many organizations, they do agile and they do DevOps and they feel kind of overwhelmed because suddenly they feel like they don't have any excuse to not do exactly what the customer demanded exactly when they demanded it. Pressure from executives and pressure from sales and pressure from product. But what this is about is starting to get out in front and starting to continuously understand what is it that your customers need next? What are they struggling to accomplish? And how can we actually point them to what they want next so that we're ahead of it? And this is the thing that allows you to really achieve this idea of amplifying continuous customer center delivery and allows your internal teams to start to become or to live up to the inspiration that DevOps got from the public cloud and that led it to make that assumption that we've been sort of deconstructing as we go. So to finish up, if we go all the way back and we asked ourselves one more time, what do we really mean? What does it really take to break down silos in a software delivery organization? And I think what we could say is that it's about helping each other create more value in order to help customers create more value. So on that note, I will hand it back to Diane and thank you very much. Well, thank you very much for that, Jeff. It always your talks are what I would call incredibly pragmatic and practical. You take things and you distill it down into really nice chunks. I was joking offline that you kind of in some ways you're like the Tim Ferriss of DevOps. You turn things into chunks that we can actually do and make happen. So really, thank you for that. I hadn't seen the chart acronym explained. And that was very, very helpful. They have a couple of other folks on the call. Jabe is from the GTO office and I'm just trying to unmute them while you give me a second. And if folks have questions and Jabe and John, questions for Jeff, please go ahead. But I think one of the things that I really loved about this, it was the R part of the chart was responding to your surroundings. Because a lot of what we're doing at from the OpenShift community stuff and the things we do at Red Hat is really about taking in all of this feedback, massive amounts of it from, you know, thousands of customers and trying to distill it into where is the innovation going. So I wonder if you could talk a little bit too, when you have overwhelming amounts of input from customers, distilling some of that down how you would coach people for that. Well, one piece of advice, I don't remember who said this. And I, it's one of those things where I wish I had bookmarked it at the time. But there was a company, software company that published an article where they said that when your customers ask for something, you should forget it. And what, and then when you read the article, what they really mean is you should write it down and then just leave it. Because if it's actually important and valuable, they'll ask for it again. So there's a certain amount of just kind of filtering signal from noise. But beyond that, the other piece of advice is this is where I get to give my pitch for involving design. One of the things I like about the promise-based approach is it's truly customer-centered and it gets you thinking about what are your users trying to accomplish. And understanding that and coming up with solutions to that is really what design and design research are all about. And when you do that, when you set, you know, AWS just didn't, I'm assuming, didn't just sit back and wait for somebody to call up and say, hey, we're struggling with Memcache. Can you build us a high availability Memcache service? Is they were actually proactively going out and looking at, let's forget about what our customers are asking us for. What are they struggling with that they haven't thought to ask for yet? Yeah, I would bet that there was a ton of questions about Memcache and configuring it in their support lines as well too. So there was a lot of fodder for that conversation. Right. But the thing that I find really fascinating and we used to have this conversation about AWS and now we have it about all the public clouds because they've all really figured it out. Is this continuous innovation is I like to use a phrase which is overwhelming your customers with goodness. Which is when you start to use continuous delivery, not just to satisfy the demand but almost to create the demand. And again, this is where research is really important because research gives you insight before the customer asks. Right. What is the customer likely to ask for next week, next month, next year? And how can we give it to them before they have time to complain because we don't have it? And that's the holy grail. Yep. Absolutely. Yeah. So there's one quick question that came in from the audience. And it's about the smaller work, make smaller work comment that you have the mantra, which I think is, I think that's what triggered the Tim Ferriss idea. And it's like, yeah, I've heard this before. So he's asking, does it always require a consultant to make smaller work? How does one do constantly over-simplifying and putting too much in a sprint? And since this is planning season at Red Hat, boy, can I commiserate with that story? It doesn't always take a consultant to make work smaller. It takes a, the reason that consultants like me help is that it does take a switch in how you think about your work. What we're used to is building big things. And the Agile folks back in the 80s and 90s figured out that trying to build big things and big chunks doesn't work very well. You know, Agile was actually, it was a very pragmatic solution to a really serious problem. Which was you had these IT projects that were going on for five or ten years and costing tens of millions of dollars. And when they were delivered, they didn't work and they didn't actually meet the need. And so Agile was a response to that of, well, how do we validate whether it works and whether it's the right thing much more incrementally? The problem is that we tend to get stuck in this idea of incrementalism. Which is, I want to build a big thing. How can I break it down into smaller pieces? But we live in a new world where you can't know for sure that you even want to build the big thing. Today you think you want to build the big thing. And when you look at things like Lean UX, what they're really about is let's make sure that we want to keep building the big thing. And the best way to do that is to build a little thing that leads you in the direction of the big thing. And then to use that little thing to say, well, we still want to keep going there. One of the things that I do with clients is I actually use a visual charting technique that allows them to lay out the promises that they are and the promises that they could or should make and think about how they want to evolve them in an iterative fashion. So instead of saying, we're going to build this new, and I like to use Slack as an example because everybody knows Slack. Instead of saying, well, we want to build this new feature in Slack to do it in terms of, well, we want to make this capability better. And what's the next small thing we can do that makes it a little better? And then how can we use that as feedback to go, well, where do we go next? So there's this important difference between incremental and iterative. And that's a very long-winded way of saying that making your work smaller isn't just about building a thing in smaller pieces. It's really about building smaller things. And delivering...  Eric, that's what's ringing in my head right now when you say iterative, like get something out there and see it. Is that what you're exposing here? Sort of. So the reason I'm laughing, and I'm guessing that Jaybe is probably defying on mute in the background. I like to refer to MVP as the worst-named good idea ever. Because if you read the Lean startup book, the purpose of an MVP is not to create a viable product. Right. It's to create the simplest possible test of whether what you think you should do next is viable or not. And actually, the sort of poster child for MVP from that book is the story of Dropbox. When they were first getting started, they didn't even know if they could get money to start a company. So the first thing they did was they created a video that showed how their interface might look. They made no attempt to make it realistic. The only point was to explain how is this different? So there was no code. There was none of this, well, we'll write a front end and collect people's money before we build the back end. They didn't write anything. It was simply how can we ask the question of is this viable from a funding perspective? So there's huge amount of confusion, in my opinion, about what MVPs are. And there's a difference between what we would call an MVP and actually delivering a viable piece of value. Delivering a piece of value, it has to work. It has to be useful. It has to be usable. And it has to be dependable. So maybe instead of viable, we should be just saying valuable, minimal valuable. But I think that's actually what you just said is actually the confusion. A lot of people, because of the nature of the book, Lean Startup and the context that it's in where you are in an entrepreneurial situation, people hear viable as just find the valuable thing. But I think in fact, viability has much more to do with things like operational burden, the ability to upgrade. All those things are whether or not finding something valuable and something viable is a different problem to me. So in contemporary language that a lot of people are throwing around right now, there's outputs of a system. Then there's outcomes. Part of the conversation of value is saying the outputs aren't valuable. The outcome is valuable. That's the first shift. The second shift is to say, is it impactful? And impact often means, hey, you could create those outputs and create those outcomes once. But can you create them over and over and over again in a sustained way that actually means that you have created an impact at a particular scale, a particular size. That's that whole argument about viability, sustainability, the longevity, the holding power of being able to reproduce the power and the value. That is viability to me. Hey, Jay. I think it's John. Hey, Jeff has a call man. Long time no see. Hey, how are you? Good. You know, I think this to me, there's nothing wrong with the V in MVP.  Right. Like, you know, and so it isn't that it is, it is viable. The problem is we don't do the classic, you know, me, I'm going to bring Deming into the story, but we don't do the PDCA. We do the PD, the PD, the PD, PD, and we don't follow the scientific, you know, a lot of stuff you think about, too. The word I always struggle to pronounce, but epistemology, right? Like we don't sort of apply that process so that the problem is these large organizations now who've seeded this idea of lean startup. They're just got train wrecks of MVPs all over the place because they're on these sort of tight budgets and get it up as quick as possible. Let's use lean startup. And then like you just have this minefield of things that were just never built in a continuous motion and primarily we're not using sort of the continuous experimentation. Yeah, I think I'll just throw in one more thing just because you know, you and I like love talking about Deming so much, right? One of the things about Deming's loop is that it's an extension of the Schubert cycle, which Schubert came up with, right? And Schubert basically had this observation. He said, like, we keep on doing this thing, kind of design production operation in a row, these three things in a row in a straight line. What if we make it into a circle, right? What if we actually hook the system back together again? And that's interesting. And then, you know, Schubert becomes Deming cycle where he adds like a moment of reflection and things like that. All also very interesting. The most interesting thing since we have Jeff on the phone here is that Schubert came up with the Schubert cycle 10 years before cybernetics became a thing. Yeah. You just couldn't leave it alone. Could you, Jay? The feedback that we describe in cybernetics, I'm not arguing that it comes from Schubert, but the language that we apply and overlay on top of Schubert and Deming, the cybernetics language sometimes, I think hides some of the original thinking around why it was a cycle, why it was a scientific cycle, what we were trying to get done with it. And the only last thing I'll say about it is that I also think it's fascinating that Schubert came up with the cycle inside of a telephone factory, which were one of the first high production factories that created a network device so that quality had something to do with the way in which these devices were deployed into a network. And that's why quality and that loop becomes such an important part of what they're trying to do at the Hawthorne factory. Anyway, that's me randomly ranting about other things. So to bring this back a little bit down to earth, I think what we're all violently agreeing about here is that the ultimate purpose of Agilent DevOps is not to deliver more stuff faster, it's to learn more continuously. And the way that you stay quote unquote ahead of your customer in a highly dynamic environment is by constantly learning. And if you don't have that loop back of we did a thing, well, was the thing actually good or not? Do we want to do more of the same thing or do we want to do something different so that, you know, you have this backlog. Don't assume that the thing that's in the middle of your backlog should still be in the middle of your backlog.  There are really interesting organizations that don't work from backlogs. They just say, I mean, I've seen teams where they do mob programming, the entire team builds one useful usable and dependable thing. And they release it and they say, OK, what should we build next? And they don't really care where a thing was on the backlog. They're just saying, OK, based on what we did last, what should we do next? And the point of Agilent DevOps is it allows you to do that much more fluidly. And it allows you to do it for your customers. And in a large complex organization, you need to take exactly the same approach to doing it for your internal customers. And that's the key, right? You break out of the prescription and you break out of the fear, right? Like, I think that the reason I love PDCA or just scientific thinking in general is everything's an experiment. So you just get rid of the whole concept of fear of doing something. Should we do this? Or do you have enough experience to do this?  No, no, I'm just going to do an experiment and the truth will bear out, right? And so both that sort of decimates the whole sort of fear of failure and then it also allows us to sort of bust prescription. Like, we did it last time. We've always done it this way, right? So to me, that sort of scientific thinking is that sort of get out of jail free card to start to change that continuous improvement. I mean, Jeff, laugh. Hey, Bangs. There's a question in the chat that I think is related to this. The question is, how do we push back against POs that constantly oversimplify and put too many things into each sprint? I have an idea. Do you have a thought on that, Jeff? I'll let you go first. So my thought connecting these two things together is that if you start sprints with the idea that you're going to learn something at the end of the sprint or during the sprint, you would always build capacity in for processing and understanding what that learning was and the implications of it. So I think actually a lot of product owners who kind of overstuffed the sprints are focused on the outputs and not understanding actually what the output is. The output, by the way, I do agree that it's important to learn. But I think the actual activity is balancing the production of value in the form of some saleable high value good and learning. And it's the balance of those two things that goes wonky. To me, if you over focus just on learning, you get also bad effects.  So it's a balance between the two. You need to learn a little bit. You need to produce a little bit. You need to go back and forth. You need to know when to tic-tac between those two different forms of value, information and value-added goods. So the way that I resolve that tension and I think you're absolutely right. And this is where the designers tend to get on my shoulders a little bit is one of the best ways to learn is from people using your software. You can't learn everything. I need my t-shirt that says I don't always test my code, but when I do, I test it in production, right? Is there certain things you can only learn in the real world?  And this is where I come back to iterative versus incremental is what you're continuously delivering has to be software that they can use and software that you can support. And by making it small and making not just the increments of work, but the increments of value small, you allow yourself to do that. I think the thing I'd add there really quickly because I agree to kind of like testing use and stuff like that is that I actually like when I think about architecture, when I think about designing software or design systems, I actually think there's two types of risk and two moments of risk. There is the risk that we designed incorrectly and then there is the risk that's exposed by in use. Is it being used incorrectly or did it not do what we wanted it to do? And there's actually two different ways to recover from that. And I think a lot of people get obsessed with the we designed it wrong theory of risk, like we didn't design it completely. And there's a loop there that says like, we should spend more time designing more detail design, blah, blah, blah. And that can cause really bad problems, right? But there is this weird way of like filtering what goes into what should be designed well or should be focused on eliminating the risk in design as opposed to the risk in use. And the risk in design is if we know that this thing needs to support the traffic for like, I don't know, 20,000 users, there's probably some design like math that we could do to make sure that whatever we design can sustain that. I usually say it's like designing a bridge. If someone says I need a bridge and there's going to be 15 ton trucks driving across it, there are social criteria that we can talk about things that like, will the bridge be used to drive the right types of things will improve the connection between the two towns. Will people like the bridge will be pretty all like all sorts of in use questions. Yeah. But there's also like just straight math of this is the minimal structure that will be required to ensure that a 15 ton truck won't cause the bridge to collapse. And so like balancing those two, like the quantified and foreseeable parts of architectures and design engineering. And then there's the, okay, there's some stuff we can't know until someone tries to actually use the thing and try to weed the difference between those twos is I think a really important thing to notice. But that again, that's just me ranting. Well, thank you for the, thank you for that. So we do have to close at the end of the hour, just to respect Jeff's time. And I, you know, I also wanted to say to Jeff, thank you very much for coming because I think the chart and I love the reference to pass the puck to where your customers are skating. I think you're helping us see where we're to look and how to look. And I think that was very, very, very helpful for today. Jeff, if you want to have the last word in here and then. Yeah, I'll just say, thanks everyone. It was, it was great to see you all again, virtually. And thanks for having me. And if folks want to talk to me more, you can find me at susna dash associates.com where I'm on Twitter and LinkedIn at Jeff Susna. And Susna is spelled s USS and a. All right, and we'll put the link to that, that book that's on the background there. And, and it's a great read as well. So designing deliveries. Awesome. So, thanks again, Jeff. I think we're going to definitely have to do another follow up on this because I feel a debate coming on. So well played. Thank you all. All right, so long. Excellent. Bye.


The natural oil and gas supplies our cessation of Nigeria. Nogasa has urged the Nigerian government to fix bad roads and encourage private and modular refineries to foster the affordability of petroleum products in the country. Benets Korey, the Nogasa president, disclosed these at a press briefing in Abuja. Does a need in Nigeria deploy what it calls serious? Let me use this example. We have engineers, good engineers, qualified engineers. Get them together. Let them go to these refineries. For how many years now we've been talking about refineries, refineries. Let them go there and check. These women have been abused as refineries and we have these people in Nigerians. They are all Nigerians. We have them. They can go there and fix it. There's nothing wrong. Show them the problem. Even though we know it's old, they can fix it. I believe Nigerians engineers can fix it. We have machines in Nigeria that can assist them to get local listening and fix that place. It's all about depending on foreigners. Every time, billions of Nairas spend, billions for how many years now on why refineries. Look at what it's doing to us today. Yes, we removed subsidy before that refinery. This is the problem we are facing today because of that refineries nowadays. If it's there, at least it will assist us. What do we study with 100 million Naira? You'll buy 1 million liters of fuel of PMS in a month to sell. Now with 100 million Naira, you can only buy 150 or 120. And you do the same expenses when you are spending 100 million Naira. The same expenses.


Live from Las Vegas, it's theCUBE. Cover EMC World 2016, brought to you by EMC. Now your host, Brian Graceley. Welcome back to theCUBE. We're here in Las Vegas, 10,000 people, a lot of energy around EMC World. Yesterday during the keynote, David Goulden said, look, there really is evolving to be two types of applications in this world. There's traditional applications and there's cloud native applications. And so today, right now, we're really excited to talk to you, James Waters, Senior Vice President of Product at Pivotal. Drew Dimick, Product Management for the new native hybrid cloud here at EMC. Gentlemen, welcome to the show. Great to be here, Brian. Good to see you. Good to be here, Brian. So Drew, I'll start with you. Big announcement this week around native hybrid cloud. Give us the basics. What is it and what's it going to mean for customers? Well, so native hybrid cloud starts with the very simple premise where we wanted to take the best Cloud Foundry implementation on the market with Pivotal Cloud Foundry and be able to take it to customers in a package format on top of reconfigured, hyper-converged infrastructure, which would allow them to implement and utilize the Pivotal Cloud Foundry environment in a very short amount of time. So we looked at the market and saw that there was a huge disparity between folks trying to use Cloud Foundry and then actually being able to use it of anywhere between four weeks to eight months to do the full implementation of their underlying infrastructure to support the Cloud Foundry environment in a way that's required. And so we said, what if we did this and we're able to deliver that in a day? Yeah, so this is all about kind of dealing with the mismatch of like, maybe it took a while to get running and but I can code really fast with Pivotal Cloud Foundry. How do I find a better balance of that? Exactly, exactly. And it came down to the reality in the market that if you couldn't get the platform up as quickly as the developers were expecting, they ended up going somewhere else and that's something that not every enterprise wanted to do. So we said, hey, if we are able to execute this vision, we'll be able to go into the market with something that's much more acceptable for on-premises consumption of Cloud Foundry. James, what's the latest on Pivotal Cloud Foundry? I mean, about every day I'll follow one of your tweets. You'll say, I was at Fortune 500 company here, so-and-so's running out, cool, thanks. What's going on with Pivotal Cloud Foundry? It's going really big. I mean, I think I flew out here with Bill Cook, our president, and it was kind of a buckle-up conversation. We're in a bunch of conversations right now where accounts that started off for us very successfully are now coming back and saying, what if everything that we had as software ran on this platform? Wow. And that's a really exciting time because you're never quite sure when that moment's going to come. Right. And I think one of the things that's happening is people are seeing, you know, the first draw is, as Drew said, like the developer engagement, you know, on Cloud Foundry's unbelievable compared to traditional kind of enterprise IT if you could just bucket things that way. Right. You know, kind of tickets and workflows like that. Great developer, you know, experience. But what they also find about cloud-native apps is it's a whole new operating model. As I said in the intro video to launching the native hybrid cloud solution with EMC, we have operators that, you know, one or two people are running 2,000 applications in a quarter of their time because the nature of cloud-native applications is that a lot of the resiliency is built into the pattern as opposed to the intervention. And that operating model is catching fire. And I think that's what's so exciting because it's not a fringe behavior, like a lot of companies had a mobile development team. For instance, it might have been 12 developers working as modern practices off on the side, but the core never changed. And what's happening is that cloud-native applications are actually starting to become the core of a lot of Fortune 200, 300 companies because of the operational model so much better as well. Yeah. So you can't go to an event these days of meetup that something like Tesla's not talked about. And people sometimes get a little bit cynical and they go, well, this new stuff is only going to work if you're starting from scratch, it's green field. You just tweeted out the other day about Ford Motor, you know, putting this into new vehicles. Like, give us a sense of like, what's going on with existing businesses? How is Pivotal Cloud Foundry working in that world? We have an incredible partnership with my friend Marci, who's the CIO of Ford, and Mark Fields, the CEO. We work together on an incredible project called FordPass. And Ford is at a moment in time where they're evolving from being a pure car company to being a mobility company. And FordPass is the expression of both a connected car as well as just connected experience with their end users to say, hey, can I help you find parking? Can I recommend other things that you might need as part of your transportation experience as part of the relationship with Ford? And they're using Cloud Foundry, Spring, and Pivotal Labs as the foundation for all of that. And what's really cool is that we're winning both the exciting new apps like FordPass, and then they're looking at it and they're saying, why isn't our data center cloud native? Why don't we get all these exciting attributes and what we do? And that's kind of the ones you punch a Pivotal right now. That's why I'm so excited about the native hybrid cloud announcement because then you say, okay, let's go make the whole data center run this way. And now we've got a bolt-in solution to just turn it on with less decisions to make. Yeah, and I think I've seen you use the term sort of value line, right? Where do you spend time? Where do you not? You've been using a term mean time to cloud, like put those in context for me. What are you guys trying to get across in that in terms of what's there for the customer versus spending time, you know, undifferentiated heavy lifting, if you will. Yeah. You want to take that or you want to? No, go ahead. So with the mean time to code is really how I look at it, but it's the, and it's really analogous with the value line that James has, which is you have a finite amount of technical resources within any enterprise. You don't want to spend any of those technical resources on non-differentiating efforts. And a lot of that is the plumbing and putting together of infrastructure is not really a value that's going to help a company differentiate their offering, their solutions, whether it be Ford or any other of the big enterprises out there to make themselves different than any of their competitors. You're not going to do that by building a better server hyper-converged environment with a network underneath it. You're going to do that by building more engaging applications, more engaging customer interactions with those applications. And that's where we want our customers collectively with Thivotal and EMC to focus, and we will take care of the underlying infrastructure pain and engineering and performance optimization that the customers need to have done to be able to be successful.  Can you talk, the solution was just announced in terms of being available. Any customer stories yet that you can talk about or customers' excitement around this? Well, we've done a number of beta tests, some in the transportation sector, others in manufacturing. They have engaged with this and actually realized the value of what we're delivering. So, for example, what they saw in a project plan doing all of the assembly of this themselves, including all the underlying IaaS and hypervisor configurations and all that, was taking anywhere between four weeks to eight months to get them to get that to production quality. We are able to come in with Native Hybrid Cloud and Pivotal Cloud Foundry on top of it to deliver this within four days and several of our beta sites as we optimize this. So, it was, one particular implementation took two days. This is from the network port all the way up to a CF login where a developer can push code. And that whole implementation is fault tolerant. It has all the backup and restore procedures built into it with all of the backing services that are offered by Pivotal and its marketplace. Right, right. You know, one of the things to me, having sort of lived through the VCE things and people want to talk about converged infrastructure, the amount of sort of intellectual property in terms of how to make a solution work that's come up through what Chad's building to now being able to deliver software, because it's complicated software. I mean, you know this James, you're in San Francisco, finding Pivotal engineers or Cloud Foundry engineers is challenging. It's a hot commodity, it's super high value, but it's not simple. The fact that you guys are turning it into a factory process in essence is really, really powerful. Talk a little bit, you know, you've had a lot of announcements recently. David talked about Virtua Streams now going to support Pivotal Cloud Foundry. Couple weeks ago, Microsoft was talking about it at Bill. What's the spread of Cloud Foundry just as a whole? So people have a sense of, you know, how big is it getting? How big is it getting? Yeah, I'd say, you know, Pivotal Cloud Foundry is doing incredibly well on let's say the Fortune 1000. So, you know, it's almost as quickly as we can get to these companies that were starting to get major, major traction at all the, especially in the Fortune 500. And I think the reason is that they have large amounts of human capital deployed in IT. And they want to get to that value line because as Drew said exactly, you know, that technical talent is so scarce. And so we have a very simple argument with them which is that you can have your smartest people figure out how to configure operating systems. We can have them shipping code. Like what's going to drive your business. And that's just actually just such an easy conversation to have. Like it's not a fight, it's not a mud wrestle. It is just, you talk to Sierra, say how many people are working above your value line? How many people are working below it? Our job as the Federation or family of companies is to get you to that value line the whole way from hardware, hypervisor, to cloud platform and framework as fast as possible. And so the number of companies that are headed that way and then what happens is the CIOs all talk. And so, you know, Marcy's very supportive from Ford and suddenly her 10 closest CIO friends all call us. And that's essentially the way that we're spreading because it's just a better way of organizing your human capital. Yeah, yeah. One of the big buzzwords about Errung's developers these days is Docker. People talk about containers. You know, one of the big misperception I think is about containers is you're seeing this huge interest in how to package a new application, a microservice. And then you go, now what do I do? Give me a sense from either one of you because you both follow that space. Like, give people a sense of how, the beauty of containers is the idea that it runs the same on my laptop as it hopefully does in production. But what does that mean? I'll go real quick just because I have opinions there. Yeah. There's kind of two ways of looking at containers. One is you can take an approach where let's just take your legacy and try to put it in a container to say, hey, I did something new. I think that's a failed approach because what you've done is you've bundled all of the complexity that you had before and just a new process management system. That's it. Maybe you save a little overhead versus a hypervisor, but I'm telling you ESX these days is really lean. So you score a fool's goal there, I think. The other way of looking at it is like, hey, this microservices approach is actually fundamentally about how your team is organized, how your code is organized, how you do fault tolerant service discovery, distributed configuration in your code. Let's go get that right. And that's where we have assets like Spring Boot and Spring Cloud that are also used by Netflix that really get you to that code level of microservices. So where we see people really being successful is a code level change to microservices. Things like Cloud Foundry do use containers to implement them then, but fundamentally just grabbing a container and putting some legacy code in it doesn't give you the benefits of Netflix's operating model.  And I think it's interesting, it's curiosity, it's discovery for people to do that, and that's great, love the experimentation. But I would say that Pivotal Cloud Foundry has the most revenue of any container-based system on the market, and it's not because we say container all day, it's actually because we focus on microservices and code to let us get to value. The how-to make it happen, not the numbers. That's right, it's almost just like selling containers for their own sake is interesting for a period of time. But who's running around talking about hypervisors these days? Right, right. So Drew, I'm going to give you the last word. What's native hypercloud going to mean to people who maybe came to EMC World, they said, look, I see David and Jeremy and Joe and everybody talking about sort of modernizing their business, what is, what is neighborhood hypercloud going to mean to them? How are they going to get value out of it? Well, come back to the value line assessment. And so what we are able to do with our value here is to be able to get our customers, EMC and Pivotal's customers to focus above the value line. And we come in with the solution that allows them to get their, essentially we're de-risking their journey to cloud native applications by standardizing on a repeatable and durable fabric that Pivotal Cloud Foundry can operate on and taking care of all the day two operations tasks that they have to do with all the pre-engineering that we've done on the platform itself. So I think if they get that as the message that this is about speed to getting to cloud native de-risking their journey there so that they can really focus on the real challenge which is the cultural change, the application changes that need to be made to make your applications cloud native have your teams work in cloud native cultures. Those are the things that we want our customers to be able to focus on and not the kind of bits and bytes of how the thing gets assembled. Yeah, so we've got native hypercloud making the underlying pieces, the operations, the ongoing, you guys are taking on that heavy lifting spring brute Pivotal Cloud Foundry taking care of that heavy lifting go focus on being creative, go focus on solving business problems. Guys, great, James, Drew, thank you very much for being here. We'll be right back with more on theCUBE live from Las Vegas here at EMC World 2015, 2016.


I'm Mel Choice. I'm a design engineer at Automatic. And as so nicely said, I'm Courtney O'Callaghan, the chief digital officer at the Freer and Sackler Galleries, which are the Smithsonian's Asian Art Museums. So here's a little history about the Freer and Sackler online, which happened long, long before I arrived. They embarked upon their web journey in the mid-2000s. We would add about 300 objects every month to our website in a section we called Collections Online. These images were usually about 300 pixels on the longest side and were not always the best images. So at the end of 2013, when I was hired into the new position of chief digital officer, I was tasked with digitizing our entire collection. This meant that we would have images of every single object within our museum, both the display objects and every single item in our storage. We would then put these images up online in standard resolution. But we decided that digitizing and revealing our collection on the website wasn't really enough. We wanted to democratize our collection and democratize art by increasing the access our visitors had with the object information. So in January 2015, we released our collection of over 41,000 objects. But we released each of these objects with as much information as we were allowed to put from our curatorial database. We also put a link to download the highest resolution of these files that we had for each object. We opened these images up as free for non-commercial use, which was the most liberal copyright that the Smithsonian would allow us to use. This led us to really look at the rest of our website, asia.si.edu, and not just our collections online. Our site was not responsive. The updates were time-consuming and difficult. Organic growth of the site over the past 15 years had created a very, very disorganized information architecture. The website also needed a visual refresh to reflect the more modern, clean design that was the aesthetic of our actual museum. So we needed to choose a content management system. We wanted one that challenged the idea that content was separate from our collection. Due to technical constraints, most museums have ended up having two separate systems for their museum information and their collections. Though they may look the same, they are often very separate databases, sites, all together. We wanted to link together both our collection and our museum content so that we could take advantage of cross-linking and forging organic pathways so that people could search on China and get everything that we had written or created about China. Or if someone searched on elephants, they would get our exhibitions on elephants, the papers on elephants, and the elephants within our art itself. So when I came in, I was told that the biggest issue we had was that we didn't have a CMS. But a CMS is a solution to a problem that they had yet to define. The museum was planning on using Drupal. I wasn't against this choice, but I wanted to know the reasons why and how they had actually come to this decision. What we really needed to do was take a step back and define our actual needs. So looking at everything, we did have problems. We couldn't update, maintainability, lack of organization, everything that we mentioned earlier. And we needed a solution. Everybody had a list of what they had heard a CMS could do, from organizing our content to watering our plants. After we gathered everybody's needs, we had to pare down what we actually needed versus what we thought we wanted, which brought us to usability. Our problem was the siloing of our content that summed it up in three words. We couldn't update or add new content easily. We couldn't update our site structure easily. We couldn't connect our content in intelligent ways easily. There was no room for easy growth. The website was one big bottleneck. So it came down to these following questions. Is it easy to set up? Will it be easy to change? Is it expensive? Is there a community? And can our staff learn to use it within less than three months of training? And this led us to WordPress. Unsurprisingly. Unsurprisingly. About three months before we were going to release this entire collection, I attended last year's community summit. One of the conversations I had was with a dot-com themeer about the way that our museum images might be useful to automatic and how we might be able to expose people to art who had not seen these type of objects before. He connected us with another team at automatic who could partner with us and help us spread WordPress to the cultural institution space where it is still relatively unused. We talked about some of the obstacles that we faced as a museum, and we realized that there was a way to combine all of our museum's research and data, exhibition content, and collections, and allow those who could never come to our museum to actually experience it. So I was a member of a team at automatic who focused on outreach and WordPress evangelizing. So our goal was to spread WordPress to 51% of the internet. And we're at 25, so we're almost halfway there. So we saw a partnership with Freer & Sackler as a really great way to spread WordPress into an entirely new space. Museums, cultural institutions, which it really isn't yet. So we agreed to join up and guide through them through their site redesign and give them our resources as well. So to kick off the project, I went down to DC to actually meet with the Freer & Sackler team in person. It was a super good trip. It was the only part of the process that we actually did in person. The rest was totally online. So this is normal for automatic. We're a distributed company, but it wasn't really normal for the Freer & Sackler team. So it gave me a chance to get a feel for their team dynamics, their opinions on design, and most importantly, get a sense for the physical space of the museum. So Courtney gave me a walkthrough. It was super pretty. I loved it. It was really, really good museums. And so I got to see how the items were displayed and the overall aesthetic of the museum. So while I was there, we also did two design activities. So a card sorting exercise using a selection of pages from the existing site and a 30-second gut check. The first activity was a homepage-focused card sorting exercise. So I created a set of index cards made up of major sections of the site, and then I had the team organize them in order of how important each section was for the homepage. I focused on the homepage because it seems like an easier activity that we could do in an hour together, and then we could do more later. So I said that they could merge, discard or add any cards that they saw fit. So this is what we ended up with. We just sat down at a table and organized some cards. So it's fun to look at, especially because you can physically see the difference between the two. So the person on the left ended up with only a few really high priority items, a bunch of things in the middle and then just a few things at the end. While the person on the right really clustered a lot of the important things at the top and they had a much longer tail of lower priority items. So they also discarded a lot of cards, which was really great because it kept the homepage really focused on their most important content, which is helping people plan their visit, current and upcoming exhibits, upcoming events, and highlighting their super awesome online collection. The 30 second design gut check was the next activity that we did. So it was really fun for me. So prior to the visit, I looked over the competitive landscape to see what other museums were like and spoiler alert. A lot of them were very outdated. And after that, I broadened my search to things that were tangentially related, art magazines, online stores, anything that displayed collections, products or events. So designs that were relevant to the museum. From that review, I was able to put together about a dozen design options to show the team. So how this works is that I would put a design example up on a projector. I would scroll through it and they would have 30 seconds to look at it, jot down some notes and then rate it on a scale of one to five. After 30 seconds, I would move on to the next design. So here's an example of one of the sites that I showed them. This is the Whitney Museum. So their comments included, boring, boxes, no explosion, no expressiveness. Love the minimal header and footer. Kind of cluttered, too much information. Black and white layout lets the art shine through though. They gave it about a two, a 2.17. So here's the Rijks Museum. Comments included. Looks okay. Larger images are good, but descriptions are not imaginative. Looks like everybody else's site, boring. Nice header, looks elegant and clean. They rated it about a three. We didn't really rate anything very high. So the last example was one I chose because it was so totally different from anything else I'd shown them. They had some really great comments. Effort to break up info, but no sense of what this institution's purpose is. And if you look, it's really hard to tell what it actually is, so it's super valid criticism. It's also surprising organization of content. Colors made it really easy to focus on very specific parts of the site, but too busy. Fills deliberately quirky, but not in a good way. So this was also about a three. So this exercise was really valuable. A, because we got to do it together. We had an hour. We just did it and it was cool. And it allowed me to quickly gauge what design patterns the team did and didn't like along with how they felt about more traditional layouts versus experimental layouts. And so after we did this, we stepped back, looked and analyzed the results, and we found that the team was really interested in having a strong grid based design. So they love sites where the stories really showed through where you could look at something and it just told a story to you. They loved it when the photos could also shine. They have a lot of photos. And the rest of the site kind of like bled into the background. So, you know, thinking back on it, if I could redo this particular exercise, I would probably focus on one kind of page. So one thing I did was I showed home pages, collection pages, pretty much anything. And if I did this again, I would just focus on one of those because I think it would have kept the exercise more focused. So additionally, while I was at the museum, I was able to start auditing their existing design materials and their overall aesthetic. During my walkthrough, I took photos of how collection items and their labels were displayed within the museum. So I also took home and reviewed print catalog that they had. So I got to see like how they actually worked with design in a printed space. And then I looked at all their digital projects. They had been doing more and more digital projects that were unconnected to the website just because it was so hard to update. So this helped me get a sense for how they did things like use space, use colors and use typography. After the kickoff meeting, we went back and we started getting our shared spaces set up. So at Automatic, we care a lot about transparency and open communication. The idea that communication is oxygen leaks into everything we do. And so this project wasn't any different. We wanted to make sure the entire process was open, transparent, and to that end, we chose our tools accordingly. These might be familiar tools for many of you. So before this project, I'd never used GitHub collaboratively with a partner outside of Automatic. So we use it internal for everything. I mean, if you've looked at Calypso, that's kind of been our lives the past year and a half. But outside partnerships are usually taken care of over phone and email. Because this project had to be so collaborative to succeed, it was integral for us to work together like we were the same team. So I pitched the idea of putting together all the designs on GitHub, which even then I feel like it's still a little bit radical. The Freer and Sackler team agreed. And so we did all of our planning, wireframe and mockups in GitHub issues. And then we also used Slack to tie everything together and have some real-time communication in there. For us, it felt much more organic to be able to comment and work in the same space that we were keeping the designs. It allowed a very seamless and iterative workspace approach, even though we weren't working physically together. And though that's the norm for Mel's company, as she mentioned, at our museum, we're used to working and designing in the same physical space. So for us to have something that felt similar was very important. Mel's ability to give us real-time iterations of designs that were being put up did two things for us. It shortened the time it took to get through those awkward spaces that always happen when you're designing something. And it continued the feeling of shared ownership between both of us on the project. So it worked out because it ended up feeling like we were together in the same space. I could put up a design, we could immediately iterate on it and I could post up another design. We did the same thing with their designer. So sometimes she would print out designs, mark them up, and then come back to me with feedback. We passed Photoshop files back and forth and collaborated on designs directly together. So that way, for instance, when we were looking at a color palette, she was able to take it, change it in person, show it around, and then come back to me with feedback and it worked really well. So we did a lot of this kind of back and forth together. We integrated GitHub into our FreeSackler Slack instance and we made a really natural feedback loop between the two services that helped us continue to keep the momentum going. So having everything together in this one place also kept us very organized, much, much better than like combing through emails. Ah, where was this decision made? I don't remember. So we took full advantage of native GitHub features like task lists and cross-linking between issues. That way, if we ever referenced another design, we could just reference it and have it immediately link. We also used labels liberally to mark out which issues were like where they are were within the design process. So we could be like, oh, this one needs feedback. Oh, this one needs a new design iteration and it was a really good way of keeping ourselves on track. Having this much back and forth real-time communication also built a lot of camaraderie between our two teams. We did a lot of joking and used a lot of emoji. We like the emoji. So by the end of the design process, we'd formed a pretty cohesive team that functioned very differently from other client services relationships. So outside of our initial introduction email, we just ditched email entirely. We used it if we had to, but we really didn't have to with Slack. So we also did Google Hangouts, whenever we felt like we needed to clarify something face to face. And I think Google better than using like a phone call because then we could see each other and like not interrupt each other as much, so. Our two teams were mutually invested in the goal of spreading WordPress into the community of cultural institutions and open sourcing knowledge. We were interested in history, culture, and knowledge being available to everybody around the world that came from our museum. We shared a love of the visual beauty of our objects and a passion for open source that wove its way through the partnership. By the end of the design phase, we created a visual language and a set of templates that covered all of our major layout and use cases. Ranging from objects to scholarly essays, we took into account our initial goal to create a unified site experience that accommodates everyone from our elephant enthusiasts to Gorio Buddha scholars. So now that the design process is complete for now, there's always room for iteration, what's next? Well, the first item is actually to build the site, but this will also include reusable templates for our online scholarly catalogs, linking together WordPress with our collections management system, relating our collections, our research, and our content with shared taxonomies from within those systems, open sourcing any plugins that we write and releasing them on GitHub and exploring the WP API using hardware within our physical space. So we hope to launch the new Freer Encyclocyte by the middle of next year and it's gonna be super cool so you should keep an eye out. And that took a lot less time than it had when we went through it. So we have plenty of time for questions. So thank you, thanks everyone. We would love to answer any of your questions. Even if they're about elephants. Although I don't know that I can help with elephants. Hello, hello, thank you both. That was really awesome to hear. I did have a question. I do have some experience working with some of the Smithsonian organizations and know that the collection management usually happens in sort of these sealed off systems like TMS or MIMS-E. How is that currently implemented? You mentioned that being on the roadmap for like down the line. So how, for what you're currently building right now, how are those systems related, if at all? TMS for everyone. So we are using TMS and it is a very highly structured, very proprietary system and it's really made exclusively for curators. So it does not play well with anything other than itself. You know those. And so we have worked to move it out into a MySQL database and it automatically updates twice a week which for a museum is like every 30 seconds for anywhere else. And we will be using that to create the relationships between WordPress and TMS. Our goal is to make it so any museum using the museum system can use this to put their content into WordPress too. That's like the overall goal for that part of the project. Absolutely. Okay, so, and just a quick follow-up then. Is the idea that curatorial would still use TMS as their primary entry point and then that information is just like synced over into the WordPress? Absolutely. We do not want to upset the curators. This kind of ties off of not upsetting the curators. I was wondering how big your digital team is at the museum and also how you've managed stakeholder management to make sure that the curators and everyone else at the museum is bought into the new designs and ideas. Well, compared to most of the museums in the United States and the world, we have an enormous team. Compared to places like the Met, we are an ant on top of like an elephant. So we have a strictly digital team of about 13 people. Three of them are web and backend. We have a video person. We have a photography department, rights and reproduction and AV and equipment within the exhibitions. So it's not huge. Met is 70 people, but it's sizable and that really helps. When it comes to thinking about how the curators fit in, there was a lot of talk about what content could legally go online and how we felt about putting up information that may not be correct. And everybody has their own opinion and if you've ever worked in an art museum, you will know that these opinions are very, very loud, but we're working through it. And I think everyone's starting to understand that we all know that research is ongoing and we all know that information's imperfect and it doesn't mean that you're not the expert on this topic, but we have 41,000 objects online. Nobody can fact check all of those and be one curator, but crowdsourcing and people who are specialists who maybe have this object so that they've studied their entire lives but they're not with the Smithsonian might be able to help. Thank you. Are there opportunities for other museums to either get involved or at least follow along the progress of these tools that you might be building? As we finish building them, we will put them up and we are creating a lab blog to just highlight as we move through these different steps. It is all iterative and it will never be done. So hopefully people though can use them. Maybe they'll create things. There may be things out there that don't fit in right now but would fit into our system a little bit later and we're hoping that the community within cultural institutions can start to better mimic the community around news services and shopping services in these places where everyone is giving all of this wonderful feedback and using their resources to create amazing plugins and actually have that available to a group that has very little money and often very, very, very limited digital resources. A little shorter. Okay, hi. Hi. I enjoyed your talk. Thank you very much. Thanks. I work at the Philadelphia Museum of Art and we are working on upgrading our ticketing presence online. So I have two questions for you. One would be about the e-commerce or the ticketing element of your site and how you've looked at that and whether or not you plan to use WordPress to interact with that at all. And then my second question would be very curious about how you're using GitHub and if that's publicly available. Okay. Ticketing right now is about as manual as you can get. We order them from Ticketmaster and then we hand sort them and then we hand them out to people when they get there and then we ask for them back at the door so that we can count them. They feel very special. Very special. It's like a super amazing high tech system. Yeah. Okay. The Cooper Hewitt's using Tessitura and we are looking at a couple other different systems but it needs to tie into our CRM. Yep. So we're not sure what's going to happen with that. It would be nice if in the future we can help the people who are buying tickets be able to see what they've got and have that integrated with our site but right now our biggest issue is trying to make sure that the collections information is actually linked with the research which strangely it's not on any site anymore. Understood. And then how would that, are you also looking at any of the WordPress e-commerce platforms so? No. We're not. We haven't looked at those yet at all. Okay. We don't have a store because we're Smithsonian and so there is another space that actually sells items but it's not our museum. Okay. And could you speak a little more to the GitHub part of your talk? We have a GitHub repository and I think there's one item in it right now but if you watch more we'll show up. Okay. Thank you. Thank you. Hi. Hey. Hi. As a designer developer who likes to build WordPress sites and likes to work with museums and other cultural institutions is there a way I can get involved in this initiative or like help it or I don't know be collegial in some useful way? I actually think that's going to become a very important part of this once the initial portion is launched. So we need to make sure that the structure is very set and we know where we're going since we're not seeing anyone else doing this. We know there's gonna be a lot of missteps but once we get in there and we have this environment fully set we're hoping to have art and IT enthusiasts come and help us iterate off of this and make something really amazing. Cool. Actually, no Annie so we can get in touch. Yes. Any other questions? Thank you. Thanks.