FlexDev
I’ve received a lot of great feedbacks on my post It Doesn’t Matter What You Call It. I get the sense that many professionals “out there” are really fed up with the endless online (and offline) debates about “the best software development methodology”.
Reality proves over and over again that there isn’t such thing. The best thing you can do (and that’s the only thing that deserves the title “best”) is to create an optimal process per project.
However, many people (including myself) seem to need a name for that. Maybe that’s because it is not trivial to say “creating the optimal process per project” three times in a row.
So, here’s my “official” name for this approach: Flexible Software Development. Need an even sexier name? Let’s call it FlexDev.
Let’s see if this works….
Developer A: What software development process do you use in your company? Is it Agile Development? I’ve heard that Agile is really cool…
Developer B: No. We are using FlexDev!
Developer A: FlexDev? What kind of process is that? I’ve never heard of it. Is it similar to XP with TDD and Pair Programming, or is more like Waterfallish RUP?
Developer B: It’s neither. But it is also both. It’s creating the optimal process for each project. You see, everything is open. We are not fanatically committed to any process.
Developer A: Sounds like chaos to me!
Developer B: On the contrary. Being flexible doesn’t mean everyone does what they want. At the beginning of each project we decide together what would be the best development approach for that project. Then, during the project we check ourselves to see if there is anything to be improved in this customized process. Nothing in the process is fixed, but everything is thoroughly considered.
Developer A: Hmmm… So do you practice Pair Programming or not?
Developer B: That depends.
Developer A: And do you write a formal design specification?
Developer B: That depends.
Developer A: And are you managing requirements in a commercial requirements tool or in a simple Excel document?
Developer B: …
Well, I guess you get the picture: everything depends… on the context.
FlexDev is your safest bet. Why? Because it’s the only bet you can change according to the project and even as the project progresses.
If embracing change is so great, why not adopt it to the development process itself? Let’s accept the fact that in our dynamic and diverse environment the development process should not be fixed either.
So, is FlexDev a “new” methodology? No. It’s a mindset.

Coming soon: The FlexDev Manifesto…












