The panelists talk to Jeff Gilbert about finding a process that works well for teams.

 
CHUCK:

Finding a process that works for your team. I have a funny feeling we’re going to talk a little about Agile. [Chuckling]

Hopefully.

Hey everybody and welcome to episode 89 of the iPhreaks Show. This week on our panel we have Alondo Brewington.

Hello, from North Carolina.

Jaim Zuber.

Hello!

Pete Hodgson.

Hello from Hollywood, California.

I’m Charles Max Wood from DevChat.TV. And this week, we have a special guest, Jeff Gilbert.

Howdy, from Austin, Texas.

I’m pretty sure we’ve had you on the show before but do you want to introduce yourself again?

Yeah, I’m Jeff Gilbert. I’m an iOS architect at Mutual Mobile. So we do development for other companies for a number of apps.

Oh cool! We’re getting into a softer topic. We tend to talk a lot about the technology in iOS and then, occasionally if it’s just Jaim and I, we’ll talk about freelancing. And this week, we’re talking a little bit more on the soft topics like finding a process that works for your team or things like that.

First off, how do you work in your company? What’s the process that you have? And then maybe you can back us into how you got there.

Yeah! So basically, we follow Scrum – two-week sprints, etc. It’s nice that we have – all of those different roles you might play are actually different individuals. So, we have a full QA department. We have interaction designers. We have visual designers. We have uppers – project managers. So everybody really only needs to wear one hat versus an independent developer may have to wear ten hats. It makes it easier in that sense that everybody’s role is a little more clear and more focused.

As far as our process, when we start a new project, we go through discovery where we have a little – work with the client for a week or two to really understand what their business needs are, and all the initial high level requirements and will come out of that. And then we will do backlog grooming and sprint planning and where we pick off which stories we’re going to do for that sprint. We usually try to allow the designer to stay one sprint ahead of us. Say for the sprint zero, they may start to do some of the initial interactions and digital designs. While in sprint zero, the developers will just be getting the project build system ready to go.

And as far as tooling, we are really big on the Atlassian Tool Suite. And so we use Stash as our git repo and Bamboo for our CI system and Confluence for a place to communicate our requirements, etc. And so, the developers will be getting the whole build system up and running. And then, by the time sprint one starts, we already have visual designs that we can start to implement for the stories that we pick.

Are these web projects or iOS projects or both?

Well, they all seem to work that way. I mean – so at Mutual Mobile, we have iOS developers, we have web developers and we have android developers; and we even had Windows at one point when there was interest in Windows development. But yeah, we can sort of [inaudible 04:19] different major platforms these days. And we all – all of the different teams work in a similar fashion. And it is common for us to maybe target, part of the same project to target multiple platforms, simultaneously. The project I’m working on now, we actually have android and iOS work going on at the same time.

I’m curious. Do you find any little tweaks you need to make for the process for developing native versus web? Just because you got that external constraint of the App Store or the play store where you can’t release – you can’t do continuous deployment for example. Do you find that the web application route is a slightly different tweak to the process? Or is it pretty much the same despite that?

Overall, it’s the same. I would imagine the stories that they pick will be different because – yes, as you say, with the web apps, they can actually deploy those a lot more frequently. Whereas with iOS, even though we are running in these two-week sprints, it’s usually several months before we have a release ready for the App Store and so I can allow us to change up the order in which we pick the stories that we’re going to work on because you have to allow us to spread the story out over multiple sprints. If we know we don’t have to actually ship a simple version now and add on to it, we can actually just take it all the way to completion.

Actually, that makes sense.

Do you wind up adjusting your process from one team to another because different people work better under certain circumstances than others? Or do you try and just hire people that will all work the same process?

At a high level, I don’t think it changes a whole lot. But once we are within a sprint, we’ll certainly try to do things differently. And I see Scrum mainly as A – the project management side of Agile. The actual engineering practices will certainly change based on the makeup of the team. Personally, I’m a big fan of TDD and I try to encourage that in the teams I work with. And based on the experience and comfort level of the people on any particular team, I will try and either push them more to do that or maybe just even help them learn to take the next baby step in that.

Are you guys, typically just Mutual Mobile folks for all of the roles or is it sometimes co-sourced with the client? Because I find that often changes the process because different clients obviously want to work slightly differently or have different comfort levels with different engineering practices – that kind of stuff.

