RSS

Author Archives: Shane Hastie

About Shane Hastie

Chief Knowledge Engineer at Software Education Agile News Editor for InfoQ.com

Please don’t equate Tragile with Agile

Lajos Moczar recently posted an article in CIO magazine titled “Why agile isn’t working” in which he states that “I’ve concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT”.  He goes on to identify ways in which he says agile is not only failing but making things worse for the IT industry as a whole.

I’ve read the article carefully and tried hard keep a balanced perspective as I perused it.  I can’t keep calm – this article is dangerous unadulterated drivel! The author misinterprets the agile manifesto and takes some of the agile practices completely out of context, using unfounded statements to justify his conclusions.

This post is my response, addressing the points he makes and tackling the myths he propagates.

Advertisements
 
Leave a comment

Posted by on June 14, 2013 in Uncategorized

 

Performance Appraisal on Agile Projects

Over the last week I’ve had two people ask me about performance management and appraisals on Agile projects.  This post is to provide them with some answers and will hopefully be useful for others in the future.

One area where the adoption of Agile approaches often bumps up against established organisation structures and frameworks is in the realm of performance management of individuals.

There is a lot of research to show that many of the current performance management approaches are actually demotivating and harmful, especially in environments (such as on Agile project teams) where the most productivity and value comes from collaboration and teamwork.

Daniel Pink gave a fantastic TED Talk in which he examines the science of motivation: http://www.ted.com/talks/dan_pink_on_motivation.html

In their book Craig Larman & Bas Vodde, discuss many of the problems inherent in the performance appraisal process, and how they actually destroy motivation and destroy team cultures – see “Scaling Lean and Agile Development”, Addison Wesley, 2009, pp.  267, 268

Even management guru W Edwards Demming advised organisations to “Eliminate Management by Objective”  and  urged “…abolishment of the annual or merit rating …”.  (Deming, W. Edwards (1986). Out of the Crisis., Chapter 3. MIT Press)

Michael James published an article in Better Software magazine entitled “What HR Doesn’t Know about Scrum” in which he summarises some of the key issues with traditional HR approaches and Agile (Scrum) practices.

The article can be found here: http://danube.com/system/files/WhatHRDoesntKnowAboutScrum_BetterSoftwareMagazine.pdf His key points are that many of the existing HR practices are derived from the era of Scientific Management and they don’t work for knowledge worker roles.   Individual performance appraisal drives behaviours that are contrary to team effectiveness:  “Team self-organization around business-driven goals will fall short when individuals also have goals of looking good for the boss or outscoring teammates in 360-degree peer review contests.

He goes on to discuss the importance of hiring for team cohesiveness rather than individual skills, ideally allowing the team to choose new hires themselves.  Yes, technical skills are important but more important is the ability of the team to jell and work effectively together.

