Over at Frederico Tomassetti's blog, he discusses how PMs and developers should communicate business priorities and consider technical priorities as part of the process of improving how these two professions interact, with the goal of improving a work product.
As a student of the Toyota Method, I've often looked to industrial process improvement for ideas on how to better manage teams, specifically around technology projects. But software development is not about 'manufacturing' an application. Modern management comes from the industrial revolution, and the idea of increasing production by adding labor, machines, etc. Software, to me, is still very much an artisan craft. Understanding user requirements to be functional is key -- the more detailed the requirements, the more time developers spend figuring out how to implement. Beyond this, some problems require the abstract thinking of a software engineer or architect, not just the assembly of blocks of code.
I have found that unrealistic schedules are the major cause of project failure. In the 1980s, Frederick Brooks noted in “The Mythical Manmonth” that adding staff to a project that was behind schedule only helped it to be further behind schedule. When estimating a technology project, two key components are difficult to assess: the complexity of requirements; and, the productivity levels (outputs) of the development team.
My solution is to track progress, and that means capturing data (metrics). But if information is not collected or collected so inconsistently, comparisons and trends are impossible. If no data is being collected, management has not required it. If collected inconsistently, KPIs have not been established and enforced, or standards are burdensome so they are circumvented. Productivity measurement and project management are powerful tools for planning, overseeing, and evaluating software development and maintenance projects -- the PM should guide the ship, so developers can pull the oars together.
Read more here...
No comments:
Post a Comment