Yeah, our most common environment in the one we [inaudible 06:43] where we do take everything completely in-house and we’re responsible for everything – QA, design, development. Sometimes, projects will come along and maybe we only get to do the design and the client may have their own in-house developers. Or sometimes, we’ll do the development and design may be done in-house. And that certainly does complicate the situation just because – well, as always, communication is critical; and when the team is separated, like if design is done here, and development is done – say done by the client, it’s just harder on a daily basis to keep the teams up on top on what’s going along with each other.

And as far as the way our office is arranged, here at Mutual Mobile, it’s a large open floor space. And we collect our desks in what we call pods. So, all the team members will put desks together. And so you’ll actually have the design, dev, QA, project management all sitting right next to each other. And then when your project is finished, you’ll pick up your stuff and move to another desk wherever that next team happens to be located. And just having that – being that close to each other, it’s just easy to overhear – maybe the designers are clocking up some cells. And you may just pick up on something that they’ve mentioned and then you’ll notice a problem. It allows you to have a problem sooner than later.

What role and relationship you have with the QA portion of your development process? Is that an external group? Is it client supplied or do you have internal?

Oh, we have our own internal QA department. And a lot of times, our QA will come up with test objectives. And they’ll actually do a lot of the testing for your release. But a lot of times, we do integrate – the clients may have their own UAT process as we get closer to releasing to the actual App Store. They’ll do their own user acceptance testing. So the bulk of the QA work is done inhouse and then we’ll slowly transition or integrate with the client towards the end of the project.

Are they also closely tied to the development process? Or are they physically in the same space?

What’s that interaction line?

Yeah! And that’s one of the things I’m trying to help improve even more. So a project will have dedicated QA members assigned to it and they come to our stand ups. They’re just a part of daily development life and they sit with us along with everybody else. Right now, we still do a lot of manual testing. They’ll come up with test objectives and they’ll share those with the developers so the developer roughly knows what they’re looking for. But then they’ll go off and as the features are checked in to the main branch, they’ll run through their test cases.

And one thing I’m trying to figure out is how to move to more automated testing so then we can free up QA to spend more time on other things that they can do to build a quality product overall.

And just plan better ways to improve the collaboration between QA and development and design.

Yeah, one thing you talked about – integrating the QA with the development staff. That’s a really a solid way of doing Agile. The more you can shorten the feedback between creating a bug and fixing it, that just helps keep your development team going forward. One anti pattern I noticed with that especially doing Scrum where you get one-week, two-week sprint is that – okay, your QAs on the team; they had nothing to do for the first 9 days of the sprint and they’ve got all the testing to do on the last day. How do you avoid that?

Hopefully, in the individual story that we take on, won’t take the entire sprint. So when a story may take me half a day or two days or whatever and so it has like “I check each story and – of the main trunk or the development we’re actually working on”. QA can go ahead and test that new feature then that does allow them to do continuous testing throughout the portion of the sprint. Of course, as we roll up toward the end of the sprint, we will do a code freeze and allow them to do sort of a

final full system check and they can run their full regression suite.

And I got to say that’s the bit of Scrum that I’m the least fan of – is that choppiness of it. The start of the iteration, the QAs are waiting for those first stories to get done. And at the end, they’re under the gun to get done before this arbitrary cutoff point. And it’s the cycle QAs end up getting. Beating up about that if you’re not really diligent about that small story thing.

Have you guys experimented with anything? The more Lean or Kanban type things of not having a cutoff point as it were but just having a continuous flow of stories moving through. And then having a cadence of every two weeks we do a retro and a showcase and the rest of it, but we don’t have a cutoff point of like “Stories must be done by 11pm or 11am on Tuesday” or whatever.

Yeah, I know some projects that have run a Kanban style process. And they’ve – I think it’s worked out well. It tends to depend on the nature of the work they’re doing and the timeline they’re working with. On a project I’m working on now, I actually ended up – for a phase, we did transition to a Kanban style. Because we were helping a client finish off some of his existing work and it went on longer than expected just as the requirements became clearer so – each case that we needed to handle. So we stopped sprinting and went – just did more of a Kanban. Here are all the issues and I’ll just work through them and release things as we see – release bills as we see they solve problems. But now that we have that under control, we’ll probably go back to a more traditionally sprint style process.

