Shaping Up Your Development Process With Shape Up — Martin Snyder

Don't be nervous, Richard. We are sure you are doing a good job in there. Thank you so much for your cooperation. So let me tell you a story. You might have heard this story before. You know, someone is working in a software organization and they find a book or a video or something, you know, and the book, of course, has... has all of the answers and and so so you start getting to work right and and and everything it goes great in the beginning you're moving so fast and you're really fast because you know you've gotten rid of all this process right yeah again you have all the answers everything is easy and you settle down and and then it's quickly all about the work and building these like long pipelines and you have you know the equivalent of thousands of monkeys pounding on the the typewriters and then at some point someone questions are we doing here? Because you've turned into something that could be called a feature factory, or your engineers have turned into people that could be called ticket takers. These are not attractive words, by the way. And it could be that the original leaders are no longer part of the organization, and they've kind of let a machine run wild with no leadership. Or it could just be it's become more about the process that was your original answer has now kind of dominated the work that you're doing. And then you get to this point of accountability where people start to question where you are and you see really weird effects here. You'll see things like the people that were the decision makers are no longer taking responsibility for any of the decisions. Whereas like this is terrible, well this is what you said to build. But no, not that way, right? Like, I was expecting, this took too long. Well, we told you, and now it's not scalable. We told you the risks. Like, it's just all this finger pointing, a lot of anger around the table. It doesn't always end this way, but it's ended this way enough that we are here today. There's a couple common problems with agile implementations and this has nothing to do with any particular agile methodology. It has nothing to do with every agile methodology. It has to do with people, right? It's like the people and their adoption of these different methodologies can fall into these traps and the number one trap, the single biggest mistake you can make is to focus on high resource utilization. So if anyone is in an organization like that, take a picture of this slide right now and take it to work on tomorrow, or whatever that is, Thursday. It's a huge mistake, and part of why it's a huge mistake is that when you maximize resource utilization, you neutralize the expertise of those resources. They don't have time to breathe, they don't have time to think, they don't have time to actually use their expertise, they're too busy doing high labor activities. Lack of ownership like agile is all about ownership and it's all about collective ownership And so if you have ever a lack of ownership either of the totality or on a tactical basis That's that's a major indicator that you're you're doing something wrong perhaps everything wrong The the point is collaboration and so if you end up in a circumstance where you have like unidirectional relationships right or it's like oh that that product team is just so demanding, or that engineering team is so slow. Once you have problems like that, that unidirectional, you've lost collaboration. And if you've lost collaboration, you've lost the capability to be agile, and this is a problem. So any of these things are a sign that it's time for a change. And I'm not saying that I have the answer any more than anyone else, but we should get back to basics before we start talking about any methodology, agile or otherwise, we should just talk about where people have had success and what the original manifesto said. And these are like the five key points to me. I didn't actually fact check these against the manifesto. But the number one thing is self-organization. So if you're in a place where it's like, oh, hey, we have ten teams and we've all adopted I'm trying really hard not to say any one methodology. We've all adopted X, right? That's an indication right away you've failed. You're not self-organizing. There's some top-down mandate of organization, so really bad indicator. There's supposed to be cross-functional teams, so if like your Agile team is only like engineers and testers and then the product person comes in at the end or something for like the the sprint reviewers like that's Fail failure, right? Everyone has to be an agile participant across all the relevant functions another indication of that is if you find your team is Frequently blocked on like a single function then and that function is not part of your team well that function should be part of your team. And then that's again, and any one of these failures, these are like critical failures, like stepping on the rake, banging in the face type failures. We can't recover. You cannot be agile if you have even one of these defects in your process. The high engagement, same thing as before. It's like, okay, well, I have this person. We have the representative of, you know, let's say technical leadership. We have that person who's on the agile team, but they only come to one stand-up a week, and they respond to emails in 48 hours. I mean, they're not highly engaged. They're not performing that function. And I would argue actually better off not having to be on the agile team than having someone halfway in. So the high engagement is super big. The empowered part is not just about them owning the decisions and being able to make the decisions, but having the team be well composed to the point that they can establish those things. And that's why you need every single represented function. If you have external blockers, you're not empowered because your team isn't composed correctly. You need all these things before you can even get started talking about methodology. And then the constant feedback is essential. You have to always be looking for feedback. And what it gets down to is that Agile was never about moving fast. Like when we use words like sprint, using the word sprint is a failure of understanding agile methodologies. Because you're not trying to go fast, you're trying to get it right. It's always been about trying to get it right. And it doesn't matter how fast you go if you don't get it right. And I think like these are all things I think that we all know, right? but we're still here because there's others out there that may not have this. And the other thing about Agile is, and this gets to a little bit of that constant feedback loop, is you have to always maintain your release capability. The further you drift from that, like if you're like, oh hey, we're doing this big refactor, it's gonna take six to eight weeks to close it up and then we got a test, we can release in like three months, you're not Agile, right? You're something else. And what that something else is might be okay. It's not like everyone has to be agile. But you want to be self-aware. And so you want to always maintain that release trajectory, that release capability as often as you can, which is, of course, you don't have to be able to release at the end of every day. But again, the further you drift, the less agile you are. So let's talk about shape-up, right? So it gets down basically to a collaboration. One person has an idea they want to express to another. How many people have ever seen this happen in the workplace? And how many people have seen that gone wrong? It's really everything we're talking about is this exchange of information. And so we have good news. There's a book for Shape Up. It was written by Ryan Singer. You can see him here bringing us the book. Thank you, Ryan. And right away we run into the fourth great folly from Vizzini in The Princess Bride, is to not solve a problem of too much fragmentation and not enough consensus by adding another choice. But we're going to add a new choice anyway. So let's talk about... ShapeUp. I know that's why everyone's here. I'm going to take you through kind of at a high level for ShapeUp. We're not going to spend all our time detailing the ShapeUp methodology because there's other resources which are at least as good and probably better. I'll link some of them at the end. There's videos from Ryan Singer and of course the book that he wrote are the places that I would start. If you really want to go deep on these things. But in order to talk about ShapeUp and what makes it different from some of the other methodologies, we want to review some of the basic vocabulary. So central to ShapeUp is the concept of a pitch. And the pitch is a written representation of the exchange of ideas. It's the light bulb. It's how... It's how we communicate between product and engineering. One of the things about a pitch, which is a little different than a user story and a ticket or something like that, is the level of detail expected of a pitch. It's a higher level of detail than might have been expected. We don't want detailed screens that are to be implemented. We don't want precise answers of exactly how to do it. We want to go a little higher. We want to talk about what is What is the problem we're solving? And why are we solving it? And what evidence do we have that this is a problem? And what properties do we think the solution will have? And what evidence do we have about that? So we'd like to be more data and analytics based in a pitch. We'd like to have things based on actual customer conversations and different analytics. We want to basically get... away from intuition and away from authority being, oh, I wrote this and therefore this is the work we're going to do, and more about being able to justify what the decisions are. Another part of the pitch though is to bound the problem by specifically calling out things that are not part of the answer. So you might say something like, well, so we want to solve this one technical problem on this screen, but we want to make certain that as part of this exercise, no one attempts to generalize this. We don't want that. That's going to be a distraction to the effort. We have to prove that this problem can be solved before we start worrying about general. And the last thing, that's always the case. Each pitch gets its own list of no-goes and rabbit holes. And these are things that are perils. They are distractions. They're things that would impair our ability to deliver what is needed. And that's, again, the focus is on what is the first thing that we need to achieve to establish that our solution is viable for this pitch. And it could be that you can completely implement it, and you can do everything you wanted to do, but this is not often the case. And so we want to put those boundaries in place. Another important thing, which is a little different than other methodologies, and this is really made clear from the very beginning, is that anyone can write a pitch, okay? Anyone in your organization, you don't really have customers writing pitches. But so in our case, engineers don't really write pitches as often. We have something else I'm going to talk about later, which is kind of like a pitch, but an alternative format. But like our support desk, they'll write pitches. Hey, we're seeing this problem. This is a real problem for us and for the customers that we serve. And we think the problem has these solutions. We see it in customer success, which is having a different set of conversations. And then you have your product team. And of course, it is the product team's job to write. So you expect most of the volume to come from them. But the operations team, they can do the same thing. We're having these problems in deployment and management. like more observability in that area, or we want more configurability in that area. Like almost anyone can commission what is needed by writing a pitch. It's a big part of the collaboration. And it gets to those agile teams having all the right functions available. And in terms of the collaboration, everyone being more or less equal. Like you don't have one group in charge. Everyone has their own specialties. They bring their own expertise to the table. We use the word appetite a lot and appetite is a proxy for budget in this case. So for the most part Everyone involved is bad with budgets. I'm not great with budgets in my role at the executive level. Engineering management's not great with budgets. Engineers of all levels aren't great with budgets. Testers are not, everyone's bad with budgets. But they are better with deadlines and time. And so there's a couple ways to constrain this. And so one is to use appetite in terms of time as a proxy for budget. And you're not... This is not a cost control measure. This is a measure to make sure that you don't overexert yourself. So how many people have been on a project where somebody's twiddling with some small part of the user interface and two and a half months go by and you're like, well, that can't have been worth it. How many people have ever seen that happen? All right, the rest of you are lying. It happens all the time. And then what happens? The engineer says, well, I was just doing what I was told. And the product person says, well, if I'd known it was going to take that long, I never would have asked for it, right? So we want to avoid that. We want everyone to be on the same page from the very beginning. If this can't be solved within this time frame, it's not worth solving. We don't want a two-month checkbox. We want a two-week checkbox at maximum. That's what we want. And if you can't fit the answer in there, then we're going to pull the plug before we even get started. Now, within ShapeUp, granularity is a big, big issue when you look at all these different methodologies. You have point systems with story points and stuff like that. There's only two choices. There's a big batch of six weeks and a small batch of two weeks. I'll talk a little bit about what we did with that. Because that represents you know obvious issues for different organizations not everyone has work that's going to fit into those batches and of course you can always Customize every agile framework for your needs so you don't have to actually follow that we try to follow that pretty carefully Because it's a the justification in the book is is pretty good. It's like if it's not worth Like if you get like a tweener it's probably you either want to split it up So if you have like a four, you split up into two twos. Or if you have like a four or something, there might be a way to negotiate upwards to fill six weeks with that and get a better outcome. And that's something that your product team should be discussing with your engineering team. What are the options and how different ways can we approach this that's going to fit in the appetite and what properties might those have? You want to have those discussions before you start construction rather than like three weeks or three months into it. And then, of course, there's a strict rule here, and a lot of methodologies have this, where if you exceed the appetite, what you're supposed to do is you're supposed to pull the plug immediately and send it back to the pre-execution phase, a harsh penalty. And it's important. If you don't have the harsh penalty, everyone knows what happens. You let one thing bleed over, everything bleeds over. You kind of lose control. The appetite ceases to have meaning. So it's important to have some discipline when it comes to this. Betting is a very important word in the ShapeUp vocabulary. So in betting, we take all of the available pitches and we, mostly the product team in this case, but also like all the pitch authors are there to represent their case. They advocate for what they think is important and they have some mechanism by which they decide what you're going to work on. And this happens for the most part every two months within ShapeUp. So that's an important thing. And then negotiation is, I think, the single most important word in the whole methodology, where you're supposed to work with each other and discuss the pros and cons of the implementation and decide the best implementation given the constraints. This is really, really important stuff. And you can negotiate in both ways. It's like, oh, well, If I use this library, then this thing that you thought was hard, we could do very easily. And either we could maybe reduce it to a two if we're in the pre-betting phase, or maybe we could take that time and we could do more with it. We're talking about adding two data fields to this analytics screen, to our warehouse and funneling through the whole analytics chain to show up on this screen. But if we do it this way, that'll give us some extra time. So what were you thinking next? Maybe we can put 10 fields in there. Maybe we can solve multiple problems in the same time while we're in that area. So negotiation goes both ways. And one of the big cautions on negotiation is this is not a sport. This isn't like salary negotiation. This isn't like negotiating for you. This is a collaborative negotiation. You do not want to win every time. That's not a desired outcome because you don't want to train product. that engineering gets to choose everything. You don't want to train engineering that they have no say. You want everyone to have a voice. It's one of the most critical things. And so you want to work together to answer those questions, to make sure people understand the pros and cons of the implementation. And this happens not just at the dawn of construction for one of these items, but throughout. There's constant engagement throughout the whole thing. Then we use the word cycle and cycle is just putting all this stuff together. A cycle is there's a batch phase which is six weeks so if you have a bunch of big batch items of course they fill the whole cycle. you know, a bunch of small batch items, you can divide by three and that's how many will fill the cycle and hopefully you have enough people to work on these things. And so that's the six weeks is the batch and then two weeks is the cool down. And so the cool down is basically unplanned activity. So you might implement something during the batch and then you did some stuff to meet the deadline, perhaps. The things you weren't proud of. But the rules are the rules, right? The goal was to solve the problem within the constraints of the exercise, and you did that. And you thought, well, hey, if only I had a couple extra days, I could tune this up a little bit in a way I'd be happy with. It would make it easier to share in the future or something like that. Well, you have two weeks of the cool down to go and do that. to remediate your own work. Or maybe you don't need to do that. You could spend two weeks of the cool down looking ahead. Maybe get a head start on something. Maybe review pitches before they're going to the betting table, which not 100% of your team would always have the time to do. Or maybe there's something you just always wanted to fix. Like there's a library that you know is out of date. You know it's just time or something. And you can just get that work done, right? It's an unplanned elective activities. And so we've built into the methodology 25% of the time is elective activities for engineering. And so one of the problems you see, when you get those workhorse pipelines, 100% utilization, your technical debt accumulates incredibly rapidly. And no one takes responsibility for it, right? The engineers are creating the technical debt, but they're like, I don't know what you expect me to do about it. Like, I'm banging on the keyboard every single day with no time to stop, breathe, or think. There's no chance I'm not going to create it, and there's certainly no chance I'm going to be able to correct it. Here you put power into people's hands to not only stop, breathe, and think. and maybe clean some of it up as it's being created, but also schedule some activities to kind of clean things up before you move forward. So that's built in. So I think that's an attractive thing. So that's it for the short version of ShapeUp. And we're going to spend the rest of the time talking about Pinnacle's adoption of it. So we're going to repeat a lot of these things in the context of some of the decisions that we made. and go through it that way. So before we start, I'll just say again. I think this entire presentation is probably mostly things that people already know. There's no silver bullets for any adoption of anything. Labor is important. Your effort that you put into this is important. Getting buy-in, organizational change, these are all hard things. So there's no part of just saying you're doing this. It's only going to make things worse if you just say you're going to do it. It took us, we've been doing this for a little over... 18 months, two years, somewhere in there. And it took us awhile to kind of learn how important some of the rules were to us. and how unimportant some of the other rules were to us, and to train people to a comparable level of execution. So you didn't, for instance, have a sinking feeling when you got a pitch from person A, but you felt great if you got a pitch from person B. It's like you want to have some sort of consistent delivery on every side of it. The other thing, the first words out of my mouth when I'm talking with anyone about any sort of management organizational or process issue is you can't use any sort of process or structure to solve a people problem. If your people aren't working well together, then... you've got to solve that problem first. None of this stuff is going to help you. And that takes some self-reflection, and not everyone has the tools to solve those problems. So if you're in that situation, I feel terrible for you. You might have no answer except to leave. And then the final thing is that Surtara and Pinnacle 21, we deliver enterprise software for regulated markets, all in life sciences, and not everyone's in the same situation. So definitely don't just copy what we're doing, because even if you completely buy into everything I'm saying, we're solving some problems you may not have. And that's part of why I'm here at Philly ETE, is because almost all the adopters of ShapeUp are smaller organizations doing business to consumer software with single products. And there's very few companies that are doing this in the enterprise space with B2B software. There's very few people that are doing this with an organization of the size of ours. So I think we do have something to share about our adoption, some things that people could learn from that. This is more than just Martin presenting ShapeUp like anyone else could present ShapeUp. So now we're getting to the good stuff. Yeah, and we actually talked to Ryan Singer about some of our stuff, and he was the one that told us we were the only ones doing this in B2B, so we didn't really know that in the beginning. I guess that's part of why we were successful with it, was we didn't realize how hard it was going to be. So we have a larger organization, so larger organizations are going to have more role definition. In your smaller organizations, you'll have people that wear multiple hats. So I'm going to talk about how we organize stuff, but don't necessarily think of these as Individual people so I have four things listed here may not be four people right in your organization But it would be you know say one or two or three people acting in these different ways And by the way like people always wonder like how do founders act so fast? When they're when they're implementing stuff it's because everything that we're talking about they're doing they're just doing in one mind right so they're doing they're an analyst They're a designer. They're an engineer. They're a tester They have everything clear in their mind. They're iterating so quickly You know all of the things that we have to build structure around to make happen they have happening kind of for free. And so that's why our team now at Pinnacle, we're probably at least 10 times slower than Pinnacle was 10 or 15 years ago. And it's just the only way it can be because founders got to found, right? I mean, they're not going to stick around and work on these large teams trying to scale up. They want to be at the forward edge doing things that lack definition, not building out larger ecosystems where you have a lot of definition. And of course, we have escalation of all these things. So the product analyst is kind of like the individual contributor version. Then you get to the product manager is kind of a higher level with greater responsibilities. You get one or the other there. Same thing with product designers. And you'll throw appropriate resources at it. You don't want to throw an early career product analyst at something that's a really nightmarishly challenging problem. So I think that goes without saying. Same with software engineers and testers. And then I think implied in here, there's also leadership involved. So like your software engineer is going to do some work. There'll be a code review with someone in leadership or they're like, hey, I have to change the data model of this application. They're probably going to talk to someone on the engineering side first. You know, it's not really something you would talk about with your kind of pod that you've constructed to implement one item. The same thing on the product side where it's like, hey, you know, the engineers want to do this and I don't know. It sounds like the kind of thing that we should talk about. I think ratios come up a lot where people are like, well, how should I structure and organize? This is about what we use. What this means, if you think about it, if an engineer in a cycle is going to do six units of work, whatever word we're going to use for that, then a product person needs to be able to produce about 36 of those, whatever that is. in our world, that's what we like to see. But you don't always see it because they're not all equal. Sometimes you'll see it could take months sometimes to put together one if it takes a lot of research and conversation. Not like months of 100% dedicated effort, but months on the calendar. So that's more of an aspirational goal. We use a four to one engineer to test ratio. And what that generally means is that your engineers will probably work on, like when we get back to this picture, your engineers kind of working on this thing the whole time and the other people are potentially working on other things at the same time. So it doesn't break the agile model for people to have other responsibilities and distractions unless they get blocked in a way that kind of scuttles like every single project the tester is working on. And then we don't have as many designers as we like, so we end up with like 15 to one. We also, we have a very mature established product where we're deploying shape up primarily. And so we do get a lot of work that doesn't really require design assistance. Like, you know, expand this screen, it already has a design. Everyone should be able to figure that out. And so this is what cycles look like. I think everyone kind of had this picture in their head already from adding up the numbers before. But it's about eight weeks for a cycle, six weeks of implementation, two of the cooldown, and then we do our betting meeting right at the start of cooldown for the following cycle. And there's a lot of reasons why you want to do that, because there's some amount of negotiation and discussion that would happen even before the betting meeting. I guess I'm going out of order with my slides, but I'll take a look at every... every pitch before the betting meeting with my team, and we'll make a hit list. Which are the ones that my team wants me to make sure do not get accepted at the betting table? It doesn't matter why, but usually it's because we're not ready for this, it's gonna conflict with other efforts, we feel like there's unanswered implementation details that are gonna make this thing a nightmare. Whatever it is, we don't want to go in unprepared. Yeah, and there's that note just, The carryover is deadly. We're getting more and more strict about making sure everything kind of lands on schedule. But if you think about it, we actually have really good goal alignment with the implementation teams here because you get 25% of your time for elective activities unless you screw it up, unless you blow through the deadline, unless you consume some or all of that cool-down period just doing the work you were assigned, and it's all your fault. because it's a fixed time variable scope methodology. And so the only way you go over, I mean how many people, if you were in college and you were told, hey, you can answer as many of these homework questions as you want, all you have to do is hand it in on time. How many would not get a perfect score on that assignment? I mean I would have gotten that every single time and I was not a gifted homework doer. So, yeah, it's your fault for running over. You're stealing from the whole team, right? You're putting at a disadvantage for the future cycle, but you're taking away that elective time for the unplanned work, the engineering-directed activities. So that's a really important part of the methodology, and it's really important that people understand that, because otherwise you're like, oh, it's no big deal, I'll get it done Tuesday or something. Tuesday very quickly becomes Thursday, which very quickly becomes Monday, right? So that's one of the hardest parts, I think, with any of the Agile methodologies, is kind of keeping everything, getting everything completed in the expected time period. And completed means the ticket's done, right? So engineering work is done, you're reviewed, you're merged, you're tested, you're PO. review, like whatever the words that you're using in your organization, you can continue to use these. ShapeUp doesn't really have any opinions when you get down to the tactical level like that. And so what that means is it means if you are in love with some daily rituals based on whatever methodology of your choosing, you can actually continue to do that. There's nothing that's stopping you because everything that we're talking about is happening on these much larger timescales in ShapeUp. So then we get to release timelines and so what you would normally do if you were a regular shop is you would release at the end of every cycle. You release every two months and that's usually appropriate for a lot of a lot of consumer applications. Now for us, our customers actually don't want that. Our customers, they face a high cost of adoption. It has to do with their compliance with regulations and the things they have to do to accept a release and to do independent testing and to train their users. It's one of the less fantastic parts of being in the life science space. So what we do is we batch together three of these cycles and we release every six months. There's an issue there. There's an obvious issue there which is six months is a long time. And how do you know that the things that you tested in, say, a small batch two-week item at the start of cycle A, how do you know that's still working when you go to release? And the answer, of course, is you don't. You don't know that it's working. And so you have to take all these things and you stitch them together and you have support releases and you have other potential influences. And you just have to, someone has to double-check that everything is merged, your branch management is correct, you've done some end-to-end testing, you've done some post-merge verification, and you go through all of your other processes and stuff. We also have a very formal testing process that we tack on to the end of that. It takes us about two months to do that. You can see in this picture how we stagger things, we overlay. You'll work on you know for three cycles and then concurrent with the first cycle for the next release You're going through those release activities for that prior release and again with a big enough team None of this stuff really matters because it's all just a matter of having people specialize and focus on the on the right the right items I think one thing that I failed to mention if I just go back up here just for a second is We basically we just try to get each person be individually responsible for the item. So in this methodology you could take like a big batch item and put like multiple engineers on it. We don't do that. We don't let anything go through that wouldn't be staffed by a single person. So we'll break it up in some way to avoid that. And we just find it so it's much easier for, so you know, you either get like three twos or you get one six or some equivalent payload of that. That just kind of lets people focus and plan. They can plan a whole two-month time section. They don't really have to worry too much about other distractions. You don't have to worry. There's some collaborative element in that you might have two pitches that are nearby each other that kind of affect the users in similar ways. You're still collaborating, and you're, of course, still collaborating as practitioners. hey, look at this code, or hey, I'm scratching my head. What does this thing do? How does it work? So you still have all that collaboration, but people are individually responsible. So now we get to the betting table. And so this is something that we struggle with, and we struggled in the beginning a lot with team balance. So one of the issues is that you want to make sure you have enough pitches at the betting table that you can't do it all. If you're not saying no to anything, if you're just taking stuff hot off the presses and going and working on it, you really don't know if you're working on the right things. You're just working on the work that's available. So you want to make sure that you have enough mass on there that you're cutting stuff. But in ShapeUp, you don't manage a backlog. It's not like, okay, well this stuff didn't get chosen, therefore it'll be on the bedding period. They actually go back to the beginning and someone has to re-propose them, which could be the original author. Or it could sit there for a little bit and somebody else becomes interested in the same problem for the same or different reasons, and they'll repropose it or something. So the work sits around, but you don't do any sort of, there's no presumption that the last one not selected will be the first one next time. It's a clean slate every single time. You know, so product, you really want product to only be, you want them to be individually authoring pitches, even if they collaborate, and you want them to be presenting them with great vigor. You want them to want their stuff to be in the product. And so if they're not... passionate about it, it might not be the right thing to work on. And I think almost every single organization is resource-constrained. And if your organization is resource-constrained, it's hard to believe you can't find high-value stuff to work on. You should always be able to find high-value stuff that you can't work on because there's other high-value stuff that you are working on. So you don't want mid-range stuff. You don't want filler. You want stuff that people are excited about at the betting table. The other stuff, if it's necessary, you can find other ways to get it in. You don't have to put everyone in. to shape up. What we like to see is we like to see a balance between intuition and research. We don't want a subject matter expert with, you know, lots of years of experience to say, this is what we should do. We're not interested in that. We're interested in why. But it's okay to have some intuition, like, you know, I think this is what we should do, and here's some data to substantiate that. So you don't want people that are, like, just only beholden to analytics, that's not that helpful. It's like, oh, well, hey, I can't answer any questions about anything because this stuff was just deployed and I have to wait six months to get data. I think that's not helpful either. So you want people to be balancing both of those things. And that's something that we've fought with because being in such a specific domain, we are filled with subject matter experts who have decades worth of ideas accumulated. So that's kind of an unnatural feeling for people that have that expertise to be forced to substantiate their opinions with people that are unqualified. It's explaining to me why our customers need this feature. I'm not a biostatistician. I have no idea why they need that. If you tell me, it's like, okay, I can argue with you, but I can't win that argument. I can just turn it in circles for everyone. And we want product to very much focus on the problem articulation. Don't worry too much about the solution. Leave the solution for that negotiation phase. Let the people that are actually going to work on it, that are going to carry it through that implementation phase, let them worry about what the solution looks like. Even if you think it's obvious, just let it go. You want to get it to, and this is a hard thing for people to get, is to get that right level of detail. That's something you just got to work out in working with people, is to get it prepared for negotiation without pre-negotiating everything, is what I've already said. So engineering has responsibilities there, too. So we don't send very many engineers. We actually send just me. But you should send some number of engineers to the betting table, not necessarily to vote on things, although it can't hurt to have a different mindset at the table. What's important? is for the engineering representative to constrain the exercise. It's like, hey, we have these other obligations. I have the support team. We had some issues there. I got to put some extra people there. We have some consultancy. We're doing an integration with a new product that was acquired. So I can bring this many people to this cycle. right and and here's their skill sets it turns out this these people it's largely early career people or it's experienced people with less than six months of experience on the job and so we got to go easy this is this is going to be tough to staff or it's like hey I have the whole team we can go crazy or constraints like hey these three things these three sixes that all look pretty good well look there We're going to want this one person to work on each one of them. So we should pick one of them. We should not pick all three because if we pick all three, you're not going to like that staffing plan because you're going to get people who aren't going to be who you wanted to implement these things that are otherwise really important. Or maybe that's okay. We have to talk it through. So that's a big part of this. And then we also, I mentioned before how engineering doesn't really write pitches. We write what we call technical initiatives. Like the justifications are different, like the problem articulation is different, like the template just doesn't really work for us. And it's more like, hey, this company was founded in 2008, it's 15 years ago. We spent 15 years, created a bunch of problems. It's going to take some time to fix. We don't necessarily have to justify why you need to upgrade a library that's 13 years old. That represents a risk for 18 different reasons or something like that. Not that we actually have that problem. But there's things like that. It gets to the technical debt pay down, especially the debt that you've accumulated over time. This is a good way to do that. And it's also, in my mind, it's a little bit of a defense against low value items out there. It's like, hey, if you keep throwing filler stuff at me, I'm going to stop. and say, look, this doesn't seem right. If you guys don't have great answers, I can take this stuff. I can put these three or four people working on that. We'll stick with the high value stuff. We'll be better prepared for the future or something. So you want to have those kinds of interactions at the betting table. Yeah, and the other thing I would say is that we don't use ShapeUp across the board. And especially, like ShapeUp, in my mind, is just for planned activities. But a lot of what I think most organizations do, not a lot, but. Some percentage is very reactive like support is very reactive consulting is very reactive You know iterating in different things like answering an RFP is very reactive depending on how you're organized and who does what kind of work So so we don't we don't do any of this for reactive efforts We just we do other methodologies, but they don't even have names because you know It's mostly you know small pods of people and with the self organizing principle I have no interest in knowing exactly how they choose to self-organize as long as they're happy. If they want my advice or advice of an engineering leader or a member of engineering management, they're free to seek it and will freely give it, but it's just not important to us how people live their day-to-day lives. So here's what you want coming out of the betting table. You want the betting table to consume all of that capacity you brought to the table. It's a failure to be doing a bunch of technical initiatives. That's not a success of your R&D organization. You want at least half of the pitches to be chosen, probably more because, again, you want to have a cut line. You don't want to do 100%, but you also don't want to do 25% and have a bunch of wasted effort from people. The big thing for me is you want the people that aren't selected, you want them angry. You want people to be passionate about their pitches, to really want it, or if it's not that important, Why are you wasting your time writing this stuff up? You should be angry that it's not in there. And if you don't have that, that's an indication that you have a people problem. You have a culture problem. You don't have an R&D organization that is properly energized about what their task is. And it's okay. You can be perfectly successful in that situation. Don't expect staggering results. And in fact, if you struggle with different methodologies, and this is your third or fourth bite at the apple, it's probably why. It's probably why you don't have people that are invested enough in the outcome that aren't excited enough about the work that they're doing. So we have one betting table. And we have a large product portfolio. And we don't use ShapeUp today for 100% of the portfolio. But you want to have all that stuff. So if I get in a situation where the pitches for product A are uninspiring, right? Well, I would love to just pick more inspiring pitches for product B. And to do that is tricky. To do that, you have to have what I call mobility in the engineering organizations. You have to have a lot of people cross-trained. You have to have a lot of flexible people. You have to have a lot of knowledge built. It takes a lot of work to get there. But if you are going to have one bedding table, then either you have to be willing to do that and invest in that technique, or you just have to silo everything and say, oh, well, I have to have at least four things for product A. But if you do that, you don't actually have one betting table. You have individual betting tables for each product. You just want to be self-aware about what that is. Because if you think about it, when you're managing a portfolio of products, that's a real thing. You might say something like, hey, there's new regulations coming out. They're going to be published in six months. We don't think we really want to invest in product C right now. We just don't have great ideas. We need more information. So we're just going to invest over here where we have greater awareness, greater ability to execute. Otherwise, the problem you're solving is, hey, guys, we have engineers that we're paying for. We better keep them busy. We're back on like slide three, and then we're not making much progress. So I happen to think that mobility is a key part of doing this well, but I think that's the key part of doing any methodology well. It's not unique to shape up. the betting table you want to be able to produce what I call an actionable engineering plan and you just don't want something that's like an Escher drawing like you know the fork with some variable number of times where you can't like you can't have something where oh I don't have enough people to staff all these projects or hey I thought I did but then these people are all on vacation or PTO or whatever the circumstances or I forgot about all these corporate events Or like I said, we have too many early career people that can't execute this stuff. Or all I have is simple stuff and my senior people don't really want to work on it. And I can bully them into it, but is this really the best outcome? You want to come out without any of these problems. And again, that's why. the structure of the pitch and the outcome of the betting table, all these things want to be taken into account. So you might choose, okay, well, this is actually my third most valuable thing, but this complements the engineering plan in a way that's going to be really attractive to us. So you don't always choose just like stack rank, these are the most important things, and I choose them. So then we come out, and like I mentioned, so we'll have dozens and dozens of people working on different things. and and they will self-organize so it's like oh hey you know we are working on data specification and data validation against those specifications, the five of us are. So we'll do stand-ups together. We'll work together. We'll kind of collaborate. We'll co-locate our space. We'll do whatever makes us more effective. And then from an engineering management standpoint, it's like, okay, well, we want to put one engineering leader to kind of have oversight for those five things. We want one tester to cover as much of that as possible. And so just for economy, right, to have some efficiency. efficiency in how you do that. So that's something. We introduced a notion called second opinion just because we have so many people. It's one thing if all you have is senior level engineers that have worked together for a couple years and a bunch of senior product managers where everyone just gets along great, where you can trust the negotiation. We can't always trust. We want people to negotiate in good faith, but they don't all have equal information. So we added this notion of second opinions. It works both ways. This was the outcome of the negotiation. I think it's a really lousy decision I just want to talk to someone about it and you can kind of get up get up to like you know director of products type type people get up to the chief product officer get up to head of engineering or Some some equivalent people who can take a closer look and be like okay? We're just going to we're going to intervene We're going to negotiate amongst ourselves and then hand this back so that's something that we added just based on our scale We added the notion of a scorecard and this is something that is valuable to us. I don't know how This is a scale thing also. So for everything coming through every cycle, we just list all the items. And we do a plus minus for how many days it was over or under appetite. And under appetite isn't necessarily great either. You want to negotiate upwards. You want to fill the time with a superior implementation. But you record that. And then we record expectations. So we're negotiating this stuff. Fixed time variable scope. If I was a bad faith actor, I could negotiate that scope down to nearly nothing and I could produce something truly awful and mark it done and declare a success. This allows the product person or the author of the pitch or whoever is the best person to look at that and be like, well, this is a little below what I expected. That's the only measure. Add expectations above or below. We're not trying to get too fine-grained. Likewise, we can rate the pitches. It's like, hey, this pitch didn't answer a lot of the questions I had. And when I started doing my own research, I started asking, why am I doing this research? I felt this pitch was below expectations versus, hey, I read this pitch. I had great ideas. I had a five-minute conversation with the person. I was off to the races. It was fantastic, above expectations. And it's helpful from a management perspective. is you can kind of take these things and you can say, okay, well, hey, you're on the product team, you're expected to produce 36 points of whatever, and I'm looking at the numbers, and you're producing less than that, and everything's getting related below expectations. Or the reverse, like you're producing like 45 points of whatever, odd numbers are hard. But you're producing this number of points, and everything's above expectations, you're doing great. But you might not know that. in the aggregate. You might know that anecdotally on an individual basis. You did good work on this one project. It's different. Then I'm looking at a six month trend and oh wow, you're one of our top producers. And same on the engineering side. It's like wow, the product team loves you. Every single thing you do is above expectations. Like you're doing great work. We may not have known that on the macro level. It's like oh this person, we gotta load them up. Six points isn't enough. Whatever level they're at, we gotta find one above it. And vice versa. It seems like you're struggling, you're over, and the results are disappointing. we want to hear what what do we need to do together to improve that situation so I think that's that's a helpful tool for us to kind of bring this together and it's also helpful like feedback is hard we're a feedback culture we have a lot of people heavily invested in that but cross department feedback gets gets tougher And so I think this kind of elevates a little bit to make that a little easier. And it's also like managers don't always have high visibility into everything that's going on. And so this is like a visibility tool for managers on both sides of the fence just to have more information that they might not have had. So that's something that we added. And then I also mentioned how there's different circumstances where we deploy people a little differently. And these are the words we use for us. We have something called a beachhead effort, which does not shape up at all. A beachhead effort for us is like senior product leader. plus senior engineering leader working one-on-one to solve abstract problems in a new product space or something that requires high revolutions. And you can't get the answers you need without banging on the keyboard. And you've got to kind of do it together. Now, of course, we don't want to do this because this breaks our ratio. One-to-one is a very expensive ratio, especially with two leaders there. So part of their job is to kind of incubate and and get something to the next phase which is which is investment when you're doing in the investment phase You're expecting like more intuition heavy heavily research though heavy in terms of customer discussion And especially on like a product launch or something like you want to have really clear picture of what you're trying to achieve there And then in the refinement phase, it's the opposite. In the refinement phase, usually smaller batch items, more supported by analytics because the software is in use and you're starting to refine that based on your understanding of how the software is used. And then in maintenance, we don't plan that. It's unplanned collaboration. But the product team is still involved. And then you can also imagine some sort of bell-shaped curve with just the cost of the people involved. Like when you're doing the investment, you're going to have more senior people involved. The beachhead is the most senior people. You want some senior people involved, but they don't all have to be senior people. You can get larger teams, especially in refinement. Then in maintenance, if you have a low-cost option, you can use a low-cost option for maintenance. A low-cost option could also be early career teams. There's a lot of different ways to approach that. That's another piece of it. We're going to take a look at some examples here of some things that we did. This was one. We implemented this screen. It doesn't matter what it does. What matters is there's six options on the screen, and they're ordered left to right in the order they were implemented, and they were implemented in that order based on difficulty. So the left one, you're starting a new specification, and you can start from scratch, an empty thing. This was done when we were bootstrapping the system in 2011 or something like that. And then we started to add these more and more sophisticated things, and each button as you move to the right gets more and more expensive for us to implement and more valuable for the customers. And we thought, well, that's great. We've done everything. We've moved on to other areas. And then we got more analytics focused, and we looked at the analytics, and like 90% of the people clicked the first button. And what was happening was... The initial customer base was like highly engaged in the sales process with the founders and stuff and they were highly engaged from the early adopters and customers were very engaged in the process. They knew what to do and they did the right thing. And then you add like hundreds of customers and thousands of users and stuff. Those people don't have that information and they don't have the same training and awareness and they just start clicking the button. So it's not like it was always this way but we grew into that problem. So this was fundamentally a design issue. And so we came up with this triptych thing. And you can see down here in the bottom, this is that first choice we don't even want people to do. We kind of hid that. We put some badges up here. This is the right-most option we put up. And some descriptive text and stuff. This is like a design-heavy thing. And then, of course, it's all front-end because we didn't really change anything in the application. So when this thing came through, it's like a 2, right? But an extraordinarily high-value 2 because it doesn't require a lot of engineering work to go and implement. It's kind of an anomaly there, but it's an interesting thing. Again, regardless of your methodology, you've got to be collecting analytics. If you're not doing that now, you've got to start. You're just falling behind the whole industry. Almost everything relies on it. And it's very useful in the shape-up methodology. And we do have shapes that are entirely about analytics, like about collecting, changing some collection in the analytics, changing some element of how that data is aggregated and viewed and stuff, because some of it's in the product and some of it's through other means. So another look here is that we had this implementation for in-app quizzes so like training is a big part of a system like this and we had like an extra like a survey monkey type training that some people did and you know you're leaving the application and there's this person and we had like a multi-step workflow and you'd lose like 25% of the people through each step. So this was a case where we negotiated upwards, where the pitch was clear, the engineer had a really clear vision, and they just went, and we ended up, instead of having like the three quizzes that were asked for, like the three basic quizzes that approximated the survey monkey thing, we had categories of quizzes for each class of user. We had something like 20 different five-question quizzes. You can see there we had the confetti library that we added for people to get a perfect score, and I did get the perfect score on the first try when I took the screenshot. Now if you take the quiz, you know the answer to the first question. So, yeah, you want to fill that appetite is the message in this one, is you want to do more than what's asked if you have the time to, but do that in collaboration with the product person. Because when people are writing these pitches, they're writing the appetite based on various perceptions of how it might go, and until somebody really drafts an implementation, you just don't know. So this thing, it could have been a two, and we would have been on schedule and gotten it done, but because it was a six, it was important enough to make the extra investment into. And then I have one here, another analytics one, where the negotiation was really important. So in this case, we saw there was a lot of export events at unexpected times. And what we learned was that people that were using our tool to implement specifications for exchanging data with their vendors, in that use case, they were basically exporting it as Excel. uploading it as a Google Sheet or Office 365 document, sharing it with the vendor, and using like the comment annotation features to kind of communicate like Q&A and back and forth with there. And part of why they were doing that was the vendors weren't users of our system. And the other reason was we didn't have the right collaboration feature. So we see the event in the analytics, and then we go through an arduous process of understanding what's actually happening. And once we understand what's actually happening, then it's like, okay, well we need to be able to support that collaboration in the application. That's what the pitch was, right? And just think about that for a second. There's so many different ways you can do that. And there's so many ways you can fall into a rabbit hole and try to generalize that, and there's all kinds of different problems. And so in this case... like the negotiation there was critical and the appetite was very helpful so the thing doesn't spiral out of control and it was said specifically you're only solving it for this one use case even though the specification editors use for for much larger volumes of people in all these different circumstances only this one narrow thing you're doing you're not trying to solve the world's problems we need to do this we need to get feedback from those customers we need to see if and how they use this functionality before we decide to invest further and that's exactly what what happened here. Alright, so we're just going to skip right to questions. I have some highlights, but anyone that's interested will be able to get the slides, and you can just review them. It's just a rehash of those things. Here's the links. The top one, Shape Up book by Ryan Singer. It's about 130 pages. If you get bored after 35, you're good. But you can read the whole thing also. Shaping in a Nutshell is one of his shorter videos. There's a lot out there. There's a lot of hour plus videos. Shaping in a Nutshell is about 17 to 20 minutes. So that's the one I recommend for people. They just want to hear more about like the mechanics, especially from the visionary. And since this is a talk on agile methodology, I gave an ETE talk about nine years ago on implementing agile methodologies in hostile environments like these highly regulated industries. So people might be interested in that talk. And then I have a link to my other presentations. So thank you all very much for your time and attention. And I can take any questions.

