Concerned with HIP sprints

During our planning I very often hear maintenance or architecture work come up and immediately be deferred with "that's a HIP sprint item."  Ultimately this feels like a cop out.  Granted that's not what the Scaled Agile Framework (SAFe) is going for with it's advocation of them.  It seems more of a place for preparing for a release and dealing with those things that can't be done before hand.

Granted my company is mostly focused on updates to existing applications and adding features to them.  (That's not to say that new things are being developed, just that the number of brand new things is less than existing.)  So while we'll occasionally have those items it seems that should be some stories in your iteration instead of the focus of an entire iteration.  Though even if it took over an iteration - does it need a special name?

I guess it's making me think this is a situation that some teams have found themselves in where they need a HIP sprint and it's being generalized as a rule to help protect others.  In the end I feel it flies in the face of sustainable pace since it gives a dumping ground for things that should be done in each sprint.  Granted we're supposed to have a mix of these items in each sprint already, but it seems the HIP sprint provides the illusion of a crutch to fall back on.  (To be sure - there's some coaching that is needed to ensure that we're not too focused on product development with no regard for keeping the system working.) 

I'm certainly giving short shrift to a topic that has had some thoughtful discussion, but it's something that's currently on my mind.

Fumbling at Finding things with Selenium

Finding things with Selenium

At it's root this is easy enough.  Just call findElement() on the driver and give it some matching - we've been using css selector - and viola.  Then I wanted it to be visible - so just call .isDisplayed() on the element, but I kept getting false.

I should note that I was adding this to some functional tests being run against our hybrid mobile application.  So I could track down the css styles viewing it in a browser I'm not sure how to map the Selenium element I'm getting in our tests to the same thing.  (Any pointers would be appreciated. :))  This left me fumbling around wondering why I wasn't matching what I was seeing in the browser.

Then I thought to search for the css selector I was matching on and realized there were two of them on the page and that I need to add another part to the selector.  Not one of my proudest moments - I'd like to blame that I'm not always/often working with css and it takes a bit for my brain to get into debugging when it doesn't work off the bat.

Vagrant

So I had hoped to dig more into vagrant...and I sort of did.  I touched base with our systems team since they use puppet and I was hoping to make use of what they did to quicken things up.  Turns out they use vagrant to test out their puppet scripts, but they don't have access that they'd like to share...yet.  I'm hoping to keep poking at that and get an appropriate access created!

Exploring vagrant and volunteering

Exploring Vagrant

Recently I listened to Ruby Rogues podcast where they chat with Mitchell Hashimoto, the creator of vagrant.  Which I'm sad to say that while I've heard of it I haven't dug into at all.  (This even came up during a hackathon at my company, but I was working on something else.)

We have a dependency on another project that's fairly complex to setup and run locally.  Recently there's been some work done to puppet-ize the setup of the servers for standing up new servers.  Looking through the vagrant docs it seems that it would be easy to make use of that.  Along with the ability to control multiple boxes it seems like it should be easy to setup.  I'm looking forward to exploring this more next week.

Volunteering with Vermont Works for Women

I had the pleasure of TAing during one of the Step Up to IT classes.  It was awesome to see the enthusiasm and drive of all the attendees.  I've certainly been getting more interest in mentoring these past couple years and this was a great day for me.  I'm TAing for two other classes coming up and look forward to see how things progress.

Random Star Trek Bonus

I recently became aware of Star Trek Continues.  I'm still trying to determine how much I like it, but it certainly gets high marks for it stay true to the original series.  The first three episodes they have out are enjoyable.  Needless to say I'm keeping my eye on their latest "Kirkstarter" while I figure out if and how much I should donate. :)

Moving to Rally

Recently my company, in an effort to increase visibility of work and help organize things, has transitioned from Jira to Rally.  Not unsurprisingly we're dealing with learning how to use the new system and the differences between them.  My team likes the flexibility of being remote - at times we've had half the team working remotely - so we don't have a physical board and are keeping things all in the tool.

Here are some of the issues we're having that we have yet to find a work around:

1. Handle unfinished work from an iteration
   
   Rally gives some advice around this, but nothing that just works.  Some options and their downsides:
   
   
   1. Move the story to the new iteration.  You lose sight that it was in a previous iteration so the planned points goes down.
   2. Split the story - which by default creates a second story with the same number of points in the upcoming iteration.  Unfortunately, if you're doing any reporting like the release burnup, then this gets a double shot of points from this one story.  The suggestion in this case is to zero out the points for the left over work, which of course changes the points planned in the last sprint. 
   
   Nothing provides a solution that maintains both the closed iterations planned and actual points as well as the release burnup.
   