I mean that’s the key thing right? It’s different processes work in different contexts and for different teams. The big – to me the only real requirement for Agile is the introspection. Like having a team be able to – on a regular basis, look back on what they’re doing and tweak the process to make it their own process rather than something they’re reading from a book or whatever. Of course, it’s quite frustrating for a team because – well, for me as a consultant, when I show up, they just want me to tell them what to do, to an extent, like “What’s the way we do Agile?” And it can be frustrating for me to say it to them. “Well, that all depends on what do you want to blah blah blah?”

[Chuckles] Standard answer: “It depends.”

I think one of the other key aspects of Agile is just getting that feedback as quickly as you can. And so the quick you can get feedback, the quick you can react. That’s one of the things I’m looking at trying to improve. And so, as you say, even if you wait until the code is checked in and QA runs their tests, that’s still a little bit of time lag between the time the developer writes the code and then wait a day or two before he finds out if it really works. And so moving towards more automated testing will allow the developers to get that feedback even faster. So if QA can help define the tests upfront and the developers can actually automate them then as the developer goes; if he’s running those tests, then he’ll get that feedback within minutes instead of hours or days.

I’d say, yeah! That’s one of the challenges is – I mean you have to have collaboration between at least QA and developers. So you have to get QA to the point where they can actually present requirements in a way that makes it easy for the developers to automate those tests. And then you have to have developers get comfortable with writing automated tests because, especially with iOS apps, they are seen as being so UI heavy that it can be difficult to understand how and what to test. But yeah, there's certainly – with enough experience, you can figure out how to go about writing the automated test for iOS apps and just get enough experience and comfort level. And then, if we do that, then that will allow the QA team to maybe focus more of their time. And if they are going to do manual testing, I think it would be better spent if they could do a lot of exploratory testing rather than functional testing manually.

Yeah. I do want to jump on here because I think we've all worked on teams that worked well and we've all worked on teams that haven't. And it seems like the teams that I’ve worked on the best – or seemed to have the best process that worked for them were teams that did what Pete was talking about where they'd get feedback on their process itself. And so, they sit down, they have – usually it's a retrospective meeting where they start saying, "Okay, what's working for us? What's not working for us? What's the slam dunk stuff? And what are the real stinkers in our process? And then, they can discuss, “Well, let's try this: let's iterate on our process and try pair programming or try setting up the CI server or try doing tests first or whatever.” And after a week or two weeks, they can come back and they can talk about it.

Or in some cases, I've been on teams that experimented for two months. They had somebody go and research pair programming and then they came back and said, “All the people who talk about it say that you have to do it regularly for a longer period of time before you can really see the benefits. And so, okay we're going to pair half time for four weeks. Then we start figuring out, ‘this really isn't working. This really does work’.” And I’ve worked in companies where teams – between teams, you have a vastly different process just because they figured out that they're able to get more done if they work in a little bit different way. And everyone’s happier that way too because everybody has input on how you do things.

I’ve been fortunate. I can only – because I’ve been doing – writing software for 24, 25 years now. And I can – I don't even need one hand to count the number of people that I really did enjoy working with. So I’ve been fortunate to always work with just really fun, talented, creative individuals and that's actually have – what makes this job so much fun is that actually getting to spend your day around these people. So just finding ways – part of your job is to actually spend time working with designers, working with QA rather than just going off in your silo and just typing code all day. That's not as fun – but so you’re figuring out a process that allows you or almost depends or requires you to spend a lot of time working with the other individuals on the team. I think makes a much happier team.

Do you ever have clients who you’re working with who see how you’re working and then ask you to help them adopt similar practices for their internal engineering teams?

As the whole iOS market has matured, the nature of the work that we take on has adjusted over time. So when Mutual Mobile started about five years ago, we were doing lots of just small little one-month real simple apps. And we worked and then put it out the door and then we'd never see or think about them again. And now, as the nature – our clients has advanced. We tend to do fewer number of projects that are longer term – six months, a year, 18 months. Because of that, it's natural for a lot of our clients to, long term, want to take that work in-house as they build up their own team.

And so, we definitely have worked with our clients to help them transition and build up their own internal staff. And they do take cues from the way we work and so then they can build their teams in a similar fashion.