Other commentators have written about the danger of individual performance reviews on Agile teams.  Esther Derby posts about the dangers of the review process, and she provides advice on addressing the common concerns among managers when looking at changing the review process.  (http://www.estherderby.com/tag/performance-appraisals)

She lists the most common  reasons for having performance appraisals and addresses concerns around them

  • Determining how much to pay people
  • Determining who to promote or fire
  • Helping team members understand how they need to improve

http://www.estherderby.com/2010/07/performance-without-appraisal-addressing-the-most-common-concerns.html

If organisations insist on retaining performance reviews there is some advice available from Alan Atlas in the Agile Journal.  http://www.agilejournal.com/articles/columns/column-articles/5742-performance-management-for-agile-people

He examines the motivation for performance management, discusses why they generally don’t work, and gives some possible approaches that could be used.  His key points for performance appraisals are:

  1. Give all of the members of an Agile team the same performance goals.
  2. Assign individual goals for individual development.
  3. Make sure individual goals are aligned with team goals.
  4. Frequent 360 degree performance feedback is better than many alternatives.
  5. Value highly the personal traits, characteristics, and behaviors of good team members.

Jeff Sutherland posted his approach to performance reviews and presents a possible approach for an appraisal process here: http://scrum.jeffsutherland.com/2006/11/agile-performance-reviews.html

Lean & Agile thought leader Mary Poppendeick has also written at length on the topic in this article http://www.poppendieck.com/pdfs/Compensation.pdf where she examines the typical dysfunctions caused by the process, and provides guidelines for designing an effective performance management system.

Tara Hamilton-Whitaker of the Agile 101 blog has two posts discussing an Agile Balanced Scorecard, which can be used to assess a TEAM as a whole, rather than trying to assess the individuals against one another.

http://agile101.net/2009/07/18/agile-balanced-scorecard-measuring-the-effectiveness-of-an-agile-software-development-team/

http://agile101.net/2009/07/19/the-agile-balanced-scorecard-tracking-the-reliability-of-an-agile-software-development-team/

I hope this helps, and as always I welcome feedback.

Posted by Shane Hastie

 
Leave a comment

Posted by on February 26, 2012 in Agile

 

Tags:

An Inspirational Visit to the Powerhouse Museum

It seems I do most of my blogging on airplanes – this is another blog post written while crossing the Tasman.

Last week the Software Education trainer team had a rare opportunity to get together for some professional development and R&R together. We try to do this on a regular basis, but it’s been quite a while since we got it right.

Nine of us met in Sydney for three days; we spent the first day sharing ideas and talking as a team. The second day Clarence White from The Actor’s Studio took us through some exercises to extend our classroom delivery skills, and on the third day we did touristy things in Sydney: a visit to the Powerhouse Museum followed by a Harbour Cruise lunch.

I really enjoyed opportunity to spend time with my colleagues – we tend to be a fairly solitary bunch, and seldom get the chance to work together simply due to the nature of our work. We travel to venues around Australia and New Zealand (and beyond) delivering courses and consulting with companies and teams on our own, so being able to spend three days in each other’s company is a real privilege.

We debated the content of courses, delivery styles, and the state of the world at length – it would be impossible for us to get together and not have intense discussions as we’re all so passionate about our work.

If you think the testers and developers in your company sometimes have passionate discussions you should see a bunch of testing and development trainers talking about the merits and flaws of each others topic areas:-). Fortunately we value diversity and embrace free thought and the sharing of ideas, and we have a social contract that sets the framework for debate so the discussions were interesting, fun and respectful.

On our third day together we visited the Powerhouse Museum and had a Curated Tour. This was generously organized by Damian McDonald and we were guided around the museum by Matthew Connell.

Matthew is the Principal Curator for Physical Sciences & IT and he took the time to not only show us around the museum, he explained what the exhibits are, what they represent, and the process the curators go through to identify and select what goes into an exhibition. This was a fascinating tour and the insights Matthew shared with us were inspirational both in terms of how the ideas apply to what and how we teach, and about the lifecycle of technology and innovation.

I didn’t take many notes (too absorbed in listening) but fortunately Sharon and Anja were armed with their iPhones and they did take notes of some of the key points Matthew made. So, thank you ladies for sharing your notes with me.

Here’s what Sharon had to say (she summarizes so well I’m not going to try to paraphrase)

  • The museum had to focus on “less consumption and more interaction” – I thought that was a good analogy for software also, particularly the development of Agile software – less “take what you are given and be happy with it” more of “what do you want out of this and how can we provide it”. Less spoon feeding more designing the menu.
  • “Living laboratories” in the museum – I could also draw the analogy back to software here –our solutions should be built with this in mind – particularly with an Agile solution – let’s hypothesise and experiment with the solution and use the results of the experiment to determine our next steps.
  • “Technology at a cultural level – what is the context, purpose, persistence of the technology” – it was a great trigger for thinking about how long any solution will be around and why is it being used. So often we see our solutions not providing a single solution but being built as a package of solutions – is that the best way?
  • “Significance is not a universal concept – it varies over time”. I thought this was very insightful as you can see this is software when the priorities change at the micro level and when the technology changes at the macro level – iPhone and iPad aps are the example that came to mind – we have moved away from complex multi-function software to small, simple aps that deliver the required solution
  • “The Rubbish Phase” of a product or an artefact – this made me think about good software solutions that do not survive the “rubbish phase” and are thrown away before people realise their value or potential value [Editors Note: the Rubbish Phase is the period between an idea being innovative and it becoming an important part of history. Matthew spoke about some of the material the museum has in storage that runs the risk of being discarded to saved space, and then becomes rare and historically significant]
  • “Innovation is something that changes human thinking” – I thought this was a great definition and would love to do some blogging and working on innovation in IT and what is it and how do we recognise it?
  • “The deficit model of scientific communication – we know everything and we will tell you what you need to know” – Matthew was talking about climate change as his example but I could see us in IT doing that to the business and our end users – only telling them what we think they need to know.

Anja posted her thoughts to the Software Education Yammer stream:

I felt inspired by our Powerhouse Museum visit in Sydney
that was guided by Matthew Connell, the principle curator.
He was an excellent speaker - now that means different
things to different people. 

