Software Management Manifesto Discussion

SteeringSoftwareProjects presented such an important idea that a separate page to fine tune it as a manifesto, SoftwareManagementManifesto, was created. All discussion of the manifesto should be carried out below. Every word matters on this one, so feel free ...

SoftwareManagers? hereby have the following rights provided to them by their CompetentDevelopers?.

Article 1: You have the right to an overall plan. The team should tell you what they could accomplish in the next year or two years, and tell you how much that would cost.

Hey Prokofiev, dude, can you write me a moving ballet based upon Romeo and Juliet? You can, that is great. Would you mind giving me a detailed, accurate project plan for the work, and telling me exactly how much it will cost me?

Oh, can you include in your schedules the actual performance of the ballet? I know Sergei, believe me I know, and I agree that 'maybe' producing and directing a ballet isn't a core skill of yours, but you're so tightly tied into the project anyway we thought that you would be the most appropriate person to carry it thought to completion.

Thanks, catch you later, dude.

Or,

Hey, guys. I'd quite like it if you could come up with a unified field theory of physics. How long will it take, and how much will it cost me? Oh, btw, I'm going to put someone with no aptitude for management in charge of the project, and I as a customer don't really understand anything about what you're doing except the anti-gravity-device I'll have the people next-door build and sell when you're finished.

Or,

Hey NASA, put a man on mars, start now, have it finished by next September, and we're going to give you $300,000 to do it with.

Or,

We need a new management system for our new packet switching national mobile phone network. How long will it take and how much will it cost?

--Thanks for paying attention. This wake-up call was provided courtesy of BryanDollery, your voice of reason for today. Enjoy the rest of your browsing.

Land a man on the Moon and return him safely to Earth before the end of the decade. JFK

You betcha. Let's compare, shall we? NASA had dozens of thousands of people (including outsiders) spending dozens of billions of dollars over several years to build a Big Rocket. (Oh, yeah - the whole thing cost a few lives, too.) The cell phone company has dozens of personel able to spend a few million dollars in a year or two to develop a product with national application. Uh, huh. Let's try not to oversimplify.

I worked a year on a project involving new technology provided by third parties. Before a couple of months into the project, I did not know how much capital equipment or manpower would be needed or how much they would cost. Not sure how management could have exercised their right # 1 under this circumstance.

Is it really possible to predict 12 - 24 months in advance? What type(s) of 'accomplishments' can be confidently predicted 12 - 24 months in advance?

How would anyone meet this "right?" Unless you have some better means of predicting the future, don't imply that is is something we can do.

(in 1991 the science magazine Nature had an article on nanotechnology and its implications for nanoengineering. The authors of that article ended by saying that we, meaning the hard science disciplines, tend to overestimate what we can do in two years and underestimate what we can accomplish in twenty years.)

What about WorstThingsFirst? Can the developers overrule the now/later choices? No, any such change must be explained and agreed to by the customer. But does this need to be added to the manifesto?

(The really important risks should be discovered in the exploration phase. If the worst thing is some third party software, explore how it works before you estimate how hard it is to use. If the worst thing is a feature you have to implement, explore how it might work with a SpikeSolution.)

The team should tell you what they could accomplish in the next year or two years, and tell you how much that would cost.

Ah, yes. The "I want you to project into an uncertain future that you have little control over, so that it can be your fault when it happens differently" approach to project management. A very tempting approach, since it has the wonderful effect of focusing responsibility and blame away from management.

It is a rare environment, in terms of marketplace, technology, and resource availability, that is stable enough to support predictions that go further than 6 months into the future. And that's probably pushing it. The best a team can expect to do, in the environments I'm familiar with, is to project ahead a few (short) iterations, after they've done two iterations. Anything more than that is folly. -- DaveSmith

Let's put the shoe on the other foot. What if management came to the developers and said, "We can't predict what the company will be doing 6 months from now. Why not just work a few months and see if we are still willing to employ you? Don't keep asking about a career path or benefits or vacation or sick leave, how can we predict what we will be able to do then?" The responsibility of management is prediction and plans for the future. To even start a project, a prediction of cost and value is needed and few high value projects can be completed in a few months. No, prediction is not accurate and we try to quantify the inaccuracy as risk, but to gain management commitment to a project, we must predict the feasibility and reasonableness of a project. No, long term prediction is not folly, it is a necessity, and having long-term plans is a right developers should demand of management. -- WayneMack