For me, I think that's one of the big benefits of a lot of those Agile engineering practices. Things like pair programming is – it acts as a really nice way to do knowledge transfer. Like when you are trying to transfer ownership of a project from something that an external company's building into something that's owned in-house. That ability to gradually move in-house developers into a team and have them pair with the existing team to learn things to just gradually transition to mostly external folks to mostly internal folks over time. It’s a very nice smooth way of doing it rather than having this adversarial point in time where you hand something off and everything has to be done and contracts are signed and all that kind of stuff is – it’s a nice way of transitioning if you can have people pair and pick up the knowledge that way rather than a bunch of documentation.

They could like – crazy until Friday – the last day and then: “Here you go any questions? Got to go!” [Chuckling]

So, I haven't had a lot of personal experience with pair programming. I’m interested to try it but I’m not sure. How do you go about starting? And what has been your experience as well as challenges with pair programming?

I think I often describe pair programming as the most stressful thing to – of all of the – if I show up to a team that's like “We want to do Agile; we want to get better at Agile”, there's a lot of stuff that we work through. One of the things that I describe is that – the thing that's going to be the most stressful for them is doing pair programming. Once you get it, and once you get comfortable with it, I think it's got tons and tons of benefits. But it's very stressful to start doing it.

So I advise teams to not dive in to like “Hey, let’s pair eight hours a day!” but to start by – dip their toe into the water and find a few tasks that they think are valuable or that are good candidates for pairing on and then gradually, over time, they’ll work out what works and what doesn't work. Slamming straight into eight hours a day of pairing is very hard work if you're not used to it because there’s a lot of communication. There’s a lot of – honestly, when you’re pairing for eight hours a day, you are actually programming for the majority of your time and the average developer is not programming – on their own is not programming for eight hours a day. They’re programming for a bit and then they're checking their email and reading an article and –.

Attending a meeting.

Yeah, going to meetings, exactly. And it's very – it surprising how much mentally draining to actually just be full on programming for eight hours.

The first time I did it for eight hours, I was exhausted.

Yeah! And so, one of the things that I see happening a lot with folks that aren’t used to pair programming is one person tends to dominate the pairing session. So one person dominates the [inaudible 20:22] the person who's more vocal and more opinionated tends to do all of the driving and the other person is sitting there. The biggest red flag for me is when I see a pair in “Where one person's checking their email on their phone while pairing”, which you do see sometimes.

So there are lots of practices around that. Like Ping-Pong pairing is one I’m a really big fan of where one person writes a failing test. Let’s say, I’m going to do TDD. One person writes the code and then their pair writes a test to verify that code. And then the second person writes the next piece of code and the first person writes the test to verify that. So you have this enforced rhythm of switching who's the driver and who's the navigator on a regular basis. That’s one nice way to keep it from being from one person doing all of the typing and the other person zoning out. Yeah, there are loads of practices like that I guess.

So with TD writing in a test and pair programming, we just hit red flags with most managers in the world of doubling effort, writing twice less code as you need to write, and having twice many people that you need to write this code. How do you show that this is worth it? Because I do agree it's worth it and it’s valuable for a lot of different things but why?

I’m going to answer – I’m going to take the easy one to answer there which is the unit testing. The question I always ask someone who asks that is “Does your manager often check in on how long your methods are or like whether you're using underscores or dashes or camel case whatever?” Your manager doesn't care about that. They care about you building quality software. And how you do that is your job as an engineer. It’s your job to be a professional and build good quality software. Unit testing is part of building good quality software. If you're not doing that, it's your fault. You don't need to go to your manager and ask them to do a good job. You should be a doing a good job. That’s like for me, the unit testing one is a no brainer. It’s like saying should I ask my manager to set up a CI server? Do you want to do a good job or not? You don't need to ask permission todo a good job. It’s not something that I think a manager should be focusing on – is “What are the technical practices of my team?” – to that level of granularity.

The other thing is that a lot of times with a lot of the Agile practices, it really is an experiment at first. And it’s a lot easier I’ve found to sell managers on an experiment as opposed to trying to sell them on some practice because it's “The way to do it”. And so, when we're talking about things like TDD or writing tests or things like that. A lot of times, you can go to them and you can pitch it to them as, “Hey, we're going to try this for a while. And then, if it doesn't work, we'll go back to doing it the way we've been doing it.” And a lot of times they're open to that. We’re trying to make our process better; we're trying to be more efficient; we're trying to whatever. You're speaking their language there because they care about the bottom line too. And so, in those cases, we're going to try pair programming for a month and see if it makes things better. And then, if it doesn't then you go back and, so there's a little bit of risk there but you're only going to keep it if it's successful.

