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.
The ideas I’m going to list are often stated as truths even though there is vast evidence to the contrary. These ideas are rarely talked about on discussion groups and are actively discouraged by the Agile Industrial Complex (AID). I am not saying people’s intentions are ignoble, but it is poor science to not examine one’s belief systems. Here are some ideas that I do not believe are true, but which underlie many of our common approaches. Note, this is not a complete list.
Each presumption is followed by a short statement as to why it isn’t true. Some have additional references to explain why.
- Systems Thinking
- Lean Related
- Related to Scaling
- Management Related
- Culture and Change Management
- Team Related
- Technical Issues
- That saying something is orthogonal to an approach is OK. If it truly is not orthogonal, one will often get poor results. Unfortunately, framework tunnel vision will often not have practitioners of the approach notice what they need to.
- That you can attend to only some aspects of project management and expect to get good results. Software development is complex. This means we must take a holistic approach. While we don’t need to work on everything, we need to make an initial consideration of those factors that are of primary importance (e.g., workload, workflow order, team structure).
- Taking a broad view does not mean you are taking a heavy view. The scope of your process/method/framework is orthogonal to the heaviness of it.
- That complexity means you must start with a subset of your system. Complex systems cannot be decomposed, they are not a collection of components. It is the relationship between aspects of the system that often cause unintended behavior. Attending to only some aspects of your organization when making changes will like cause additional challenges. Complexity, in fact, means just the opposite – a simplistic approach to organizational development is fraught with risk.
- That adding Lean practices into a non-system thinking approach makes the approach any more lean. Lean is a mindset based on systems-thinking. While you can add lean-practices (e.g., managing WIP) that does not make the approach you are using Lean unless you have a Lean mindset to begin with.
- That if you are not focusing on people then you are not valuing them. Sometimes the best way to manage something is to attend to the factors that affect it. One best demonstrates respect for people by making the environment within which they work better. Creating an environment for trust is better than merely having conversations about it. In the same way that focusing on cost reductions often results in high costs, focusing on people directly often is less effective than attending to other issues.
- That if something works well at the team level it is ok to assume it will work at the team of teams level. Different dynamics and motivations are taking place here – this assumption is usually wrong.
- That a collection of good local changes will result in a good global change. It is almost certain that several local changes will need to be less than optimal for those involved in order to be optimal globally.
- That having an approach that can handle large teams means you are endorsing having large teams. Many organizations have overly large projects. However, if that’s where they are, that’s often where you need to start. Merely kicking off a large project does not mean you endorse them, it just may be that with all the complicatedness of the organization’s current solution, there is no other option – and that it is better to start where they are and lean things out than to try to decompose things right from the start.
- Management decisions regarding how to do Agile will always be counter-productive. Not at all my experience. Unfortunately, anti-management sentiment still runs rampant in the Agile space.
- Management’s main role is to remove impediments for teams. While this is definitely one of their roles, management must be proactive and take a bigger picture view and improve the structure within which teams work.
- That saying one should not take a bottom-up approach means one is endorsing a top-down approach. There are many ways to make the organizational transition than bottom-up or top-down.
- That teams must self-organize and learn to work together to create the proper structure for the organization. A higher view is usually necessary to achieve this.
- That you should always start with evolutionary change. While you should always see where you are, there are often opportunities to make a significant improvement that most everyone will accept as being a good place to start. Not doing so risks motivation declining because of the improvements being slower than desired when more is possible.
- That you should always start by managing flow and feedback loops. There is no one-size-fits-all.
- That people resist change. Resistance Is Not to Change. Assuming that people resist all change is simplistic.
- That one approach is best in all situations. While I know everybody says that “one size does not fit all” look at how many consultants promote only one approach.
- That one must get teams in an Agile manner before attempting to get them to work together. Creating the structure within which teams can work together in an Agile manner often helps them learn Agile faster. See Challenging the Assumption That One Must Get Teams to Work First.
- That you should always have cross-functional teams. While cross-functional teams are good they often are not economically viable. When subject-matter-experts (SMEs), architects, those knowledgeable of legacy code, or just otherwise smart folks are scarce, it is often too expensive to train others or acquire them. In any event, it is often not needed to have a special skill on a team for the life of a project. This is especially true for projects that have UX and database issues.
- That self-organization is what makes Scrum work. Scrum works because it manages flow implicitly through cross-functional teams and time-boxing. See Why Scrum Works and How This Tells Us When It Won’t.
- That doing it right the first time takes more effort. The right approach is often faster than hacking things in. Admittedly, one needs to know how to use design patterns and test-first to achieve this.
CEO, Net Objectives
Others that will be written up soon
A simple start is good, but using the same simple start everywhere is not
Enabling the adding of practices is good, giving guidance on which ones to add and providing them is even better
Some practices are really good, but none are optimal everywhere, so demanding everyone do them can be counterproductive
Making it easy to adopt a framework is good, but doing it by leaving out critical parts is not
Adding functionality to a system is good, but it shouldn’t require making the system complicated
Incorporating practices from other mindsets is good, but pretending that this means your approach has the same mindset is not
Recognizing that most companies need to do similar things is good, pretending this means most companies need to start the same way is not