Sprint tactics versus strategy

At work right now we have moved from a one week sprint to a two week sprint. This didn’t seem like a big deal at the beginning. The idea was that we spent a lot of the time as a percentage of the work week doing sprint planning and retrospectives. We thought that a two week sprint would let us get an ideal ratio of work to planning.

The reality is a bit different. What we saw was that we had to do a mid-week correction after things didn’t go as planned in the first week. This arose on Tuesday standup of the second week as we looked at the burndown chart.

I’ve been a few places now where we wanted to change the sprint length, and I think I’m starting to see a pattern. The stakeholders see sprint planning as a strategic tool, and the implementers see it more as a tactical tool. Strategically it is advantageous to see out two weeks in advance, but tactically it’s more useful to look at the next few days. I think a lot of conflict and misunderstanding around agile stems from this split.

So is a sprint a strategic tool or a tactical one? I’m still not sure.

Advertisements

React Native

I’ve started a major React Native app recently after doing a bunch of “regular” react stuff. I had pretty early access to React Native when it first came out, but really didn’t check back in on it until I started using it in earnest recently. It turns out I had some preconceptions about it that aren’t really accurate and I thought it would be interesting to talk a little bit about that here.

Write once, run anywhere

We’ve heard this one before. The first for me was Java applets, but some form of this narrative seems to pop up in different forms over and over. The Web is pretty close to this but it’s more like “write once run most places sort of”, which is honestly a little bit better than “write once crash and do nothing in 10% of target environments”.

How does this relate to React Native? Well, in the back of my mind I thought of the project this way. Write React components and use them on mobile and the Web. Well, it doesn’t take long to realize that there are no divs in React Native. In fact apart from the same jsx syntax, the components are all different. What about CSS? That’s there sort of, with slightly different attribute names. Oh and layout is centered (no pun intended) around flexbox.

Components and Composition

Ok, this one I actually had right. The basic ideas around composing an interface translate pretty well, just without much ability to share components between Web and native.

Navigation

Getting from screen to screen is totally different using React Native’s own navigation components. This makes sense since the target is different, but again, it’s a major difference between a Web app done in React and a React Native app. Apparently react-router now supports React Native as well but from my cursory looks it’s not clear how standard app navigation transitions work in that context.

That’s it for now. I’ve been super busy lately but more React Native stuff to come.