I think, Chuck, you've made a really good point. Really, you've got to think about what do they care about like “What's their focus?” And their focus is in things like having a productive team, reducing the bus factor or the lottery factor. They don’t want – if one person wins the lottery and decides to quit the company, they don't want half of the knowledge of that code base walking out with them. That’s one of the things I would point out with pair programming is it's a really good way of spreading collective code ownership and not having all of the knowledge about one part of the code living in one person's head.

It also makes it way easier to on board one person into a team. It makes it really easier to transfer knowledge about some new technique and normalize the team so that you don't have – Bob and Sarah have decided that they want to use AF networking with glocks and Jim and Helen using networking with __ you want consistency across your code base. And if you're pairing up on things, then it helps spread that consistency. So there’s a lot of benefits to pairing that are more than just the standard productivity argument of you can get more stuff done, which I think is true. But there are lots of other ancillary benefits that a manager type can relate to.

Well, and the other end of that is that if you come in and you make arguments like that, it’s different from saying “Well, I heard about this pairing think because I went to an XP meet up – XP, extreme programming – I went to and XP meet up and they were talking about – so we’re just going to try it because it sounds cool.” as opposed to “I’ve done some research and then you list all the benefits that Pete just listed, so we’re going to see if we get those here.” If it's a well thought out, well researched idea, then it’s a completely different sell from – well, pair programming’s a cool thing so we’re going to try it.

Yeah, I think the plus factor's a quick win with pair programming. And even with pair programming, you don't need to do it eight hours a day. Like Pete said, you can just do a little thing – half hour, hour at a time if you’re just trying to pass off different functionality and that spreads knowledge around the team even a little bit, you can get benefit.

Yeah, I like processes or practices that, sooner than later, illustrate weakness in your overall process. Like taking TDD as an example, if you have trouble writing tests, it could be that the requirements aren't very clear. You don't understand what it is you're supposed to be doing and that you need to work with QA to help figure really what the requirements or specifications are. Maybe the client hasn't really thought through what all the edge cases are.

“How should the system respond in this particular situation?” And so who answers those questions? That would be the different designers – your business designer, interaction designer, virtual designer. They define how the system responds. And then who asks the questions? That’s the job of QA. And so if everybody's playing that role, then the whole development will flow smoothly and when we start to see hiccups like if you are trying to do – write tests maybe the requirements aren’t clear because maybe the right questions haven’t been a – they haven’t been answered properly. But then when all that does come together, then that certainly makes the job of the developer easier.

So one thing we haven't really touched on is – I’m really interested in because it's particularly – it’s a bigger issue in mobile development so you already touched on the fact that with mobile, things tend to be UI heavy. Particularly with iOS, we have a very strong focus on like really nice user experience and really rich UX. What do you do to help bring that into the process? Bringing in design – as in making and making that design need for a holistic user experience line up with the Agile thing of releasing value after every sprint because I think that's a really, really big challenge. It’s something I’m still trying to figure out good answers too.

Yeah, and we're still struggling with that because – say the designers want to define a design language for the app as a whole and figure out how the whole app should feel even though all the features may not be understood on day one. But they need to design something that will be flexible enough to as we continue to add features that their design will build to accommodate and expand for that and so, that is for now, what we do is we just spend more time upfront giving the designer – and a lot of this will start in our discovery phase where they’ll start to do things like create mood boards and work with the customer to understand what the rough visual styles they're after. But we will still front load designers and give them enough time to design something that's flexible.

But the downside of that is it does delay how quickly development can really get going because if we don't have any UIs to develop, usually not a whole lot we can do. So we were still trying to figure out ways that we can let the designers do their work but then also allow the developers to start their work sooner. But, as you say, it is still definitely a challenge.

Yeah, I think there's a lot of interesting stuff going on in the last couple of years with the UX is one of the things I’ve seen – one of them I can – I’ve seen going around of trying to make that user experience work more iterative and more feedbacky, which is what – I think you already said this – like one of the really big things of Agile is getting feedback and replaying that back into things like UX. But I still think it's something we're all figuring out good practice on is how to balance that need to have a really nice holistic thing that you fight for upfront and mood boards and stuff like that. But also be able to respond to change, which is what we're trying to get with Agile right? Is being able to see a change in our external environment or our internal market or whatever and shift gears. It’s really interesting – it’s a really interesting challenge to solve that particularly in something like iOS, which is so UI heavy.

