Product vision and product team

Colm Lyons, Founder and Managing Director of Realex Payments, describes aspects of high-tech development and entrepreneurship, reflecting on his experience starting and growing Realex.

What came first, the business case or the prototype?

You are invited to an industry led discussion panel on software product development addressing the iBusiness class this evening (Wed 23rd Nov, 2011) from 6.30pm to 7.30pm in room D209 at the Michael Smurfit Graduate Business School, Blackrock. There will be about 70 people attending.
I'll provide a short personal introduction to each of our guests and ask them to make a brief reflection on managing high-tech products and development after which we'll have an open discussion taking questions from the floor.

What came first, the business case or the prototype?

• How do I go about getting a project off the ground in a company?
• What do I need to do to convince management to support my project?
• Is the elevator pitch important?
• What if the project is very risky?
• How important are the financials, really?
• Should my approach change in a small company versus a large company?
• Who do I need to convince?
• What came first, the business case or the prototype?

"We think about ubiquity first, revenue later."

"Figure out quickly if there is usage and adoption... You will then understand how your customers interact with your potential product and then you build a revenue model on it. The traditional view of starting with your revenue model and your business model looking for customers is somewhat less relevant in the digital world. It's 'get customers first'!"

John Herlihy, vice-president Global Ad Operations, Google

Further reading
(Banking & Finance Magazine link)

Directions:

View Larger Map
The room is located at point A. Parking in areas B and C as indicated.
Just don't park directly in front of the building as it is paid parking.

Provoking creativity

PROVOKING CREATIVITY
Creative companies and teams can be “remarkably inefficient and often terribly annoying places to work, where ‘managing by getting out of the way’ is often the best approach of all.” (Sutton, 2001) Management is generally characterized as the activity of organizing, leading, controlling an organization to achieve stated goals such as producing profit or value (often a social good) efficiently while constrained by limited resources. General management is about managing routine work using well proven rules, procedures, policies etc. Managing for creativity however is counterintuitive to general management practice. Sutton presents what he terms a set of weird ideas illustrate how to hire, and manage creative work (below).

Creativity Management (anti-)Principles, from (Sutton, 2001)

• Place bets on ideas without heeding projected ROI.
• Radical innovation implies ignoring what worked before.
• Take happy people and goad them into disagreement.
• Reward action, success AND failure.
• Have people who don’t fit in.
• Disagreements are necessary.
• Use new employees to bring in NEW ideas.
• Generate and use NEW ideas.

Sutton contrasts these weird ideas against the conventional ideas implicit in general management practice. The ideas are counterintuitive because for most organizations only a tiny fraction of effort is spent developing new products and services. They provoke discomfort because “rare and unfamiliar things provide negative evaluations.” (Sutton, 2001) The practices Sutton highlights will seem ‘wrong’ simply because they are different to current accepted norms of best practice. We are all subject to the psychology of ‘difference’ and so these ideas for promoting creativity will seem wrong-headed and counterintuitive.
Decide to do something that will probably…

“there is one simple, proven, and powerful thing you can do to increase the likelihood that a risky project will succeed: Commit to it wholeheartedly.” (Sutton, 2001)

The ‘self-fulfilling prophecy’ argument relies on somebody taking ownership. The idea is closely related to the concept of the entrepreneur. Someone in the organization makes up his or her mind that this idea is good and runs with it (for example, the case of Tom West at Data General (Kidder, 1981)).

“Henry Ford put it more succinctly: ‘If you think you can, or if you think you can’t, you are right.” (Sutton, 2001)

The consequence of this kind of thinking is

“if you can’t decide which new projects or ideas to bet on based on their objective merits, pick those that will be developed by the most committed and persuasive heretics.” (Sutton, 2001)

Seek out…
Ways to avoid setting out how the project ends, how much it will cost, how much it will return. Adopt the idea that the person behind the project is a visionary heretic. The notion is that really creative and innovative work often ignores the narrow incremental requirements of customers and others with their own quite short-range views of what can and should be done.
Think of some…

“Every bit of solid theory and evidence demonstrates that it is impossible to generate a few good ideas without also generating a lot of bad ideas.” (Sutton, 2001) p101

Therefore…

“Creativity is a function of the quantity of work produced…. [therefore] measuring whether people are doing something – or nothing – is one of the ways to assess the performance of people who do creative work.” (Sutton, 2001) p102

Reward… If creativity is a function of quantity of work produced then we should reward for both success and failure. Managers, experts (even customers initially) do a poor job of judging what will succeed and what won’t. There is little evidence that using stage-gates and other gating reviews improve the probability of eventual success (Sutton, 2001) p102.
Find some happy people… Find happy people and get them to disagree. Disagreements are about ideas and disagreement can generate a productive dynamic. Bob Taylor’s DARPA research conferences were an example of this kind of engaged critique.

“’I got them to argue with each other,’ Taylor recalled with unashamed glee… ‘These were people who cared about their work. … If there were technical weak spots, they would almost always surface under these conditions. It was very, very healthy.’” (Sutton, 2001) p101.

Hire… Hire someone you don’t need, indeed hire someone who has never solved the kind of problems you are faced with (Sutton, 2001) p98. Furthermore, hire slow learners who resist picking up the ‘company way’ or who won’t do it ‘the right way,’ they ensure that things can be seen ‘different.’ They may be high-self esteem people who can stay convinced of the worth of their own ‘different’ ideas, or they may simply be insensitive to other’s perceptions of their positions, ‘low self-monitors.’ Being insensitive or resistant to conforming pressures is a valuable trait if an individual has to go against the flow to bring an idea to fruition.

“Confident people continue to believe in their ideas despite rejection and criticism.” (Sutton, 2001) p98

Sutton refers to the example of Gary Starkweather at the famed Xerox PARC research laboratory. In 1968 he felt compelled to follow his conviction that laser imaging was superior to incandescent light. Starkweather complained about ‘laboratory dogma’ that resisted his line of research and experimentation. He was transferred to PARC and as a result he (and Xerox) ultimately launched the first commercial laser printer. Some people get around the selection problem by pretending to fit in with the ‘company way’ but it takes courage to stand out. Varied backgrounds offer unexpected resources for problem solving and idea generation.

Take your past experiences… Forget them, or at least don’t expect them to provide the answer to today’s problem.

Use job interviews… Naïveté is useful, people from other areas, disciplines, and experience see problems in new ways, and they bring a fresh perspective. In the case of Lotus in the early days the management team applied a decidedly fresh and unstructured approach to selecting and hiring people. Lotus Corporation’s CEO, Mitch Kapor (programmer, capitalist, meditation teacher and counselor) had grown the company with spreadsheet package Lotus 1-2-3 and riding on the success of the IBM PC (Rosenberg, 2007). Once bigger than Microsoft, by 1984 Mitch eventually brought in a professional management team to solve the incredible problems of managing large-scale product development and thousands of employees. But the culture and environment changed in the process. In 1985 Kapor and Freda Klein…

“…tried an experiment. With Kapor’s approval, Klein pulled together the résumés of the first 40 people to join the company. She disguised the names and put them into the applicant pool… Not one of the applicants was called for an interview.”
(Sutton, 2001)

Ignore people who have…

“In the creative process ignorance is bliss,” (Sutton, 2001) p99

In the Pulitzer prize winning account of Data General’s Eagle mini-computer project (Kidder, 1981) Tracey Kidder recorded Carl Alsing ’s rationale for pairing the experienced Dave Peck with the talented novice Neal Firth. Consider the situation faced by Alsing when he decided that a software simulator was needed

“Alsing realized that a program to simulate Eagle would be huge. It might take a seasoned programmer a year and a half to write such a thing, he figured. But Alsing kept these calculations to himself… Alsing considered the situation. He had two confident programmers – one relatively inexperienced, the other reluctant.” (Kidder, 1981)

The engineer Firth particularly, didn’t know it couldn’t be done.

Encourage people…

“to avoid getting stuck in a rut… be especially wary of opinions from customers who use their current products or services, and from the marketing and sales people who represent their views.”
(Sutton, 2001)