He was fluid, and was able to provide knowledge in context
of historical, current and future changes within the
engineering space. 

Moreover, he was very personable - or, he was in the moment,
very approachable and humble about his knowledge trying to
connect to us by giving us his focused attention for over
an hour. And no GAMES!

In his words, displayed work ("art") is not just about
communicating and interacting with people, but to engage
them in context of their realities, their lives -
how and why we are evolving.
Innovation in his own words he described as providing a person
with a new understanding of the world and themselves, their
culture with the main objective to have a social impact.
Innovation can be gradual or big bang. 

The main message I took away from "new approaches to teaching
and learning" is that of an intuitive journey -
to provide for the individual as opposed to mass!

So we had a great time, learned a lot and gained an insight into the historical and scientific mindset. If you’re in Sydney and have some time to spare go and visit the Powerhouse – it’s a great experience. I certainly plan on returning to see the new exhibitions.

Thank you Matthew and Damian, and thank you to my colleagues for sharing the time. Thank you James for the idea of visiting the Powerhouse.

Thanks too to Martyn & Phil for giving us the time and money to be able to get together in Sydney. Now, where should we go for the next trainers session (Fiji anyone?)

Oh, yes – just in case you think we were purely focused on work and learning, I can attest to lots of banter and laughter over great German food and a wonderful cruise on the Harbour. Significant quantities of good beer and wine somehow appeared on the bill at each meal we shared 🙂

The photo was taken on the first day when we were behaving ourselves because the boss was there with us. There will be no published record of the later events. 😉

Posted by Shane Hastie

 

Tags: , , , , , , , ,

Using your brain effectively

Another post from an airplane 🙂