I just want to ask along those lines with regard to UX. Have you encountered any situations where – in your process to support A/B testing? I know on the web it’s a bit easier to do but it's a bit of a challenge. We had some discussions about which UX implementation would work best. We don't really have robust way to verify – right now build it, make a decision after some discussions, implement it and then get feedback after the app's in the App Store.

We have recently started a user research team at Mutual Mobile. And so, we will actually go out and find prospective real world customers not just people in-house necessarily. And we can start with mockups but then often times even as the actual development progresses, we can take the build as it stands. And we will let real users test it in a controlled environment so we can monitor the reactions. And then we definitely have taken that feedback and we do refine – are able to refine the UI throughout the lifetime of the apps. By the time it actually does get to the App Store, it has already undergone a fair bit of user testing. That works well with projects with long timelines. If you have a project that you're trying to do in a month, there would probably be less freedom to do a lot of user research testing.

Yeah, absolutely, it seems like – in that case, you have to make a decision and roll with it versus getting feedback in an app that has a longer life cycle as far as development is concerned.

Yeah, A/B testing on UIs, seems like we have to be pretty big problem to tackle with native apps just because it seems to take longer. There’s more involved in actually fully implementing the UI on a native app versus a web app.

So, I’m curious. And this is a question for everybody, what parts of your process do you think make the biggest difference in the way that you write code?

That's a good one.

Is it the way you write stories? Is it the way you actually – some process in actually writing your code? Is it the way that you track progress? Is it the way that you communicate? Is there one method of doing that that makes a big difference?

We are actually been going through a – developing a new process and we've been iterating on this for a number of weeks. And I have to say, probably the biggest thing that I find is a benefit for us – it helps us – is something that I would not have thought beforehand and that's the attitude of people involved. Our team is really open to continually improving the product and then improving our process. So there are very small egos when it comes to implementing changes. Even if someone's used to doing something a certain way, our team's very amenable. And I think that goes a long way to finding the optimal solution for your team. Just being open to hearing and also being vocal. Having to be vocal to your fellow team members about what you think works and what's not working. And then having that discussion and moving forward with giving some modification a try.

I think that is an awesome point. I totally agree with that. The thing that makes this stuff work is a team that's not terrified of change. Everyone finds change scary and uncomfortable but being open to it and embracing it enough that you're vocal about what's working and what's not is the key to success. If you can do that, I almost guarantee you'll get that – in some ways you might – you’re never going to be perfect. You’re always going to have little roadblocks and little niggles and issues but if the folks in your team in general are open to improving themselves and open to the processes of doing then there's no way you're not going to get better over time.

For the way we work, I think that just the fact that everybody sits together as one group, I think that makes the biggest difference just because you have a continuous collaboration. Like in – if the developers implementing UI, they’ll actually sit there and they’ll sit at the desk with the designer and they iterate very rapidly. They can make a change. “How's this look? Oh, let me tweak this.” Type a little bit. Within seconds or minutes, they're able to get that feedback.

So about a year or two ago, everyone started saying that Agile was dead that the capital A Agile – and they changed it to something else. I’m not sure of this but people are still having success using different Agile methods and Agile itself is not a huge defined methodology. It’s more a way of being which is it Lean? Is that the one?

Yeah, I’ve been joking recently that Agile with the big A is dead. It’s agile with the small A. Oh wait! Agile with the small a – it’s dead. It’s Lean/Kanban. And pretty soon, Lean will not be cool anymore and then we’ll be doing the lean reverse. Lean with the small N maybe I don't know – Lean with the small L rather.

Yeah, something like that but the basic concepts are pretty solid and they've been solid from day one. Getting feedback on your mistakes faster. Getting what you do in the hands of people that make the decisions that want to see it so you can improve things and keep on improving. I’m just wondering what things have you adapted from agile that maybe wouldn't fit?

Are you asking what isn't in the dogmatic canon of Agile but turns out to be sticking to the principles of it rather than the rituals?

Yeah, I think that's good. What things that may go against capital A Agile or whatever the new word is now are working for you and your team?

