Sat in on a talk about agile development and the problems with it at scale. I have seen this first-hand, with the usual suspects: We can’t all do that, we are not all developers. We can’t organize and align our teams, it’s too hard and we’re too big, working on too many different things. We can’t work in that particular way because we’re different, so we need to have a different development process.
All of this is untrue, which is not to say that it isn’t hard to make it work. But that’s really more about the difficulty of accepting change in culture and that most teams are pretty unorganized. There’s also a bit of “not invented here” syndrome when you operate at scale.
Still, the talk had a link to a where the author was stressing the differences between increment and iterate. Nicely done and so true. Semantics matter and the difference in these concepts is critical to allow for incremental, iterative delivery of value in technology. You’re going to work towards an optimal solution and you may well get parts of the present goal out in chunks.
The traditional [PMO](http://en.wikipedia.org/wiki/Project_management_office) is often painted as being the salvation of an organization out of control with bad projects littering the landscape. But unless its a good PMO, the entire exercise can lead to only additional overheads, blessing even more useless projects that should have been stopped. In reality, there are lower cost methods other than a new PMO that can save the organization from its own bad culture and lead to effective projects that return value, and a cessation of the bad ones that don’t measure up. Continue reading PMOs not as useful in a world of agile management
I was reading an article on HBR about [leading through a team](http://blogs.hbr.org/hill-lineback/2012/04/good-managers-lead-through-a-t.html) and it made some good points about how micro-management will kill the team, and the difference between a work group and a team. Continue reading Leading Through a Team
Agile, as tied to the [Agile Manifesto](http://agilemanifesto.org/principles.html), is 10 years old. Everyone and their brother wants to apply *agile* to their area of work now. But what does it really mean to become more agile in project management? Continue reading Agile Project Management
Nilofer Merchant writes a [series](http://blogs.hbr.org/cs/2012/03/stop_talking_about_social_and_do_it.html) on how business models have not sufficiently changed in response to social-era changes. Continue reading Organizational Change Models
A neat [piece](http://vgalovski.wordpress.com/2012/02/02/innovation-benchmarking-the-5-stages-of-grieving/) on the five stages of strategic grief and how to leverage it to get into innovating out of the problem. The five stages are detailed: denial, anger, rationalization, depression and through to acceptance, when the organization can begin to solve its problems through innovation. Thought provoking.
[Here](http://bit.ly/qyXeLU) is a synopsis of the *Dealing with Darwin* piece by Geoffrey Moore, which describes different stages of innovation and some levers. This is important as a model for crossing the chasm which is needed to reshape large, territorial groups in an enterprise and allow for an innovation culture to overtake a silo culture. Continue reading Innovation levers and attacking silos in your org
Phil Daniels, while a psychology professor at BYU, is credited with presenting the SKS method. The method is built on asking colleagues what you should *S*top doing, what you should *K*eep doing, and what you should *S*tart doing. They fill in the blanks with no more than three bullet points under each category. Continue reading SKS: Simple mechanism for eliciting feedback
Eri Swager was a system engineer at Toyota and gave four nice, simple (that being the key), low tech techniques for implementing [Kaizen](http://en.wikipedia.org/wiki/Kaizen) in anyone’s workflow. Continue reading Four simple techniques for Kaizen
I’ve been thinking quite a bit about technical debt lately, and found a couple of interesting pieces trying work out the concept in terms of quality and cost. Continue reading Technical debt as quality and cost metrics