#agile #project management #programming
epoch: 1321519931
I don’t like name dropping consultants. Name dropping transports no knowledge at all, just obfuscates what is needed to find a decision. A little better is concept dropping, but only a little. What I expect of a consultant is, that she or he asks a lot of questions about my problem and afterwards shows two or three possible solutions for that particular problem, combined with an estimation of the costs.
#agile #programming #project management
epoch: 1321519870
In agile, I guess, it’s all about quality, not quantity. Quality of code, quality of user experience, quality of customer satisfaction. It’s about maintaining quality in a world of change. It’s not at all about being as fast as possible, but as good as possible - while everything around us is changing constantly. It’s about being smart, not being “schneller”.
Remark: “schneller” is German for “faster, now”.
#planning #project management #complexity #uncertainty
epoch: 1311170383
It is widely believed that a huge amount of software projects does never meet their planned objectives, either in time, cost, or scope. Numbers differ, but to think of about 65% to 70% of failure meets very well with my experience. Software industry exists for about 60 years now but until today, neither engineers nor managers seem to have good planning strategies.
The question I want to ask is not why software projects fail. The question is: what is failing at all, production or planning?
Planning is the attempt to implant certainty into the uncertain future. Planning software projects additionally tries to generate certainty out of complex dynamics. It is well known in project management: the farther you try to think into the future the larger the failure will grow. In my experience, it is almost impossible to forecast the state of a software project three months later. Larger projects may easily run for 6 months or more. And the same failure growth applies for complexity. The more complex both your problem and your organizational ecosystem becomes, the larger grows your uncertainty. To generate a planning model and to keep certainty alive, you have to apply a procedure of “reduction of complexity”. The price is a blind spot.
The more you treat your plan as prognosis, the more side effects you have to ignore. You add team members or whole teams, but do not change the plan, though project communication becomes more and more complex. Based on what the team experienced so far you have new ideas and change or add features but you don’t change the plan. You realize dependencies to other projects you never thought of, but still keep the plan untouched. The team finds some features much harder to implement than the project manager has guessed, but no way for him to change the plan. Sometimes you even change the production process (e.g. by demanding a more rigorous reporting or by adding working hours), but only to defend changes in the plan. All those distorting influences of the production process remain located under the plan’s blind spot.
In the end, the conditions of the production has been evolved sometimes dramatically while the plan has not. No wonder, if the production does not meet the plan.
Recently the agile movement was trying to implement new values and procedures to reach a better success rate. It helped, but it didn’t helped that much. Though they unveiled a lot of what have been hidden under the blind spot using post-it transparency, neither Xtreme, Scrum, Kanban or whatever could really circumvent the problem of organizational complexity. Your agile culture is almost always embedded into an alien business environment, adding boundary conditions you have no chance completely to survey or to influence. Whether it is the marketing or sales or simply your customer out there, they simply don’t care about your agile speech and Scrum Guru-Guru.
What is failing in all that is not the production process, because it is simply responding to every change and influence, whether you like it or not. What fails is the planning. The moment you nail down your plan - you’re lost. While production is in flow, your plan becomes a static contract.
What can we do in such a bad situation? What I can suggest is probably not what you want to hear, but it may sound practical:
The big mistake in planning is to muddle up planning, prognosis and estimation. An estimation is no prognosis, and a plan should be nothing that cannot evolve. The reality of production is in constant flow. In complex situations such as weather and software development, forecast is subject to fail. As a rule of thumb: Just try to always have an umbrella at hand.
Powered by Tumblr; designed by Adam Lloyd and Ingo Schramm.