I received a promotional email which intrigued me, and followed the link to download the Synaptic Potential (http://www.synapticpotential.com/) paper titled “How to use your Brain to be more Efficient, Effective and Productive”, I was a bit skeptical (thinking I know this stuff, after all I teach all about it) but discovered the author (Amy Brann) does actually have some very valuable content to share, based on solid neuroscience and brain research.

She presents a three-component model to help understand mental processes and address the questions of “how quick, how good and how much” do we use our brain capacity?

The paper gives a useful discussion of the underlying neuroscience and introduces the prefrontal cortex and Neural Darwinism, then goes on to address the three components of her model. Amy provide concrete tips and ideas on how to change your behavior for each aspect of their model.

1. How Quick?
There are three factors that improve how quickly we think – Monotasking, Minimizing Distractions and Maps.

Monotasking is about focusing on one thing and doing it well. She cites studies and investigations that show how bad multitasking is in terms of actually achieving effective results (“one study showed that visual input dropped by 29% and listening ability dropped by 53%”); this impacts on stress levels and creates “constant and intense mental exhaustion”.
Minimizing Distractions Builds on monotasking and looks at the impact of interruptions on productivity – every interruption takes at least 15 minutes of productivity away from the task you are working on. Even the smallest interruption (noticing the text message that arrived, even if you don’t stop to read it) has a concentration impact. Minimizing distractions requires active management of your personal environment and space.
Maps are the mental models that help to form pathways in the brain and enable us to do things by rote, deep learning. She recommends identifying the cognitive tasks that you need to do regularly and build maps for them.

2. How Good?
She presents three ways to be more effective in your thinking – Flow, Unstuck and Sleep.

Flow is the mental state when we “feel at one with what we’re doing, immersed, focused, fully consumed and involved”. She explains the chemical balance the brain needs to achieve flow and gives advice on achieving this balance.
Getting Unstuck requires changing the frame – raise above the details and look at the big picture, go for a walk, do something non-stressful and different to allow your mind to jump out of the rut it gets into.
Sleep is vital to effective thinking – she talks about how important it is to get sufficient sleep on a regular basis, and discusses the value of the power-nap, a 20-40 minute sleep during the working day can result in a 40% increase in cognitive function!

3. How much?
The final threesome are Allostatic Load, Challenges and Expectations.

Allostatic Load is related to levels of stress and stress management. She talks about how stress impacts the ability to think and provides advice about healthy body-healthy mind.
Coping with cognitive Challenges requires acknowledging the emotions you feel when faced with challenge and not succumbing to the negative emotional impact.
The final piece is to set high Expectations – goals based on clearly stated high expectations motivate and encourage us and help us keep working towards those goals.

Overall I found the paper an interesting and useful read. I can certainly recognize the three aspects in my own cognitive working. Over the last two weeks I’ve worked on some tasks that have enabled flow, focus and monotasking and the rate of productivity has astounded me.

Being aware of how you think, and taking ownership and control of your cognitive behavior is a great way to improve productivity and satisfaction, whatever you are doing.

Posted by Shane Hastie

 
4 Comments

Posted by on June 24, 2011 in Culture

 

Tags: , , , , ,

Answering questions from the User Stories Webinar

Last week I delivered a webinar talking about building good user stories. We had nearly 200 participants from five countries. Thank you to everyone who took the time to register and participate.

I was unable to respond to every question as they were asked in the chat window, and we had to stick to the limited time we had available.

Fortunately we were able to record the questions so I could try to answer them after the event. Here are a sample of the questions with my answers. Where more than one person asked a similar question I have only recorded it once, and there are a few questions that I can’t answer publicly 🙂

There was one question about the work being done on the Agile Extension to the BABOK(tm) – is the working group only looking at techniques or at the broader framework?
We are examining all aspects of how Agile techniques impact on all aspects of business analysis activities. Keep an eye on the IIBA(tm) website for more details as the work progresses.

When we were talking about the Vision Box someone asked: Would going into detail like logo and other not destract the purpose of the vision meeting?
The logo and other details are not intended to be high-fidelity or precise, they are meant to provide a hook for the conversations and creation of shared understanding of the vision. Don’t get bogged down in the exact placement of graphic elements, fonts and Pantone colours – focus on the essence of the vision elements.

The discussion about Personas generated a few questions:
Could you please advise what tools and techniques we should use to ensure that we have identified all the personas?
There is no magic trick to this one, I’m afraid; you need to conduct a stakeholder survey and ask lots of questions – who are our customers, users, clients, victims, other interested parties. A question that I’ve found useful is to ask every participant in the workshops “who else should we be talking to about this thing”.

Should a regulator/ govt law maker be a persona?
In my experience external groups that provide constraints rather then functional aspects generally don’t warrant detailed personas (but they might be referenced in stories such as “as the compliance officer I want …so that we don’t lose our banking license”) if they will actually interact with the product then they deserve a persona and profile.

The Epic Model also generated a number of questions:
A few people questioned the “one person” aspect of the definition of an Elementary Business Process.
The description I use is that an EBP is something done “in one place, at one time, by one person” and it should achieve a specific result for the business. It will normally be part of a chain of events that result in the delivery of value for the consumers of our product or service. There are some EBPs that are not “one person”, often these are “small team” activities where a small group of people are working together to do a job. Some EBPs have no human interaction – these are fully automated activities. Examples of these two types of activity are – replacing a large window in a building (“replace a window” will be an EBP for a glazing company but some windows are too big for one person to replace alone) and the overnight charge for staying in a hotel (undertaken at say 2am every morning by a computerized process).

Someone questioned the amount of detail in the epic model – should this not be left for the detailed user stories?
Here I resort to the consultant’s standard answer “it depends” – if you are able to identify the primary objects and start to understand their relationships at the Epic stage then do so, but be very careful not to get bogged down in the detail. In my experience adding the objects at the Epic level helps clarify the overall understanding of the scope of the work to be done without increasing the amount of work and time needed at this stage in the overall process.

There were a few questions specifically about user stories and acceptance criteria.
Do user stories supplement or replace functional specification documents?
In my experience user stories are a far better tool than functional specification documents, especially when used in this Progressive Elaboration way. Most of the requirements are likely to change over the duration of a project so trying to lock down the detail early on simply results in more wasted effort as we make the changes later in the project.

User stories are deliberately kept light early on, and the acceptance criteria are only added to the story on a just-in-time basis, typically this is done a few days ahead of when the story will be worked on by the technical team. What goes into the acceptance criteria depends on what the team need – it could include screen wireframes or mockups, low-fi data models and other structural aspects. I feel you should always include the test design criteria, ideally in the Behavior Driven Development format.

Someone asked What is the difference between Use Cases and User Stories?
A Use Case is a combination of scenarios about how an actor will interact with the system, normally written in a structured “Actor does … System does …” format. A single use case normally includes multiple paths through the system (primary flow and the alternatives/exceptions) and is often built with the intent of defining the full interaction early in the project. This is far too detailed to be used early in the project.

Each row on the Epic Model could be a placeholder for a Use Case, and that model can be used to provide a list of Use Cases if you are using that approach.

A User Story is much smaller than a Use Case and the two are quite different.  A Use Case covers multiple interaction scenarios, whereas a User Story could cover a single scenario for using the resultant system.

Alistair Cockburn says that “a user story is to a use case as a gazelle is to a gazebo

When should the Acceptance Criteria be added to the User Story?

As late as possible, but not too late 🙂  The concept here is the “last RESPONSIBLE moment“.  There are some things which we need to consider early on in the project – typically these are the Architecturally Significant Non-functional Requirements that are very expensive to refactor if they are not built in to the product from the beginning.  The trick is to consider just enough and just in time without undertaking a lot of wasted effort.

Again – thank you to everyone who participated.  The audio recording and copies of the slides can be downloaded from the Software Education website.

Posted by Shane Hastie

 
Leave a comment

Posted by on May 30, 2011 in Agile, Webinar

 

Tags: , , , , , , ,

How technology changes our behavior

I’m a technology aficionado – the latest device, the newest toy, the cool new technologies appeal to me. I subscribe to technology magazines and enewsletters so I know what’s coming next, and am happy to debate the virtues of HDMI over WiMax, Blueray over Bluetooth and why 3G is just too slow! I don’t have to own every new gadget (just most of them), but I make sure I know about them.

Despite this I have always treated computing technology as just a tool – I describe a computer as “just a really fast pencil” and that’s how I’ve lived. Yes, we have four computers and two printers at home (one of the computers is a server), and I’ve had an email address since 1983 (unfortunately not the same one all that time), but the technology has not substantively changed how I run my life.

That changed in August last year when I got a Tablet device (an iPad) – insidiously this book-sized tool has significantly changed my behavior. I purchased it mainly to be a book reader – I’m a avid reader and travel a lot. On a recent trip to the USA I came home with 10kg of new books, and decided that maybe an ebook reader would be a good way to go. I researched the available devices, and decided that the iPad would probably suit me best as it opens up additional possibilities beyond just reading.

I had no idea just how much of a paradigm shift this device actually is. Yes, it’s a pretty good book reader, and you’re not limited in the format of what you read – I have five different reader apps on the device, and can read pretty much any format available today. At last count I had just over 150 books in my mobile library – saves a fortune in excess baggage charges :-). But the book reader has become only one of the uses for the device, and not the driver of change.