At the outset of a project, developers may have little idea of timescales and costs, but generally they have a better idea than management; this is particularly the case if management have little or no experience of software development. The team might not be able to give precise plans, but surely they are responsible for passing on their considered opinion of what is possible, along with some idea of their level of confidence, and for updating management as the project gradually becomes more concrete. Perhaps the manifesto would read better if the word "attempt" was inserted. Poor information is better than no information, as long as it is made clear that estimates are nothing more than informed guesses. Or is this nieve?

Article 2: You have the right to see progress. From the very beginnings of the project, the team should be producing functionality that you care about. The functionality should be in the form of a running system, proven to work by passing repeatable tests that you specify.

See AutomatedTestsProveProgress. Questioning the use of 'automated' here was in line with my view that the manifesto shouldn't describe XP - it should set out a new business context within which many (including myself) expect XP to thrive. So is the view if the tests aren't automated tests don't get run and the project goes to hell really a part of the manifesto or one of the key differentiators of XP versus other evolutionary methods? -- RichardDrake

Perhaps "repeatable" instead of "automated"? done

Perhaps a more reasonable statement wouldn't say that functionality should be available from the very beginning of a project. How about at the end of say the second iteration. This gives us time to, say, gather the requirements in some way, or maybe even hire some staff, or at a push we could even put together a development environment and build at least the foundations of an infrastructure (you know, some conventions, some package structures, some high-level base architecture). Hey, we could even buy a computer or two. -- BryanDollery

Passing tests provides no benefit to a user. What the user wants is an automated business process. Don't try to cloak "responsibilities" with the term "rights." Suggested wording, "You have the right to a system that correctly supports your needs at least partially as soon as possible."

The project manager's job is "client control." The goal in this part of the project is to keep the client in his/her "comfort zone." If the client feels important to the project, and that his/her concerns are being met, the client will be happy and will support the project, even during troubled times. It is really all about effective communications. The client must feel that progress is taking place. CM

During one project, management had no idea which functionality might be important to them until several months in. During this time, management attempted to find customers and promise them that we could deliver whatever they wanted, meanwhile we were hiring the team and ramping up on the technology - not getting our first development box until many months into the project. We were attempting to use the new and rapidly changing technology in a manner nobody else had used it, were told by everyone else in the industry that we were far ahead of what anyone else was doing and they were surprised that the technology could be made to do it. Not sure in this environment how management could have exercised right # 2.

Article 3: You have the right to change your mind. As software development proceeds, you should be able to substitute new functionality for old. You should be able to change the relative priorities of the features of the system, dictating what should be done first and what should be done later.

Don't like "features" - good chance to use "functions and qualities" instead? Don't like "functionality" twice in the previous section and once here either, because QualitiesMatterMore? to customers. Prefer "functions" to "functionality", "method" to "methodology", "tough choices" to "architecture". Guess it's my problem though.

I thought that, given a choice, most customers would forgo quality and accept earlier delivery and lower costs. This is why everyone buys Ford rather than Jaguar. Notice, there's no mention of a right to make such a choice. Quality is just what the customers demand, so they have the right to modify their demand. Internal quality (maintainability) is what the developers should provide, whatever the customers demand is about it. If we stop providing maintainability, the other customers rights cannot be respected.

Clients should only have this right if they understand how to use it, and specify at the start of the project the level of exercise they will give it.

How about a more user focused statement, ignoring terms like features and statements about changing your mind. Something like, "You have the right to a system the rapidly adapts to your needs and business practices as they exist and evolve."

Management sure exercised this right a lot on a project. However, they did not let development adjust the schedule accordingly; the same delivery dates based on the original idea were still required for the adjusted ideas they thought of partway in. - ChrisBaugh

Oh, sure you do, but if and only if those tasked with accomplishing the project are then granted the right to say this is a 'start over from scratch' change in terms of schedule, plus, the additional functionality is going to pile X% more time and resource needs on top of that and you are willing, in advance, to accept that response. Any other course leads to madness and project failure, and probable loss of staff. -- KentPaulDolan

Article 4: You have the right to be informed of schedule changes. Since some things will turn out to be easier than expected and some things harder, the schedule is going to change. You have the right to be informed of such changes as soon as the programmers know about them. You have the right to exercise your business judgment by choosing among options for reducing scope so as to restore the original date. You have the right to cancel further development at any time and be left with a useful, working system that reflects your investment up to that date.

Whoa! A software manager has "the right to be informed of schedule changes?" The software manager has the full responsibility for the schedule. The software manager has the right to be informed of difficulties, but it is his responsibility to decide how to react; add personnel, reduce functionality, slip schedule, or some combination.