Alan Cooper (2003) warns against the foibles of being ‘Customer Driven.’ Users should not be the source of design decisions, although they are often its victims. The user may know what is wrong but will rarely know the best way to resolve the problem.

Brooks suggests that systems architecture must have conceptual integrity; that a system should present an interdependent and integrated set of design ideas.

“[T]he setting of external specifications is not more creative work than the designing of implementations. It is just different creative work.” (Brooks Jr., 1995).

Creativity Ethos… A caution; using tried and true methods is a wise approach to manage a company.

“But if part of your mission is to explore new possibilities, then your goal must be to build a culture that supports constant mindfulness and experimentation. [my emphasis]. … It should be an arena, a constant and constructive context, where the best ideas win.” (Sutton, 2001) p103

Sutton’s analysis is insightful and his presentation employs his counter-idea itself, the concept of opposite, counterintuitive choices, as a necessary aspect of creativity. The presentation of creative management is itself an exercise in counterintuitive decision making. Clearly there is a distinction between the activities of producing the same product and service, and producing something new and innovative.

The coexistence of the two objectives within the same business units must inevitably be problematic, particularly if each is successful, because their cultures and behaviour are so radically different. Sutton’s ideas could be construed as mandating a kind of ‘anti-organization,’ nearly all the tenets destabilize the strands and behaviours generally construed to contribute to stability and operational interaction.

MDD Class 2011: Guindon design challenge

an xkcd for today "The General Problem"

Permanent link to this comic: http://xkcd.com/974/

Three software development team archetypes

