None of this is Real!

When in a small web company, Agile releases are real. By real, I mean they SHIP, and then you get feedback. In situations where you don't actually release the software at iteration end, done means different things, but until it is released and people are USING it, it isn't done. Even then, it isn't truly "done", but that isn't my point. My point is, we set up these arbitrary iterations to help us meet our goals, yet it is just a structure if we aren't actually releasing at the end of a sprint. There are many business reasons why it isn't always possible to release that often, as well as testing considerations! It isn't always best for the customer to get the latest code every few weeks even if we like the short feedback cycle. My point is, when you aren't really releasing, there is an awareness that the iterations are a fake framework slapped on top of a real release schedule. This has some pros and cons. Also, I've learned in the last month that business size has little correlation to agility. I'm working with a very agile team at a large company, and a team which isn't following any process I've experienced before at a very tiny company. Overall, I'm glad to be experiencing both!

Pros
-Ability to work in testing that spans features. There is a huge gap in the general "Agile Testing" strategy used right now. That is the basic fact that many teams using Agile aren't on the first release anymore. There is a huge debt swamp of regression, building changes, and outside risk to be slogged through, sifted, and planned for. If we prioritize these, they can be great to automate, manually test, as exploratory charters, or even as end to end collaborative test exercises.

-Flexibility in validating bug fixes. We aren't REALLY releasing. This means even if others try to impose an emergency, we testers can be wise and stay calm. Emotions can be useful in testing, but they are deadly and dangerous to making good decisions. We can keep things in perspective.

-Partial stories don't have to make sense to the user. We just have to demonstrate them internally.

-Retrospective, burndown, & backlog all regularly get done, so we can incrementally improve.

Cons

-No feedback from users!

-Not really getting the full advantages including actual practice of a full release every iteration.

-Testing is still going to be different before a real release than it is for iteration end.

-Little to no incremental insight into how to adjust our testing to improve it.

Personal Life Stuff
Much of my daily life has changed! Long time no post, and mostly that is because of all that has been happening behind the scenes. First, I've gone independent! Yep. I am now the sole owner of Spark Quality, LLC. In a few months a business website with all sorts of info should be ready. For now I'm focused on my work. My main work is happening in South Bend, Indiana where I'm working as a testing coach and consulting tester. The team I'm working with is amazing! They are not only the most "agile" team I've worked with, but they have the most functional and best FitNesse automation that I've seen in practice. The testers pair with the developers and each other. They are warm, welcoming, friendly, and just a killer team to work with.

I'm also working as a test practitioner at starting a test team from scratch. We've gone from no testing, to one fulltime tester, one part time lead (me), and one intern I'm coaching to become a tester, which is a huge challenge to do on a remote part time basis. In fact, it may be the very biggest challenge I'm facing, and I'm facing many.

So, overall, I LOVE IT! I mean it. I have never been happier as a tester and human with my career. Not every part of it. I HATE doing the bills. I HATE being away from Craig so much. The time zones are difficult. The worst thing so far is the increased pain & loneliness of not having my support system, and also the food in Indiana is yucky to me. Pretty flavorless. When I think of Seattle I think of fresh seafood, variety, produce, & spices from around the globe. I think about Indiana and it's fried stuff, bland grey beef, and more french fries. Kind of makes it easier to not overeat, except for the few exceptions. There's an Italian Bakery--WOW. I could eat all meals there. Heh. The best things about Indiana are the people I work with. They are true good people. Just all heart, humor, and hard work. They are the kind of team to welcome you in and help you overcome all obstacles in order to be productive. Then there is Matt, who is the only reason I was able to work out a way to try this job! Thank you so much to Matt Barcomb, who is an inspiring agile coach. The opportunity to work with him is a true blessing. I feel like I won the lottery here with this job.
 

What did you think of this article?




Trackbacks
  • No trackbacks exist for this post.
Comments
Page: 1 of 1
  • 2 Apr 2011 Fiona Charles wrote:
    This topic is important to me because I work on big projects. Your description of the fakery in internal releases does make sense to me in that we don't get customer feedback.

    But I think that -- without getting entangled in Orwellian doublethink -- we have somehow to get beyond that and view internal releases as real. I see too many projects where getting working software really doesn't seem to be anybody's goal, and the awful consequence is that we often end up not getting any -- or we have horrible quality problems, especially integration bugs, when we finally do get a system. To combat this, I believe we need the discipline of regular internal releases that produce working software every time, and we need to think of these releases as both essential and (in an important sense) real.
    Reply to this
    1. 18 Apr 2011 Lanette wrote:
      The only time I prefer not to see internal releases as "Done" in the same sense as released code is "Done". Once it is released, we have yet another chance to incrementally improve. My point is that we should use that chance. Also, that when the iteration is costing us productivity, as can be the case with some "sprints" where we might get some work "done" but if it can't be totally "done" it would be worthless, internal sprints might be useful to start on a story just to finish it in the next sprint. At least that is what we are seeing to some extent.

      I agree that integration and regression testing as well as user experience testing are woefully underrepresented in most written and spoken practices on agile teams. They are huge issues and there is not one "blessed way" to deal with these that works certainly with all agile teams.

      How do you deal with a gap in quality between everything you've made since "becoming agile" and the stuff made years ago which has no existing tests? We talk about technical debt, but do we ever talk about quality debt? Testing debt? Some applications are just about bankrupted. Not all are starting at the same place with the transition to agile. I'd really like to see much more talk about practical solutions with legacy code, and code without tests.
      Reply to this
  • 2 Apr 2011 Levi Wilson wrote:
    We are happy to have you! Awesome to hear from an external observer that we are doing some things right with our automation and overall agility. As you've stated, we owe a lot of that to Matt Barcomb's guidance...he is a fantastic agile coach. Looking forward to learning more things from you.
    Reply to this

Page: 1 of 1
Leave a comment

Submitted comments are subject to moderation before being displayed.

 Name (required)

 Email (will not be published) (required)

 Website

Your comment is 0 characters limited to 3000 characters.