An Agile, Lean Communication

Sometimes the conversations that we have on-line are revealing and illuminating. My recent discussion with ActiveEngine Sensei, who focuses on software development processes, allowed us to share lean, agile and best practice collaboration processes that drastically cut wasteful activity and accelerate business processes. He comes from a software development perspective whereas I come from a business process strategy perspective. Here is our unedited discussion:

Sensei: Bob- I agree with your position that project management is viewed as fix for broken processes. The PMO should be the “library” or internal consulting group that the units turn to when they need to embark on complex initiatives, as the PMO should have the best practices assembled from previous successes.

Numerous times I have heard “I don’t know how you are supposed to run a software implementation project.” The PMO should have the materials, although at an appropriate level, for a quick read. Better yet, would it not be great if one their peers had submitted a best practices 1 – pager? This communicates with people on a level that engenders the use of those practices before the crisis hits.

PM411: Sensei- The one pager best practice guidance is good because I believe that PMOs should “guide” and not “monitor”. I’m a big fan of a PMO helping to accelerate projects also and the idea that value of a project should trump cost. This aligns with agile software development- a quick look at your blog revealed software development experience- what do you think of agile methods?

Sensei: Although they are no panacea, Agile methods and Test Driven Development in particular can greatly enhances the communication process, as it focuses the developers on solving the customer problems with the customer as a partner in the analysis and creation of the solution. The developer(s) and the customer(s) write the test together, creating a single point of specification.Too many times I have witnessed the customer develop something WITHOUT the developers, deliver a spec, then demand budget and timeline. Now you’re on the fast bus to valley of frustration, as the developers need to re-work the “spec” to create something they understand. In the end you have two views of what the deliverable should be. Not what I would consider effective communication.

PM411: Yes! If only we would communicate- in software development, in selling, in management and in our lives outside of work. Software development is a fascinating process of communication followed by extended, creative work, followed by review/testing/spec changing that somehow reveals the power that communication methods can have on other processes. I’ll be doing a post on an article I read years ago about comparing agile methods to lean manufacturing that I’ll send to you. Us non-software developers have a lot to learn from your craft.

Sensei: I am on the quest to shorten the cycles between communication, analysis, development, testing and acceptance. The sweet spot would be to implement processes that capture the communications and turn those models that the discussion produces directly into workable products. In addition, the ability to adapt changes on the fly while not having to re-deploy the solution would bring great savings to an organization.

PM411: There is nothing like solving the problem NOW, assuming you have a workable solution, versus delaying with wasteful “time to think about it”, “get opinions of others”, “formulate an email summary”, “create a spec”, etc. I’m reminded of a lean vs agile comparison in which the “inventory” of a software development project is documentation- i.e., most documentation is “waste”. Working the NOW way forces you to collaborate and move ahead- so much more can be accomplished. My most recent example is in a packaged software sales process where a typical multiple phone call and multiple visit “sales cycle” is short circuited by first agreeing on the problem to be solved and then the value of solving the problem; the typical approach is to present the generic solution first which usually causes a huge disconnect that must be unraveled through wasteful communications.