Table of contents
[Skip to any section because you can]
I have been working in software development a long time. Early on I recognized the need for Process as a way of re-using best practices for teamwork. At that time, Process implied for most of us the Waterfall model, which divides a development project into discipline based phases, each to be visited once in turn, in a kind of cascade: Requirements; capture the requirements, do the Design, Implementation, Verification and Validation, Deploy, then shift into Maintenance mode. Most people still follow that model implicitly, it has stayed in the everyday consciousness of process, much like Newton’s laws instead of the Theory of Relativity, much like the theory of Creationism over the scientific Theory of Evolution kicked off by Charles Darwin. Yep, Waterfall often creeps in even when people say and even when people think they are using Agile. Of course, project difficulties and even failures based on the extremely high propensity (40% minimum) for requirements to change within the life-cycle of a project highlighted the dire need for at least an Iterative and Incremental model. And when that became too top-heavy, at least in its wonderful, eye-opening but hard to tailor and work with Rational Unified Process, I moved on to a kind of personal synthesis of CMMI (love that continuous improvement and organization wide adoption!) and Agile and Scrum approaches. More recently I have loved the simpler work in process and visual approach of the Kanban as a lean variety of Agile:
“Some Agile methods take a more flexible approach to time than Scrum does. (For example, Kanban does away with the notion of a two-week batch of work and places the emphasis on single-piece flow.) But you can still make time within a Scrum sprint in which creative activities can take place.” Gothelf, Jeff (2013-02-22). Lean UX: Applying Lean Principles to Improve User Experience. O’Reilly Media.
Following in the footsteps of C and Unix programming, C++, Enterprise Java and light-stepped Spring Framework Java, as well as Ruby on Rails, I found myself more as process engineer, architect and mentor in the web application world, rather than mainly programmer, and adopting the Drupal framework and community as my workplace. So I wanted to bring all my prior experience in process and architecture to Drupal and to its community. So I did, with the publication of Leveraging Drupal. Steeped in the Agile moment when it was published in 2009, the first chapter outlined and the whole book implemented in a number of projects, most clearly in Chapter 11: Full Swing Agile Approach to Drupal Development, a process for Drupal incorporating the best practices I had made my own throughout my career.
That was then, this is now, with, as Karen McGrane explains (Responsive Design Won’t Fix Your Content Problem), responsive web design only scratching the surface of how content needs to be structured and based on a clear strategy for today’s multi-device world of consumption. And with all of this heavily impacting the kind of process on which web app dev teams need to base themselves, it’s time for a new process to emerge, and for a new book to be written. The process must take from Agile, from the application of lean startup process (web app dev as product dev of real value based on real needs), and from the need for the team to work on the same visible work in process together, without waterfallish handoffs and with maximum permanent client feedback; and the process must allow itself to be heavily impacted by the need for modern web apps to be responsive, adaptive and based on structured content. For each app is a back-end based API with multiple clients on multiple devices. And each app (and even each distributed component within the app) must have the most adequate framework as its vehicle. So Lean Process is the best process for Drupal based web apps, but at the same time, must emancipate itself from Drupal per se. People are facing today’s challenges on many fronts, and the process will work at its best with Drupal, but also with Backdrop, other CMS’s, and many other stacks all of us are flocking to.
Initial vision for Lean Process artifact workflow; but there are no handoffs here: what used to be scrums are all-eyes interdisciplinary motorized work applied to a common theme everyone is working on together.
Drupal Lean Process is Web App Lean Process, and is emerging as it puts a number of projects concretely under its belt. Today very few are starting from scratch, so we must focus on migrations needed right now, be it Drupal 6 to Drupal 7, Drupal 6 to Backdrop CMS, or from Drupal to other stacks. And it must be a repeatable process; that is, if it is used to migrate from Drupal 6 to Backdrop CMS, it may, in large part, be re-used for alternative future migrations to stacks which may not have come into being as of this writing, but which will capture hearts, minds and communities in the future.
The first public airing of Drupal Lean Process will be at DrupalPicchu, where I will head up an AWebFactory workshop (bi-lingual, English and Spanish) “Conquering an agile process for Drupal, driven by user experience enhancements, with tools” (link coming as soon as sessions are published), that is, on Drupal Lean Process.
Many will come to DrupalPicchu. Many may not. So I have decided to base the workshop on a concrete project, housed in a public GitHub repo, being kicked off as we speak.
Lit Drupal Lean is both the process and the project. Characteristic of Lean Process projects is, just that, they incorporate a reusable process, with workflows and templates and artifacts, and, oh yes, the executable, deployable code, all as a work in progress, erm, in process.
This particular web app centers on the need writers, workshop leaders and publishers have for a community of literary workshops. The project is being kicked off right now, if you watch it you may witness its growth, as it acquires the form it will take during the free workshop January 20-24, 2014 (we might get enthusiastic and start it a day before the conference itself).
Again, here is the link for the public GitHub repo: https://github.com/victorkane/lit-drupal-lean with entry point at the issues page, not the wiki. The Kickoff Milestone tasks already explain a lot about the process.
The book will be self-published this time I think. I will welcome donations of course, but my income is derived mainly from the mentoring services I offer, so the advantage will be that the book will be kept up-to-date, with versioned downloadable tags in the repo for the usual formats. I’m going to take a stab at Markdown → Static Site → ePub and other portable formats (a project in itself 🙂 , and it will be in a public repo). At some point, popular versions may be self-published in the usual sense if deemed useful, but the main objective will be to centralize and openly update the process.
Tools come and go, vary on a per-project basis. But bringing a number of recent articles together, let me share how I am using Eclipse as both an IDE for coding and DVCS, and a powerful (if novel and as yet not totally complete) project management tool.
Remote Perspective with Terminal for Git command-line management.
I could have used the incredible Git Repository Exploring perspective I wrote about recently, and managed version control with the Git visual interface, instead of the command-line as an added option, working directly on a local working copy of the code, while still accessing GitHub issues for project management. Increasingly however, I work on a server, so I prefer the Remote perspective as a starting point. Notice the use of the Markdown Editor plugin associated with *.md files, which comes with a Markdown HTML Preview view.
Remote Perspective showing Task Issues Repositories and Task List Views
I really enjoy the Task Issues Repositories and Task List Views, and have simply added them to the basic Remote perspective. In the former I specify a GitHub repo and an initial query (as I outlined in a previous post), and in the Task List Views, I can work with individual issues, synchronizing them from and to the Issues section of the project, specifying Milestones, specifying and even creating labels, assigning tasks to collaborators, cloning issues from template issues (for often used artifacts), etc. Again, it had better be self-explanatory.
Recent related articles: