#AgileMM May 2022 - English Edition - Book Club "Shape Up" by Ryan Singer in 15 minutes

Hello and welcome to our Agile MM in May 2022. Today we do an experiment. We will do our Agile Meetwork-Mittag's Pause in English and we will talk about book. Normally our meetings are in German and take place on every third Wednesday in months. So every third day of every third week. Yeah. Okay, then let's talk about the book and this is Book Shape Up by Ryan Singer from Basecamp. So what this book is about? It describes in detail the software product development process, how they live it in Basecamp. They came to it after many years of experiments and of productive software development. So how they work? First it begins... Every feature and so on begins with the shaping. So there is six week shaping cycle where one or two shapers normally it's somebody with the product background and can be supported by somebody technical, define the rough idea and how should it be implemented. Then they create a pitch. The pitch pitches come to the betting table where the CEO, CTO and Ryan himself decide what will come in the next building cycle. The building cycle is also six weeks and it can contain, we can have one team working the whole six weeks on one feature or you can have teams that work on smaller features which last like one, two or three weeks. The teams, the building teams have one designer and one or two programmers in them. So how does shaping work? The idea of the shaping is to have to prepare like the shape worked. So something which is not so abstract like couple of sentences in the requirements, but something which is also not so concrete like already worked out wireframes. So how it works? You start with a problem. Then you set boundaries. You set boundaries not only for the time for the development, but also for the shaping time. Then you define roughly the elements. So it's really a rather high level draft and the main elements that should be there. And it's not up to detail, as I said earlier. You think of all the risk and rabbit holes that may occur. In this part, you also present your solution to technical experts if they are not already part of the team. And in the end, you write the pitch. The pitch contains the problem so that people understand what are they actually trying to solve. So it's not like, oh, we're making a calendar or we're doing a bit of file management. No, they really understand what's the problem. For example, here with calendar, the problem was that the people wanted to see their free slots in the next two months. and which free slot they could give for the next meeting. Then you define the appetite. Appetite is a bit opposite of the estimation, so how it's normally done in the project. You define how much time do you want to spend on this problem. So you can say, okay, this problem in six weeks, I can have this and this and this other features, they will not be able to implement. Yeah, in a normal project there are a lot of possibilities that in the end you spend too much time on something. Then it also contains the rough solution. As I already said, it contains the main element, but there is still a lot of free space for the team to design it and to make here more details. It contains the rabbit holes and possible risks, so that you make people aware what they shouldn't do and it contains not both so the things that are out of scope so that people in the six-week cycles don't lose time on them. Then the next phase is betting. In the betting there is no big backlog. The only thing that people at the betting table work with are the pitches from the last six weeks, are the previous pitches if somebody wanted to bring them to the table again. And of course, information about availability of the team. All the pitches are previously made available for the whole team. By the way, during the shaping, the pitches are not available. It's done behind the closed doors so that people can do it on their own. And if the idea is not worth it, then they can throw it away. Before the betting starts, the whole team can see the pitch, can comment on the pitch, can perhaps point out other aspects that they haven't been noticed before. And after that, the pitches come to the betting table. At the betting table, the base camp, like head people, the CTO, CEO and Ryan asks following questions regarding the pitches that they get so that they can get the best solution, whether it's the right time to implement something or not. So whether something really should come into the next cycle. And the output of this whole betting is the cycle plan, so that you know who is doing what in the next six weeks. And the planning is done only one cycle in a time, so that they can react to the changes. And then comes the betting phase. In the betting phase, during the kickoff, the pitch is presented once again to the team, to the development team, which is one or two developers and designer, and then responsibility is handed over to them. So they get uninterrupted time so that they can work really on this problem and not that there are no bugs coming in the whole time, for example, but at the same time, by default, they get no extensions. So if you have betting on something for six weeks, Then at the end of these six weeks, this feature should be developed and developed means also tested and deployed. How you should start? Well, as in other agile methods, the good practice would be to get one piece done. And this piece should be core functionality, it should be small enough and novel. And if you have a feature that goes through multiple levels, then it should go through all the levels. slice. Yeah, another practice that they do, they don't do like work breakdown structures, but they do scope mapping so that you see here, here is my scope, you see single feature that belong to this scope and then you can tick the boxes. And another metaphor that I liked very much is the uphill versus downhill work. So Of course, also in the base camp you need to show your progress. But normally, when... I mean, I'm always struggling when I'm being asked how much percent is already done, because actually at the beginning you don't know where you are and how much work is awaiting you. If you don't think it's something which you haven't done a hundred times before, but this is the seldom case nowadays. So here is the metaphor that at the beginning, when you have a lot of unknowns... then you are doing the uphill work. But then when all unknowns are clarified and it's just like work, like doing normal work, only developing, developing, developing, then you are on the downhill. And this is, for example, one of criteria when the project can be extended. If you finish somewhere here and you have only downhill work, then it could be extended. So, Another point which is highlighted in the book is where to stop. And one idea that I liked it very much. It also shows why people who get silver are not happy and people who get bronze are happy. Because the people who get silver compare themselves with gold and the people who get bronze compare themselves with the baseline, which means getting nothing at all. And we should be... all happy like the people who got pros in some competition yeah so and here when this cops is keeping creeping then in the book you have this checklist of the question to ask so do you really need this feature and here are some parameters for how you can test it another aspect is i also like it very much how they handle bugs and Normally, it probably also happened to you, then people say, oh, if you see bugs, then we need to fix it. But it's actually not always the case. Yeah, okay, if there is an emergency, then you have to drop everything and then fix it. But real crises are rare, at least they are rare at Basecamp. That's why what is normal approach to fix like... medium and not so important bugs. One would be use cooldown phase. This is the two weeks between six weeks of the titles. Another option would be bring the bugs to the betting table if they are too big or once a year Basecamp schedules a bug smash. So this is a whole cycle dedicated only to bugs. I mean, I really like this book, but if... I would implement it into like not product company, but to consulting IT consulting company. So somebody who develops software for one, for example, big client, then I would see several challenges. One would be uninterrupted time. I mean, when the customers say the bug is important, then it has to be interrupted. There are also adjustments always coming in. As a product you can control it better. If in a big company you have some other departments who have some special requirements, then you have to comply with them. And I also suppose that they have less dependencies to external systems, which is normally in IT consulting, it's rather the case. Another way I wrote Stellar, well I think Basecap. has really great developers. So even the juniors should be really good people. That means if you have such developers that you need less preparation, they can get better code structure, better bugs, better tests, and you can also work with smaller teams. You don't need some requirements in your business analyst to prepare it for you because the developers can understand it directly. Yeah, the third point, which might be different in Basecamp compared to other companies, that they have really easy company structure. And that means that all decisions can be taken in one meeting. And another point is also that they have constraints, so they're paying their own money. And I think it's a big difference when this guy decides whether to implement something or not, whether you pay for it yourself or it's somebody else's money. But there are many ideas that could be applied in any project, I would say. First idea is the shaping, how it's described in the book, can really be done before a big team or larger team starts to work on the solution, even for agile projects. So if you would have, I don't know, core people, product person, architect. working on the solution before everybody else joins you so that you prepare shaped work so to say then the uninterrupted work is really great every neuroscientist would say this so the more uninterrupted work the more focus you have the better and that's why it would be good to batch bugs or some smaller things into cycles and then let other cycles to do big, big things so that the people don't have to switch the context all the time. Then the constraints. It's really easy to ask, oh, what would be good, whether X is possible, but actually you shouldn't ask this. You should ask whether function X is possible to be done in two weeks, in three weeks, in six weeks. So you're always... better put constraints to your question and to your wishes and then you can decide much better what to do and what not. The metaphor that I like very much is this uphill versus downhill work. It can be also used for status and I would assume it would be also understandable by management and people who read status reports. The small thing, but I think it's also nice is to put a tilde before nice perhaps. in Jira when you create them and the checklist that I've checked that I've shared previously for improvements. I also think this is a nice checklist to go through when you are considering the feature or a bug. So thank you very much and I really recommend this book. There are much more in it than I presented to you. So have fun reading it and hopefully you will find some ideas for you to work with. Thank you.

In May 2022, in #AgileMM (Agile Mittwochs-Mittagspause) we tried a new format. First, the meeting was in English, second, it was a book presentation. The book "Shape Up, Stop running in circles and ship the work that matters" describes how Basecamp (aka 37signals) shapes, bets and builds its products. This video summarizes the main points of the book and also contains couple of thoughts what would be challenging and what could be easily applied in IT consulting and service companies.

I highly recommend this book, you can download it for free or purchase a print edition at https://basecamp.com/shapeup 

More information about #AgileMM: https://www.agilemm.org/

And apologies for the bad sound quality.

00:00 - #AgileMM
00:33 - Book "Shape Up" and 6-week cycles
02:00 - Shaping
04:33 - Betting
06:14 - Building (Not betting;)
08:42 - Decide where to stop
09:37 - How to handle bugs
10:40 - Challenges for IT consulting or service companies
12:45 - What can be applied to any project