Building Tools for Shape Up – Klaus Breyer & Matt Lane (Co-founders of Dumplink)

Welcome to Shapers and Builders, the show about better ways to deliver great software products. In Season 1 of this podcast, I've been speaking with a lot of teams who have adopted ShapeUp, a delivery framework originally created at Basecamp. If you've never heard of ShapeUp, check the show notes for a link to the video Shaping in a Nutshell by Ryan Singer, former head of strategy at Basecamp and author of the book ShapeUp. Stop running in circles and shape work that matters. Today, I'm joined by Klaus Breyer and Matt Lane for a very special bonus episode. Matt and Klaus met through the ShapeUp forum when Matt posted about seeking collaborators around a ShapeUp tooling idea he had. Well, this infamous post now has turned the two into co-founders for DumpLink, a lightweight project and task management tool for teams that use ShapeUp. But really, calling it project management software is not doing it justice. for it's really a communication, de-risking and sense-making tool for the build teams on software projects. Listen to Klaus and Matt nerd out about directed acyclic graphs and foliation graphs and catch an exclusive demo of DumpLink. If you're listening to the audio version of this podcast, I recommend you check out the video version too to get the full picture. There's a link in the show notes that takes you directly to the screen-sharing part of our conversation. But enough preamble, let's get into the conversation. Just make sure to listen carefully to find out how you can test Dumpling for yourself today. Hey Matt, hey Klaus, I'm so excited to be speaking to you today. We have something kind of special because we'll talk about tooling for ShapeUp. But before we get into that, I want to ask you maybe to just talk us through your background of just professionally in a way, but also your background and experience with ShapeUp. So, you know, Klaus, maybe you want to start? Yeah, sure. um i studied software engineering and directly after the studies i founded my first company it was a social media agency and we built a lot of facebook apps back in 2010 and we grew pretty pretty fast back then because it was the right topic at the right time And I did this for five years and then I founded my next startup. It was a marketplace where social media influencers can be booked by brands. And we had a matching algorithm and access to their statistics and did all the payment via our platform. and for the last couple of years i was building up a new business unit for an industrial company from germany they are doing hydropower turbines for example and it was a product in the iot space and it was during this project that i introduced shape up to my team we were a scrum team previously and basically everything was working for us but we after a year or so into the project we optimized ourselves into the silos i would say so we had ux silo ui silo and we had the developers silo and we had a very long refinement meetings to talk through all the tickets and every silo was optimizing kind of for itself the process and then i realized we need something else here and then i remembered shape up which i read um in 2019 when the book came out and then i then we tried it out and it was really a good method to bring the team back together like have those small teams working together at one thing and um did a couple of experiments and then at one point it was not a question if we want to do shape up but just how we want to do shape up and Yeah, and the team was pretty happy with this decision. And you actually talked about that experience on a meetup that I used to run. So this isn't the first time we get to speak about ShapeUp. So it's really cool to be speaking with you again. And I'll link that episode or that meetup recording in the show notes for sure. Cool. Cool, Matt. Yeah, what about you? yeah so like claus a little bit of an entrepreneurial background i my first foray into product development was with my own startup here where i'm currently based in new york city we were doing a lot of stuff in the style transfer space when that was before it was really popular with music production and i co-founded a startup to help musicians essentially reduce the time they would spend on post-production um by helping to auto mix their records and so we did that for about five years went through an acquisition with sony and then from there my career was mostly just in product management across fintech different product categories in industry so fintech and freight tech sports betting a little bit in health and music tech again and so what was interesting to me is just sort of seeing how, especially in the startup experiences that I've had, and even more so with my own, because it was very much the beginning of my career, how unorganized so much of our work is, mainly because, you know, so much of what we do is creative problem solving and software development, which is very different than the way that I think things are currently treated. And so for me, it was just a matter of trying to figure out, like, well, we're always trying to get stuff done, you know, especially in startup world where you're trying to move really fast and there's usually a clear focus. But when there isn't or teams are sort of trying to figure out what it is that they're trying to even do to begin with, there's very little attention that's given to how we actually work together. And so paying attention to that over the years, being interested in essentially product operations and how teams essentially are working well and don't work well and how the best team members actually do the work in their own heads and just observing that and seeing how that type of thinking plays out with some of the most senior people that I've ever worked with. It was interesting because once I came across ShapeUp years later, I realized that there's so much overlap between how the best teams are already working or thinking about the work. And so it was really refreshing to read that. and it wasn't until about halfway through my career where i started to implement shape up across some of the the startups that i was working at and leading product for and it was always little pieces of it and you know we'll get into it later but lots of different sort of implementation challenges from adoption to execution of the methodology awesome and then you too you met uh via the shape of community generally right do you want to maybe talk talk a minute about that yeah i mean i i posted something in the shape of community i guess it will forever be a fossilized sort of um thing that people can always look at as long as that form is up when class and i first uh sort of linked up on there and um proposing a very rough sort of you know approach to implementing tooling for ShapeHub. And of course, the impetus for like why to even do that and why even build tooling around this is an interesting question. But yeah, I just put it out there and Klaus thought it was interesting enough to respond. And then we sort of became fast friends and hit it off. And I think having the similar appreciation for the methodology improved, like really, really impacted the way that we work together. like it was almost like a clear shared understanding of how we want to work and our shared values so it was a cool place to not only meet somebody to try and develop work with but develop tools that are actually based on the philosophies of some of this some of the stuff we're talking about so yeah really cool and also using a lot of the shape up tools to develop it develop our tooling by ourselves so obviously we did not do a six week sprint because in the research and development shape up is not a perfect pitch and a perfect method but um yeah we we did a lot of breadboarding fed marker sketches but worked in very in shorter cycles but this is like this research and development phase where you have just uh senior people like the creative people the people doing the work and the people doing the decisions are all the same people so it's a really cool um It's a really cool step in the life cycle of a project to start something, especially with somebody who is already experienced with ShapeUp. So we did not need to teach the method to each other. We can just use whatever was working for us. What we did do, though, sometimes was ask ourselves, we're not really following ShapeUp right now. We're not doing that. And I think it's really important. feature to to mention about the methodology which at least for us is true is that new product development when we're just like trying to do something completely new you're not building features on top of something um it's not always applicable i mean there's aspects of it there's some philosophies and concepts like thinking in terms of appetites for example like that's that can be so like um or you know some other things but mainly like we we would we would ask ourselves are like we're not really like doing exactly that and and i think that was critical too and how we were thinking about building a tool that we'll talk about later but that for continuous feature delivery or innovative feature development or feature strategy and development um it's an incredibly useful toolkit of ideas and shared language that you can use um but yeah when do product development things are always a little bit more wild west so yeah yeah Yeah, for sure. And you mentioned this, Matt, the fact that you put this post into the community kind of looking for collaborators on this idea that you had. There's two things I want to get into. And one, of course, is the why did you, you know, what pushed you to put this out there? And why did you believe there was... a need for tooling dedicated to ShapeUp. And then for Klaus, your side of the story that I would be really interested in hearing is what place were you in that you felt like, oh, this is an interesting thing for me to jump on. So maybe we can talk about that for a bit. So applying ShapeUp to my current team, I really saw the light kind of. I'm a big fan of Basecamp all the time, I don't use Ruby on Rails in recent years, but I really like what they're doing, what they're putting out. And so I'm very closely following Basecamp and it's really inspiring what they are doing and applying this method to my current team. As I said, I really saw the light and solving the issue between designers and developers working together was always very close to my heart. Since my very first company, I tried to make it make bridge the gap between designers and developers so i was coming i was coming from the technical side but i was always kind of leaning towards product without having a dedicated education on this but i always needed to bridge those two worlds and shape up what's the first time that somebody formulated those some principles and more like principles than the process at the end that you can really apply to a lot of teams so i saw a lot of worth in shape up and on the same time my current gig of building up this business unit where i introduced it was coming to an end so i had a little bit of time and i was again in some entrepreneurial spirit to start something new and i was i was looking for stuff that i could co-found or that could i start on my own and so it was just a good timing reading um reading matt's post and i've and having something i had a lot of solo projects that did not work out and have learned a lot and one of my recent learnings was that you really need to be inside of a community that you need to be an insider to provide value to a community if you want to really grow something and not just being an outsider trying to sell something so you really need to understand the the people using the tool and in the best case you can scratch your own edge and yeah so it was the the right time and it was the right um topic for me at this moment yeah i would i would just build on it with a there's so much in my head i want to say about this too because um there's a lot of reasons for me uh i think Primarily, just obviously from my own direct experience in trying to get ShapeUp adopted and executed effectively. And those are both two different things. Trying to get it adopted has its own challenges. Education and convincing, like, why even change things at all? We're trying to focus on building the product right now, you know, and why are we even talking about this? And then executing it. So once you have adopted it, like, what are the challenges there? There are a lot of little anecdotes from my experience about what has made those two things challenging. And I come back to, you know, like tooling for us is provides a bunch of things. I mean. The goal of what we're trying to do, though, is not simply to offer tooling as a way to instrument a process, but tooling to improve interactions of talented people and subsequently improve the products they ship. And we want to do that with simple, effective, lightweight software tools for making software. And I think we had to look, even though we don't really, I guess maybe it's more we don't want to, but I don't think that we really will be seeing ourselves as competition if you will to project management software there will be some sort of overlapping aspects especially in the beginning when it's not fully clear what the entire vision of what we're going to be doing is because we're starting small but we did look at sort of a bunch of the different project management tools and during the times where you're adopting and executing shape up in an organization you're using tools that don't necessarily allow you to customize and make it clear like the specific aspects of of shape up for example like just having something as simple as this middle layer of what we call scopes in shape up where you have these sort of groups of related tasks that live within a project that let you understand this is a specific slice of work um and how do we sequence it based on these slices how do we understand things at that second order view where we can get a little bit more altitude from just the implementation details And so I think there's lots of challenges with existing tools. For me, I think there are three, right? So the first is project management software tools. They're greedy for attention. They want you to account for everything you'll do or are doing with very little differentiated return on value. It's sort of like organization and structure upfront at the expense of letting people just get better at their craft. and letting them focus on doing just that. And then number two, the interfaces, and this is not a surprise to most people, the interfaces are bloated and complex, and people generally hate using them. It feels like extra work, especially if you want to tailor it to how you want to work, like I was mentioning before. And I think this is generally the case because these things were either designed primarily for bug tracking or note taking. um or for large organizations that didn't really perfect maybe their team topology structure um growing pains when they hire more people and they have tons of hyper dependent groups essentially waiting for each other and using outdated primitives in these tools and then lastly like um they're mostly based on two methodologies of work that aren't at least in our opinion entirely well suited for creative problem solving And that's Kanban and Scrum. And so whenever you open up most of these tools, you sort of have like these two options. And we think in these two paradigms where we forget that I think, for example, Kanban, this is primarily designed to visualize a reactive way of working. And if used improperly for innovative feature strategy and development. you'll be hard pressed to get normalized ticket sizes when you're doing new things all the time. So you'll never really be able to get your average throughput and run a proper cumulative flow diagram and know what your queue length is and the clear date of the nth ticket. Like I've never seen Kanban actually work because we're doing creative problem solving and software development, not manufacturing, which is where it came from. And then, you know, with Scrum and its backlog grooming, and sprint planning at events, you'll essentially be locally maximizing at best, right? Because we're always working on disjointed, busy work stuff and never really able to focus on whole completable and bounded features with maintained context. At best, like we'll drag on what we think are uniform and coherent pieces of work for longer than we wished, which was never really the point of Scrum. It was like, let's work in small little iterations. an iteration just being a funny word too which comes from the root of like redoing what you really should be doing is being incremental um a different point and so to apply any of these two methods correctly and this is the craziest point it not only really happens but even if you do they never really ever seem to be the best fit for innovative feature strategy and design and development and so it's it's really an interesting organizational predicament because we've all been essentially putting ourselves in this unknowingly um and so we've been let loose to figure out how to solve this and that's why in my experience most teams that i've ever worked with um there's just a lot of confusion about how we should work with video teams so we we end up praising just the individuals who are really really great at what they do um and not really knowing exactly how that gets done and this gets back to the original point i was sort of finished up on this like this is why when i came into contact with shape up it really reminded me of what those best teams kind of looked like and what they were doing having that conceptual design track before actually betting on making a decision about development and having the time to do that um yeah anyway so yeah and and if you look at the big tech companies like amazon and facebook meta apple and so on they don't work with scrum or they don't work with a fixed process but they end up a lot of times with principles that are very close to what shape up formulated at the end so it's a really interesting organic development of state-of-the-art software development but in a kind of yeah it's principles that you could apply to a project and it's the first time and to my knowledge that somebody really really wrote it down and the problem with the tooling maybe to add on this is as matt said kanban is from the manufacturing from a manufacturing process but building software is a design process and this is why a lot of the standardized processes do not work when you develop software because you you have you are in the realm of creative problem solving and not of doing repetitive tasks over and over and um yeah so this is i think the the problem with the current tooling and people who solve the tooling and in my experience with who i had contact either through customer interviews for the tooling or by consulting work was they are doing it in kind of a whiteboard tool. They come up with their own solution or just on a Confluence page. They use a very universal tool to solve it and not solve it within the ticket system. And what we built was inspired by things that are already working in a whiteboard or in a self-developed way. Yeah, that definitely resonates with the teams that I've spoken with as well. They do a lot of the work of figuring out the scopes and kind of capturing the work and then tracking it in stuff like Miro, as you mentioned, like a whiteboard tool that is basically just a shared canvas that people can look at. Matt. One aspect of you kind of posting this message and in a way committing to, hey, I want to build something here. I want to just complete the picture by asking, where were you and mentally, what was driving you and your ambition for making a project out of this? I think it was just that. It was just seeing teams that every team I've worked with, I would say 99% of the people that I've worked with, didn't know about shape up i mean we're talking about like a very um i you know i've turned a couple of um my close engineering friends onto it and they've they've tried as well to implement and listening to their challenges you know when you're working in these early stage startups um there's so much like stuff that's done by the hip um or like opportunity driven sort of decisions and less uh conviction and focus on like this is what i know like there's some direction that i feel is right here and we're going to change and we're going to adapt as we go but um a lot of the times there's there's a lack of conviction about what that direction might even be and so there isn't really a mature foundation for like really putting in um some of these principles into an organization. So for me, I knew that if there was time and there was the ability to do that, that some of these organizations would find a pace that made sense for the kind of work that they're building. And you generally see this pace not happening in an ideal way when you have very non-technical or not very familiar product development experts running. organizations um where there's conflicting interests that make it prevent them from being a real product company and so i think that there's just there are some experiences i've had where like you know you're we're clearly at a product development shop and it shouldn't be hard to figure out what our pace should be and how we should invest in projects and how teams should spend their time and how we can start to do things that are much more real and connected to what we're going to do versus talking about what we'd like to do um yeah and so i was thinking like you know how can we i think i think a lot of it came down to inspiring me to say like are there some tools that we can develop that just create the energies needed for doing real work versus just accounting for it and tracking it and assigning stuff and like you know there's got to be something out there that can help people just say like look if you're working in code you're pretty much doing at least half of the right thing like because you're doing as a form of thinking but there's this other part of the stack that isn't just coding um that i think there's this whole mess of like tools that don't really warrant their um value in your headspace um so i i think it was mainly that i was like just getting people to be in the right tools because those kinds of tools wouldn't create dead documents or they they wouldn't just be like endless mirror boards with like workshops in them or something um but like real stuff that sets a direction that we could make an informed decision about either doing or not doing um and there just weren't those those guidelines you know i think you'd have to really become one of those shape up community experts to like have and have enough people around you who you're working with, like Klaus and I are, and then just let it fly. You could probably get away with no tooling. So I think the ultimate test is with whatever it is that Klaus and I end up building after what we've already done, how useful it is to us as well. Yeah, I think... when when you know shape up it's pretty easy to do it with whatever tooling you have i i have used shape up with gyra even um but if you don't if you don't know shape up you need some i think at least a little guidance could help um a little guidance that is independent from the current tooling could help with applying the principles of shape up yeah so I maybe this is the perfect moment to to have a look at what you are actually building and we did discuss this beforehand so this you know as a podcast most people will consume this audio only we decided to to go into screen share either way so if you're listening to this make sure to check out the YouTube video for this part I'm going to link the timestamp in the show notes so you can know where to look at But yeah, I'd love to just see what you have done and then you try to talk us through what we're seeing and the concepts of what you've built. If you don't mind, just before we do that, David, just to set the context here of like, we're going to show you where we're at today, but I want to just sort of explain some of the questions that we asked ourselves and why we thought they were important. So we started to ask ourselves questions like, how can we help creative problem solvers shape a feature so it sets the direction for implementation teams at the right level of abstraction right so shaping how can we help teams package their conceptual work into a two-way document designed to function as an input guide for the development and design cycle so documents that are like really dedicated for this back and forth and packaging or auto packaging that shape work and then how can we also help teams organize bets to select or ignore versus manage a backlog. So some sort of pipeline, right? And then finally, like, how can we help teams figure out, you know, the details of the work to bring planning into the development cycle, which a lot of engineers I've worked with in the past have been confused about. It's like, you plan things up front, we have to know what we're doing. How do we bring that into the build cycle instead of trying to plan everything up front versus, you know, be a place. versus just being a place to account for the work to do. And so what we hope we'll end up with is a lightweight toolkit that essentially helps improve team collaboration, communication, and upskilling the talent across product companies. So that while you're using these tools, you're using them because they're useful in making the software that you're trying to develop, like you would see in creator tools, like in a Figma, for example, or in some script editor. but that they're also giving you the value back in terms of organizational data structures and things like this so just to wrap up like we see a future where disjointed ticket work is not going to be the mainstay but shaping the boundaries of a solution path is that tools like figma they're going to be used in a more targeted way when high fidelity is needed to spike on some interface design instead of just saying like let's just work in this thing and get everything pixel perfect before we go into development, i.e. this like planning things up front. And I think we'll see more designers becoming front-end developers or front-end developers taking on more design functions and working in the native and web materials directly. And then two more points, I think we'll also see non-technical people becoming more effective partners in the process of development. of in-flight projects and making better trade-off decisions and then um a point class brought up the other day which i thought was great was like you know there's going to be a lot of solopreneurs and um with the advent of you know better no code and ai technologies we're going to see much more um like just more great work coming from small dedicated teams who need specialized purpose-built tools that are valuable beyond the primitives of transparency and actually helping software makers make software. So just to put those things in context before we jump in. Yeah. So this is the tool. The tool is called dump.link. And what you see, we have a couple of different steps. So it's targeted at teams currently building within a build cycle. and we have three different steps here and the first step we have is called our we have a dump area and we have a task grouper so here for example if you remember the kickoff exercise from ryan or this in general the concept of affinitizing it's like you dump all the tasks inside here and by the way this is fully collaborative so if somebody else knowing the link um could just open it and and join me and then we could collect as a team collaboratively all the tasks here so some more tasks and then the next step in the affinitizing you would group all those things so you would move those tasks into certain task buckets that are closely related so that you can independently ship from each other so you move the tasks into the buckets basically here and key thing is they're unnamed because we don't want people to create these arbitrary categories but let what they think develop speak for itself yeah there are unnamed at the beginning and and you name them once you have the tasks and so for example you figure out one of the buckets is there to build a scope with the name dump area maybe another bucket here is the so-called task grouper i don't know i just do the scopes we have in our own project and then you would maybe have a sequencer and maybe at one point you realize oh no um this actually is a task for something else with the arranger and yeah maybe while you're doing it you you come up with even more ideas um like have a podcast record or um marketing reach out and so on so you could either do it in the dump area as a collective brainstorming thing or while you're using the tool you could just add to those buckets you already have and you could you could name them and you can see that we're not we're really forcing people to think at that second order view where they're not at the implementation details on a kanban board where it's really not about thinking in terms of tracking but more about what are the components of this project or this thing you're working on exactly yes and if i have the tasks in the buckets i can just if i have done them i can i can click the check box here and and you see this overview um this is not a progress bar it's more like a risk ratio um we leaned a little bit on the concept of hill charts and in base camp but we wanted to have it more organically so all right we have orange tasks and those are the tasks we are still figuring out and if i have um checked something here it's it's figured out and so the risk ratio is is changing all the time and i can do this yeah for all of them i have also the possibility at one point to flag the to flag a bucket because maybe we have some unknowns here and at the end it could have the meaning every team gives the flag but in my cases the flag mostly means danger or meant a lot of unknowns we don't know what we what we do here um yeah and Once you have completed all the tasks, this affordance here on the top changes because now you could just say this whole bucket is done and then this bucket is done. I think there's an important component there if you uncheck the box as quickly like the. you know now we're finally in every task has been figured out and it's not until every task is figured out that then you can say well i might still be working on some of these tasks even though they're figured out there's just no more unknowns um there's no more um but it might be that there's still things to solve and so it's not until every task is figured out that then we give you this opportunity to say well when you're done you're done and then there's just no more risk so as long as there's one task still in a figured out stage we consider that the scope of or what we're calling task groups here at risk yeah because maybe you're while you're working on it you want to add more so and now we have a other risk ratio again and you need to finish them before you can really complete the scope yeah this is amazing it relates to this imagined work versus discovered work notion right So that resonated quite visually immediately with me. Yeah, we see people at the beginning of maybe a build cycle, like coming up with these initial tasks, or you can call it imagined work. And then eventually as you're working, this is what we meant by planning as a part of the process of development or in the context of construction, because as you work, tasks come up. And so that's why Klaus can show how you're adding tasks to maybe an already existing scope or task group here. But one thing... point out too is um that the when you have this default state where you bring in a ticket right or a task into a group it starts off in the figuring out stage right and that's just a default you might already kind of know what you need to do and you can just click it and then it goes into figure it out well now our tool has basically two um moments in in the process where i can use it so you can use it every day to track your tasks and track the progress on scopes and for this um you have also this this top bar here where you have the appetite for for example i have not still six weeks left because i just created it today and six weeks from now and it's january the ninth so if we also want to include the appetite here so that maybe in a product manager who is not on a daily basis in on a task level with the team he can quickly figure out this is how much time we have left a lot in this cases and not in this case and here we have the overview of the scopes so we have six scopes that we are figuring out and we have one scope that is already done and as it progresses It's just a good overview on a higher level to bridge the communication between product and engineering. And we realized, you know, these are snapshots in time. Like, as the project evolves, things can change. But this at least gives some people a common language around risk as it relates to the fixed time variable scope approach to work. And these very more like what Klaus was saying, more natural metrics, I think, are just the... better reflection of that kind of fixed time vario scope work and again like try not to have these tools especially at this stage where you're actually developing which is essentially a really fancy to-do list not be greedy for your attention like other task management tools where there's just three states here there's just unsolved solved and done or we call it figuring out figured out and done and those just feel like the most important states to track in creative problem solving like if you feel like you need to you know a uat column and you need a qaing column that's different than that or integrated testing and you need this like fine like you know uh we really haven't seen the need for that when you really think about it as long as the team is small and communicates this helps to be that bridged between business and development yeah it's just the importance that you think of those buckets as shippable scopes and and how the team then organizes itself itself within those shippables go it depends on the team we don't want to be prescriptive or i know i know there are certain teams who has the quality testing as a as a kind of final bucket as a final step but i think this is not as shape-up recommends it but yeah at the end you can You can do it like you want with this tool. But you still need to know the principles if you want to do it perfectly. But if you understand this concept of shapeable scopes, it's much easier to organize yourself in such buckets than in a Kanban with fixed columns for states for every ticket. Yeah. I think Claes is also saying the way I understand it, too, is like, when all tasks are figured out in a specific scope or in one of these task groups, we call it, it's at some point the team says, let's QA this, you know, it's because they're all ready to be tested together instead of individual tasks in a Kanban board. And I think this is not just having that second order view of things at the, you know, the language of the project level as, you know. shape up talks about it these these task groups isn't just good for communication about progress or movement in a project but also for the teams themselves so for qa like when is this thing needing to be tested before we call it done yeah good point and also maybe a quick anecdote from uh from one of my shape up cycles where i was a part of a where i was developing code so normally if you have designer feedback in a kanban way where you have it in the in the very last column most of the times you get then you get ui design feedback and the font is too big or too small and this is the worst for me for a developer because then i need to go back in the whole context of this ticket and then i need to change the font size and then i move the ticket back again and it's still wrong and within shape up i as a developer wanted to have feedback from the designer so it's a complete opposition of push and pull because I want to finish the scope, I want the feedback, and I am currently in this context to implement this, what I want from the designer. And so this completely changes how people are working together. Yeah, definitely. I think that that's one of the most powerful concepts of ShapeUp for a lot of teams is these vertical slicers. It's really hard to grasp for the teams. I think we needed three or four cycles with having nobody with experience to really get it, how you want to organize yourself to work in shippable scope. So our first cycle had just had a QA stage at the end for two weeks. The next cycle, we had just two or three scopes. And you really need to learn as a team how you work within those scopes. And I did not know about this affinitizing method, which is basically the blueprint for this tool here, besides of some other advantages our tool have. So it was, yeah, we really want to provide some structure. But maybe I can continue a little bit because it's not just for the daily work for track your tasks. It's also for the initial planning session or for the initial kickoff when you start with a new project. Because this is where we have something we call the task group sequencer. And here you can create dependencies or sequences. of your of your buckets you have created in the screen before so for example the dump area is something i need to do first and then the the bunker the dump area allows allows me to work on the task grouper and if i have the task grouper and the this unlocks me to work for example on the um on the sequencer i'm currently in and task group also allows me to work on the arranger and if i have both of this then this allows me to do user tests so i can create some dependencies here some some sequence and if i have user tests i can i can do releasing and i can do marketing for example And maybe to give a, sorry, Klaus, to give a bit of a voice of what we are seeing here. Basically, the task groups that you created in the step before are laid out in a circle. And what you, Klaus, you were just doing was kind of linking them very, and here, you know, I might be fanboying a bit, but. uh it it immediately feels very lightweight of drawing these connections quickly between task groups how they are dependent on each other so now we're getting more into like a star shaped or a web of um of relationships so all the boxes are just created out of the buckets um we we collected the tasks in the first step and now we can easily draw connections between them technically it's a directed acyclic graph so one thing can lead to another but you can't have um cycles here and some call this also a spider graph but yeah at the end you end up with a lot of arrows going from one box to another the boxes are arranged arranged in a circle here and i i can also remove those dependencies so um by just by clicking on on one of them so and i can also make them there again so and for every box i have a list of all the dependencies and here you already see one of the first advantages that our tool has above a whiteboard because we have all the data in a structured way so we can color the boxes automatically because we know what tasks are done and we can also track the dependencies and this allows for a whole range of um other applications to be to be helpful so 1.2 on some of the principles we talked about earlier is like you know we don't want to be a greedy tool for your attention so it's like well we're you know you're going in here and you're you're doing stuff right uh so what's the real value you get out of this structure and we'll go into that with the arranger but notice this is not at the task level the implementations we're really keeping you at that level right above it at the task group level where you can really see and communicate about what your plan is and that's not only going to eventually be very like useful to the team itself but it's very anxiety reducing if you're not directly on the launch team itself and you might be just a reviewer or a partner or stakeholder or whatever you want to call it and you kind of just want to make sure that you feel like the team understands like hey like they're they're not just going into this without seeing where they're going to not or paint themselves into a corner and that they are focusing on the most unknowns or the biggest pieces first and they've thought through that and that not only again will show in a minute but like how that's valuable to the team but also to building trust in the organization through clear communication so we really see this as a communication tool at its core that you're building here and and like you said it's a spider web for people who aren't looking at this but eventually be much cleaner with the next tool we're going to show you Yep. Let's assume that these are all my dependencies I know of right now. They can always come back later and change them. And now I would go into the next step, which we call the task group arranger. And the task group arranger is here you have layers and the boxes that previously was organized in a kind of spider web spider graph a circle with a lot of arrows are now ordered by dependency starting with the with the box that have no other dependencies at the very top and then it leads to another box that is dependent on this um on this box on this bucket and and so on and so this gives you like the like a timeline this is like you you could just see how your project will unfold over time so here i see the task group is leading to arranger and sequencer and because it's in the next lane and those two are leading to settings and i i can also still do some adjustments so for the tasks that have no other dependencies i can i can optimize them a little bit because i'm here in this case there are We have something where one box unlocks two things. So we have two boxes in the next layer. But maybe I do not want to do both of them at the same time. So maybe I want to do first releasing and then marketing. So then I could just move the box down here and optimize it. And it's the same for basically every box that has no other... no other boxes depending on it so i could maybe rearrange it like this so here sequencer and arranger unlocks user tests but sequencer and arranger also unlocks settings which is in a different lane and because we know the dependencies from the other tool from our sequencer we can easily draw this foliation graph how it's sometimes called in scientific scientific wording where your sequence is unfolding over a couple of layers and you can really see the boundaries of the solution like if there were task groups that emerged in here that just didn't feel like they were part of the original package of shape work that you were using to set direction you could really immediately start to see that here like this is like as Shepa calls it, the language of the project and seeing things at this level. And sequence at this level really gives you a lot of, again, confidence that the team understands what you're doing. And we were just using some examples about clicking when something is done or being figured out. But technically, if you were doing this, you probably wouldn't see something in layer four that's done. If you were to come into a conversation with the team, you'd be like, hey, why did you all do that? user testing first like how is that done it doesn't make sense um and so what you can start to see is things that get done should actually happen in this downward causation sort of path um otherwise why did you sequence in this way um so you could have that be something that sparks conversation and you can see the risk ratios too right so you can start to see hey look like we're not really figuring anything out on a ranger sequencer because we're on task grouper right now start to have it conversation about what's really at risk when is that going to be done and you can then see this in relationship to the appetite time piece that we have up there where you see how much time you have left in the project so if for some you know let's assume you have one week left from a six-week budget you set and you have you know a whole bunch of things that are still being figured out you can start to say man we're really at risk here you know let's have a conversation like are we going to overrun if we are are we going to overrun with only solve tasks or things that are figured out if so maybe we can we can extend it if not maybe it makes sense to come back to this project because we have other options we need to execute so we'll get into those things later on but um yeah so you can start to see the relationship between your risk ratios over time around your scopes and your appetite bar and really have that spark a healthy conversation with the teams. Yeah. I think that just the visualization is so powerful in this where, you know, even if you were using other tools to track your work and trying to work those tools around the concept of scopes, you know, in JIRA, you might try to shoehorn epics into scopes or in the past, what I've done is, you know, I would just have a... I would pre-append tasks with a name like scope one and track it that way. But the clarity that such a picture provides is just orders of magnitude beyond naming scopes and trying to keep them in the head, the relationship between them and the sequence. And you have all the relations as data. So we have a lot of options to branch out in building specialized tooling for i don't know existing ticket ticket systems or maybe connect uh chira to the tasks here so and and you still keep your relation and your um sequence and your arranged foliation graph yeah so yeah we really see this as a good starting point um and what we can see too is that this whole time is not just about feeding the system information and getting no value back it's about a collaborative process with you in this tool to figure out yeah and get back helpful visualizations that let you plan better and communicate better with other people and so that's our first step it's fully collaborative so if i'm another user in another tab and by the way you can just right now we don't have a user sign up we just have a link that you can share with your team you put it in a slack channel or wherever and then they can just collaborate collaborate here let's say i'm another user in another tab and over time a lot of the things here will be figured out and done this directly updates the state in the in the other tab so you can keep it open on a on a big tv on your office wall if you like to see how a project is progressing we obviously have a lot of ideas what other things to do with the project state um maybe on a on a higher level if you are a head of product one needs to take care of a couple of different projects and you want to have a quick overview we have a lot of ideas um what we can do here but we really wanted to start with the work inside of a of a real team and with a It's a basic tool that everybody can use that is currently practicing ShapeUp or wants to start with ShapeUp. Yeah, because I mean, I've obviously heard a lot of case studies of teams that have adopted ShapeUp and they typically start with one person being passionate about it and bringing it to the team and advocating for trying it. And then in a way, what I feel like now seeing the tool or a tool. to aid this process in the stories that i've heard the person was the tool so they would always have had had to guide the team working through the first shape up cycles on how to scope how to yeah visualize progress or how to attack the project in a way and and being able to offload this responsibility in a way to a tool uh just for me it opens up a much larger adoption potential for shape up and i think it's a good point because you are talking less about it teams you know that somebody whether they're an engineer a product person or designer who wants to bring shape up in they can talk and talk and talk and educate forever but wouldn't it be great like a lot of the teams that i've talked to they're just like let's just do it you know yeah and okay well then how do i make it clear for you to understand it through seeing it And I think having this is at least you're going into that battle with something that lets you visualize the work. Like Kanban lets you visualize reactive work and, you know, first in, first out type approaches, whatever you can use it for. But this lets you visualize it for this methodology and beyond, honestly. So you're going in there with at least armed with something. Yeah. And it's also a good tool for kickoff maybe because we did a lot of customer interviews. As I said, also some consulting gigs with pretty chaotic startups. And sometimes when just the engineers come up with those buckets, you have sometimes a taste of waterfall comes back into how a team organizes itself because then you, I don't know, you have API preparation, front-end preparation and something else all depending on each other. this is really the spot where a product manager can work on a high on on the right level not too high and not not too deep down because the product manager is not interested in the in the in the tasks that were done here but just have a feeling if the the grouping is progressing and the the grouping is then really based on the on the real tasks and so um yeah it's it's really a good communication tool to bridge um product and and engineering and the the ability to make trade-offs in a project fundamentally they start with understanding what is the project and if you look at this you can you can immediately see like well couldn't we just do the sequencer in the next development cycle well just the grouper itself might be useful as a to-do list that's possible maybe we could launch this without But certainly just doing the sequencer would be weird. Like that wouldn't add much value. There's no connective tissue there to anything else. And so this is where I think a lot of people in like the pure agile community would poo poo meaningfully large feature development where like everything has to be like in days. It's like, well, if you're doing everything in days because you're trying to be so responsive to people's feedback, like. it just seems like you don't have any conviction. And so this is also a tool for people who want to do meaningfully large projects. So if you go into the settings class and show what you do when you first start a project is you name it, but you also configure your appetite timepiece, which is the question of how much time is worth spending on this thing. You will select that and in partnership with people in business, but also in technology say, look, you know, you want this done then. that's fixed time fixed scope what is this we need to bring in a culture variable scope but you want it predictability as to some version of this thing and you want to know when that should be done that's a progress that is progress that you've made with that leader of that organization but at least you can say instead of how long is this going to take you can really put the time budget in here and have that thing be the back pressure that's always visual to the team that's working in here to make those trade-off decisions with the right level of abstraction of the project in your face all the time yeah i um i'd love to understand how long you've been working on this now and what's the process been like for you so far it's a good question um um to be honest it's the our second approach on building shape-up tooling So when we started, we really thought about our own pains. And actually, I had two pains. I had not just the pain of the team working inside of the cycle. I also had the pain of how to organize the cycles. So who is shaping what, who is building what, the talent management. So this was our first approach. And we even built a prototype. But it turns out, at least at the customer interviews that this is highly specific to the organization and that you would compete with tools that are very deeply embedded already doing the job good enough like like a github projects or some something somebody mentioned or notion integrations all over the all over the teams we interviewed so you would compete with something that is working good enough and Yeah, and we also had a very nice chat with Ryan about it and learned a little bit of how he sees the majority of teams, how they are doing it. And ultimately, this led to a completely different approach. And right now, we could even use this tool while we are developing our tool. and really dog fooding what we are doing and this for me is a very it's a better positive sign than building something that is very yeah that is helping bureaucracy um in organizing talents and so on and if in in our top-down approach as i would call it or our first approach we were much too rigid and we assumed that a lot of the organizations are using the the ocean liner model that they all have the same cadence and this is also something that um ryan said that we may we should not assume that everybody is working with a fixed cadence but um the funny thing is now that we are coming bottom up with this tool starting on the individual team and having the structured data we can see a lot of possibilities how to build the next step the next layer above how to organize different teams working within those um fixed time cycles and yeah right i mean it was close to saying something about the the um we were using this we were dog fooding this because we could because it was useful in how we were building this because we were starting with the teams that are actually doing the work into something you mentioned earlier david which is the people who are usually bringing shape up into organizations are those who actually are on those implementation teams or have some sort of um you know like they they they have some uh value that they get from these teams working in a new way and going to them versus the tool that cost was just talking about which is more top down like how do i look across my entire organization and manage a shape-up process and see how the cycles are being utilized and who's allocated to what so they don't get allocated to something else to protect their attention it's a it's a thing that we can work back to but more from bottom up and it's an interesting thing maybe just for our b2b go-to-market strategy which is if we can use it today and the people who are trying to bring shape up into an organization today are coming from the you know direct or individual contributor side well then this is the place to start it seems at least yeah yeah yeah definitely that resonates just a lot with the the people that i've spoken with that would typically tended to be individual contributors wanting you know being inspired or or finding some sort of um just you know yeah where where shape of just resonated a lot with them and then when they try to push for getting a team to try shape up it it always involves a lot of advocacy politics kind of and using their relationship capital with you know the level above saying all right you get this as an experiment for a cycle whereas having a tool to give to them it feels like nobody has to know we're trying shape up right now in a way and then at some point we can say hey with you know this project we actually we shipped on time because look we were using these principles aided by this tooling exactly yeah awesome and time wise you asked how long does it take um to come to this point i mean i think matt posted his um posted in the shape up forum in june now and we are recording in november end of november and i would we did not work full time on it um but i think roughly it would be two to three months full time if you if you break it down um for each of us so it's uh and that that time period that class was talking about is like lead time like when this thing was just first the proof of a raw raw idea to the construction of this core team which is klaus and i and then moving toward that prototype and thinking about what we want to do and that then not being exactly where we want to start as the wedge and then coming to this and the cycle time for each of these things is different um so i i would say um you know not to um embarrass my uh co-founder here but it's worked extremely quickly and we've had a shared common language on what is we think we want and i think i would say the answer is fast when we actually decided what it is that we want to do because we just really understand how to like take the words out of each other's heads about what it is we should or shouldn't do there's a lot of shared understanding that's going on to class's original point about building within a community having that shared understanding is critical for speed for sure so so far i haven't read any kind of public announcement of this tool what is your plan uh towards rolling out or giving more people access and have you have you had other people use it yet for projects or how are you thinking about rolling this out and then maybe even your roadmap afterwards So what I just showed is literally the latest version one or two hours ago deployed. So it's really under, it's still under development right now, but the plan is to release it very soon. So we don't want to put out a polished product. It's just do what it's doing and then gather feedback. As I said, we don't do a user registration right now because this is not the main thing where we're creating value. We just want to have people using it. And if you as the listener goes on our homepage, dump.link, then you will see probably when it's finished. But at the time when you're hearing it, it will be finished. um there will be a button to just create a new dumpling board and then you can use it with your team and our plan is to just have it out there have it used by teams and then build upon upon this so maybe at one point enterprise customers have different requirements maybe at one point it needs an account registration but this is not this is not for now yeah it's it's very easy to adopt and you shouldn't let any current tooling get in the way of trying this honestly you know get get through that crazy mindset just if you think that this could add value to what you're doing we've made it as easy as possible to just click try it share it um and there's a lot more to come like we talked about earlier that it's going to really sort of um complement this piece you know this is a very very small part of the value stream architecture of this entire methodology and there are lots of exciting ideas that we have and so any support people can give by just using the product and sharing their thoughts i think is going to be really really helpful so if you're trying to build meaningfully large projects you know not too large but things that need that extra time this is a great tool for that And we're definitely excited to see people using it. As far as some other, you know, hopes about this product being able to be used in December, we are also, you know, like Klaus was mentioning, really, really dedicated to the ShapeUp community and want to make sure that we're going to adapt it and adjust things as needed to this community primarily. just know that you know we're small obviously and um to make some changes as needed so yeah yeah so if if it's working for you for the for the listener or if it's even if it's not working please let us know both of it because we we just want to put it out um and we really need to learn so if it's not working please approach us and if it's working would also be nice to hear from you Awesome. Yeah, I love the thinking you have around making it as easy as possible to adopt where a team can just pull it in for the next project and try it out, even alongside existing tooling. Exactly. I will not build user registration or billing before we have a meaningful amount of users. Cool. And I mean, we're coming up a bit on time, so I don't want to kind of... take up too much of your time but um you were speaking of developing this inside or for the community that you're part of um how has the interaction been uh while you were building it because i know you reached out to some people to understand their um their struggles with shape up how how has that played into what you were showing today and we should also mention that that david has helped us uh introduced to a lot of the people on his podcast um in the shape up community so thank you for that um yeah of course i mean yeah claus i'll let you take it first yeah we had uh so to be honest our first version we built completely without customer interviews and maybe this was an issue um but um the second version after customer interviews led to where we are now so we had an initial phase of customer interviews where we just wanted to understand the current state of tooling we had roughly 10 interviews there and then with some of them we did another round and let them try out the tool in a in a very early version but they will probably recognize it if they are watching this now or using it now so it um yeah this was so we how we how we ended up here but um we did not test every version and we just wanted to understand if we have the right fundamentals because um some of the interviewees we had they are in a head of or cto or cpo position and they are not necessarily the 100 the target group of using it in a day-to-day business Vision makers and I think having those connections and talking to them in these interviews was helpful and. It'll be even more enlightening when you get the champions of the tool who actually having to use it and then roll back that feedback to whoever's running that part of the organization to be like, hey, we hate this. We don't want to use this anymore. You know, these are the things have to change. But our interviews were generally structured around understanding how they got involved with shape. how implementing it or when that happened and what that was like to get it adopted, what were the challenges, and then we moved into focusing on the current tooling they're using to support that across teams. But to Klaus's point, there's a lot to learn from the builders, the launch teams themselves, and using this tool and what that will be like for them. Yeah. This is, for me personally, this is going to be really, really exciting to watch, to see. see the adoption and and yeah i'd love to kind of be able to follow along a bit your journey of of rolling this out um because i'm really excited for you guys to succeed with this thank you thank you yeah and thank you for being an awesome partner in all this and i don't know if i said this already but i love the podcast shapers and builders it's just direct to the point these are the people who actually do this is their name Yeah, I got lucky with thinking of that one. It was, I mean, the backstory to that is I wanted to build a job board for companies that use ShapeUp. And because at that time, the company I had worked at and where I had introduced ShapeUp was getting liquidated. And I was trying to find a place like where are companies that use ShapeUp. And so I also reached out to, in this case, Ryan, and then he forwarded that to Jason to say, hey, you know can i build a job board for companies using shape up and then he said yes but you can't use shape up in the name of the domain or the brand because i had already registered registered shapeupjobs.com and that forced me to go back to the drawing board and think of shapers and builders so that's kind of the the backstory to that i love it and it's it's a great idea i hope that that port that portal grows because the more organizations can understand if they recruit people who understand these things that the more that they can actually work collaboratively together because they have this sort of shared value system but it's also just this amazing pace and way of thinking about work that this conceptual design track that shaping has been missing for a long time and that separating different types of work whether it's reactive from planned work etc is critical and it's missed amongst so many organizations and so if you have companies that are working this way they should be finding ways to hire those people so um yeah really really cool work there awesome yeah thank you so much for your kind words um again kind of looking a bit at the time uh any famous last words that that you want to close with um anything that we didn't cover All right. Then, yeah, if you're listening to this, go to dump.link and check out the tool. Try it for yourself and give feedback to Matt and Klaus. Let them know what you think. Awesome. Exactly. Thank you, David. Thanks, David. All right. Thanks, everyone. Thank you so much. Bye. There you have it. I hope you enjoyed this exclusive look at how Klaus and Matt created DumpLink. I have a strong conviction that the right tooling can act as a massive accelerant for driving shape-up adoption and a feeling that DumpLink will do just that. Thank you so much Matt and Klaus for sharing your story with me today. Now go check out DumpLink at dump.link. Yup, that's the domain. And let the two know what you think. Thank you so much for listening and I hope you have a great day.