Is the last sentence, You have the right to cancel further development at any time and be left with a useful, working system that reflects your investment up to that date the ultimate key to real change of our industry?

I do not believe the last statement is universally feasible. I have seen too many projects which do have a large core of true requirements. Unless and until these requirements are met the system is of no value to the user. (You can still use small cycle iterative development, but the interim versions are only of interest to the development team, not the end users). -- WayneMack

It was my sentence and it took a year for someone to make the counter-assertion I expected, so thanks. The simplest response is I guess "where there's a will there's a way". I increasingly believe that it is possible to find small steps delivering business value at all times, if the business context allows you to think laterally enough. -- RichardDrake

Absolutely spot on Richard. In fact I firmly believe it's an imperative duty. Scope of the project, resources and schedule are intimately linked and should be under the high level control of the client/customer as they are paying. A customer agrees a scope, at a cost, to be delivered to an agreed schedule. Many types of changes will invariably occur within the best plan and it's up to the customer to agree to changes in scope and/or cost and/or schedule. One key to successfully managing this approach is to ensure the technical team plans are in small technically manageable steps, each (small) step providing a useful building block directly related to a customer requirement. In addition, the technical team need to thoroughly appreciate how important their (cleverly conceived) short-term plans can be to the overall success of the work.

IMHO this approach is one way of managing large projects with many requirements as it provides for immediate, positive action against the long list of required accomplishments. As an added benefit, customer agreement on changes implies projects will remain on schedule, as the schedule revisions are assembled in agreement with the customer. The 'initiative-sapping', all too familiar cry of blame the technical team can be controlled. -- DaveSteffe

Most of my experience comes from two different areas: business process automation and embedded system design. In both cases, the end product needs to supplant an existing process or product. In a business environment, there is little value in a replacement which does less than the original. Similarly, to get even a single customer (including in-house) to use a new product, it needs to satisfy his needs at least as well as what he is currently using. If the customer is used to Mocha Cappuccinos, you won't get away with offering plain espresso. -- WayneMack

The big project I'm referring to was *absolutely useless in every way* unless *every* part of it worked. We were intending to capture client data, discard irrelevant data, put relevant data into a database, calculate some statistics such as moving averages and running totals in database stored procedures, forward both raw and calculated data as XML, combine the XML data with MozillaXul templates, and deliver the realtime updates plus a cached subset of the statistical summaries to a variety of standard and nonstandard browsers. No subset would have been of the slightest use to any of our customers who, management hoped, would pay for our service of disseminating realtime data to their end users. The project was cancelled before the complete service was available, after almost a year of development and with about 3 months of work left to do, and without any customers having been obtained. The service concept being developed by the Portland office contradicted the do-it-yourself products (already several generations along) being sold (to existing customers paying money) by the San Diego and D.C. offices. As technical lead I developed most of the approach and since the company seems to have lost interest, I intend to finish developing the system on my own for either commercial release or open source distribution.

I think that this is okay, except for the last sentence. "Receive business benefit that reflects investement upto the last release," would be a bit better. How can you provide business benefit if the project is cut half-way through an iteration? -- BryanDollery

How about something concerning controlling costs without going to the extreme of canceling a project. Something like, "You have the right to increase or decrease spending, through changes in staffing levels, as business factors dictate."

Real world example. My team received authorization to move an existing VB/C++/Oracle 3-tier client/server application to a web-based architecture. Due to issues beyond the performance or control of the team, this authorization was canceled within 6 weeks. At that point, we had a log on screen and 2 1/2 (of 15) data entry screens converted. There was negligible business value to the software at that time.

Re: Punchline

I believe that clear separation between the manifesto and XP is to the benefit both of XP and all purchasers of software development. A free market in methods for the programming team to deliver on the manifesto - whatever the marketing people choose to call them - is exactly what's needed. In this new context XP and its derivatives have a great market opportunity. -- RichardDrake

Having said that "may allow" was just too weak - does "is designed to allow" strike the right balance between confidence, bulls**t and humility? (HumilitySells? as long as you get it right)

Look back to the start of SteeringSoftwareProjects:

Here is an attempt to create demand for processes like EvolutionaryDelivery and ExtremeProgramming, on the assumption that once the demand is there, the names won't matter so much.

The great illusion of management is that it exists...

See: SoftwareManagementManifesto

Contributors: RichardDrake, BryanDollery, ChrisBaugh, DaveSmith, WayneMack, DaveSteffe, MartySchrader

CategoryCustomer