What has driven the change in the way I work is the ubiquitous phrase “there’s an app for that” – think of something you are interested in, or want to do, and there’s bound to be an app available to help you do it. Want to convert feet-per-second to Kmh – I use PC-Calc Lite (a fully fledged scientific calculator with over 30 conversions built in). Want to write a WordPress blog entry while traveling at 30000ft, use the WordPress app; want to know the current time in New York, or Bangalore – I use Worldclockr. Want to read today’s newspaper – The NZ Herald app let’s me download the news when I’m in a WiFi zone, and read it later (some of the other news apps use a live Internet feed, I like the offline capability of the Herald). Want to watch a Ted Talk – yep, there’s an app for that too, and this one let’s you download talks for viewing later (a really great way to get value from those endless hours spend in airplanes and airport lounges).

The beauty of these apps is the price – they range from free (most of those I mentioned above) to a few dollars. I think the most expensive apps I’ve purchased are Apple’s Pages and Keynote – and they were less than $20 each. At these prices you don’t bother with “try before buy” – just buy it and see if it does what you want. If it doesn’t do what you’re looking for the write-off is trivial.

This is the secret to the change in behavior – finally the promise of ubiquitous mobile computing is becoming a reality, and it’s affordable. I can check my email in an instant, no waiting for a boot up process. If I want to find directions to somewhere I tap on the Maps icon, type in the address and a comforting blue line shows me where to go, and estimates (pretty accurately) how long it’ll take to get there. If I want to chat with a friend in Israel, or a coworker in Dallas I load Skype and we can talk for hours (almost) for free. Yes, I can do these things on my laptop, but the instant on nature of the tablet means I can do so at a moment’s notice, and the lightweight form factor means I carry it with me without bother, there’s no need to stop and think, I just pick up the pad and am immediately productive, or entertained wherever I happen to be.

The tablet also has some capabilities that the laptop lacks – a built in gps and accelerometer tell me where I am, what direction I’m going in and (one of the best apps I’ve found) Star Walk let’s me hold the device up to the sky and shows me the names and descriptions of the constellations that are visible right now. Yes – I’m a geek, but you’ve got to admit that’s cool.