The big thing that I’ve been doing for the last – or I’ve been on teams that are doing for the last two years or so is not doing a story estimate and not doing iteration planning meetings. And oh, my gosh! It is so much nicer to not have to do the planning and do the story estimation. It is so much better. Every team I go on now, I sing the song of like "Maybe we don't have to sit in a hot conference room for an hour every week or every two weeks arguing about whether it's a threepoint story or a five-point story. That’s my big – the thing I’ve been doing on teams recently that diverges from the big A Agile. Maybe the Scrum. Definitely – I’m pretty sure Scrum has in the manual somewhere that you're supposed to do estimation. I don't believe it's a productive activity.

Heresy!

I enjoy being a heretic a little bit.

I think there are a lot of things in Scrum that can go against a lot of development environments. It’s – some environments where you can’t really fit what you need to do in two weeks and splitting up – you take more effort splitting it up trying to make something deliverable within a week or two weeks. A lot of times, you're trying to estimate a story and you don't know. And they call it a swag because you're just guessing. But you definitely don't – a lot of times, you're not getting a lot of value out of those meetings. So, I agree with that.

For me, the two things – the main value I’d say you get out of those meetings is you discuss the work ahead of you and you make sure that everyone understands it and having the kind of the sword of Damocles over your head of “You better get these estimates right because half way, someone's going to beat you up in a week’s time for not hitting your velocity number.” That sucks. But it's good enforcing people to actually pay attention to “Do I understand the work ahead of me next week?” So that's the one thing that is useful of estimation.

sizing the stories that way, what I find is it works way better and gives you most of the benefit is just make the story small. If you think the story is too big for you to do in two or three days, slice it up into two smaller stories. And then, you get the benefit of point in terms of a rough plan of how much are we going to get done in the next weeks because you know we've got ten stories and on average, the team seems to take about four days per story. So we’ve got forty days of dev days of work ahead of us. So I think you get a lot of the benefit of doing that without the angst ridden onehour sweaty conference room debating over whether it's a five-point story or a seven-point story or whatever.

It’s a real skill. Jaim, one of the things you said that I hear a lot and I totally relate to is you can't make this like “How to slice up this work so that we can get it done in less than x period of time?” I think it quite counter intuitive that some of the stuffs that you can do to make it happen – you can make it happen but sometimes it feels like you're giving yourself more work than you need. But the flip side is you breaking up into small chunks and you can make continuous progress towards your goal rather than not really knowing whether you're going to get there in time or not.

Yeah, one other thing that I really think goes into Agile or just successful teams as general as communication. And it's funny because I talk to people that are going freelance and I’m like “You know what ABC stands for?” And they all say “Always Be Closing” and then I tell them “No! It’s Always Be Communicating.” If you you're communicating well then you're going to be closing deals as a freelancer. But if you're communicating well then your clients are happier. You understand what they need. They understand what you need. They know where you're at. They know what the snags are. They know why you're going to be late or why you're going to be early. They know that they're getting what they want. And it's not that different in a team. And I think that's one of the major things – if this is the first point in the Agile manifesto I think is communication collaboration over whatever it is and –.

Contracts.

Right. And so it's – the more that you can communicate, the more people know where things are at. The more people know what they need to do and the more that you are getting clarification and feedback, the better off you're going to be. And that's what a lot of these systems are about. So if you're focused on just doing the thing because somebody said you should do it – and this is the problem I have with a lot of the methodologies then you're not going to succeed but if you're talking about it and figuring out, “This is working. This makes this different. You’re talking to the other stakeholders. Doing this makes this other process easier.” And then, like I said, the communication and the timelines, the costs and the requirements. It just makes a huge difference.

Big plus one to that last sentiment of not sticking to doing stuff because something tells you to do it. Look beyond the manual and look beyond the practices to the principles behind those practices and then you're going to be successful. If you can iterate over time and improve your process and you understand some of the reasons behind these practices, then the team will get better over time.

Yeah, all right, let's go and do some picks. Alondo, what are your picks?

Actually, I only have one pick this week. And it is – I got some of the tiny sky Nano drones. It’s a really small precision control quad copter and I got them for my nephews. I previously, had a pick with the Edison robots. We got those before the Christmas break and we enjoyed them and so I decided to introduce them to little Nano drones and see how they enjoy those as well.

Awesome, Pete, what are your picks?