May 10th, 2006 at 8:13 pm
I’m sure you’ve already run across it, but the approach of invent a methodology that works for each product and adjust as necessary is Alistair Cockburn’s approach in his Crystal methodologies.
May 10th, 2006 at 9:06 pm
See OPEN websites for the theory of customizable methodologies.
http://www.open.org.au/
http://www.donald-firesmith.com/
http://www.opfro.org/
May 10th, 2006 at 10:40 pm
Both comments above refer to a "collection of methodologies" or practices. As Alistair Cockburn’s site states: "Crystal collects together self-adapting family of ’shrink-to-fit,’ human-powered software development methodologies."
Even this approach seems not flexible enough. The collection of relevant practices and methodologies is infinite. Everything is open.
No need for fancy process diagrams (see: http://alistair.cockburn.us/crystal/processes.html). All you need to do is analyze your needs/constraints before the project and as the project progresses. That’s all… (and of course you need experience and common sense, but no diagram can deliver those…)
Of course there’s nothing original about this idea… but the fact is that many people are still hung-up on a certain methodology while ignoring the necessity for a mix-and-match approach.
FlexDev rules! ;)
Lidor
May 10th, 2006 at 11:04 pm
It is a nice idea. I work at an organisation where it is hard enough educating the business and getting their buy-in for a development methodology that we can explain the rules of in detail. It would be chaos here trying to re-educate with every project. We’re moving away from an environment where the SDLC involves a business stakeholder telling a developer something needs to be done by such and such a date and it being up to the developer to juggle their current workload etc.. and make it happen. Little steps huh?
May 11th, 2006 at 12:12 am
[…] My friend, Lidor just posted an introduction to what he calls FlexDev. […]
May 11th, 2006 at 7:00 am
I don’t think FlexDev is anything new, if you understand what Agile means then FlexDev is just a new alias for it. Agile is any process that is flexible and embraces change.
I recommend you read Agile Software Development (http://www.amazon.com/gp/product/0201699699/) and better yet understand the principles behind agile in Lean Software Development (http://www.amazon.com/gp/product/0321150783).
Good luck reinventing the wheel :-)
May 11th, 2006 at 8:45 am
There’s always been JFDI…
May 11th, 2006 at 9:14 am
Ali,
Please refer to my comment above.
The fact is that in our industry, the word Agile was hijacked for describing a concrete process (or a family of processes). But the real world is more complex for any single process to deal with.
Agile makes flexibility as an axiom for the product. But does it really emphasize flexibility in the process? To what extent? Will it be considered Agile not to practice TDD? Will it be Agile to make iterations longer? Will it be considered Agile to write a formal design specification? Will XP (which coined the expression ‘embrace change’) accept a project with no pair programming? From a quick look at various XP forums, it doesn’t look that way…
I don’t want to have to deal with these questions. I just want to do what’s best for the project I currently work in. No matter what you call it.
This is why FlexDev != Agile Development (as interpreted by many).
I am not reinventing anything. I am just stressing what real-world development is like. Whenever someone pulls out the word ‘Agile’ (or XP, or RUP, or any other methodology name) the discussion loses its focus. It becomes a theological discussion.
Instead, I offer to do whatever seems right for a certain project, and not to use the latest buzz as an argument when analyzing what will the development process look like.
Lidor
May 12th, 2006 at 9:26 pm
At what point does an organization reach the maturity level at which it can effectively practice FlexDev? This seems pretty far along the learning curve to me. Wouldn’t it need to have experience in a good sampling of the development methodologies before it could intelligently choose the optimal pieces of each and tune them to the current project? Experience enough to have a good understanding of the different facets of each? The organization would have to have some powerful forces that were willing to be pragmatic and overcome the religious bias inherent in the “methodology wars” that I see in so many blog postings (along the same lines of Linux vs. Windows, EMACS vs. everything else, etc…). I am reminded of the SCMM levels and how an organization will have to progress through them before it becomes capable of handling more ambitious projects.
May 12th, 2006 at 11:14 pm
Hi Jay,
Your observation is correct, but things are not that pessimistic.
First, I would like to focus on the project scope, and leave the organization scope outside this discussion for now. At the project scope you do need an experienced and open-minded people leading the project. They will balance the forces and come up with the optimal process for that project (collaborating with the other team members).
Clearly, using this method at a single project scope is easier than achieving this understanding across the organization.
In time and with more successes this mindset will spread around the organization. The experience and knowledge of other people will grow in time as well.
As you pointed out, the key is to overcome the religious bias. For this, I don’t have any magic recipe. I guess more of us should raise this option whenever a discussion becomes “religious”.
Lidor
June 23rd, 2006 at 12:24 am
Lidor, on the one hand, I do agree with your “theory”, on the other hand, I doubt its applicability. See more at my blog: http://bdory.blogspot.com/2006/06/flexible-software-development-aka.html
June 23rd, 2006 at 12:47 am
Hi BD,
You are right in your argument, but not in your final conclusion: handing the decision about the process to each developer will not work. Maturity, knowledge and experience are all required to make the right adaptations to the process.
But I’ve never said this is for each developer to decide. If you assign a responsible and experience process leader to each project (or if the development lead is one) FlexDev becomes feasible.
You have to have someone accountable for the process in order for it to work. Otherwise, you will get chaos.
As for picking up a concrete methodology in cases where the development leader is not experienced: this won’t work either. You have to know what you are doing and verify that it is good for you along the way. This is true even if you use an of-the-shelf process.
Again, having an experienced process professional who knows to identify the pitfalls and adapt the process as you go is the best approach I can think of. I know that it is also feasible.
Lidor
June 26th, 2006 at 3:15 am
Thanks for your idea Lidor. I agree with you completely that projects are best developed using no predefined process at all - instead, just let the team create their own process, along with whatever practices that bring about the highest possible productivity. The point is that a mature team will know what to do to get things done and any kind of predefined procedures will only serve, more or less, as a burden.
Nonetheless, my point is that it is not easy at all to find teams with leaders/managers who can be of that mature. I’m working in one of the largest outsourcing software shops in Vietnam, and have seen enough incompetent leaders and managers who never quite get what process really means - and thus, there is no way they can create a good process for their own projects (i.e. “what the heck is refactoring that you’re talking about, the code works and just leave it alone, we need to code new features asap my dear boys!!!”).
For those teams, it’s better to have excellent software people around the world to define a bunch of principles and practices (and called them with names as XP, or Scrum etc.), writing books them (and even bringing hype about them) so that the less capable people can learn about them. I don’t say those less capable people can get the much, if any, from doing that, but at least this will definitely help some of them learn something or two about the current state of software engineering - and thus hopefully they can move towards FlexDev.
June 27th, 2006 at 5:08 am
[…] I’ve come across yet another independant redefinition of what pliantalliance.org is getting at. It comes from Lidor who once again hits the nail on the head with FlexDev. FlexDev is defined as “creating the optimal process for each project”. Brilliant. […]
July 27th, 2006 at 11:58 pm
[…] FlexDev: afirma que se debe de implementar el desarrollo óptimo para cada proyecto. Nada de tener un proceso estático que se aplique a todos los proyectos. Dependiendo del proyecto, se implementa un proceso. […]
September 30th, 2006 at 1:44 pm
Watch out — FlexDev is getting popular.
But seriously, here’s another clear thinker:
http://ryan-technorabble.blogspot.com/2006/09/try-your-best-agile-and-why-we-cant.html
He ends with
At best, you could come up with a new group, like “The Workable Code Movement™”, that’s a subset of practices if that’s what you want.
September 30th, 2006 at 2:18 pm
Here’s another one:
http://www.stsc.hill.af.mil/Crosstalk/2003/07/sheard.html
Ends with
A truly successful effort will result when a company develops specific solutions to its specific concerns.
January 30th, 2007 at 1:42 pm
[…] Lidor Wyssocky had a post about the way process should be grown out of project needs and he calls that Flexible Software Development (or FlexDev). He basically argues that people should not be bought into any kind of development processes (e.g. RUP, XP, Scrum) or practices (e.g. TDD, pair programming), instead they should just work out a process of their own during the development life-cycle, depending on the project needs. This can be summarized by the following statement of Lidor […]
January 30th, 2007 at 2:14 pm
[…] Lidor Wyssocky had a post about the way process should be grown out of project needs and he calls that Flexible Software Development (or FlexDev). He basically argues that people should not be bought into any kind of development processes (e.g. RUP, XP, Scrum) or practices (e.g. TDD, pair programming), instead they should just work out a process of their own during the development life-cycle, depending on the project needs. This can be summarized by the following statement of Lidor […]
February 23rd, 2007 at 5:49 pm
Lidor — I keep hoping you will notice the little self-contradiction you’ve gotten yourself into. The moment you named your (non-)methodology “FlexDev”, you immediately bought into the exact problem you mention in the paragraph below… simply substitute “FlexDev” for the phrase “any other methodology name”.
>
It’s a catch-22 — if you don’t name it, no one can refer to it; if you do name it, you immediately get trapped in theological discussions, as has happened on this page. If you allow anything, then you allow more garbage than you intend; if you exclude anything, then you are back to the theological arguments.
Welcome to the club.
Alistair Cockburn
March 15th, 2007 at 3:07 am
Of course you are right, Alistair.
If it wasn’t clear, the FlexDev “marketing” stuff should not be taken too seriously. What should be taken seriously is the fact that common sense is often abandoned in favor of marketing hypes or theological debates.
You quoted me as saying “everything is allowed”, but that refers just the pool of options. Of course some solutions are better than others… but in a certain context. If you know this, and you analyze your needs and constraints properly, you won’t let the garbage in: you will filter it out. You will then have a better chance of succeeding than by sticking to a certain process as described by what could be best referred to as a cult.
Lidor
February 4th, 2008 at 5:46 am
Purchasing Inventory Management Software for Process Manufacturing Businesses
Reducing inventory management costs is an essential and integral part of any business, but none more so than in the process manufacturing business. Proper inventory management can make a real difference in obtaining and retaining a competitive edge in …