It is dawning on me that in the world of project management (and business management in general), that we are too obsessed with managing complexity and reducing chaos which are becoming more inevitable in our increasingly dynamic and hyper-connected world. The concoction of tools, methods and processes that has flourished in the Agile community in the past two decades has all been in one manner or other, simple variations to address complexity and the ensuing chaos that results from this.
Maybe it is time to go the other direction and embrace complexity and exploit chaos. This is very new and I’m still thinking it through, but rather than the reductive process of extrapolating out the clearly defined project activities in a controlled iteration, could there be a way to let these “run loose” so to speak, see what kind of behavioral patterns and team dynamics result and just help facilitate the team to channel the flow patterns till they deliver what they need?
I know this is what many of the well know Agile methods are supposed to facilitate, but I don’t think they go deep enough or really exploit the small perturbations that could result in big breakthrough productivity gains.
In any event, rather than Agile I would like to call this Fragile project management. Because it’s the kind of project in which you must constantly “handle with care.” More explorations to come!
I have written extensively on this blog about the adoption of the Agile mindset to industries outside software development. I find this trend interesting as it indicates that the profession we are involved with comes equipped with tools, techniques and most importantly, a conceptual model of project management that’s applicable to all industries. That this trend is increasing is a great barometer on the future viability of this profession.
So it comes as no surprise that I run into this article about adopting the Agile mindset to the multi-channel marketing field of commerce. As the articles states:
Agile Commerce is the fresh and new approach to commerce in 2014, and it’s a critical way of thinking that you can’t risk overlooking… Undoubtedly customer sales and engagement channels are ever evolving; from brick and mortar stores, e-commerce stores, social media platforms, mobile as well as all the traditional media channels. For this reason, the focus needs to shift away from the “inside out” approach – companies looking at channels as individual silos, and instead look “outside in” by looking at the customer journey and the roles that each channel plays in the broader context to serve your customer. The reality is that customers are interacting with your brand across multiple channels in multiple ways. This realisation is at the core of the Agile Commerce methodology – Agile Commerce is about optimising the customer journey not just individual channels.
Aside from the faddish and incorrect use of terms like “Agile methodologies” that pepper the article, it is interesting to see this retail marketing group appropriate ideas from the Agile canon to discuss ways of incorporating better customer engagement and process to deploy marketing channel distributions faster.
From a purely practical perspective, this indicates that for us whose bread and butter is developing and applying project management methods and concepts, that we will be poised to be the ones who could lead these initiatives. We just need to think and break out of our IT industry box!
Last November I wrote a post on the initial botch up of HealthCare.gov’s use of Agile techniques on the front-end that didn’t help them deploy the site more efficiently, nor effectively. So it was with interest that I ran into this Time article where it seems they brought in some heavy hitters from Silicon Valley and revamped the site so that it now at least is workable.
So the article points out the broken contracting process (no surprise) and the idea that the “traditional” methods of deployment were just too old school:
But one lesson of the fall and rise of HealthCare.gov has to be that the practice of awarding high-tech, high-stakes contracts to companies whose primary skill seems to be getting those contracts rather than delivering on them has to change…
One of the things that shocked [the rescue] team most–”among many jaw-dropping aspects of what we found,” as one put it–was that the people running HealthCare.gov had no “dashboard,” no quick way for engineers to measure what was going on at the website, such as how many people were using it, what the response times were for various click-throughs and where traffic was getting tied up…
What saved it were stand-ups... The stand-up culture–identify problem, solve problem, try again–was typical of the rescue squad’s ethic.
But wait a minute, didn’t the government contracts stipulate that they use Agile last time? What was different this time? You can read the article for more details, but my feeling is that it is often times easier to fix problems that have already revealed themselves. And with such a large and public deployment like HealthCare.gov that did so badly the first time around, people’s expectations were as low as you could go so any improvements would look great.
Would getting the elite, heavy hitters from Silicon Valley initially been more beneficial? Maybe, but then they would have dropped in with a style that is very contrary to the government’s style of IT deployments that it may have created more problems. We’ll never know, but the lessons learned from this are one’s that we as project professionals should pay heed.
I found this article on the Defense.gov website and it seems they made a decision to go Agile with how they procure and deploy IT:
So, based on recommendations contained in the 2009 Defense Science Board Report, the department is working to speed up the route to acquiring new systems by increasing collaboration and improving processes, McFarland said.
“To do this, one must start with the defined requirement or capability,” she added.
In the past, once an IT requirement or capability was defined, organizations were able to acquire only that technology which precisely met the predefined parameters.
The introduction of the “IT box” concept is a significant change to the IT acquisition process, McFarland said. The IT box gives organizations the ability to acquire technology that improves on already-approved technology, as long as the changes don’t exceed certain parameters.
In addition to the IT box, the department has introduced interim guidance to adopt “modular, open system methodology, with heavy emphasis on design for change,” which will help DOD adapt to the changing IT environment, the assistant secretary said.
“The policy addresses the realization that IT capabilities may evolve, so desired capabilities can be traded off against cost and initial operational capability to deliver the best product to the field in a timely manner,” she said.
I still find the statement confusing. On the one hand, they are saying they need IT requirements to meet "predefine paramaters", but will also need to heavily emphasize "design for change".
Maybe the goverment works in a different reality, but that's not how Agile typically works. If I'm wrong, please let me know!
It seems lately that I'm finding quite a few articles on the web where people are moving away from Scrum to Kanban. As this post from the blog "Journey of Continuous Improvement" indicates:
Some people will argue that we weren’t doing Scrum right so no wonder we had problems. But this is the crux of my problem with it – so much effort goes to doing scrum instead of channelling that focus to building better software, faster. For my team, using Kanban to liberate us from a prescribed process and visualising the way we worked allowed us to have this focus. I think there is a misconception that Kanban is a process and directly comparable to scrum. I don’t see it like that. I see Kanban as a set of practices which helps teams define their own way to work with absolute freedom. It wraps around your way of working and helps you refine it.
The section about liberating from a "prescribed process" was interesting to me as many think Scrum is about being flexible, but in reality if you're doing it "right" you have to come up with good story point estimates and plan your Sprints to ensure you deliver working software at the end of a Sprint. Estimating is notoriously hard and even more so if you're doing cutting edge software.
In this post from "Blue Sky on Mars", it outlines a similar sentiment:
With Scrum, this sort of planning is built-in to the process. You estimate all of the stories in question, add them up and divide by the velocity to find out how many sprints it’ll take. Or, compute how many sprints you have and then you can choose which stories fit best into the time you have.
In the Kanban process, you can get the same kinds of useful estimates by computing “cycle time” and “throughput”. Cycle time is the average time it takes for similar-sized stories to work their way across the board. Throughput is how many similar-sized stories are done over a given period of time. Using this combination of data, you can do the same sorts of planning you can do in Scrum. As a bonus, cycle time and throughput are easy to compute, and should be easy to adjust when exceptional conditions arise.
Though completely anecdotal, I'm not surprised by this trend. It seems the typical transition is from Scrum, to Scrumban to finally, just Kanban. Could it be that the pace has gotten so fast that even Scrum is starting to feel like a bottleneck? Will Kanban be the new Scrum going forward?