While it is obvious to say that social engagement is an underlying dynamic in teams, the `obvious' is often ignored or even thought of in terms of a problem that must be overcome. Consider instead if we start from the assumption that team structure arises as a consequence of social relations rather than the other way around. Under these assumptions then, the activity of management (not necessarily the job title) can be seen as the act of fostering the social relations of a team rather than manipulating them.

Sawyer's analysis offers some paradigmatic filters to view and manage systems development, as a diagnostic lens and a tool to intervene.

"The sequential team archetype of software development team social structure draws on the work design tradition in industrial engineering. Work is seen as a set of discrete tasks that can be measured." 

"The group archetype draws its intellectual roots from theories of social psychology, such as 'work redesign'. Work redesign arose in response to such issues as personnel motivation, retention, and productivity that typically occur in a work design approach." 

"The network group archetype draws on concepts of social network theory. In this archetype a group of people is linked by the relative 'strength' of the social ties among them. Work is seen as the use of these links to deliver and receive information; these uses both span and define tasks."

Certainly Sawyer's archetypes are just that, archetypes or caricatures. All teams are hybrids but we easily recognise elements of the archetypes at different times and in our own behaviour. Perhaps a key insight is that our individual personalities and temperaments incline us towards one mode or another, perhaps at different times and regardless of the organisational structures in place. And each archetype invokes a specific remedy (communication can overcome the limitations of silos, groups often need direction and control, networks need opportunities to interact and bottle-necks can be a problem).


Reference
Sawyer, S. (2004) Software development teams. Communications of the ACM, 47, 95 - 99.

No Silver Bullet

Programmers have a

"fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning." (Brooks, 1975)

But programming in its essence is a kind of linguistic exercise, translating between what someone wants and what another understands, and translating again between the requirement and the machine. The problem is that translation is circular and often open-ended while the medium is controlled and ultimately restrictive. As Brooks notes in his book "The Mythical Man-Month" the essence of programming is "fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles", but the essence of the tasks we want the machine to perform are linguistic, human, and open-ended. To restate the problem somewhat, a computer's interpretation is deterministic, the behaviour of a finite state machine (albeit highly complicated), but the user's interpretation is constantly revisable subject, linked as it is between the objects we encounter, the situation, our goals and to our human capacity to learn and to judge.

References
Brooks Jr., F. P. (1975) The Mythical Man-Month : Essays on Software Engineering, Reading, Mass., Addison-Wesley Pub. Co.
Brooks Jr., F. P. (1987) No Silver Bullet Essence and Accidents of Software Engineering. Computer, 20, 10-19.

Usability Evaluation Considered Harmful

"It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them."

Steve Jobs, quoted in BusinessWeek (25 May 1998) cross ref. (link)

Can usability studies be more harmful than productive to the design process? (Greenberg & Buxton, 2008) Is usability evaluation - laboratory-based user observations, controlled studies, and /or inspection - the last word in evaluation? What does usability overlook and why?

I keep thinking back to the first problem based learning case we studied - The Avalanche case (link) - and wondered where 'in the wild' field studies fit within the industrial development process.

Prototype tracker

It seems that a key ingredient of a successful design is having a strong top down vision. But in the absence of vision who has the big idea of what the product is? Who decides what belongs and what doesn’t? And who gets the 'learning' out of usability studies?

References:
BusinessWeek (25 May 1998)
Greenberg, S. & Buxton, B. (2008) Usability Evaluation Considered Harmful (Some of the Time) (link)
Henry Lieberman (2003) Tyranny of Evaluation (link)

Liquidator appointed to Zapa (NFC tech questions)

Image source: Maxwells. Irish Times, Oct 22, 2011

(see the Irish Times, Oct 22, 2011 - www.irishtimes.com) 
News of a provisional liquidator being appointed to Zapa Technology suggests the difficulty of establishing the dedicated physical infrastructure needed to deploy near field technology within an existing operating environment. Various explanations have been offered, no dominant standard for NFC, user reluctance to change behaviour, small operating margins, limited value proposition for the various actors involved. While the advance of NFC technology into consumer payment and loyalty systems seems compelling, it is by no means inevitable.

Reference
The Irish Times, Oct 22, 2011 (link)

Mutual Adaptation

MUTUAL ADAPTATION AS A METAPHOR FOR DEVELOPMENT/MAINTENANCE
The following commentary can be understood in terms of the product explanation videos at swrve.com, as examples of how 'use' can be learnt by the organisation and turned into actionable change in the organisation's product or service.


Technologies that aide the process of understanding customer/user behaviour across all possible dimensions of interaction with a high tech system are one way of enabling organisations learn how their products and services are used. When 'use' is available to observe and analyse then the product can be tuned and adapted to suit. The idea of 'mutual adaption' can become a core process in development. The consequence then is that development can no longer be viewed as a project with an origin and an end point (perhaps it never was). Rather, development becomes an on-going process of constructing, deconstructing, maintaining and responding to use.

New product development projects are often presented as radical innovations driving change and transformation in industries and markets. But If we take a closer look at actual projects we see that there are few 'one-shot' projects that come 'out of the blue' and become dominant by virtue of being better or best at something. Indeed we know that few (if any) innovative products are specified, designed, implemented and introduced in one smooth process of development. The practical reality is that novel high tech systems are more often developed by being ‘tried out’ through prototyping and tinkering.

Eric Von Hippel (2005) traced the history of selected technology innovations and arrived at a pragmatic realization that products continue to be developed even when they leave the confines of a laboratory or engineering shop. He develops the concepts of ‘lead user’ and ‘innovation communities’ and concludes that innovation is a process of co-production shared between the producer and the consumer of a new product. Innovation might therefore be thought of as maintenance; a collective and intrinsically social phenomenon resulting from the fluidity of systems undergoing cycles of design, delivery, learning through use that feeds back into further design, delivery and learning.

The innovator's dilemma (Christensen, 1997) is the consequence of a situation where organisations (and therefore management) attach perhaps simplistic overarching emphases on financial optimisation of product offerings. We might argue that businesses resort to such measures as strategy from an era when customer data and feedback was difficult or impossible to gather. This produces the dilemma identified by Christensen, goal displacement, by focusing on cost or short term profit rather than value to customers. Learning and understanding what makes a product successful in the first instance and needs to be done to continue to succeed is the crucial point. What matters is how an organisation responds to both its further development and what they 'learn' from their customer's use of the product once a product starts to get used.

Note: This kind of analysis is well and good when you have the product to start from. But how do you go about producing a product you don't have for people who don't know they need it? (paraphrased from the HBR blog article, blogs.hbr.org)

References and links
Christensen, C. M. (1997) The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail, Harvard Business School Press.
Von Hippel, E. (2005) Democratizing innovation, Cambridge, Mass., MIT Press.
See promo videos at swrve.com

RTE Dragon's Den

Application deadline approaching: If you feel your business idea is ready to pitch.


Some of you may be interested in applying for RTÉ's Dragons Den. I think the deadline is end Oct or early Nov. Application forms are available at: www.rte.ie/tv/dragonsden/

p.s. Catherine's tips on the perfect pitch are really helpful www.rte.ie/tv/dragonsden/tips.html

Expressive objects

A personal reflection:
It seems to me that Moggridge's "Expressing Experiences in Design" presents a kind of method for technology development; articulation by illustration and descriptive prose. The paper demonstrates this with examples of technologies that had not yet found their place in the present (the paper was published in 1999). Even so, a designed object that has not yet become commonplace can be articulated, its aesthetic hinted at, sketched and praised. 

I think Moggridge's method is to rely on illustration and descriptive prose. A designed object can be talked about, imagined, its aesthetic hinted at, sketched and praised.  Moggridge draws attention to the potential for 'made objects' to exert an emotional appeal. Objects that evoke feelings even as we work, think or play with them. Such experiences may be positive or negative, even a confusing mix of with other perceptions. These objects remind us of past experiences, our encounters with them at other times even ages in our personal biographies.

But in these examples the design process is overlooked in light of the finished product as a whole, as if it were completed thing, already integrated within the equipment surrounding someone's life world. What else does Moggridge's presentation leave out, what does he miss from these snapshots of what was then speculative and futuristic technology? For example, the design process is overlooked in light of the finished product as a whole, completed thing.

The Osborne 1 my Grandfather gave me...

Image: oldcomputers.net/osborne.html

Can I do the same I too? Depict an expressive object that means something to me, give voice to modes of interaction that evoke some emotion, memories or feelings from when I used it? And an object that is more than a memento, a tool that allowed me express some goal, attain something I couldn't do before.

References
Moggridge, B. (1999) Expressing Experiences in Design. Interactions, 6, 17-25.

Managing Distributed Teams

What is a 'distributed team'? Why are distributed teams such a key part of development initiatives? What tools are out there to help me manage a distributed team?

• Basecamphq project management software (...as a service, monthly fee) see basecamphq.com/
• Pivotal Tracker for Agile project management (...as a service, monthly fee) see pivotaltracker.com/
• activeCollab for project management (installable or as a service, mixed pricing) see www.activecollab.com/

Why the Irish are the business.

Robert Short from RTÉ interviews Bono after the Global Ireland Economic Forum concluded. He asks about Bono's perspective on Ireland as a place to live and a place to work, considering the character of Irish people, their fighting spirit, self belief, and what he suggests is an openness to thinking different.



Robert Short recalls Bono's earlier reflection on ideas around anarchic mind, Bono replied...

"That really is the key to the digital age..."

"To write code, to write software, to crack the problems of the digital age, you have to think different!"

"In the information revolution, thinking different, smartness; India particularly there are some amazingly brilliant software writers - Ireland this is who we are... That anarchic spirit, it's actually, that's what makes us good at the future."

"We live on a small rock in the North Atlantic Ocean, it is pissing rain here, a lot! We have to be very smart about how we bring people, to want to work here and live here."

"And then think it's other things. It is culture, it's, you know, walking around Temple Bar and there's something in the air."

Bono (Paul Hewson)

---

And consider this short promotional video from IBEC, the Irish Business and Employers Confederation, on why Ireland is a good place to do business and to be a base for business with the rest of the world. Naturally IBEC has its own take on the financial crisis, Ireland's position in the world, and the kinds of values we should hold, however it does present a compelling view on 'why Ireland'.



(for more on IBEC see ibec.ie)

Is Software Process Improvement the problem?

"Faster, Better, Cheaper" (FBC) was a development philosophy adopted by the NASA administration in the mid to late 1990s. The conclusion from the FBC experience was "Faster, Better, Cheaper? Pick any two". (link)

"How do you merge agile, lightweight processes with standard industrial processes without either killing agility or undermining the years you’ve spent defining and refining your systems and software engineering process assets?" (Boehm & Turner, 2005) Is this even a reasonable question to ask let alone attempt to answer? Should the question be recast; where do agile lightweight processes work best and where do standard industrial processes that you've spent years defining and refining work best? Alternatively, are software engineering process assets in contradiction to agile, lightweight engineering processes?

The authors frequently refer to 'scale', they also refer to barriers. What assumptions does the 'scale' argument make? What barriers are they talking about? Finally, is SPI (software process improvement) the problem rather than a solution? If instead risk is the real problem should our response be to manage it away with contain and counter strategies or can risk be treated differently? In drawing the distinction between systems and software engineering (whatever Boehm and Turner really mean by the terms), are they suggesting that integration is in fact impossible, that the two perspectives may interact but superficially, as a sort of respectful disengagement?

REFERENCES
Boehm, B. & Turner, R. (2005) Management Challenges to Implementing Agile Processes in Traditional Development Organizations. IEEE Software, 22, 30-39.
Menzies, T., El-Rawas, O., Hih, J. & Boehm, B. (2009) Can We Build Software Faster and Better and Cheaper? PROMISE '09 Proceedings of the 5th International Conference on Predictor Models in Software Engineering.

The point with agile is to KEEP changing

The rhetoric of 'one way', even it if is Agile, Scrum or some other method, may be the problem rather than any particular method or practice being correct or not.
All organisational systems are systems of control, but not necessarily the simple view of control by management over production. Systems of control can be used in different ways. Visualisations of process are powerful representations, representations that become resources for control. New resources like burn down charts and story boards offer opportunities to exert control, exercise power and exercise resistance through compliance, non-compliance, inauthentic compliance etc.

The example presented here (www.infoq.com) by Marcel Wegermann, a narrative of Justin's Kanban journey, a journey that remains incomplete.
justin.time@it-agile.de

Another long rant on the list of many...

The post by Ryan Dahl that got Zack going... (link)

The only thing that matters in software is the experience of the user!

Then Zack Morris touched a chord with many in a retrospective and reflection on the 'state of computing' and wondering how it all got so wrong.

...The Real Zack Morris (link)

"Designing software is an exercise in managing complexity"

It's hard to disagree with observations and statements that have the ring of truth to them. These two essays say something true about the work of writing software. I take the work of writing software to include everything that contributes to the concrete production of an information system, production of the system as a concrete source code listing and byte coded thing through to configurations, usages, practices, aesthetics, etc.

So taking this broad characterisation of software to be Reeves's subject matter what is he stating and is it important? If we accept what he writes to be part of the truth of managing systems development, how does this understanding inform how I manage and how I work with technology?

REFERENCES
1. Reeves, J. W. (1992) What Is Software Design? C++ Journal. (link)
2. Reeves, J. W. (2005) What Is Software Design: 13 Years Later. C++ Journal. (link)

Problem posting to Blogger from different browsers...

A number of people have had problems posting comments to Blogger from either Google accounts or OpenID accounts.

I reproduced the problem and resolved it on Safari, Firefox and Chrome by clearing the browser cache. I think the problem arises from the way Google handles multiple logon identities in the browser.

The 2009-10 ASE class cantilever exercise

The ASE class were my guinea pigs for the first version of the cantilever exercise.

The MSD class 2010 working on the cantilever problem

The following slideshow records The MSD class 2010 working on the cantilever problem.


The Guindon design exercise says something deeply important about the dynamics of design work in teams addressing partially specified problems.

Student solution to creativity exercise.

One of the students from 2010 captured her group's solution which was probably the most entertaining of the whole classes.

Group Creativity In-class Project from Sileg on Vimeo.

Respect for rigour in software development

Respect for rigour in software development. The way to software you can trust your life with is through rigor and control. In Fishman's (1996) report we are provided with something of an overview of the situation, the resources, the working environment and the demands being satisfied by a software team responsible for developing the on-board flight control programs for the Space Shuttle.

"Consider the stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors." (Fishman,1996)

"the shuttle software group is one of just four outfits in the world to win the coveted Level 5 ranking of the federal governments Software Engineering Institute (SEI) a measure of the sophistication and reliability of the way they do their work. In fact, the SEI based it standards in part from watching the on-board shuttle group do its work. (Fishman,1996)"

But if rigor can be good, why do CMM, CMMi and other control frameworks have such a bad reputation in the profession?

"I am convinced that most organizations using the CMM are still entrenched in a default waterfall model mentality. I won't lay blame on the model itself, for I am aware of some process improvements made within a CMM context that were very much based on a modern, iterative approach to development. But this enlightened interpretation is not the norm." (Royce, 2002)

Is rigor only possible with frameworks and management control? Are other kinds of rigor and control possible? If there is a common problem what is it? At what point does more 'stuff' become the problem rather than the solution to the problem?

Commentary on 'the Right Stuff' on the C2 wiki (link).
And the backstory to waterfall, Winston and Walker Royce (link).


References
1. Fishman, C. (1996) They Write the Right Stuff.
2. Royce, W. (2002) CMM vs CMMI: from conventional to modern software management.

Theories of Organisation

THEORIES OF ORGANISATION
What theories underpin contemporary coordination and communication approaches? How do are these theories arrayed and structured organizationally, what tools, and knowledge are assumed and necessary to manage the implementation/delivery mechanism? How might we interpret or theorise the underlying processes taking place in this cycle of learning and adaption, because of course technology and systems don’t evolve of their own accord. If we can assume that the organizational system for high tech development is itself a knowledge intensive system, with some (but only partially) immutable structure, then we can employ organizational theory to make sense of (and perhaps manage) these systems.

MAKING SENSE OF ORGANISATION
Organisations are a kind of social order that we ourselves take part in constructing to give shape to special forms of collective action. As Max Weber observed, take away the people and organisations are nothing (Weber, 1949). However sociologists remain divided on the topic of the structural status of organisations and even society. We generally treat social structure as if it is real. Indeed there may be as yet unidentified physiological/psychological mechanisms bases for social patterning, they remain at the moment however, mere conjecture. But even if the human mind produces society and social structure through some as yet unknown intricate biological mechanism, the putative extrapolation of such a function from the individual up to the level of organisational forms, indeed to cultural, social and societal forms (Compte, ), is still the realm of science fiction rather than of science.

Whatever about the status and debates in organisation theory and sociology we still want (and need) to understand and make sense of organisations, especially as we are all in various ways involved in their production. Understanding how we go about doing this is important because our very understanding is in some way bound up with our experience of organisations. The ways we make sense of organisations attunes us to how we interact with others. The language we use, the ways of thinking about events and contingencies encountered from day to day predispose us to ways of interpreting work and our working lives.

METAPHOR
Assuming that there is as yet no unambiguous physiological or functional mechanism underlying the phenomena of social organisation; how then do we make sense of organisations even as they appear to surround us and constitute the fabric or our organisational lives? Metaphor is one way. The language and concepts we use in everyday speech govern to some extent our perceptions, distinctions and decisions. Metaphor is one way of interpreting and making the complexity of everyday situations comprehensible. A metaphor can represent a working hypothesis, a theory of what is happening, how it happens, who is involved etc. Metaphor is an approach we all use, almost without thinking about it, to interpret and simplify everyday realities. Lackoff & Johnson (Lakoff and Johnson, 1980) argue that organisational realities are constructed in language, and that metaphor is a pervasive and necessary element of this.

“Our concepts structure what we perceive, how we get around in the work, and how we relate to other people. Our conceptual system thus plays a central role in defining our everyday realities.” (Lakoff and Johnson, 1980)
“Metaphor pervades our normal conceptual system” (Lakoff and Johnson, 1980)

The prevalence of metaphor and its role in constituting organisational meaning may be a crucial instrument for interpreting and managing social interaction and (potentially) organizational design. Skilled and effective managers and professionals appear to have an innate ability to ‘read’ organisational situations, analyse and diagnose them by forming theories of what is happening and devising strategies to address situations (Morgan, 1986). There may be a direct association between a manager’s abilities to ‘read’ situations and their operating theories of organization. A metaphor lends a particular view or insight into a situation, one that ‘frames our understanding’ (Lakoff and Johnson, 1980) of what is going on; it is an operating theory of the situation.

Gareth Morgan (1986) offers eight images of organisations for interpreting and diagnosing conditions and situations (Table below).
Table: Eight Images of Organization (Morgan, 1986)


Lets look at three of these images (organisations as Machines, as Organisims, and as Brains) as ways of interpreting organizational systems and thinking about how to organise systems development.

ORGANISATIONS AS MACHINES

“When managers think of organizations as machines they tend to manage and design them as machines made up of interlocking parts that each play a clearly defined role in the functioning of the whole.” (Morgan, 1986)

The machine metaphor has become so pervasive that it is often simply unquestioned. Mechanistic models are one of the foundational concepts of organization theory although the software development industry appears at times to have a special attachment to it.

Functional mechanistic organisation design may be a direct analogue of the organization’s dominant product architecture or be based on process specialization. Product analogue organization maps the macroscopic structure of the development firm along functional lines to the functional organization of the product. Process specialization is where rather than the organisation's product determining the design of the organisation, the organisations processes (chains of activities) determine the structure of the organisation. These processes (e.g. maintenance, new product development, consulting) govern the divisional structure of the firm even though at the micro level (in sub groups or teams) individuals may still apply a mapping between the product design and their own roles and responsibilities. For example specialist engineers will own specific code modules for new development, fixes etc.

ORGANISATIONS AS ORGANISMS

“The problems of mechanistic visions of organisation have lead many organization theorists away from mechanical science and towards biology as a source or ideas for thinking about organization.” (Morgan, 1986)

The metaphor of the organisation as an organism presents a view of the organisation as having needs and existing within the wider environment that impacts it. The organism itself consists of interdependent organs and is situated within an environment or ecology. It may have relations with other organizations and belonging to a type or species.

Certainly the ideas of biology have also, like those of mechanisation, filtered into popular discourse. Biological thinking has become one of these background assumptions constituting modern thinking. Organisation theorists have adapted the idea of an organism to that of organization; existing in an open system, adapting to its environment, interacting with other organisms, and applying the notion of fitness, surviving, and evolving over generations. The organism metaphor conveys ideas of a life-cycle, health, reproduction, predators, prey, food, waste, etc.

ORGANISATIONS AS BRAINS: LEARNING
Organisations as mechanistic or as organisms assume and encode very specific models of learning and knowledge. Mechanistic feedback control loops are goal driven error minimising functions. The classic negative feedback loop is the underlying theory for many organisational principles. The Plan Do Check Act model (ISO, 2000) achieves product conformity by first planning, acting, detecting the error between what was desired and what was achieved, and then adjusting (Figure below). The organisational system applies an adaptive approach to achieving convergence with some defined objective or goal. Such cybernetic or feedback systems in organisations apply this kind of action/learning method to dealing with uncertain situations.

Figure: PDCA single loop learning of the Demming cycle

Single loop learning is characterised by negative feedback, assessing the difference between what was desired and progress to attaining it. The error or difference is measured and then minimised, further action is dictated and the process continues until the goal is achieved. This kind of cybernetic feedback loop may be explained by the example of picking up a pen. In a sense we pick up an pen by ‘avoiding not picking it up’ (Morgan, 1986: 85). The argument goes that iswe make a guess or approximation of where the pen is then gradually adjust our hand’s position towards it.

PDCA is a kind of ‘single loop learning.’ (Argyris, 1977) A single loop learning organisation designed around PDCA is good at producing and refining well defined products efficiently, predictably, and within high quality tolerances (think Six Sigma) but they may not be as effective at responding to changing requirements and dynamic competitive environments. One problem with simple learning models is that they can be inherently incremental, focused on perfective rather than more radical adaptive learning. The PDCA or the single loop learning model is perfective rather than adaptive.

Throughout the 1990’s Kodak “kept making the process of manufacturing and distributing chemical-based film more efficient instead of devoting attention to making the shift to digital photography” (Amabile and Khaire, 2008)

Put another way, the single loop learning model doesn’t tell us much about adapting the organisation to changing circumstances, new goals. An intelligent person for example, situated in a particular context treats learning in a fundamentally different way. We can conclude that as with individuals, organizations can step out of single loop cybernetic goal directed action by reflecting. According to Morgan, overcoming the organisational limitations of single loop learning involves: Institutionalising review, challenging norms, challenging policies, challenging operating procedures, reporting on change in the operating environment, and encouraging on-going debate, encouraging innovation (adapted from (Morgan, 1986)). All of which will however generate organisational tensions if single loop learning is institutionalized through the organizations structures and procedures.

Systems Development Life Cycle Notes

Life Cycle Archetypes
A simple definition of the classical Systems Development Life Cycle (SDLC) depicts high tech systems development in terms of 4 main activities or phases (Raccoon, 1995). Raccoon’s insight was to interpret other life cycle models in terms of the SDLC. Raccoon’s four life cycle archetypes are easily extended as variations on the theme of the SDLC as activities rather than as a sequence. If interpreted as a strict linear sequence the SDLC equates to the waterfall, if as overlapping phases it approximates the ‘V-model’, the spiral life cycle as lingering, and chaotic as all-at-once or code-and-fix. As Raccoon suggests, life cycles are just our own perspectives “on the state of a project rather than any essential truth about the state of the project” (Raccoon, 1995)
1) Requirements Analysis
2) Design
3) Implementation
4) Maintenance.
The waterfall model can be presented graphically in terms of SDLC activities as shown (below). The effort associated with these activities (or phases) can be plotted over time to create a shorthand representation of any life cycle in terms of the effort spent on these activities over time.

Watefall	Sashimi	Regression	Chaotic

A life cycle can in principle be presented in similar fashion, for example the Rational Unified Process depicted below conforms roughly to Raccoon's ‘Regression’ archetype.


References:
Raccoon, L. B. S. (1995) The chaos model and the chaos cycle. ACM SIGSOFT Software Engineering Notes, 20, 12.

Exercise: Systems Development Life Cycle Analysis

Objective:
To translate descriptions of different systems development life cycles into realistic/probable milestones and actionable activity timelines; as templates for the purpose of choreographing or managing teams.

Preparation:
Allocate at approximately 30” to run this exercise. 5” setup and briefing. 15” complete the exercise instructions below. 10” debriefing. This exercise can be carried out individually or in small groups. No special room/space requirements. A document projector is desirable.

Material:
Provide copies of this instruction sheet and additional blank sheets of paper.

Instruction:
Generate a milestone calendar or activity/time diagram using (at least) the activities of the generic SDLC, for one of the following life cycle models.

1. Waterfall.
2. Spiral development.
3. Or any other life cycle/method you are familiar with.

Outputs:
A single A4 sheet of paper upon which each student/group creates their own annotated diagrams for the life cycle model, e.g. a timeline of phases/activity for a project or iteration, a map of business function/activities over time, a consolidated diagram. Write your name(s) on the sheet.

Learning Outcomes and Reflection:
At the end of completing the exercise the tutor can gather the diagrams, group and display them during discussion using a document projector. Alternatively select student/groups to show, talk about and explain their diagrams to the class.

Practical Aim:
Identify the key characteristics of the listed software production and systems development lifecycles.

Knowledge Aim:

• Describe and discuss current and emerging management approaches to systems development in general.
• The overall goal of this exercise is to explore how you would operate or organise your team's activities over time based on one or other lifecycle.

Cross reference: Systems development life cycle notes

Life cycle considered harmful - stop - I want to get off

Let's not fool ourselves into thinking that our grandparents programmed in a world unfettered by software development lifecycles and the like (Gladden, 1982; McCracken & Jackson, 1982). What appears striking from these accounts is that the authors appear to have established their careers as programmers without the 'benefits' of standard life cycles or packaged methodologies.

It may be of interest to reflect on the careers of these early critics of software development life cycles. Michael A. Jackson (link) went on to develop JSP (Jackson Structured Programming) and subsequently JSD (Jackson System Development). Both design methods for system development rather than lifecycles or management frameworks. McCraken's career also flourished (link) in industry and academia. I have no further knowledge about G. R.Gladden aside from his/her role as quality assurance supervisor at Honeywell's building services division in 1982.

REFERENCES
Gladden, G. R. (1982) Stop the life-cycle, I want to get off. ACM SIGSOFT Software Engineering Notes, 7, 35-39.
Mccracken, D. D. & Jackson, M. A. (1982) Life cycle concept considered harmful. ACM SIGSOFT Software Engineering Notes, 7, 29-32.

Storyboarding ideas

Why should I care about what you've got to say?
Storyboarding is a technique I can use to help craft my message (Reynolds, 2008). Going about the business of presenting ideas has to be seen as a process. It's a creative process that rarely proceeds in linear, sequential fashion from initial concept through to completed work. The problem with software tools like PowerPoint is just that, they are tools, part of my equipment but not the source of my inspiration nor necessarily the subject matter. That said the tools are great aides for producing 'the work' but I need to include all the equipment I'm going to use because it's all part of the process and therefore necessary and relevant: sticky notes, whiteboard, back-of-a-napkin, sheets of paper, and software tools.

Foremost I should know what my message is. In this case, I want to convince others that storyboarding is a great way of structuring a persuasive narrative. I also want to link this to the idea that the media I use is merely an adjunct to the the narrative, even when I capture and distill my story in a close-ended format like film. What I mean is by this is that the narrative still needs me (and you the audience) to interpret it.

Garr Reynolds describes 'crafting the story' as a process, a process that takes place over a number of steps (Reynolds, 2008). I'll use the phrase 'categories' rather than steps. The process of crafting the story starts from a 'core message after which we branch into a mixed sequence of activities that I'll paraphrase from Reynolds as follows:

• Brainstorming
• Grouping & identifying the core
• Layout and organising
• Dry run and re-organising

Implicit in the process is its iterative, non-linear nature.

Let's look at "The Learner's Journey in Practice" by Brian Sawyer to illustrate the narrative of a story and an approach to structuring it. Sawyer presents a case of storyboarding with a colleague (Michael Milton) to outline the detail of a book chapter. They structure the chapter around a learner's learning process. They start from a basic linear narrative ploy, learning as a journey with a beginning, middle, and end. The learner they envisage needs to cover a number of major points and the major points are interspersed with supporting subtopics. They then create a scenario, a "learner's journey", to overlay the storyline. Sawyer then uses the idea of an actual reader undergoing his or her own learning experience; feeling the peaks and troughs of accomplishment, the 'oh crap' valleys and the 'I rule' moments. The scenario becomes a narrative tool to refine the chapter content, order, and presentation.

Sawyer's linear story is just one way of depicting what Reynolds calls layout. But how does the scenario work? The story is the simple linear sequence but the narrative is what they construct around the bare facts of the story. The narrative sketches how someone (a generic audience) encounters the facts as they are presented or made available 'in order'. Perhaps most important and implied but not explicit is that the rough notes, the storyline and the narrative structure are also necessary tools and technique for communicating ideas these. In the first instance Sawyer might be working alone but still putting ideas down and re-engaging with them, reorganising them. This process of capturing, organising, reorganising is a simple compelling account of what goes into presenting ideas but a lot of work has taken place prior to this stage; the goal of the book, deciding what the chapters should cover, how the chapters relate to each other etc.

RESOURCES
The following tutorials from UCD's School of Information and Library Studies (now titled the UCD iSchool) may be of interest (note that JayCut, the Blackboard Wiki, and other systems they describe are no longer available).

• ep1 Planning and organizing a video essay (dspace.ndlr.ie) 
• ep2 Creating and Capturing Video Content with Flip Cams (dspace.ndlr.ie) 
• ep4 Presenting your video essay (dspace.ndlr.ie)

Footnote:
Storyboard techniques for software projects

REFERENCES
Reynolds, G. (2008) Presentation Zen: Simple Ideas on Presentation Design and Delivery, Berkeley, CA, New Riders.
Sawyer, B. (2009) The Learner's Journey in Practice. (blogs.oreilly.com)

Creativity: Wile E. Coyote and Roadrunner

Robert Fabricant positions creative interaction as the crucial dynamic within groups of people solving problems. That is, creative interaction as a messy, chaotic, conflictual - but occasionally productive - dynamic between people who may or may not get along, with customers who may or may not get exactly what they want or even need, and making things you didn't know you were going to make before you made them (really).

designmind.frogdesign.com

Big Ball of Mud

It might be said that any software codebase and architecture initially resembles spaghetti code by being incomprehensible at first to any but an acolyte deeply familiar with its design.

The Big Ball of Mud architecture pattern was proposed by Foote and Yoder (Foote et al. 2000) as an 'anti-pattern' in software design and an inevitable consequence of the forces experienced by development. Development takes place within an environment of contrary forces and time pressure that imposes restrictions, constraints etc. on 'proper' design. For example, foundational design concepts such as coupling and cohesion of code modules are gradually broken and so architectural integrity degrades over time due to the ad hoc nature of evolving needs, requirements, and bug fixing. Boehm claimed that both ends of the lifecycle spectrum, ‘Code and Fix’ and Stagewise models end up producing unmanagable code or programs that fail to address the customer's goals (Boehm 1988). Foote and Yoder take an alternate view, that life cyle isn't the problem, the problem is intrinsic to code that succeeds and therefore needs to be maintained over a long time. They suggest that the BBM pattern is present as entropy, an attractor to disorder that imposes a constant tension on code but one that can be resisted through the practice of Refactoring.
"A certain amount of controlled chaos is natural during construction, and can be tolerated, as long as you clean up after yourself eventually. Even beyond this though, a complex system may be an accurate reflection of our immature understanding of a complex problem." (Foote & Yodder, 2000)


On the mysterious mound builders of Mountain View.

Brian Foote observes that in the years since he and Yoder wrote the article, "that no one has ever challenged our premise. No one has ever said 'no it isn't the most frequently deployed architecture out there', 'it isn't what we're all doing'" (Foote, 2007: 17'29")

One of the dynamics that produces BBM is turnover. "All too many people get onto projects, beat the heck out of the code, and move onto the next project. The code 'dies', the code is unmaintainable, nothing else can grow there, the enterprise founders, the end of the story." (Foote, 2007: 30'35")

The messiness of the relationship between code, architecture, and design may again be an intrinsic facet of software. Richard P. Gabriel (link) is credited with the counter-intuitive adage that 'worse is better' to characterise the dynamics of software acceptance. Subtly it can be understood from two perspectives, the developer and the user. From the developer's perspective worse code may produce better results for the user. From the user's perspective less features (worse) may be better because simplicity is what the need rather than what they want.

REFERENCES
Big Ball of Mud: Foote, B. & Yoder, J. (2000) Big Ball of Mud. IN HARRISON, N., FOOTE, B. & ROHNERT, H. (Eds.) Pattern languages of program design 4. Addison Wesley. (version online)
A wiki discussion on one of BBM's topics at Ward Cunningham's c2.com (link) - photo credit JohnLennon shovels on the spaghetti in cover art from the Magical Mystery Tour.
Foote, B. (2007) Big ball of Mud. Google Tech Talks.

Motivation

Consider work that involves genuinely creative and inventive aspects but work that also by necessity is the product of group interaction and multidisciplinary involvement.

Dan Pink's compelling (with RSAnimate's engaging video/graphic style) piece on motivating humans, intrinsic vs extrinsic, a (now) classic web presentation that must be seen (video on youtube but produced by www.thersa.org).

Question:
So how does compensation structure perform as a determinant of team performance? Put another way, how do teams perform as collaborative units under differing reward structures?

Creativity and the Design Process

Creativity and production of digital goods: managing creative intellectual teamwork
The results or outcomes of creative processes are unique and sensitive to context. This section reviews practical strategies for unleashing the creative dynamics of teams in digital production. Creative performance on teams is shown to be affected by group relations, structure, composition and skill. Therefore management has a role in cultivating the conditions for the creative dynamic to occur by supporting divergent and convergent thinking, producing a (usually) productive process of problem/idea/solution generation.

PERSPECTIVES ON KNOWLEDGE, LEARNING, AND CREATIVITY

"Seymour Cray described how his little company, located in Chippewa Falls, Wisconsin, had come to build what are generally acknowledged to be the fastest computers in the world... Cray said that he liked hiring inexperienced engineers right out of school, because they do not know what’s supposed to be impossible."
(Kidder, 1981)

If I cannot control an individual’s creative potential how is it possible to manage that of a team? It seems possible that two different processes are in play, collective and individual, and that both processes are interrelated in certain ways. E. Paul Torrance defined creativity for his groundbreaking studies of creativity in children as:

"The process of becoming sensitive to problems, deficiencies, gaps in knowledge, missing elements, disharmonies, and so on; identifying the difficulty; searching for solutions, making guesses, or formulating hypotheses about the deficiencies; testing and retesting these hypotheses and possibly modifying and retesting them; and finally communicating the results."
(Torrance, 1965)

Torrance described two main activities in the creative process: divergence and convergence. Divergence described ideation, extrapolating and growing ideas; convergence described judging and selecting ideas, reducing the alternatives being considered. People displayed different proficiencies for purely original thinking versus elaborating on existing ideas. The creative process consisted alternatively of divergent and convergent thinking. There are also two broad approaches to understanding creativity; on the one hand, creativity as an individual's own cognitive process (Treffinger, 1995), and on the other hand, organizational/contextual analyses of creativity or innovation (Hargadon and Bechky, 2006). The brainstorming captures elements of both individual and team creativity whilst it structures the two activities. The suspension of judgment allows for elaboration and extrapolation of ideas, while a returning focus on the problem allows for periods when ideas can be tested and selected.

Certainly creativity is largely an individual cognitive activity. Indeed the ‘ex nihilo’ generation of ideas may be a necessary underlying process of individuals during a collective design or problem solving activity. However cognitive psychologists conclude that individual creative processes are more often processes of analogical reasoning applied to make sense of new situations rather than gestalt insights. Therefore the individualist perspective overplays the role of the inventor in the process of creative production while innovation studies in particular, often emphasize the importance of contextual factors in successful innovations but underplays the role of ‘supraindividual creativity’ (Hargadon and Bechky, 2006).

However there are interesting dynamics surrounding design which unfold over the life of a team that suggest a strongly collaborative collective aspect to design and learning in general. Creativity is can be defined, in terms of team outcomes, simply as the “recombination of existing ideas” (Hargadon and Bechky, 2006) to produce a novel solution or address a problem. From this perspective the phenomenon of interest will be apparent in groups through interaction and behaviour.

SIX CREATIVE WORKPLACES

"What turns collections of creative individuals into creative collectives, where particular interactions yield creative insights, yet those insights cannot be attributed to particular individuals?"
(Hargadon and Bechky, 2006)

Attempting to answer this question drove longitudinal study of professional service consulting firms in the business of developing ‘novel and valuable solutions’. The study was designed to understand how collective creativity takes place in groups and therefore addresses a gap in our understanding of the links between creative problem solving and innovative production in organizations. Hargadon and Bechky's study relates to digital and software development because it can inform how we might better understand creative processes in software development teams. 

The findings are based on six in-depth case studies of highly creative industry workplaces. The research looks at group members’ own reflection and sense making of their experiences working in groups involved in creative production. All six firms in three industry areas worked directly on problems that required creative solutions. The view of collective creativity presented is plausible and actionable by others. If the practices can be introduced they could then be regularized in policy or supported by management. 

Where Do Collective Creative Processes Take Place? Hagridden and Bechky’s unit of analysis is group interaction and design behaviour.

"this perspective recognizes the fleeting coincidence of behaviours that trigger moments when creative insights emerge. ...insights that emerge in the interactions between individuals."
(Hargadon and Bechky, 2006)

Their analysis identifies a model of collective creativity consisting of four dominant interrelated activities: help seeking, help giving, reflective reframing, and reinforcing. They draw on Weick and Roberts idea of mindful engagement in social interaction that shapes group or collective cognition.

"Mindfulness describes the amount of attention and effort that individuals allocate to a particular task or interaction. Participation in group interactions, as a result, becomes a product not of membership or presence within a group, but of the attention and energy that an individual commits to a particular interaction with others in the group."
(Hargadon and Bechky, 2006)

HELP SEEKING
Informal events and formal processes were identified as important enabling factors to initiate problem solving. Chance meetings in halls were cited as were organizational norms for brainstorming and problem solving.

• Design Continuum used formal brainstorming sessions.
• HP’s SPaM group and IDEO held weekly meetings to openly discuss current projects and problems.
• Boeing’s Ops Tech group met monthly but also informally more frequently.

"The simple practice of holding regular review and brainstorming meetings was an important enabling factor was were ‘ad hoc meetings,’ ‘hallway conversations,’ and ‘tapping into personal networks."
(Hargadon and Bechky, 2006)

The absence of social costs or sanctions for asking help after failure, and organizational cultures that did not stigmatize people for seeking help for problems or failure are powerful enablers to reinforcing help seeking behaviour.
At IDEO "blame for any particular design failure depended on whether the engineer had asked others for help or not: If they had not sought help, then they would be held individually responsible." (Hargadon and Bechky, 2006)

HELP GIVING
The counterpart to ‘help seeking’ behaviour was ‘help giving,’ without which there could be no collective creative interaction. ‘Help Giving’ also had to take place and in a timely manner. There were obstacles to help giving. The more experienced people were often very busy. There were often institutional constraints around accounting for people’s ‘billable time’ and you can’t always get the obvious person involved. Help seekers would resort to people who were available and accessible instead of going to the top.

"You talk with whom you can. You explore until you find people in the firm that are accessible, near enough in the time frame to talk about it." (Hargadon and Bechky, 2006)
"There were certainly times when, for example, solicitations for help arrived as clear questions and could be easily returned with equally clear answers." (Hargadon and Bechky, 2006)

However while the process of formulating and expressing the problem in documents can often help resolve the issue, email and document mediated interactions could be useful but lost immediacy and clarity.

REFLECTIVE REFRAMING
Reflective reframing is a process of recasting problems or solutions from one field into another. The actual process or act of expressing the problem with another and engaging with them in a ‘brainstorming session,’ ‘ad hoc meeting,’ or ‘hallway conversation,’ was the key interactive dynamic that represented the formation of the creative collective.

"Within such interactions, introducing an alternative frame – and reflecting upon it – makes new aspects of the situation salient to other participants, prompting them to view the relevance of their past experiences in a new light." (Hargadon and Bechky, 2006)

This was the experience of expressing the problem with others engaged mindfully in the interaction. It was a joint process of seeing solutions in terms of past experience or reframing the problem from a different perspective.

REINFORCING
Reinforcing is the normative personal and social process of feedback and recognition (both good and bad). Reinforcing plays an important role in making individuals aware of the activities which feed into the creative process and it predisposes individuals (positively or negatively) to engaging with the process again. The set of behaviours will also be reinforced if individuals have positive experiences when they engage in the process of help seeking and help giving. Reinforcing influences shape how individuals may become more or less open to future creative interactions, capturing in some sense how people remember these experiences and value them. Reinforcing behaviour becomes a matter of shared values and beliefs, the local organizational culture and that at large. Importantly they found that

"asocial means of enabling knowledge sharing do not encourage people to participate in joint problem-solving efforts." (Hargadon and Bechky, 2006)

CONCLUSIONS
It is evident, from research and experience, that collaborative creative interactions are complexly sensitive to issues of group interaction, relations, behaviour, practices, skill, group composition, experience (prior and together), and access to each other, time, materials and other resources. This list of factors is also unlikely to be exhausted. Performance of creative interaction is subject to the vagaries of situations, context, history and local culture. However there are some things we can say about creativity in teams; creativity is an emerging phenomena. The ideas and decisions made in collective processes emerge in unplanned ways. The quality of the ideas is a function of various group aspects alongside structural enablers like norms, culture, attitudes and process. Unquantifiable aspects may be as important as those we can manage; for example, ambiguity may be a necessary condition to allow misunderstandings to occur. Ignorance of prior limitations may allow the problem to be approached in a fresh light, unencumbered by pre-existing paradigms.

Atlassian thinking behind agile practice

(via Dagny) Atlassian present a video piece on their own agile development approaches. In these interviews with the employees they highlight the difference between agile & waterfall in a brilliant way. Many more videos supporting (atlassian.com)

Who is Kent Beck?

Kent Beck is a software programmer running a small consultancy business in Oregon. As he says himself, he divides his time between writing, programming, coaching and farming Goats. Kent was a SmallTalk programmer who attempted to re-think the essence of software development having been involved in attempting to recover some significant software project failures. JUnit is a unit testing framework that has since spawned the development of other testing frameworks NUnit etc. He has written several important journal articles and books, mainly addressing Extreme Programming, SmallTalk programming and JUnit, his most successful project.

Kent is a respected voice in software development's professional communities; taking an active role in discussions, speaking at conferences and sharing with other programmers these ideas for a better way to organise the work of programming for which he coined the label 'Extreme Programming.'

For more see:
Kent on Twitter
Kent's Three Rivers Institute
And the active Extreme Programming group on Yahoo (extremeprogramming@yahoogroups.com)

Who is Barry Boehm?

Barry Boehm's career in computing and software coincided with the early evolution, definition and expansion of the discipline of computer programming in the 60's. His background in mathematics (primary, masters and Ph.D.) predisposed him, through his early programming experiences, to the need to attain algorithmic correctness, however his subsequent exposure to the production of relatively large programs, diverse programming languages, diverging computer architectures, human interface and usability considerations drew him to conceptualize of the general experience of programming as a highly subjective exercise in group communication.

On Wikipedia
Barry Boehm quotes

A modern interpretation of Royce

There are some points we can take from Royce if we interpret him generously:
Program Design Comes First: Analysis/Design (and code) is indeed the heart of programming, but is it realistic to expect these activities to reside mainly at the beginning of a project? Document The Design, and/or perhaps the architecture (whatever that might be) is desirable but in answer to the question of 'how much documentation?' Royce states

"[m]y own view is ‘quite a lot;’ certainly more than most programmers, analysts, or program designers are willing to do if left to their own devices. The first rule of managing software development is ruthless enforcement of documentation requirements." (Royce, 1970)

On this point Royce suggests that for a "5 million dollar hardware device, I would expect that a 30 page specification would provide adequate detail to control the procurement. In order to procure 5 million dollars of software I would estimate a 1500 page specification is about right in order to achieve comparable control." (Royce, 1970) p332  More ambiguously perhaps he mandates that (at least at the start of a project) "the documentation is the specification and is the design." It is clear that Royce assumes that the document communicates perfectly and unambiguously, that a document overcomes the problems of interpersonal communication (or its lack) by being clear and unambiguous. If we read ‘understanding’ instead of documentation and consider it to be present in ‘communication’ in the processes and practices of communication, of interpersonal interaction and sense making along with the source code and ‘documentation’ then perhaps Royce isn’t far from the mark.

Do It Twice, an insightful recommendation, that the software is actually a product of learning; learning what the requirements really are rather than what they were initially thought to be, learning how a design performs, how it interacts with the hardware and other software, learning how the software is actually used, timing, scale, performance.

Plan, Control, And Monitor Testing. Yes but, perhaps happening later as it does in his model, the model may collapse as bugs, problems and inadequacies leak back again to affect the requirements, design and analysis.

Finally Involve The Customer, perhaps the most insightful recommendation and perhaps one that we still find difficult to achieve.

Royce can be read perhaps as a radical, making recommendations not usually associated with this era, principles and practices which might be understood in Agile Development as emphasizing communication, design/coding as the central activity, responding to change, refactoring design, visibility, and on-site customers. At the end he arrives at a process model for software development, an approach which is essentially iterative, involves customers, and is dominated by strategies to facilitate communication with all involved.

While Royce’s paper was influential in the move towards methodologies and understanding and developing principles for the organization of software development teams, it also (sadly) said very little about the practicalities of organizing teams and actual people. For this one must turn to Brooks (1995 (1987)) and others who followed.


REFERENCES

Some questions on systems development

Question: Do the objects and practices of the software engineering domain propagate elsewhere? Are they reproduced in other professions and settings?

Questions on Royce's article:

• Who are the ‘designers’ if not the ‘programmers’?
• Comment on Royce’s assertion to ‘document the design’
• How does Royce remove task leakage in his modified model?
• Does his modified model really succeed in overcoming leakage?
• What does the direction of Royce’s diagram arrows represent?

Questions on Boehm's Spiral Model:

• Does Spiral end up treating development as a game, with the goal being to pass the ‘review,’ lead to short term perspectives with implications for investing away from long term goods like training and discovery?
• Can the spiral model be used to develop/maintain a mature product/project?
• Is a single generic life cycle useful?
• How might successive generations of a product undergoing continuous development and delivery in new releases be managed using spiral?
• Does spiral address the activities of production/programming (analysis, code, fix)?
• What are underlying drivers of increasing complexity of high-tech products?
• Does spiral that programming is an intrinsic process of analysis, design, coding, fixing, testing ad infinitum?

Questions on Raccoon's Chaos Model:

• Is Raccoon’s analysis insightful or useful?
• How might we act differently on the basis of this Raccoon’s presentation of the work of design and coding?
• Taking Raccoon’s idea of recursive development seriously, can we also assume the same approach apply to testers, QA, consultants, and product owners, even customers themselves?

Questions on Process Frameworks:

• Are software process frameworks The challenge for systematic (and systemic)?
• Do process frameworks reinforce implicit linearities in conventional production?
• Can process frameworks support iterative processual modes of working?

Questions on ISO9001

• Can it can be mapped onto all the different life cycles in use in the software industry, e.g. waterfall, incremental, evolutionary, spiral life cycle, etc?
• Should you deliver something that hasn’t been tested, or fails the tests?

Questions on Agile development

• Which half of the list of XP Rules is already accepted as general programming best-practice?
• Isn't Pair Programming an unnecessary doubling up of resources?
• Why should a development team adopt Collective Ownership? Surely it is a recipe for out-of-control code?
• Comment on the following: 
• Continuous Integration of developer code will produce a bug factory, i.e. code perpetually broken and in an indeterminate state. 
• Refactoring is a way of saying we haven't got the architecture right (do we even have an architecture?)!
• Agreeing to 'sustainable pace' or a 40 hour week will slow product development down.
• The XP Planning Game removes control from designers.
• Royce’s proposed remedies to the waterfall model (Royce, 1970) can be read as a radical approach to refocus on principles and practices rather than structure and method. Is it reasonable to interpret Royce in terms of the Agile movement? Royce’s ‘5 Steps’ suggested:
1. Program design comes first (code is design)
2. Document the design
3. Do it twice
4. Plan, control and monitor testing
5. Involve the customer.

Some Questions on Creativity

• Consider Sutton’s recommendations, are they irresponsible?
• Is a creative culture following Sutton doomed to self-destruction?
• Does it make sense to conceive of a stable self-sustaining version of Sutton’s creative culture?
• Can a creative development culture coexist with a general production culture?
• From Katz; how does compensation structure perform as a determinant of team performance? 
• How do teams perform as collaborative units under differing reward structures? 

Managing teams

COLLABORATION IN TEAMS
The social dynamic of software design work in teams is beginning to be understood as an intrinsically creative process. Creative teamwork is often difficult to pin down however as it may manifest unexpectedly and in unplanned ways. Interpreting high tech design and development as a creative process is the first step to suggesting approaches to structure and manage conditions to better enable productive team centred design and production (Ancona and Caldwell, 1990).
Contemporary innovations in software process knowledge reflect a renewed emphasis on the importance of coding (Sharp and Robinson, 2004, Mackenzie and Monk, 2004), leading us to conclude that co-design activities of software development present an empirical moment of central concern to organizational studies of software product development. Software design in teams is an inherently social activity (Winograd and Flores, 1986, Suchman and Trigg, 1996, Dittrich et al., 2002, Weinberg, 1971) but one which seems to constantly slip from management and control.

Managing Creative Interaction
The creative problem solving process involves generating waves of diverging and converging ideas. The process of productive interactive problem solves some key practices and joint understandings.

• Focus
• Suspend judgment
• Build on ideas
• Personal safety
• Serial discussion

The capability to solve problems creatively and to engage in creative forms of collective production is dependent on a number of distinctive behaviours that become embedded in the institutional setting (Hargadon and Bechky, 2006) p485.

• help seeking
• help giving
• reflective reframing
• reinforcing.

While the unfolding process itself involves distinctive transitions.


Proficient teams of creatives will discuss, negotiate and establish group guidelines for brainstorming and other solution generative activities.

Design philosophies and development methodologies are rarely applied in a formulaic manner, rather they are used to initiate and facilitate the organization of design thinking, to better deliver usable computer systems supporting work and other activities.


TEAMS: MOTIVATION, REWARD, AND COMPENSATION
Collaboration on teams is evident in how team members teach each other and learn from together to overcome problems faced by the team as a whole. However peoples’ behaviour may be conditioned in part by the reward structures of the organization. Can reward or compensation structures have an impact on people’s propensity to teach and their motivation to learn? If so what reward structures support this behaviour? Is compensate or reward anti-ethical to teamwork and collaboration?

Many reward structures have cultural aspects (motivated by personal and professional beliefs and values) but compensation also plays a part. The right compensation scheme can at the very least impose or remove some of the obstacles to cooperation, collaboration and teaching/learning/creative processes taking place between team members. In an experimental study Nancy Katz experimented with 100 participants in a Bolo exercise as used by US Army Research psychologists (Katz, 2001). 35 three to four person teams played a war game simulation against the computer, capturing refueling bases (illustration below).

From Scrapbook Photos

Figure: Credit: Atari Battlezone. Bolo is a networked multi-user, real-time tank battle simulation.

The simulation created a number of common conditions; dispersed information, time pressures, easily evaluated performance, undifferentiated member roles, and the need for collaboration. The following compensation structures were employed and group performance assessed (Table below).
Table: Compensation schemes trialled in Bolo exercise (Katz, 2001)

From Scrapbook Photos

So how does compensation structure perform as a determinant of team performance? Put another way, how do teams perform as collaborative units under differing reward structures? Katz found that the hybrid ‘threshold’ schemes were best at encouraging behaviours that maximized the team’s performance. Both threshold schemes were associated with cooperative behaviour, increasing the likelihood “that people with greater skills will help their teammates become more proficient.” (Katz, 2001) p22 The group threshold motivated teaching behaviour on the part of the most talented team members,
“encouraging high performers to teach and share information.” (Katz, 2001) p22
The individual threshold scheme was a driver for individual learning effort, motivating low performers to learn and improve themselves. The ratio scheme, while better than both equity and equality, encouraged anti-group behaviour.

“most likely because it placed a cap on performance rewards and made team mates constantly concerned about their performance relative to one another.” (Katz, 2001) p22

Another aspect that might seem obvious but needs to be highlighted. There team performance is learnt over time. Team behaviour is sensitive to its experiences, how long it remains together, the relative learning trajectories of its members, the shifting levels of knowledge, skill and expertise which change over time.

“enough time for highly skilled members to teach their less skilled counterparts.” (Katz, 2001) p22

Without the time and opportunity to learn the processes underlying collaborative, learning the work just cannot take place.