Self-organizing, cross-functional teams are good when it is possible and advisable to achieve them.
The question is how do you create them? I tend to look at the edge conditions because I believe that when you learn to handle difficult cases you also learn how to manage and teach the easier cases even better.
Continue reading “Getting to cross-functional teams”
This blog was originally written in August of 2014. I’ve added a few items today. And will continue to add items as they occur to me. When I first wrote this I called them ‘myths’ but now call them presumptions since that is more indicative of what they are.
The difference between science and religion is religion can’t abide being wrong science seeks to be wrong. Neil Tyson
One of my frustrations in the Agile industry is that so many people continue to propagate ideas which have never been truly explored and which I do not to believe to be true. One of the foundations of the scientific method is “scientific skepticism.” Scientific skepticism means both that one does not accept something as true without evidence. And even when accepted as likely true, we keep looking for evidence that it is not.
Continue reading “Presumptions I Do Not Believe In”
This post was originally written 2014-03-15
As some of you may have seen, Ron Jeffries put forth a blog on SAFe that assumes something I don’t agree with – always get teams doing Agile before starting to scale. By Scale, I don’t mean making projects larger, but rather having Agile extend across the entire project.
Continue reading “Challenging the Assumption That One Must Get Teams to Work First”
This was originally written 2013-12-30 22:56 by Al Shalloway
I have just started writing a new book and there is a section in the introduction that I thought would be interesting to people. It’s called “Systems Thinking and Complex Systems.” Here is an early version.
I keep hearing that because we are working on complex systems we cannot have full coverage of what to look for. I think it is just the opposite. Because we are working on complex systems we must have complete coverage.
Systems Thinking and Complex Systems
Continue reading “The Implications of Systems Thinking and Complex Systems”
Our Agile at scale methods are often like driving on the wrong side of the road in reverse during a rainstorm. While the driver’s are well intended, and may even appreciate that at least they’re in a car, that are better ways. Here’s a list of things we must do that are usually not done when attempting Agile at scale.
Continue reading “We shouldn’t be surprised by Dark Agile. We should be surprised it works as well as it does”
Originally posted October 3, 2010
It is seductive to think about scaling Agile up from teams to the enterprise. It seems the correct path to take because you can almost always find a team or two where Agile methods lead to great improvements over Waterfall methods. But what works for a few teams at the local level often obscures the bigger picture: creating enterprise agility. Enterprise agility is the ability of an organization to deliver value quickly when needed. Sadly, I have seen many organizations achieve many successes locally – team agility – and move even further away from enterprise agility.
Continue reading “How Successful Pilots Often Actually Hurt an Organization”
While the Agile community is finally starting to embrace Lean it’s still behind the curve. The real target is flow via business agility – the quick realization of value sustainably, predictably and with high quality.
Even this is no longer cutting edge. Donald Reinertsen’s Principles of Product Development Flow is over a decade old. Agile’s recent adoption of Lean is good but it still is a bottom-up approach. Thinking in terms of flow creates a better context and will put you years ahead of current, common thinking.
Continue reading “Why we want to focus on Flow while using Lean and Agile”
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extending functionality. (GoF)
Continue reading “The Decorator”
Consider how your organization is currently developing products and/or services. As a thought experiment, consider how to make things worse. For example, have people work on too many things, don’t have a process where you resolve multiple requests, have product managers create requirements
for the team and just hand them off in written form, have developers and testers be in separate organizations, have managers makeup schedules and then berate developers when they are not met, … You get the idea.
I’m pretty sure you can see that things will get worse. Now, consider where in your organization you are doing some of these ineffective things. Could you stop doing some of them? Even partially? If it became worse when you started doing these wouldn’t it get better if you just stopped doing them? Sometimes improvements are easier to achieve just by stopping doing things incorrectly.
Of course, making these changes is no guarantee of improving your process, but generally, improvement will occur if you do them. As always, you must run any improvement as a hypothesis of it being a better way and validate that it is.
Learn more at Understand Your Options.
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. (GoF)
When planning a vacation, business trip, or other travel there are a lot of different aspects that have to be reserved, scheduled, and otherwise arranged for. Each of these elements (a hotel, a rental car, etc.) has a different way of accessing it. In the past, this would involve lots of phone calls, the use of a legacy system called Saber, some faxes… A lot of people preferred to use a travel agent to handle all of these details. Continue reading “The Façade”