37signals pioneered “Shape Up” a macro-level methodology focused on product/engineering collaboration, which was developed by their former Head of Strategy, Ryan Singer. Shape Up helped 37signals manage periods of extensive growth and a rewrite of their flagship product from scratch for its 2.0 release.

In the Foreword to Singer’s book, “Shape Up: Stop Running in Circles and Ship Work that Matters,” 37signals CEO Jason Fried explains that Shape Up does not require “daily stand ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end. No backlogs, no Kanban, no velocity tracking, none of that.”

So what does “Shape Up” involve?

In this talk, Pinnacle 21 CTO Martin Snyder will cover the basics of this novel approach and share lessons learned from years of practice.

Pinnacle 21 is an early adopter of Shape Up and has scaled its implementation from a 30-person startup to being part of a 100+ person R&D organization at Certara, the company that acquired Pinnacle in 2021.

Link to slides: https://martinsnyder.net/presentations/revealjs/shape-up.html#/

__________________________________________________

About Martin Snyder
Martin is a technology executive with extensive experience in the software industry that includes building and driving high-performance product development organizations. He is currently Vice President of Engineering at Pinnacle 21, which enables Life Sciences organizations to measure and improve the quality of their submission data. Pinnacle 21 was acquired by Certara in 2022, where he now serves as VP of Engineering for the Cloud Data Science team.