So, my first pick is this idea of no estimates and I’ve already ranted about it so I’ll just leave it at that. Consider just breaking up your work into small stories rather than estimating each story in excruciating, grueling detail.

The other pick is an engineering practice, which I’ve seen a few teams use and I think is generally quite useful is this thing called mob coding. So the idea is once a week, or twice a week, you get together as an entire – all the developers on the team get together and work on code together so someone throws up their idea into a projector and you small problem together. It’s a good way of aligning on engineering practices. It’s a good way of spreading knowledge on some new technique that someone decided to try using or some new library that they started using so. Mob coding is a good idea.

And then, the last pick I’ll have, which is a little bit – I thought was a little bit – apparently isn't is a

Tete-a-Tete desk arrangement. So this is something that Josh Susser of Ruby Rogues fame or of Ruby fame in general blogged about five years ago. And it's this weird arrangement of desks that make a pair programming more high-fiveable. Nothing else! It makes it a lot easier to high-five while pair programming if you set up your desks this way. And I always thought it was kind of a joke. And then I pinged him on Twitter the other day to see if he continued using it and apparently, five years later, he's still a huge fan of it and all the teams he works on use this arrangement. So Tete-a-Tete desk pairing is my final thought-it-was-a-joke-but-not-really-a-joke pick.

Very cool. Jaim! Do you have some picks for us?

Yup, I have a couple of anti picks. One is the mail carrier showing up a little bit earlier than usual during podcasts. My dog is currently scaring them off. I think they just left. He scared them off so we're all good. So that’s my anti pick. Stick to the schedule mail carriers so I can do live podcast.

Another anti pick. So I’ve been doing testing with swift and if you've been doing any non-trivial testing, you get into the problem where, unless you declare a property or method public, your test bundle can't see. You can't see from the test bundle. So all the descriptions I’ve seen about how to handle this say “Well, make everything public!” Which is okay but most of them are also saying, "If you just add the file to the test bundle, then you'll be fine." And I’m saying, “Don't do this because you'll end up managing two test projects with all the files in there!” It’s a complete headache. If you have any CocoaPods or anything like that, then you have to manage them in both places. So it's a pain so don't add your files to test bundle. Don't do it. That's my anti pick for the day.

Hmm very cool. I’ve just got one pick. I’ve been playing this game on my phone. I think I picked this on all of my shows because I like it. It’s called A Dark Room. We had Amir on the Entreprogrammers Podcast and talked to him for a while about building iOS apps and marketing and stuff like that and it was really cool. There was a lot of a – I guess it's been a very successful app for him so to the point where it was number one in his category of games. And it's basically one of those text-based games that you used to play on the PC back in the day when you didn't have the high-end graphics and stuff. Anyway, so the interface isn't very pretty but it's a lot of fun. So anyway, totally just enjoyed it. I just beat the game like right before the show. So, anyway go check it out. Jeff, what are your picks?

I got a few today. First one is a book. A TDD by example “A Practical Guide to Acceptance TestDriven Development.” And I don't like it just because it's about testing but its example of setting a long-term goal of something you can drive towards and the journey of actually trying to get there will just show you what parts of your process you need to improve. And love it as you can focus on communication with the rest of your team. I guess - out of that the super recommendation is just set a long-term goal of something that can help improve the communication between people in your team.

An app I like is called Time Out. It’s a little app that sits in the background and encourages you to take breaks occasionally. And they have what's called the regular breaks and micro breaks. It’s like a micro break is a 15 second break every 10 minutes that just gives you a chance to shift your focus instead of staring at your screen. It gives you 15 seconds to look out your window or something like that. And then by default, every hour it wants you to take a 10-minute break and that gives you a chance to get up stretch your legs, take a walk and talk to somebody. It just keeps you from falling into a hole and disappearing for the day.

And then as far as the beverage, something I have in the day is a Breckenridge 471 Small Batch IPA. Fine folks at Breckenridge, Colorado and I love IPAs. I’m a big hophead. And this one is nice because it has a little more sweetness than I’m used to in most IPAs. So it's a nice change of pace and that's it.

Very cool. I think that's everybody. Thanks for coming Jeff. It was a fun conversation. Hopefully, we helped a few people figure out some stuff that they can try out in their process.

It was a lot of fun. I certainly learned a few things I’ll have to go try out too.

Awesome. All right well we'll wrap up the show and we'll catch you all next week.