Why Agile?

My motivation for using Agile practices is to foster accomplishments and build high-performing teams, and along the way become self organizing and autonomous in What?, When?, Where? and How? for things they work on.

I first started using agile practices, thats agile with a small “a”,  around 2000, when I was working as a consultant at NASA Ames Research Center. I had been working there since 1994 in various roles, being handed off from one consulting company to the next as the contract term for the consultant company expired. If you had worked in a government agency of one sort or another during this time, you will have experienced what I had – essentially by July/August time frame budget on any project other then the favorite project(s) has been exhausted and you are in a limbo not knowing whether you have a job to come to from one week to the next. The situation is made worse by the fact that part of your team, being civil servants, does not have same concerns as even though the project has truly exhausted a budget they are special.

It was under these conditions and being exhausted by the daily grind of team discussions on whether we have new budget (if possible raided from another project) or are we to look for opportunities outside that I proposed the following

  1. we meet daily as a team
  2. take that time to define a set of prioritized features
  3. define some simple use cases and acceptance criteria

Once we had a prioritized list, we opened up the list to other teams on whom we relied on to provide the systems interface. Our program and product management were wowed by this, as not only did we specify the features but score rank these based on a need or a want and has specified a probability/impact metric. We met daily as a team to define on the product feature list and once this was defined we met every other day in the course of fulfilling the development of the prioritized features. After a few weeks went by we decided to demo what was developed, mocking up elements that were not yet developed as they were lower down the priority. As we discovered strong participation from stakeholders, especially during demo days, we instituted a demo day every 2 weeks and opening this up to end customer every 4 weeks – this was so we could get their input first hand.

In essence we made these decisions to save anyone going bonkers, as well as saving the embarrassment felt by some of the civil servants on the team at our situation. You see, some of them were not so long ago consultants themselves and couple of them were recruited straight from college and were junior team members when compared to experienced consultants who had already worked 7-10 years across many projects within the agency.

It wasn’t until I started working at Salesforce.com (SFDC) that I realized software and systems development outside the environments I had worked in organized themselves into functional roles.  This machinery if you will was no doubt influenced by how things were done in mass industrial production system, and no doubt driven by the ideas of production efficiency in so far as how software used to get delivered in shrink wrapped boxes be it consumer or enterprise software. It was around that same time period SFDC started it’s Agile journey, one of small product teams focused on product excellence. At this point I had a formal introduction to Scrum, only to find that this said had been much of the way I had worked in environments years prior. Of course, I wish I could say it was like duck taking to water, alas that would be stretching the truth. It works out adoption is prefaced by the context and culture you find yourself in. So, if you want to know, sure I can be talked into sharing stories as I recall them over a beer or two!. In the end this experience led to the opportunity of being a consultant agile coach at PayPal, which was equally rewarding as I now gained experience from a consumer focused environment one that couldn’t be so different from SFDC.

Currently, I am a full-time Agile Transformation Leader at Adobe Systems, Inc® a product company for helping creatives in all of us realize their creative side!. In the past two years I have attained Certified Scrum Trainer® status through the Scrum Alliance® . By mid-2015 I have trained over 2000 people on Agile practices – from Scrum, Lean/Agile and Kanban system practices, and have now led enterprise scale adoption across multiple product/service areas. This also means I have been coaching teams on agile practices, for better or worse, for past 6 years and for the past 5 years I have also focused coaching line managers and leadership on how best they can go about cultivating a sustainable agile eco-system.

Finally, In order to be a better coach and facilitator I have embraced the idea that if we come to play then that makes work easy. So I am on a journey of learning to play serious games, and in the process helping people, teams and organizations play serious games to do the heavy lifting with their decision making one that helps them disambiguate the uncertainty and conflicted views that is part and parcel of complex adaptive systems. I am a black-belt facilitator in Innovation Games, and this embodies much of the tool set I when playing serious games. I have recently started a journey into Organization and Relationship Systems Coaching, so I can continue to help bring about positive organizational change for those seeking it.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s