Wednesday, April 21, 2004

Under Designing for Success

Strategy + Business Magazine offers us this article by Koehler and Weissbarth, The Art of Under Engineering. It underscores a message at the heart of the agile movement - the best way to be agile and the best way to deliver better shareholder value is to avoid developing features the consumer does not value.

The summary offers these key observations…

1. The need for end-to-end tracking of ideas. A point I also made very strongly in my book.
2. The need for transparent reporting. Again I point I made in Agile Management. I think the essence of this is that transparency allows “what the customer truly values” to be communicated cleanly.
   Where I disagree with the author is on “benchmarking”. Many authors of continuous improvement literature such as Deming do not believe in benchmarking against competitors, rather they believe that an internal focus on improvement is better. However, I see big American companies benchmarking all the time and set “cost goals” based on those benchmarks.
3. The need for a cross functional team which communicates closely and works together. This is definitely the approach taken by Lean manufacturers such as Toyota. In any knowledge work industry - any type of product design - there is a need for close cross functional cooperation and sharing of knowledge. Without it, it is impossible to gain a full system view of a design. Without a system view, individuals tend to locally optimize designs and the result is sub-optimal for the whole.
4. Management commitment is clearly necessary. When you try to change a culture the management needs to be instrumental in creating the new culture. Deming really understood this.

The 4 points above are derivative requirements from the main message that you should only design what the consumer truly values. The 4 observations represent what  is needed to create an environment for communicating true consumer value. So many companies build things which they “think” the customer needs because they didn’t validate their belief with objective market research and don’t have controls in place to insure that the internal communication is honest. Without these, every salesman will always tell you that their hottest prospect’s pet feature is a “must have” to close the sale.

[Thanks to Glen Alleman posting in the Agile Management Yahoo! Group for this topic]

Saturday, April 17, 2004

Management versus Leadership on ‘The Apprentice’

So America sat glued to its TV sets on Thursday night to see Bill, the entrepreneur, win and Kwame, the Harvard MBA, lose in the final episode of The Apprentice. As The Houston Chronicle reports, it is really hard for us in the audience to judge the result due to the shows editing. We clearly didn’t have all the facts. However, it was very obvious in the end why Kwame didn’t win. He lacked leadership. It was a theme over several shows. His cool, unflappable, trained manager, Ivy League MBA style might have been full of delegation and empowerment, but he wasn’t prepared to provide the leadership, direction and example when it mattered. When his team was flustered and confused filled with ambiguity, uncertainty and doubt, Kwame didn’t step in and show them how he wanted it done.

Management is an essential skill in business but it cannot go without leadership. The season of The Apprentice showed us why and how leadership matters. What does this teach us in the software business?

I discussed this once before - my belief that all good software development managers have to have come from a strong coding background, whilst some others believe that the problem with managers in software development is precisely because they did come from a development background and have no management training. I feel The Apprentice has reinforced my belief that leadership is essential and in software to be a leader, you need to carry the respect of the geeks who work under you. To do that you need respect as a technically accomplished individual who can step-in and show them how and why. Managers can be trained. I’m not sure that is true of leaders. I feel leaders are born. So perhaps the correct recipe for a good manager in software development, is to find the talented developer with born leadership skill and train them as managers - coached by a mentor, someone who has learned good management practice and can provide Kwame-like coolness, delegation and empowerment, whilst maintaining the ability to jump-in, analyze, design and architect with the best.

Friday, April 16, 2004

MSF - Worth a Look?

It’s a few years since I read any of the Microsoft Solutions Framework material. This latest stuff would sound familiar to readers of Jim Collins or someone trying to apply the principles from Peter Senge’s The Fifth Discipline to software development.

Founding Principles

• Foster open communications
• Work toward a shared vision
• Empower team members
• Establish clear accountability and shared responsibility
• Focus on delivering business value
• Stay agile, expect change
• Invest in quality
• Learn from all experiences

Meanwhile, this is what it has to say about agile development…

Agile methods, such as Lean Development, eXtreme Programming, and Adaptive Software Development, are software development approaches that embrace practices that are adaptive versus predictive, people/team centric, iterative, feature- and deliverable-driven, communication-intensive, and require direct business involvement. In comparing these attributes to the MSF foundational principles, MSF and agile methodologies are very much aligned in both principles and practice for software development in environments that require a high-degree of adaptability.

Wednesday, April 14, 2004

Why Individual Measurement is Bad

I had dinner with Johanna Rothman, here in Seattle, on Monday evening. We got to talking about the problem of individually measuring developers. She sees this often with her clients. It typically comes just after the organization is beginning to stabilize. It is possible to measure velocity, to estimate capacity and to stem off the input to a rate which can be processed by the current team. Now that it is possible to measure, the boss turns his thoughts to how it might be possible to increase the productivity.

All managers know that software development productivity is closely related to the ability of the individual. We’ve all known this since the early 70’s. And we also know that the productivity differences can be huge. Sackman reported this in the late 60’s. So managers start to think about how to identify the weaker links and hopefully eliminate them.

THIS IS SO WRONG!

