The insanities of roadmap publishing
Last night at DelphiLive they had a “Meet the team” event in one of the halls, where most of the RAD Studio development team was present and the attendees could hang out and chat with them. While I was there, I talked with Mike Rozlog a bit. He’d seen some of the critical things I wrote on here and on the forums about the roadmap, and he explained to me a bit about how the process of making a roadmap works. One thing to keep in mind is that he told me it’s like this everywhere he’s worked. What I’m about to describe is apparently not a symptom of dysfunctional corporate culture at Embarcadero; more like dysfunctional corporate culture in general.Apparently, due to really complicated business-related reasons that I didn’t understand well enough to explain here, producing an official roadmap for a commercial product almost invariably has to be signed off on by anyone and everyone with any degree of decision-making authority. This might be a bit inaccurate, but the impression I got is that it’s kinda like getting Congress to pass a law, except that each individual Congressman has not only a vote, but veto power as well!
They’d have something almost ready, and then person A says “No, we can’t do this, we shouldn’t have X on there, it needs to be Y instead,” so they take X off and replace it with Y. Then person B looks at it and says, “hey, what happened to X? That was critical!” So Mike has to explain that it was removed because of person A, and get those two in a room together where they can discuss it and work out a compromise, and then they update the roadmap so it says XY. And then of course, person C comes by and says, “hey, what’s with all this X stuff in there? I thought we took it out, because we won’t be able to get it implemented on this schedule!” And it’s back to square one.
Repeat a few dozen times, over a period of a few months, until finally they reach the Ultimate Compromise that everyone can bring themselves to agree upon, and then they finally publish the new version. That’s the easy part. Once everyone’s signed off on it, it takes about five minutes to get it posted to embarcadero.com. He said that he’d have liked to publish the updated roadmap before the XE sneak previews started, but that just wouldn’t have worked on the timetable they had. It was a real eye-opener, talking with him about the process. It makes the roadmaps being the way they are a bit more understandable.
Mike also mentioned that a lot of people, including himself, don’t like the “PowerPoint slide” format that the last few roadmaps have been done in, and the next one will probably be done a different way. Of course, working out what the new format will look like will be another long round of negotiations and compromises…
Again, apparently this is all completely normal for trying to publish a roadmap for a commercial product. What do you guys think? Has anyone out there been in a similar situation? Are roadmaps always that messy, or has Mike just had a run of bad luck?
Do you guys ever watch MSDN Channel 9?
http://channel9.msdn.com/tags/Visual%20Studio/
You get a real good idea of what Microsoft has in store for the next editions of Visual Studio.
THAT is what we want to see for Delphi. It doesn’t have to be a “roadmap” per se… but they need to let us know what they’re working on, and NOT working on, to give us an idea as to what will “probably” make it into the next releases.
Here’s a good example: I remember seeing on Channel 9 a guy say “you had better start looking at WPF forms, because we’ve stopped working on WinForms…”
If only I had heard from CodeGear that they’d stopped working on VCL.Net in the same way. Instead of just POOF dropping it out of the product one day.
Sorry, but the idea that this is how it works *everywhere* is hogwash. Maybe it’s the way it has always worked when Mike Rozlog has been involved, but perhaps that tells us something about the way he goes about such things.
I have been involved in producing roadmaps myself, and the way they haved work in my experience is this:
You get all everyone with input to the roadmap to attend a summit to discuss the roadmap.
The roadmap is agreed AT that summit – summit isn’t concluded until that point of agreement is reached. Depending on the size of company/product and scope of roadmap (how far out you are looking) that summit can take anywhere from a couple of hours to a week. At the end of the summit, you have your roadmap.
Not only is this critical to the production of the roadmap, but it’s critical for the DIRECTION OF THE COMPANY.
This is the way it has worked at all the companies that *I* have been involved in producing roadmaps.
Bear in mind, if you can’t settle on a roadmap then you aren’t settled on the direction in which you are going and the priorities you are setting yourself, then you will be constantly changing direction and priorities.
Oh but wait, that’s exactly what we have seen over recent years at Borcaderoprise… now it all starts to make sense.
I should have added that the product of a roadmap summit is actually TWO (or more) roadmaps:
1) The actual roadmap that describes the product/company direction for internal use to provide the “vision” that everyone in the company is working towards
2) An edited form of the roadmap for publication. This is not a *different* roadmap though – it cannot be. The company cannot be going in one direction internally but telling the outside world something else.
The published roadmap(s) have certain information or detail removed as required.
Roadmap(s) plural because you may have different external audiences – customers will need to see even less information than partners/resellers etc, who in turn don’t themselves need to see the FULL roadmap.
The customer roadmap can (I’d say *should*) be reduced to a series of bullet points – not necessarily PowerPoint, but very little more information than can be conveyed in a PowerPoint.
Reseller and Partner roadmaps will often require additional narrative background/support.
The full roadmap is a document.
BUT the point is, this is all hammered out AT THE SUMMIT. Not over months and months. The information and decisions that feed INTO and inform the roadmap summit are the accumulation of those previous months and months of decisions, experiences and discussions – the point of the roadmap is to sit down and say: “Right, given what we (note: “WE”) have learned and achieved in the past N months, where do we want to be in A, B or C months/years time, and how will we get there”.
It doesn’t take an MBA to realise that the most effective way of doing that is NOT by sending documents around and around for individuals to critique, edit, modify etc to suit their own personal agendas.
So Mike is saying that everyone in the company has a veto when it comes to deciding what’s going to happen with a product in the future? He’s saying that a strategy for the future is decided on someone painting up an idea of how it might look up and then he runs from person a to person z multiple times until they all agree? Sorry but that doesn’t sound right. And if it is right then the company is in urgent need of a meeting room, a product strategy manager per product and a strong CTO/CEO/CFO trio. Maybe I’m wrong but the best way to find a strategy is that all involved talk to each other, compromise where possible and a strong hand that makes a decision when compromise doesn’t seem possible within a reasonable timeframe. Just my thoughts.
From my experience, Jolyon’s post describes how the roadmap often starts off.
Sometime later down the track, one (or more) things happen to modify the roadmap: Competitor activity, Development slippage, buzzworditis, whatever. A new summit is not called, but rather “those in a position of power” (TIAPOP) change the roadmap (with varying amounts of consultation from those who originally created it) to either add or remove features to respond to the new business realities.
It is a fact of life that features they remove will invariably be close to completion, and features they add will be more extensive than (they) estimated.
In some cases, product priorities come down to whatever promises TIAPOP have made.
I’ve seen this occur in a wide range of organization sizes. Nobody seems to be completely immune.
However there is hope ….
One of the goals of the Scrum methodology is to provide a framework wherein TIAPOP commit to NOT make changes, except at well defined points in time. In exchange for this, the development team commit to deliver what was committed to by the agreed timeframe. Other aspects like Developers not setting priorities & non-developers not making estimates are fundamental to the Agile techniques.
I know that comparisons doesn’t fit, but that itself is disgrace…
Microsoft maybe have 100 people for each one Embarcaderian dedicated to Delphi, but isn’t that a bigger challenge indeed?
Well, Microsoft can coordinate the roadmap of .Net framework included the core library, plus the C# and VB compiler, plus ADO.NET, ADO.NET Entity framework, plus WCF, plus Silverlight, RIA Services, Linq to (SQL|Collections|Entities|XML|whatever), MEF, WPF, MEF, Visual Studio, ASP.NET (and MVC), plus their community connection, marketing, SQL Server, Expression (Blend, Web, Designer) and at the same time, keep the efforts and strategy connected with Office,Servers and Desktop teams…. in recent years (last 9 years at least) almost everything have been orchrestrated smoothly, so every one of the technologies I mentioned supports or is supoorted by or builded over some of the others.
I mean, there should be a better way, always exists a better way… maybe it just needs a better main head that can trust the minds that knows what they are doing, and could just let them be… a greater leader.
And I don’t think the problem came in the codegear package, I think maybe is a enterprise cultural crash, a democracy of professionals crashing with a command and conquer style of management maybe?
That’s how the Japanese work.
1. American goes to Tokyo with a business plan.
2. Japanese bosses take plan and say “Yes”.
3. American goes home and thinks the deal is done and the wheels are turning.
4. Japanese bosses discuss plan amongst themselves and reach consensus.
5. Each boss goes to each division, discuss the plan with that division’s heads, and reach consensus.
6. American gets frustrated because nothing seems to be happening.
7. The division heads go to each guy that will actually do the work and reach consensus.
8. Only once the company is sure each person knows what they have to do and that they can do it, does it give the go ahead.
Source (IIRC?): Everything Is Negotiable by Gavin Kennedy
I remember being in a team that spent months writing a set of C++ classes that wrapped ODBC for a project we were doing at the time.
Shortly after that, the next version of MS C++ foundation classes appeared, with classes for ODBC!
I expressed my bitterness at the next DevCon to a Microsoftie. He said Microsoft cannot announce what it is developing because it would be a declaration of commitment and “you’re a programmer yourself, right? so you know how it is with deadlines and writing software.”
I found it hard to disagree.
It is the process everywhere I have been, especially when the release timeframe is greater than 3-4 months.
The analogy with Microsoft isn’t a fair one in my opinion. MS’s strategic product line (if you can call it that) is Windows and Office. The Development tools “business” is not self-sustaining commercially nor is it considered strategic (ie, everyone in the compant is dependent on its delivery for their objectives, hence they want to have a say in the content). Embarcadero’s entire product line is development/admin products, and, unlike MS, its totally strategic. So they have to continually adjust the mix of bugs, competitive reaction, hopeful opportunity, etc. of the product line and it has to be self-supporting.
I am disappointed that the SA agreement I purchased last month isn’t obviously going to cover the OS X implementation as I had planned. But the reaction of many to this unpleasant news appears to be so like teenage angst when a boy band fires one of its members.
I am surprised at the large number of developers using Delphi (this should be a marketing angle for Embarcadero) that never have slipped a deadline nor had a 1-3 year plan go astray, this is an amazing achievement and obviously given the concentration of this success in the Delphi community. as opposed to the industry at large, shows the power of Rad Studio!
[…] (Delphi Live). Vielleicht wurde dort etwas gesagt. Obwohl seine Aussage, wohl auch etwas auf diesen Blogeintrag Bezug nimmt Markus […]
Neal … not teenage angst. It was foreseeable that an alpha that started in the mid of February cannot end up in a finished beta in September – not for a cross plattform addon to an IDE. Now we come to the point in the first RoadMap it was not in – in the second version of the RoadMap most people refer to it is not in. This RoadMap shows projects not the yearly releases. We get what was planned a maintenance release on 32bit for last version on the old compiler. I think it was a tactical decision these day after lots or rumor to put the crossplattform thing on the way. They need success, that’s their problem. Desicon makers do are not interested in compiler features or IDE features when the productivity of the IT department is 50% or less…
The tool market since I am following it – I is currently running against the same will the Case Tools run into. An old prof of mine said – Michael, when the methodologists have no answer the move goes towards business process driven view. This is what we are experiencing now in enteprises. Hardware is cheaper so the IT stuff is no longer a matter of investment (Oracles Database Machine is an investment, an outsorced computer center is an investment) software licences are Indirect third party spend.
Now they put together what they have into a bundle RadStudio or AllAccess and provide something for almost every strategic decision for a way Software is built. The few who are still working Inhouse and consider the new markets. No one in invests a cent into existing licences when there is no bigger future sales and honestly Delphi’s native customer base is setteled. Selling licences is not a good business, selling SA is a good one. What you and EMB in the must make is to sell this bundle place this bundle and the more they have in the easier it is take out products evelove them into the right direction.
What they need too is convinved dependent followers, you cannot so simple compete the toad and it took a for example in another case until Sparxsystems Enterprise Architect spread even it was a lot more cheaper and better these days as Rational Rose.
So our role is to take and use and hava an SA. It will not work another way. I am confident that they make it …
On MS – MS has the Sales Force. There is a limit – there more you sell the more you get doest not work and the times of every 2nd year a new Windows or Office are over … every decade one and a half. The Desktop is very unattractive from this point. Shipping things that work out of the box is enormous expensive and maintaining them the more broad the user base is.