QT: Changing to a delivery mindset

Hey folks! This is Dave Albert for a quick take.

On this quick take, I’m going to talk about changing your mindset from a typical developer to a delivery mindset.

So in the early days of using Trello to basically manage all of our tasks, I basically thought of everything in the way that a developer would think of them and would are basically split things up into multiple elements. So API needs to develop this data needs to develop this and iOS needs to develop this element and then there’s an operational bit. The problem was that it wasn’t obvious to the team when there was overlap, so for instance, there were a number of times where through my own poor planning, obviously, the iOS developers would be ready to implement something, but the API would not be ready. And so even with mocking that out, it was much harder to understand how that actually was going to work when it was integrated. So we went through a pretty long phase of not being happy with the predictability that we had. So we had a meetup, we have a number of developers in India who are part of our team and they one of them came over and one of our marketing folks from India came over to Dublin, Ireland, for those of you who don’t know, and I had a discussion about how we could be more predictable and more Agile, not not in the typical software development lifecycle, Agile terminology, but in the responsive to needs Agile. And one of the things we came up with was that if we were to change our mindset to actually we … our iOS developer from India, Raj, Rajkumar, he came up with the idea of switching our mindset to a more delivery-focused mindset. And so what we did was began to I guess, basically what you could say is we kind of switched to more of a user story thought process, but really what it was was we changed to what needs to be delivered. So X feature we want that delivered. And then within the trailer task, we split it out into the number of things that need to be done to complete that. So we had one board, we called the delivery board and another board, the development board. And so we would as a full team, including the marketing group, groom, our deliverable board, and then from there, things would flow over to the developer board. And that definitely improved our process we got to be I wouldn’t want to say that we were more predictable because with a small team and a startup you have unexpected and events happen all the time. But we were able to forecast within the week better if we were going to be able to deliver something that process still needs more work.

We’ve started to integrate a tool called product board. And this was needed so that our CEO can understand better when things will be developed. So the longer term planning so we’ve had a hard time trying to lay down how to write a roadmap properly so that we understand what’s going to be available when so that she can go and begin to sell elements to our partners, customers, clients, users, etc. And she didn’t have that and Trello really is not good at that. And I’ve had the discussion inside my own head about switching from Trello to JIRA probably every month since I started. It’s not that I like JIRA. I mean, it’s a good tool, I guess. But all the experiences I’ve had with it, it becomes unwieldy and it’s hard to keep the work that’s important in front of you. And obviously having a team that is split across multiple locations and we allow working from home you know, whenever it’s needed. Most of us work from home on a Friday and if you have any sort of appointment or whatever that you need throughout the day, that no problem or if the weather’s bad, so you know, we want to be very flexible, it’s also nice to have that camaraderie within the Office, but we can’t have a physical board that just doesn’t really work for us. So using Trello and product board has sort of worked for us. I mean, it’s it’s an ongoing journey of, I don’t know I it’s one of the things that I feel the worst about my performance as keeping the team groomed, I mean, not a team groomed, which I don’t go around like a monkey picking hair, picking bugs out of the individuals hair but keeping the tasks groomed and prioritized so that everybody knows what they should be working on. We’re very good at making sure everybody’s working on the most important thing at any given point in a day and pretty solid within a week, what needs to be done the next week and the next week were not very good at at all. Which makes it nearly impossible for future planning to to do pre-sales development, pre-partnership development. So you know laying groundwork for launching partnerships and sales and I don’t know how to solve that. I know we don’t do a good enough job at it and ha ha the the royal we, I don’t do a good enough job making sure that happens because it falls on me as the CTO.

My CEO, she is dealing with a number of elements that are keeping us in business while we’re still developing our product revenue generation. So you know, it falls to me to become more of a not more of but the defacto product owner and partial Scrum Master. I don’t even know if you would call what we do Scrum, exactly. It’s kind of gone back and forth from pure Kanban to Scrum to Scrum-ban. As we hit, we have a lot of really good elements within the theme. I mean, the team is amazing. The way we work is pretty good. But, you know, I’m, I’m an overachiever. Most of the people on the team are and want to be better all the time. So you have to go and look for your faults to be able to keep improving. So I don’t know there’s no great point to this. It’s just that we we’ve had trouble I’ve talked to other people who’ve had trouble In large organizations, and they’ve had trouble. So obviously there’s huge industry around software development lifecycle and Agile and I don’t know how to solve it. Well, I kind of do having a product owner and a scrum master or whatever equivalent it is in Kanban. I don’t know what that’s called. That’s the solution. But we don’t have the budget for two additional people for that role. So I don’t know I’ve got a few friends who work very closely in Agile and I hope to have them on the podcast and talk to them about how how they think we might solve this problem. I don’t know it’s just the you know, the more the deeper you dig into anything, the more value you find in different areas. So I always thought that potentially a fully functioning will form team could do okay with less of an emphasis on Agile facilitators, I guess is what I will call that for product owner and Scrum Master. I mean, you know, our UX guy Philippe, who I hope to also have on the podcast is really he’s amazing at owning the impact to the user and on definitely making sure on each thing that we work on that we do it to the best of the abilities for at least what’s good enough and it must be good enough, not garbage we, you know, it always has to be good. It may not be great yet it will be. But that doesn’t mean that he’s able to necessarily do all of his work and also help prioritize what needs to be done in what order. So, you know, there’s not enough of him to go around to do design work, UX work front-end development on the website, and all the other bits that he deals with. And also on top of that, do this product on a roll. I’m just I’m apparently not good at it. I want to either be helping facilitate the team, you know, building the team, which I guess you could say that facility facilitating the team is ensuring everyone knows what they’re working on and what’s coming next. I guess is that liaison between the business side and the technical side where I failed the most. I think I think I did a solid job keeping the team happy. I think I need to do a better job of one on ones with the people in the team to make sure that everyone is happy but I sure do hope that they know that if there’s anything that they ever want to talk about they can always talk to me I’ve told him that before but yeah i’m i’m going to get back to having more one on ones.

So this was supposed to be a quick take me 12 minutes that’s not too bad. So I’ll go ahead and leave it as a quick take, it’s longer than I expected. And apologies if you’ve expected quick takes to be quicker or even more to the point but I think I think this this, if you plan to be a CTO of a startup for the first time, or a co-founder, that’s all this uncertainty that you have to learn to, if not embrace, just not be overwhelmed by and I guess that’s what this really turned into a planning is really, really, really hard estimation is really, really, really hard. Doing that on top of trying to deliver an amazing product for your users, it’s really, really hard. So yeah, I don’t have a great takeaway for you on this one. I wish I did. But I really do hope to talk to some some folks that are deep into Agile in the near future and see if we can you know, just discuss strategies that will help me and help you, so if anyone out there is listening and has any input on this, I’d love to hear what you have to say.

As always, you can email me [email protected] or hit me up on Twitter @Dave_Albert. You can tweet at me or you can DM me, my DMs are open. So I hope to talk to you soon. Take care.

Until next time, remember any sufficiently advanced technology is indistinguishable from magic.