#Bonus: In season 1 of this podcast, I've been speaking with a lot of teams who have adopted Shape Up, a delivery framework originally created at Basecamp. If you've never heard of Shape Up, check below for a link to the video "Shaping in a nutshell" by Ryan Singer, former head of strategy at Basecamp and author of the book "Shape Up - Stop Running in Circles and Ship Work that Matters".

Today I am joined by Klaus Breyer and Matt Lane for a very special bonus episode. Matt and Klaus met through the Shape Up forum when Matt posted about seeking collaborators around a Shape Up tooling idea he had. 

This infamous post has now turned the two into co-founders for Dumplink, a lightweight project/task management tool for teams that use Shape Up. But really, calling it "project management software" is not doing it justice, for it's really a communication, de-risking, and sense-making tool for the build teams on software projects.

Listen to Klaus and Matt nerd out about "directed acyclic graphs" and "foliation graphs" and catch an exclusive demo of Dumplink. 

Make sure to listen carefully to find out how you can test Dumplink for yourself, today!

Links:
Matt's post in the Shape Up forum: https://discourse.learnshapeup.com/t/community-project-proposal-to-help-get-companies-started-with-shape-up/1069/1
Klaus' talk at the Shape Up Practitioners meetup: https://www.youtube.com/watch?v=XEnrFbR2qso

Dumplink: https://dump.link/

Shaping in a nutshell: https://www.youtube.com/watch?v=h_8M23wVjXk
Shapers & Builders job board: https://www.shapers.builders