Adventures in Agile Development
ADF EMG Podcast

So I’ve started a podcast.  Specifically, for the ADF EMG.  That’s the Oracle Application Development Framework Enterprise Methodology Group.  Reception and feedback from the community has been great so far and I’m looking forward to evolving it over the next several months.

You can check out the blog for the podcast at http://adfemgpodcast.wordpress.com (not much there yet besides episode 1, still a work in progress).

You can subscribe to the feed at http://feeds.feedburner.com/ADFEMGPodcast (it’s not up on the iTunes store yet, but you can paste the URL into the “Subscribe to Podcast…” option in the iTunes Advanced menu).

Thanks for listening!

Transparency is The Key to Agile

Over on Forbes.com Steve Denning has been writing multiple articles about Agile.  What it is, how it works, and how to sell it.  Tucked away in the last paragraph of his article from April 17th is a quote that pretty much sums up Agile for me, “Agile thrives on transparency”.

To truly be agile you have to have transparency, both vertical (engineers, managers, executives) and horizontal (developers, testers, users).  So many of the stress causing bureaucratic/political problems I’ve seen over the years were mostly, if not entirely, due to the lack of transparency and communication. I’ve always felt it appropriate that “Individuals and Interactions” was the first line of the agile manifesto’s core statement.  When all of a project’s stakeholders are kept in the loop, problems are identified sooner and the team is better able to handle the problems that do arise.

A few thoughts on Agile

For the past few months I’ve been acting as my company’s de facto Agile/Scrum/Kanban coach, and as Jira administrator.  Here’s a few things I’ve learned so far.

  • Teach Agile first, process (Scrum, Kanban, etc.) second.
  • Keep coaching.
  • It’s the people that make the process agile, not the process that makes the people agile.
  • Be truthful, don’t hide facts, it just hurts in the long run and makes you less agile.
  • When it comes to communicating a project’s steady stream of issues and ideas, shorter, more frequent meetings are better than longer, less frequent meetings.
  • Agile doesn’t mean “We don’t do that.”, it means “We don’t do that unless it produces value.”
  • Every team, and product, is different. 
Interesting issue with JMeter and ADF.

There is an excellent post by Chris Muir on his old blog about how to configure JMeter for ADF (Chris’ current blog is here), so I’m not covering all of that, just an interesting issue I found while running some tests.

Long-story-short: The afrLoop variable can vary in size from server to server, and change over time, so your parser may need to change.

Back in December I needed to setup some load tests for a couple of ADF apps I was working on.  I had used JMeter before, but hadn’t used it with an ADF app.  Fortunately a Google search found the blog post linked above, and after following through the post I had some working tests for both my apps.

Fast-forward about 4.5 months, and I need to run some more load tests.  so I open up JMeter, load up my tests from December, and run…all of my page requests are returning a “Because of inactivity, your session has timed out and is no longer active. Click OK to reload the page” from my ADF app.

Why did these tests that worked great in December just stop working?  I hadn’t changed versions of any of the software involved (JMeter, WebLogic, ADF, etc.).  Time to do some detective work.

I started tracing through the requests sent and responses received by the steps in my test case and noticed that the adf.ctrl-state variable was not being set.  Looking through the response for the step where it should first get set I didn’t notice anything wrong at first, but just by chance I happened to notice that the afrLoop variable my test was setting and sending for that step was 1 digit short (the one in the file ended in a double-7, mine had one 7, so it was easy to spot).

Turns out, my parser for the afrLoop variable was pulling 16 characters from the response, but the afrLoop value being sent was 17 characters.  Doing some further tests I found that across various servers (JDev integratedWLS, QA/PreProd/Prod) the length of the afrLoop value being returned was 15, 16 or 17.  On the server I was running my tests against it was 17, though back in December a length of 16 had worked just fine on the same server.

So, I increased the number of characters being grabbed by my parser from 16 to 17 and bingo, my tests worked just fine again.