Request for Input
I will be speaking in the forthcoming Agile Roots Conference in Salt Lake City, Utah. The motto for the conference is Rooted in the past. Growing towards the Future. To properly express this motto in my presentation, I would like to embed a broad spectrum of threads and opinions from as many Agilists as possible. Any suggestions made by readers of this blog will be much appreciated.
The Agile Executive 
With this motto in mind I think of the growth of Agile practices is similar to a vine.
There is a common root system for individual branches which extend in many directions on the trellis.
We cannot forget that there has to still be a trellis – a business whose operational and organizational infrastructure will continue to exist.
A few regions of the trellis with which Agile will be well served to find ways to coexists as time goes by include DoD, FDA, TUV, ISO and CMMi-oriented, etc. organizatons.
Agile can continue to flourish on the trellis of a broad spectrum of software development businesses, organizations and certification models – continued growth in the future across this spectrum will strengthen the acceptance, adoption and institutionalization of Agile practices everywhere.
Have I belabored the analogy badly enough yet? 🙂
Brad
Brad Sherman
March 24, 2009 at 5:02 pm
Obviously, it is not without a reason that we have the VC firm Trellis Partners in town (Austin, TX)…
Thanks!
Israel
israelgat
March 24, 2009 at 5:28 pm
The need for Agile is clearly rooted in the past, in the high percentage of projects that failed to deliver as promised or failed to deliver at all.
Agile Scrum has been around long enough to have developed a “past” now too. Agile Scrum’s past is rich with tales of accelerated development, increased productivity, decreased time to market and higher levels of responsiveness to project sponsor feedback.
The picture of Agile’s past is not entirely rosy. Jumping right into a project armed with a backlog list and little else has resulted in some great looking projects and happy project sponsors. The bloom sometimes comes off the rose when the underlying foundation of the project does not scale and needs to be rearchitected.
As Agile Scrum grows towards the future maybe it’s time to focus more attention and apply more structure to the process of defining the foundation/architecture of the project before we begin the sprinting.
Continuing with Brad’s analogy – the Trellis is after all a great example of a supportive architecture.
-Leesa
Leesa Haslam
March 24, 2009 at 7:15 pm
Leesa, please help me better understand the point you are making. I view Scrum as a “just enough” management methodology – sufficient substance to do the job without unnecessary complexities. Needless to say, the foundations/architecture you mention are of critical importance. In well managed Scrum teams they evolve before a release starts, during “Iteration 0” and in the course of the release. Likewise, the co-existence that Brad highlights is part of the governance that a Scrum project needs for success. However, I do not know that the foundations/architecture and/or the co-existence have to be specified in Scrum. I actually often draw a picture a la the OSI Reference Model. Scrum in this picture is a layer, not the whole stack. Layers of the software engineering fabric surround the Scrum layer in this picture.
Are we basically in agreement or am I missing an important point?
Thanks!
Israel
Israel Gat
March 24, 2009 at 10:20 pm
My reaction to this question is “how does an Agile team remember its own past”, or record knowledge for later sharing. Not exactly what you asked… but here goes anyway 😉
Some long time ago I decided that everyone on an Agile team _must_ be able to draw the design of the system on a whiteboard. If somebody can’t do that the team has failed to communicate and must fix the situation immediately.
A little later I grew that to everyone associated to the project must be able to describe the one or several goals of the project, in terms of customer or business success.
Still later, I decide that any one goal/component/integration should have a “one pager” that provides the roadmap for that piece.
Then, lots of time passes until the last year or so.
I recently found a book on the Toyota A3 thinking tool: http://www.lean.org/Bookstore/ProductDetails.cfm?SelectedProductID=246
From the page, the A3 is “practice of getting the problem, the analysis, the corrective actions, and the action plan down on a single sheet of large (A3) paper”.
That link has the intro and first 2 chapters available for download, I’ve bought and read the book, loved it.
I’m now trying to integrate the process of A3 management into my daily Agile development and coaching.
So, my suggestion is a non sequitur into the learning and roots of each Agile team for it’s own future.
Cheers,
John
John Heintz
March 27, 2009 at 9:59 am
John, your suggestion is to learn from history at the individual Agile team level. A3 fits into the learning from history thread in two ways: A) as an artifact that is added to customary Agile/Scrum artifacts such as backlog(s) and burndown charts; and, B) as a refinement to the Agile process. I believe I understand the first one – A3 as an artifact. I would like to learn more from you how you weave “… the process of A3 management into my daily Agile development and coaching.”
Thanks!
Israel
israelgat
March 27, 2009 at 6:44 pm
Israel, We are in agreement.
Thank you!
-Leesa
Leesa Haslam
March 27, 2009 at 10:16 am