He is also an active member of the technology community as an organizer and frequent presenter for regional conferences and events, serving as leader of the Philadelphia Java User Group for three years and co-leader of the Philadelphia Area Scala Enthusiasts for four years. He has served on the programming committee for multi-day conferences including Philly ETE and The Northeast Scala Symposium, and his presentation credits include BoxWorks, LibertyJS, Philly JUG, Philly ETE, React Philly, and Northeast Scala Symposium. He has published and presented on a variety of topics over the years, most recently on Scala, JavaScript, and Functional Programming.

__________________________________________________

About the Conference
The Philly Emerging Technologies for the Enterprise (ETE) is the Mid-Atlantic's premier developer's conference. Entering its 17th year, we've brought world-class speakers — including some local favorites — to speak about leading-edge technologies being used today, and emerging technologies that will be important for attendees to know about in the near future. 

__________________________________________________

About the Host
Philly ETE is hosted by Chariot Solutions, a software development consultancy.
 For over 20 years, companies of all sizes and industries have 
looked to Chariot as a partner to help them solve their toughest software challenges, and move their business forward. 

Are you a business looking to build and manage software solutions optimized for your unique needs? We're here to help. We’ll apply our strategic, high-touch approach and extensive tech experience to solve your most complex business problems. Reach out today. Visit us at https://chariotsolutions.com/