2. Starting and stopping an iteration
   
   It doesn't appear to allow any flexibility in the time an iteration is to close - so midnight on the day indicated is when it happens.  Historically, my team has closed the sprint after daily standup (which we do at 10:15) on the day we're planning our iterations.  Which immediately afterward we do our planning for the next iteration.  Since it's all automatic, we'd have to close things up the night before so that any reports look reasonable and aren't missing our last morning of work.  This just seems too rigid and I'm not sure what the benefit is versus our being able to indicate we're done with the iteration.
   
3. Identify what stories/features are being released
   
   Rally has introduced milestones that seemed to be a perfect fit for this.  These can be applied to portfolio items and stories.  However, I have yet to find a way to view everything it has been applied to in one view.  So while I add the milestone to everything I can't a view that will show everything that's going out in the release.
   
   Some of this I'd take as a challenge to avoid working on things that aren't going to get released, but I've learned that reality gets in the way.  So it's not impossible to figure out what's getting released I just prefer indicating it as soon as I know and having a single place where people can look at it.

Some things we've found work arounds for that we're not really satisfied about:

1. Unable to view defects on Task Board view
   
   I've honestly found Defects to be next to useless.  Maybe they work better with the test plans, but they behave differently than tasks and stories.  In the end they are work that needs to get done, but they don't work well with the rest of the system.  So this is just the biggest annoyance with them.  The Task Board view is how we do our day to day work, but defects created under a story don't show up along with the tasks on the story.
   
   Our work around for this is to stop creating defects.  This means we can't report out on things we consider defects in our own work as easily, but we'll see about figuring that out when we get a chance.
   
2. A couple of good views to work with
   
   It seems like every view is not quite all there.  You can do 90% of what you expect, but not everything.  For instance, the Task Board is great for updating tasks and progressing them.  However, viewing the parent story and adding new tasks is awkward.  The Iteration Planning view is good for putting stories into iterations and adding tasks.  However, viewing the story is awkward since it takes over the view and when you come back your location on the page is lost.
   
   Our work around for this is to open stories in a new tab.  Jira certainly isn't perfect, but I really appreciated it's plan and work views that seemed to really focus on the purposed for those views - also it's opening selected items in a sidebar view.

It's not without cause that many coaches advise finding you're own flow to things and keeping tools out of the mix as long as you can.  Because of our desire to work remotely and not wanting duplicate entry of stuff (as in update what we're using and keeping the central tool matched) we're continuing to work inside the tool.  I'm concerned with wanting to keep reporting in Rally with some of these concerns.

Appium - iOS and Android webview context

I encountered another thing I wasn't expecting with Appium related to the webview context.  For iOS the context was WEBVIEW_1, but for Android it was WEBVIEW_.  I'll confess to not having dug into the context very much and how and why it might be named.  However, I was expecting them to have the same name.  So instead of just calling AppiumDriver.context("WEBVIEW_1") I ended up looping through the available contexts and finding one that starts with "WEBVIEW" and selecting that one.

Fixing Appium functional tests

Lately I've been trying to get functional testing for our mobile application up and running.  Some initial work was done for it, making use of Cucumber and Appium.  Sadly, it hasn't been a focus so while we had things working for a bit we messed things up with the upgrade to Xcode 6, which caused a delay while Appium was updated to be able to work with some changes.

One of the interesting side effects was that calling click() on the WebElement used to work, but after the upgrade those tests failed.  For which I found this discussion that led me into trying to use tap().  I fumbled for a little since:

• We have a hybrid app and we've focused all our work in the WEB_VIEW context.  Turns out calling tap in that context doesn't work and you have to switch to NATIVE_APP context.
• Then I tried using the tap(fingers, WebElement, duration) variation of the method, but that would crash Appium an error "uncaughtException: Cannot read property 'x' of undefined".
• I haven't nailed this down, but I'm guessing this is because I found the WebElement in the WEB_VIEW context, then switched to NATIVE_APP context to tap.
• Finally used the x, y coordinates of the WebElement and used the tap(fingers, x, y, duration) method to actually do the tap.

Then I ran into another issue - the location of the WebElement wasn't quite right.  First off we are still running in compatibility mode which caused the location of things to be fairly far off when using the iPhone 6 simulator - at least that's our current theory.  When using the iPhone 5 simulator things seemed more consistent.  The y coordinate was still off by a little that we had to add as an offset - 26 pixels.  The theory we have for this is that the changes in iOS 7 to make the status bar transparent might be behind this.