Tuesday, March 30, 2010

Mapping Agile Success

So, I am wondering if Agile successful adoption levels have been mapped. When I say mapped, I mean mapped in two dimensions, Value Stream Mapping and Momentum Mapping (R. Ryan Nelson and Karen J. Jansen (University of Virginia) MIS Quarterly Executive – September 2009).

I am not a Lean expert, but from what I know, delivering projects via waterfall creates waste, mainly due to "partial work done." Delivering incremental value reduces waste, but by how much? Can this be mapped?

VSM (Coarse-grained)
1. First, VSM the the current waterfall delivery processes, indicating waste points.
2. Next, over time, adopt an Agile methodology.
3. Finally, re-map your delivery methodology under the new Agile processes. Shouldn't the second VSM now show less waste?

Perhaps this is a good place to start: The Art of Lean Software Development: A Practical and Incremental Approach

Granted this is a contrived example, but if Agile delivers value incrementally, before and after VSMs should be able to show the decrease in waste and increase in value.

Understanding value streams is all fine and good, but to me Agile is also very dependent on the team positivity or negativity. How they perceived the progress of the sprint or project can drive how they are open to adopting or adapting to Agile. Emotional Seismographs (Esther Derby) can be used to map "...how people responded to events....and provides clues on where the real juice is for a particular project community..." These seismographs are also know as Momentum Maps.

So between the two mapping methods, we can get an reading on waste-removal and value-added as well as how well our teams are adjusting and implementing Agile.

There is more to come on this topic as I work through the mechanics of these two techniques.

Friday, March 26, 2010

XSS Restrictions - A barrier to UX and eloquent design

So, this is sort of a rant, but here goes. I am working on an E-Commerce punch-out application. For the uninitiated, punch-out is a form of E-commerce where by the user of a procurement system wants to shop for items found in a remote inventory management Internet site. The user initiates an action in their system that "punches-out" of their system and into a shopping experience hosted by the remote system. The user shops in the remote system and then returns their local system with the shopping cart contents, including pricing. Punch-out is based in large part of the CXML standard. It is CXML that is exchanged in these punch-out conversations between each system.

To test our new system, I wrote a small Java web app that uses AJAX to send and receive the CXML to the remote system. Since AJAX using JavaScript, I immediately ran into security issues with XSS (Cross-site-scripting). I know about XSS, but I initially ignored it because this test app is an Intranet only app running on my local Tomcat server. I was wrong to be so cavalier.

I am using IE8, and IE8 (along with other modern browsers) has seen fit to disable XSS by default. After all, XSS is a major security issue. I just don't think that it is a major security issue in my environment and I resent the fact that I can not use it. So I did some digging and it just so happens that I can disable the XSS Filter in IE8 by passing the proper HTTP response header to the web browser, from my Tomcat sever.

response.setHeader("X-XSS-Protection","0");

This code will stop IE8 from preventing the potentially malicious AJAX call and simply alert the browser user of its existence. However, if I try to use SSL then I am right back to where I started as IE8 just seems to ignore my response header in this situation. So, now my AJAX is muted.

I saw AJAX and AJAX-like technologies to be a major positivity to UX (user experience) design in modern web applications. However, unless I am satisfied to only make AJAX calls to my local server, I am doomed.

Tuesday, March 23, 2010

Hope Driven Development

In a recent group conversation at the AgileCoachCamp 2010 NC we were discussing how we convince developers that Agile testing techniques like TDD were good ideas. During this conversation it was apparent that the lack of testing was acceptable to some developers. How could they justify not testing, did they just hope that defects would not materialize? Perhaps they hoped that any defects would be mild. Hope should not be a strategy for delivering value and quality. This quickly led to remarks that the approach of delivering non or under-tested software was akin to HDD (Hope Driven Development).

Hacking Work...

There are too many obstacles preventing us from doing our jobs. We are strapped with archaic and inefficient processes that add little value and really just slow us down. I am not alone in this thinking. During several sessions at the AgileCoachesCamp I heard others trying to make sense of clumsy processes that they had to suffer through just to make management happy. These Agile coaches and trainers were describing having to move through the motions of waterfall to satisfy their managers or customers while they actually execute their projects in true Agile fashion.

Is this what we are reduced to? Is this what I am expected to do? Are there any organizations that get it, really get the idea of Agile and why it does not necessarily need to be prosecuted in waterfall fashion with waterfall processes and artifacts? As a burgeoning Agile professional, I am somewhat disappointed at this prospect.

Last week I read an article in HBR about "Hacking Work." That's what we do when we overcome obstacles to getting our jobs done. I know I have done this; what's more, I feel that I do this more often. I see others do it so often that it almost becomes the new norm. There are unofficial positions at companies filled by people that just get things done, regardless of how.

My issue is that I think "hacking" causes us to use more time and resources than we should have to. It introduces stress. Let's face it, those of us that are embracing Agile or have embraced Agile are doing so because we passionately feel that we can do better...better than we did in the past...better than we were taught. What keeps us pushing in our jobs when their is so much pushing back? How do we change our organizations? I mean, if status-quo was good enough there would not be this movement towards Agile. Doing what we did and getting what we got would be just fine.

According to Dawn Cannan, "There are many techniques for pushing through resistance...". I agree with her when she says, "Change your organization, or change your organization." I am just not sure how much fight I have left in me. I am truly ready to help transition an organization while learning the best ways to go Agile and deliver value regularly and routinely. However, is there an organization out there that is ready to take that journey with me? I hope it is my current organization, but if it is not, I might just "change my organization."

Sunday, March 21, 2010

AgileCoachCamp 2010 NC - An Unconference

This weekend I attended the AgileCoachCamp 2010 in Durham, NC. It was free, I am completely new to this community, and there was no agenda. There was a call for "position papers" that were really just session abstracts. To the best of my knowledge there were no identified speakers before the conference started.

I think I might have been one of just a few Agile newbies at that OpenSpace (what was called an) unconference. I am new to the world of Agile, and I was surrounded not just by Agile practitioners, but in large part by Agile coaches, people coaching others in the best practices of going and using Agile. I first felt out of place, but the OpenSpace format was amazingly simple yet really effective. I joined sessions at the beginning, but later left when I was done providing and receiving value. The entire process seemed so organic in so much as everyone immediately understood it and used it for mutual advantage. The session marketplace concept was intuitive and allowed us to self-organize effectively.

This community of Agile Coaches is something that I plan to follow and participate in as much as I can.

New ScrumMaster....

So, last weekend (3/13-3/14) I attended 2 days of ScrumMaster training in Richmond, VA with Lyssa Adkins and Catherine Louis. This was an AWESOME experience; quite honestly some of the best training I have ever experienced. The following Monday I logged in the Scrum Alliance and took the evaluation to become a CSM - Certified ScrumMaster. I am motivated to become more acquainted with Agile (and Scrum) in an effort to deliver value. I have much to learn, but I am determined to get there. So far, I have seen that the Agile community is eager to help.

Avoiding Tech-sand

Tech-sand (technical quicksand) is my label for technology (hardware, software, knowledge, and/or practices) that keep us from delivering value or progressing in our craft. Often tech-sand is poorly understood yet still implemented technology. It can also simply be outdated legacy technology that is heavily entrenched. If you have any IT experience, you most likely have experienced tech-sand. My blog is about the pursuit to deliver value without creating tech-sand for me or others to deal with. As far as I know, I came up with the tech-sand moniker. That is to say that I searched for related instances on tech-sand so that I did not squat on someone's IP or trademark. If you think I have failed in my attempt to be original, let me know and I will consider your argument.