__________________________________________________

Sponsored by Pinnacle 21
Employees at Pinnacle 21 do tech work that means something. Their software enables key transitions in the clinical trial data pipeline and streamlines regulatory approvals for drugs and medical devices, getting new treatments to patients faster. Pinnacle 21 supplies its SaaS platform to the US FDA, Japan’s PMDA, 24 of the top 25 biopharma firms, and many more biotechs. It ensures clinical trial data comply with the standards of both government agencies and trial sponsors. With strong product-market fit and an aggressive roadmap fueled by their 2021 acquisition by Certara (NASDAQ: CERT), the team is quickly becoming the one-stop data brokerage for the life sciences. Learn more: https://pinnacle21.com

Sponsored by Lutron
Lutron is the worldwide leader in lighting, automated shade and temperature controls, with headquarters in Lehigh Valley, Pennsylvania and engineering offices in Philadelphia, Boston, South Florida and Austin. We are a privately held manufacturing company with over 4000 design and product patents. We are at the forefront of innovating IoT products for smart homes and connected buildings. We provide solutions for residences that span from 500 sq. ft apartments to 10,000 sq. ft homes and commercial solutions for small office spaces to entire building complexes such as the New York Times Building, Lincoln Financial Field in Philadelphia, Empire State Building and the Guggenheim Museum. Learn more: https://www.lutron.com/en-US/pages/default.aspx