You simply cannot measure developers individually. Why not?

Software development is a knowledge work business. Knowledge is about information. The more knowledge and information available about the problem domain then the better off we all are. When you start to measure developers individually, you incentivize those developers to hoard information for themselves. Why share when you will get rewarded for keeping it to yourself? Why share when doing so allows your colleagues to go faster? Whether it is information about use of a language, or skill in UML, or knowledge of unit testing techniques, or domain subject matter knowledge, or just plain use of the IDE, it is all useful knowledge that can help a team go faster. Knowledge sharing is a key to success. To elevate the system of software engineering, you need to encourage more, not less knowledge sharing.

Individual measurement is anti-team working. Groups of individuals typically perform poorly compared to a good integrated team.

Individual measurement is also demotivational. We live in a world where geeks grow up to be conspiracy theorists. For their protection, their government spies on them in many forms, commercial companies spy on them particularly on the web. Their privacy is invaded day and daily. The unlucky ones may even have a spouse or children or parents who spy on them. The last thing they need at work is a boss who also spies on them and punishes them for under achievement - however that is defined. Knowledge worker productivity is directly related to motivation. If the developer is a little coding machine, then that machine works harder when pumped with the right motivation.

Individual measurement is demotivational. Poorly motivated developers under perform. Good leaders motivate! Bad ones don’t! Managers who measure individuals aren’t good leaders.

UML Fever

Martin Geddes brought this story on Slashdot to my attention. It seems that the market is beginning to wake up to the issues with the UML. Perhaps it is because it is too big or perhaps it is because it lends itself to the pursuit of intellectual efficiency (big batch sizes of artifact generation) but I really hope that managers everywhere are going to get the message - UML is a tool and engineers must learn to use that tool effectively. If you use a tool to do UML, such as Together Control Center, then you have to learn the tool, but you aren’t learning how to use UML. Hence, giving engineers training in the tool is not enough, they need training and preferably expert mentoring in use of UML for analysis and design. As Alex Bell writes…

Shape shifter fever. Victims of shape shifter fever demonstrate raging affliction by sending people to brief design tool and language syntax classes with the expectation that they return as experts in best practice. Afflictees mistake the ability to navigate “File New Class Diagram” dropdowns as the signature quality of a software designer. The symptoms of shape shifter fever are particularly exacerbated when classes on tool and language usage are taught out of context from how they will actually be used on a program. As some believe “clothes make the man,” afflictees of this fever believe “UML makes the designer.”

It takes experience to know how much of the UML is needed to generate just enough knowledge before code can be written. It takes experience to know which parts of the UML to use and when.

An agile approach to UML is the identification of the minimal set of diagrams in the minimal set of circumstances required to reduce uncertainty and generate knowledge such that coding can start and reviews can be performed against the design after coding is complete

It is just this focus of approach which Peter Coad and the rest of us took when we created Feature Driven Development. In fact an entire decade of Peter’s career (in the 1990s) was dedicated to devising approaches to modeling, analysis and design which facilitated agility - the ability to cope with change - and lean development - the elimination of waste through the reduction of artifact creation.

In the first article, Death by UML Fever, Alex Bell of Boeing argues that much use of UML is waste - it’s plain artifact generation. It’s not Lean and it’s not agile! Much of what Bell writes is of course accurate and yet it is so easily overcome. You simply must put in place a management method which tracks the flow of value through the system of software engineering. My technique of using Cumulative Flow Diagrams to track client-valued features through the system, would illuminate the problems described by showing that lead times through analysis were too long, and that WIP inventory in analysis was too large. In other words, end-to-end traceability is the antidote to UML Fever. When determining whether a UML artifact is waste (“muda” in Lean terminology) ask

• Who, further down the value-chain consumes this artifact?
• What uncertainty did this artifact eliminate?
• Did this artifact enable us to write code, or get significantly closer to writing code?

If you can’t answer all three questions positively, then don’t produce the artifact. Eliminate this piece of UML from your process.

I’ll give the final word today to Grady Booch who in reply to Alex Bell writes…

Many ... organizations, however, have not enjoyed the successes they assumed to be implicit by merely using the UML. Success with the UML requires thought and planning accompanied by an understanding of its purpose, limitations, and strengths-much like the usage of any technology. It is only through such awareness that an organization is most capable of applying the UML to address its unique needs, in its own context, and in a value-added manner. Blind adoption and usage of technology for technology’s sake is a recipe for disaster for any technology.

...

<!—StartFragment—>The entertaining tenor of “Death by UML Fever” should not be inferred to suggest that UML fever is an imaginary ailment. It is genuinely real, it is thriving, and its presence is causing cost and schedule trauma on many software programs right now. Furthermore, the root causes of this fever, in general, have nothing to do with the UML itself: Rather, this fever and its various manifestations are largely symptoms of deeper ills in an organization’s software development practices. Software organizations should consider launching self-diagnosis campaigns to assess the presence or extent of UML fever on their programs and plan rehabilitation strategies as necessary. Developing good software is a difficult enough task without having to endure the preventable and often painful complications of the dreaded UML fever.