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.

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.

First iteration under XP

Unfortunately, I went on vacation the last day of the iteration, missing the demo and retrospective.  From my perspective we stubbed our toes a bit.

We focused on our most recent app that had been developed using BDD.  It was the teams first shot at it, so there were definitely rough edges to our practice of it.

We're struggling a little with defining what our tester should be doing.  Our current focus is helping with developing acceptance tests and doing some exploratory testing.  This felt awkward during the first week because our tester didn't have access to our git repository and was sick/working from home at the beginning of the sprint.  So we didn't communicate or share the acceptance tests we had already developed.  I hope getting access to the git repo will help some of this.  Regardless, we need to take time to discuss them.

Another painful spot was a story that ended up bring much larger than expected.  What made this painful was we recognized that there was more work and discussed it as developers, but neglected to create a task to expose it.  So when we ran into some trouble we ended up splitting the story at the last minute.

Finally, we had some difficulties working through the automation of our acceptance tests.  Between learning how to write the tests and learning the tools (cucumber and geb) we stumbled a couple times.

While I enjoyed Florida, I was a little sad to not be with the team as they start the second week of this.

Transitioning to XP

My team at work is in the process of reading The Art of Agile Development by James Shore and Shane Warden.  I gather initially it was brought to the team as a way to learn how to improve our writing of stories. We've decided to go further with it and try to rethink our development process.

We have seven developers that maintain several applications, with generally two or three of them getting focused attention (more than just fixing bugs) at any given time. These apps vary greatly in how much automated testing had been done for them and how much technical debt they've pulled up.

Our first step/attempt is going to involve one person trying to do any necessary maintenance work for all but one of the apps. Everyone else will be doing a release on the remaining one.

Some concerns we've got:

• How quickly can we minimize the maintenance role? Cause it's no fun being the only one on the outside.
• We don't have a coach. The book seems good, but experience is better.
• We've still got a bunch to learn/internalize.  From TDD to visible charts to retrospectives.  While it makes sense it's not second nature so we'll have to be mindful - not the worst thing to have to be. :)
• We can't just focus on one app and switching between them will be necessary to continue to deliver value for each of them.
• We've got a customer identified for our first product, but the other apps aren't as clear cut for who could serve that role.

I'm certain will have more concerns and challenges as we go along, but hopefully we'll keep moving forward.