This Guest paper series was originally published by the Cutter Consortium Agile Product & Project Management Advisory Service in 2009. It is reproduced here, September 2014, with permission from the publishers (www.cutter.com).

Cutter's Agile Practice helps you solidify your agile project management and software development techniques, agile engineering practices, and software governance with access to a vast repository of reports, exclusive peer-to-peer events, consulting, training, and coaching — all delivered by Cutter's team of Agile experts. Sample Cutter's Agile research at www.cutter.com/ content-and-analysis/ sample-our-research.html.

Part 3 published here November 2014.

PART 2 | Introduction | Tackling the Problems
Beginner's Mindset | More on Klein's Work | PART 4

Introduction

Do the factors outlined in Part 2 of this series of papers mean that developing higher-order thinking skills within the context of a project-based environment is an unachievable goal? Clearly not, since many people have navigated the minefield on their own, and some organizations have achieved more wide-ranging success. The pressing question is how do we broaden those successes so that they become attainable to a larger audience?

The answer to that question lies in a number of elements and perhaps the easiest way to explore the question is to contrast examples of efforts that have worked with some that have failed. The starting point for such discussion comes from looking at the way organizations provide formal training. Although much of the traditional training targets the lower levels of Bloom's Taxonomy, carefully structured programs can be developed that directly focus on the higher-order thinking skills.

I observed one good example in an organization I worked with many years ago. The department in question had a team of approximately 30 developers who were responsible for the bespoke development of software to support a large multinational commercial business. The developers had a range of backgrounds (some had computer science degrees and others had moved into the field after working in other roles throughout the organization). Experience levels ranged from as little as three months up to 15 years and included a large contingent of newly hired junior developers.

Over the years the organization had provided the developers with initial training that taught them the syntax of the programming language they were using. But beyond that there was no additional training in how to structure code effectively, how to make code less bug prone, strategies for simplifying the programs, how to write code that was maintainable, or strategies for promoting code reuse. Interestingly, even those who held formal computer science degrees had never been trained in such considerations either.

In essence, the developers had been through Levels 1-3 of Bloom's Taxonomy but had never had any formal guidance in the higher levels. As a result (and as is typical in many other roles in the IT sector), each individual had developed their own thinking on issues such as what the difference between good and bad practices were. The results were as you might predict: productivity and quality variances between individuals were high; teams were having difficulty sticking to project schedules due to the wide-ranging variances; and because of continual quality problems. Wastage from rework was high.

PART 2  PART 2

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page