About Jim Magers

Sometimes the best way to learn something well is via the school of hard knocks.  That’s where you discover that all of the classroom training and academic exercises you were taught are not always as easy to apply as the instructor may have led you to believe.  Much of what I have learned about implementing agile over the past 10+ years has been from having to do it in the real world…on the job…mostly in situations where the product development process was badly broken and needed to be fixed in a hurry.

I’m not your typical agile coach.  Long ago, at the start of my career, I was a developer, and a pretty good one, if I must say so myself.  It wasn’t long before my boss ordained me as the team leader and started me down a management path.  Much of my career was spent at CheckFree, guiding and directing the development of various online bill payment applications.  While at CheckFree I held a variety of titles, including VP of Development, SVP of Product Management, VP of Research and Technology, and VP of Corporate Business Development.  I’ve always prided myself on being a technician at heart who could deal equally well on the business side of the board room table.  I’ve run product organizations so I understand and am sympathetic to the challenges faced by product management professionals.  All of the projects that I ran from the early 2000’s until I left CheckFree in 2008 were organized and operated around agile process and principles.

After CheckFree, I spent a couple of years as the EVP of Product Development for a small, $20 million company whose strategy involved a fairly heavy use of outsourced overseas development personnel.   Their organizational structure was fatally flawed, their product development process was badly broken, and there was a lot of bad blood between the product management team and the development team.  Our implementation of agile took hold quickly and was powerfully transformational.

Finally, faced yet again with needing to improve process at my next company, where I served as CTO, I once again directed and managed the company through a successful and rapid implementation of agile.

So, I’ve implemented and managed successful agile teams many times over the course of the past 10 years.  I’ve personally experienced what works and what does not work, and I’ve had to negotiate and navigate just about every obstacle imaginable that one might encounter when undertaking an agile transformation.

This background of having to address real business needs has caused me to be a very pragmatic practitioner of agile   I believe in tweaking and adjusting the process to fit the needs of the organization, and I strive to accomplish a few things that I believe pay off big in terms of benefits:

  • Create highly engaged and collaborative cross-functional teams.  When this happens, many of the fundamental issues that occur inside of the development machine go away.  It always energizes me to experience the change in people when this works well, as you see them step up and take on responsibility in a different way than before.  They become part of the overall solution as opposed to just chess pieces being moved around on the table.
  • Create consistent and predictable velocity out of the Scrum teams.  This builds confidence within the team and to customers of the development team as well, and helps ultimately with predicting release dates and managing schedules.
  • Get the product owner and the QA resources fully integrated into the team.  When you do this well, adversaries become partners and advocates.  Effective face to face interaction results in higher quality output and fewer disconnects in terms of anticipated features and functionality.  All very powerful stuff.
  • Create what I might best describe as a “rhythm” inside of the Scrum teams.  There is a comfortable and consistent cycle that the team can settle into when the process works well that helps enable the predictability that we strive to achieve.