I remember the first “mobile” computer I worked with – the Osborne One Sewing Machine (they didn’t call it that, but those of us that lugged them around sure did) – I think it weighed 19kg, needed mains power, had 256KB of RAM, a tiny orange & black screen, a keyboard that folded down in the front and dual 5 1/4 floppy disk drives. And it was a steal at a mere $12000! Despite the weight (it was more “lugable” than portable) the freedom to take work to the customer site was liberating. Since the 1980s we’ve gone from lugables to laptops to netbooks and they have all been improvements, but the shift to the tablet factor, accompanied by the availability of a vast range of apps at affordable prices has really triggered a change for me.

I still use my laptop, mainly for work stuff, for bulk storage (150GB of photographs, backed up in 3 places), for presentation delivery and for writing long documents, but I’m finding more and more that I can use the tablet most of the time.

The tablet isn’t perfect, and I’m sure there will be significant improvements over the next few years. Mine hasn’t got a camera (almost reason enough for me to shell out for an iPad 2), and “battery anxiety” is a term I’ve become familiar with, if the battery level drops below 30% I start to get nervous, but I do get a solid 10 hours out of a full charge, plenty enough for a trans-Tasman flight; a USB port would be a good thing, so I can access external storage (those photographs on a portable hard drive). The competing operating systems mean that once you’ve chosen a device you are locked into that manufacturer’s offerings as the apps aren’t compatible between them.

We’re starting to see the low-price app model migrate to other form factors as well, and I wonder what impact this trend will have on the software development industry?

Music companies are having to adapt their business models to cope with digital distribution, and losing control over how their customers consume their music, are software companies facing the same challenge?

Are we going back to the days of the individual software craftsman building a product for a small audience that exactly meets their need, or will software development remain a teamwork activity. Will the software industry split into those building apps and products for the corporate environment using teams of people (probably using Agile techniques) and the solitary developer building a couple of apps, hoping that one will become the next Angry Birds? You can be sure large software organizations are looking at the app marketplace and drooling, will their business models cope with selling an app for $2.99, where they have been used to charging $2999.00?

What do you think, will tablet computing be a new paradigm or is it just the next small step in the evolution in computing?

“Live long and prosper” the tricorder is almost here!

 
1 Comment

Posted by on May 13, 2011 in Uncategorized

 

Tags: , , , ,

Learning from Baboons

I’m sitting on a plane flying from Wellington to Melbourne, and find myself urged to write this blog post.

I’ve just watched a National Geographic video called “Stress. – Portrait of a Killer” that I found really fascinating. It looks at research that has been conducted over the last 30+ years into where stress comes from and how it impacts us.

Stress related illnesses have a huge impact on our society today, and together make up the majority of the illnesses that kill people before their time.

I knew that, and was at least somewhat aware of a lot of the material presented in the documentary.

What leapt out at me were some of the conclusions, and a piece of research done by Robert Sapolsky.

Over 30 years he has followed a number of troops of baboons in the Serengeti and found typical baboon behavior (hierarchy driven, top-down, might-is-right, to win you need to beat everyone around you, etc.) which is equated to the behavior seen in many hierarchical human organizations; the documentary talks about the Whitehall Study that show the same stress responses in 20000+ civil servants in the UK as found in the baboon studies in the Serengeti.

Sapolsky recounts the story of one particular troop of baboons that suffered a tragedy about 20 years ago – illness wiped out all Alpha males in the troop along with many others. The animals that survived were the ones who were more cooperative than combative, perhaps it was because the “nice” baboons were the ones who would be cared for by others when they fell ill.

The fascinating thing is that this troop of baboons went on to become a grouping of “nice guys” where collaboration, grooming & feeding each other and supportive behavior is now the norm. When new males join the troop they bring with them their old hierarchical habits and it takes about six months for them to learn that “that’s not the way we do things here” and to fall in with the cooperative behavior.

Part of Sapolsky’s research involves taking blood samples from the baboons and he has found a significantly lower level of stress hormones in the cooperative baboons than in any other troop he has studied over the last 30 years.

He goes on to suggest that human beings could learn from these baboons and create a better society, in which collaboration, autonomy and cooperation are the norm, and as a result lower our stress levels and improve both the quality and duration of our lives.

Being a staunch Agalist I found this speaks to my fundamental beliefs about why Agile practices work – an Agile team is a collaborative environment, where people support each other and all “win” together, rather than competing for power and privilege. Certainly it has been my experience that effective Agile teams are nicer places to work, with generally less stress and greater levels of happiness.

What do you think – am I just an idealist, or can we turn our organizations into happier, more productive places?

 
2 Comments

Posted by on May 8, 2011 in Agile, Culture

 

Tags: , , , , , , ,