QT: Jira, and kick-off meetings

 

 

Spotify | iTunes | Sticher | Google Play | Player.fm | MyTuner Radio

 

Hey folks, this is Dave Albert for quick take.

Hey, everybody, I hope you’re doing well. In this episode, I’m going to talk about JIRA, which has finally won out some workflow changes we’ve made that have really helped us and how we’ve continued to try to improve our process so that we can move faster.

So if you’ve been listening, you’ll know that I’ve been having the fight with myself over whether we should move to JIRA or not. Trello was great in the beginning and then as the team started to grow and we had more disparate work between the marketing team and the product team that it became untenable to try to manage that with any sort of planning is I mean, it was easy to lay out tasks and Trello and then work on the next available task. But if you’re trying to plan out some sort of roadmap, it just, it was nearly impossible, at least for us.

Now, if you’ve done it, I’d love to hear from you and how you did that. But I was not able to make it happen and no one else in the team was able to come up with a good solution. I’ve been having this fight with myself for well over a year and a half and I finally gave in and we had the opportunity to have an intern with some project management background and who’s currently learning agile methodologies. You know, I had a good grasp on those already myself. So I use that opportunity to go ahead and investigate if JIRA would work for us using the free trial. Of course, we’ve got a small team, so less than 10 people. That means that it’s only $10 a month, which Trello may be free, but we were paying more with product board which was working for us, but the expense of something like $600 a year per person who can edit just … just made it really a hassle. So only one person could update descriptions basically do anything other than make a comment so if you wanted to change your status, add, attachments or change what sprint it was going to be in or anything like that. Either you had to pay an additional five or $600 a year for that person or send it through your bottleneck. And if you’re familiar at all with no current faults on software development bottlenecks are your biggest issue. Well, not just software development, pretty much anything.

So I went ahead and tried JIRA. Well, we went ahead and tried JIRA. And it really did seem to start to make things a little bit easier. It did not solve all the problems. They did help us identify a number of places where we had problems and we instinctively knew but we had a harder time understanding how that we’re specifically the problem was and how we could address it. No, sorry. So we made some additional changes along with JIRA. But what I would say to myself in the past, as soon as we outgrew Trello we should just have moved to JIRA. There were we basically we were trying to recreate JIRA with product board and Trello or Confluence and Trello or Confluence and product board and Trello.

We’re still using Confluence to do some of our road mapping. I’m planning out when we expect to work on specific elements because we still don’t have a true understanding of how much work we can get through our system within any given timeframe. And all the work is is different size, different complexity. So it’s not unique in there. I mean, it’s not uniform. It’s all unique. So we don’t know how much we can get through. And we don’t know how many points each individual story would be because there’s too many unknowns and a lot of other work that we’re doing so there’s so much investigation and prototyping beforehand and not just a user prototype but a prototype of the technologies to make sure we understand how one might implement certain elements.

So, without that predictability, you know, we can’t really solve all of the problems. But some of the techniques that we’ve we’ve started to work with that seem to be making a positive impact very early on have been based around the fact that because we’re so busy and it feels like we’re so far behind where we want to be, we continue to keep trying to move faster and that causes us causes us to actually I don’t know if I would necessarily say make mistakes, but it causes us to have to revisit things. So I think I’ve talked about this before. But you know, you have your lead time, which is the time from when you to define something that should be implemented and the release time that’s your lead down, then you have cycle time, which is the time from when you start working on it until you finish working on it. And then you have the touch time the amount of time a designer works on the amount of time well actually step back the amount of time of your business person in air quotes. So whether that’s you know, you know, a user has decided they need something and … and you within your company, your team have decided to start working on it and understanding what the value is all that. Maybe done before beforehand. So that may or may not be part of the lead time. But there may be some investigations in user experience and the user interface design implementations of each of the different people.

So say for instance, we need API or we need data work and we need iOS development and Android development. So if … if the person working within the iOS team realizes that something is not yet the way it needs to be in the API, then there’s a back and forth between those two people that have has actually caused a slowdown because now your iOS developer has to stop. And then if he or she switches tasks, you know, there’s always the … the cost of task switching and context switching. The person who’s working on the API has to go back and make changes. So every time you have those back and forth, and rework required that actually extend your cycle time, the actual touch time gets extended a little bit with the cycle time gets extended a lot more, which of course, extend your lead time. So a couple ways that we found just which seems super obvious after you’ve implemented them and started to see the effects but when you’re running as fast as you can, sometimes it’s hard to see what’s right in front of you. Before we begin before we again, before we begin really implementing even to the user experience side of things, we start with more developed wireframes and then have a discussion around it with all the people involved, you know, the if there’s going to be data involved, we have them have, obviously the user experience, user interface, the business owner, product owner, which in our case is our CEO, the API developer operations which those are both usually me or sometimes our data engineer, our iOS developer and then we thoroughly interrogate those wireframes. We already found one issue that … where one story we were about to begin implementing … implementing that if we hadn’t had that meeting we would have had rework because it just it wasn’t obvious from the initial outset of a specific feature. So that needed to be included otherwise it wouldn’t it just wouldn’t be as a useful feature. So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potentially it could have just been rework of the useevinterface but that could have caused significant So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potentially it could have just been rework of the useevinterface but that could have caused significant So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potentially it could have just been rework of the useevinterface but that could have caused significant So that saved us rework which potentially it could have just been rework of the user interface but that could have caused significant So that saved us rework which potenavoid. We were able to make these time savings just by simply having these two short meetings before the initial design and before development kicked off. So yeah, I’m finding a lot of value in that. And, you know, we’re already identifying waste that we can remove.

JIRA has been a good thing so far we thought product board made sense in the way we had organized it had it just was inconvenient to manage the actual tasks without having full users for everyone in the team, and that was just too expensive. So yeah, if you were feeling like you’ve outgrown Trello seriously consider JIRA. But it’s funny how many Atlassian products we use, Confluence, JIRA, well, Trello was now Atlassian and bit bucket and the bit bucket pipelines. So, that’s the ultimate. That’s how we make our automated deployment pipeline work. Which there’s an episode on that which, if you’re interested, you should definitely listen to. You know, I’m definitely not Atlassian fanboy. It’s it’s funny. It’s almost like I use the products in spiks without having full users for everyone in the team, and that was just too expensive. So yeah, if you were feeling like you’ve outgrown Trello seriously consider JIRA. But it’s funny how many Atlassian products we use, Confluence, JIRA, well, Trello was now Atlassian and bit bucket and the bit bucket pipelines. So, that’s the ultimate. That’s how we make our automated deployment pipeline work. Which there’s an epis right now, Confluence in JIRA and Bitbucket are really good solutions for what currently exist. I’d love something even better. And I’m sure that’s what everyone there is trying to do can take is to continue to improve it to make it what we all want it to be. But then again everybody has a different opinion of what we’ll be right so I don’t know. I’d love to hear your thoughts you can email me at [email protected] or on Twitter @Dave_Albert

This episode was planned to be a longer episode but I got through that much quicker. So I guess this is a quick take a little bit long for a quick take, but it’s a little bit short for long take full episode I suppose. So thanks for listening.

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