RSS

Monthly Archives: September 2009

Evolution by Diana Larsen

Diana Larsen is the current chair of the Agile Alliance, and will be a speaker at the SDC conference in March.  In this month’s Agile Alliance newsletter she posted the following discussion under heading “Evolution”.

Republished here with Diana’s permission – Thank you!

** Evolution **

After Alistair Cockburn’s opening keynote address at Agile 2009 “I’ve Come to Bury Agile”, I’ve been thinking even more about the evolution of organizational ideas. This topic piques my interest on a recurring basis, so this time I thought I’d see what I could find out about organizational movements, a.k.a. “management fads.” In other words, how do new thoughts about the best ways to do work emerge, evolve, grow and become common practice? I found some clues in an article, “Management Fads: Emergence, Evolution, and Implications for Managers” by Jane Whitney Gibson and Dana V. Tesone (fromThe Academy of Management Executive (1993), Vol. 15, No. 4, Themes: Business Strategies and Employee Development (Nov., 2001), pp. 122-133).

Gibson and Tesone quote B. Ettore’s life-cycle theory of management fads to describe five phases of evolution: discovery, wild acceptance, digestion, disillusionment, hard core, with each phase lasting anywhere from 2 to 15 years. At the time of publication, for instance, they suggest that self-managing teams in manufacturing had only reached the digestion phase, after about 20 years of managerial awareness.

They provide a checklist for deciding whether a “management fad”, let’s say Agile for instance, has staying power to adopt it for your organization:

Has [Agile] been around long enough to have a proven track record?

Does the goal of [Agile] complement the needs of the organization?

Does implementation of [Agile] mesh with the organizational culture?

Will adopting [Agile] help the organization remain competitive?

Does the organization have the resources needed to implement [Agile]?

Do the expected benefits of [Agile] outweigh the direct and indirect costs?

Can [Agile] be implemented in small sections of the organization to test the new concepts with minimum risk?

Has the organization’s track record with previous fad adoptions been positive?

Can you wait for the long-term benefits of [Agile] adoption?

Can organizational inertia and resistance to change be managed to successfully implement [Agile]?

Do you have a choice?

Gibson and Tesone conclude, “Management fads…are cyclical in nature. They start out quietly, attract a lot of attention, spread through expanding adoption by people who want to be in the in crowd, then often fade into obscurity as the adopters tire of the fad and the effort required to maintain it. Some fads, however, are so useful that they become mainstays of our repertoire.”

Does any of this sound familiar?

Best regards,

Diana

Agile Alliance Logo

Agile Alliance Logo

Advertisements
 
Leave a comment

Posted by on September 23, 2009 in Agile, Culture, SDC 2010

 

Agile Development: A Manager’s Roadmap for Success

Hi all,

I found this link  today on Software Quality.com

Agile Development: A Manager’s Roadmap for Success:
http://go.techtarget.com/r/9265705/9110836/1 .

It makes lot of sense to me

Posted by John Watson

 
 

Agile 2009 Session Recordings

InfoQ has put together a number of articles and sessions from the Agile 2009 conference at http://www.infoq.com/Agile2009 

Scott Ambler’s survey results are very interesting and Alistair’s keynote is great!

Posted by Shane Hastie

 
Leave a comment

Posted by on September 18, 2009 in Agile 2009

 

STANZ 2010 – Who and what???

Someone recently asked me “if you could ask any person anything, who would you ask and what would you ask?” This was very thought provoking…and reading the discussion on the STANZ LinkedIn Group made me think about it too. Who and what? To assist I cast my eyes over my bookshelf, blog list, and magazine subscriptions.
Who would I ask and what would I love to hear them talk about?

Rex Black – metrics – best ones, quick wins, most effective

Michael Bolton – metrics – as above (I love to hear the variety of approaches)

Dot Graham – Automation

Capers Jones – estimation, metrics again (am I boring??)

Lisa Crispin &/or Tip House – testing agile!

Karl Wiegers (I know he does requirements – BUT….) – how to test requirements

DeMarco & Lister – Peopleware is a FABULOUS book – more on the soft skills and understanding how testers can work better.

Critical Thinking….anyone who can talk about how to expand my mental horizons and think “outside the square”.

Wow…and the list goes on!

Who would you ask, and what would you ask?

posted by Sharon Robson

 
Leave a comment

Posted by on September 17, 2009 in Project Management, Quality, Testing

 

Tags: ,

36 Testing Heuristics

I was able to see James Bach at STANZ  2009 and one of his slides REALLY stood out. He called it the Thirty-Six Testing Heuristics, and he uses it as checklist or reminder of the key things that need to be considered in testing anything. Sounds good huh? Well here we go:

cidtestdsfdpotcrusspicstmplfdsfscura

Everyone got that? Any problems understanding? LOL – it is just a quick way of listing the following things…a checklist to help focus your thinking:

Group 1 – cidtestd = Customers, Information, Developer relations, Team, Equipment & Tools, Schedule, Test Items, Deliverables. These are the high level planning activities, the logistical and the “set-up” focus of the testing. This helps set the context in which the testing will be done.

Group 2 – sfdpot = Structures, Functions, Data, Platforms, Operations, Time. I also heard Karen N Johnson refer to this acronym as San Francisco Depot (SFDPOT). This allows you to understand the environment that you will be testing in, in terms of scope, resources and time – the key arms of the quality triangle. This is a vital part of testing in my opinion and one that we often forget to consider in detail.

Group 3 – crusspicstmpl = Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatability, Supportability, Testability, Maintainability, Portability, Localisability. This is a great list of the quality characteristics of a system. I prefer ISO 9126 (it is shorter!) but this one gives excellent coverage of the key attributes that will need to be considered for any system. I really like the use of the “ity” at the end of almost all of these – keeps me focused on qual”ITY”.

Group 4 – fdsfscura = Function Testing, Domain Testing, Stress Testing, Flow Testing, Scenario Testing, Claims Testing, User Testing, Risk Testing, Automatic Testing. This list of the types of testing that may, could, should be done on a test project allows us to understand and explain that there is more than one way to test something, and to do it better we need to understand WHAT and HOW we are trying to test something.

Why do we care about this stuff? Well….I often find that people struggle to understand the “entirety” of testing…ie, all the stuff that needs to be considered when we do testing. This helps to outline it to people!

I recently presented a paper on Agile Test Estimation – and mentioned this aspect as well. No matter what lifecycle we are using – these things still need to be considered. And having an impressive party trick like this may just be the answer!

This is a great list, and I am going to be trying hard to remember it. If you see me, see if you can get me to repeat it and if I get it right!

posted by Sharon Robson

 
1 Comment

Posted by on September 17, 2009 in Quality, Testing

 

Tags: , ,

We always knew it . . .

Multitasking gets in the way of effective performance.  It’s something “everyone knows” and now there’s proof.  Deborah Hartman Preuss posted a news item on www.infoq.com that talks about a Stanford University study that investigated the impact of ongoing multitasking has on productivity and effectiveness. 

The conclusions:

Researchers were particularly surprised that what they called “heavy media multi-taskers” performed worse on a test of task-switching ability, “likely due to reduced ability to filter out interference from the irrelevant task set.”

This study again confirms what cognitive scientists have said all along: processing multiple incoming streams of information is considered a challenge for human cognition.

The article can be found at http://www.infoq.com/news/2009/09/study-multitasking-performance and the Stanford study at http://www.pnas.org/content/early/2009/08/21/0903620106.abstract 

This is a message that “everyone knows” but so often gets forgotten in the workplace.

Posted by Shane Hastie

 
1 Comment

Posted by on September 13, 2009 in Quality

 

Tags:

More on Agile 2009

I’ve made the long journey home from Chicago, 30 hours of purgatory in airports and airplanes; the only redeeming factor was it gave me time to contemplate the conference.

I was really pleased to see the comment from Alistair with the link for his slides – Thanks! (See his comment on Tuesday’s session for the URL).

The conference theme was “Making Agile Real” and I came away with the strong feeling that Agile is THE way of working in Information Technology today.  The conference tackled some of the significant challenges facing the Agile movement as we move from “small teams in small rooms tackling small projects” to organisation-wide adoption across indistries from government to manufacturing to financial services to medical systems. 

One of the impacts of this level of adoption is the need to tackle problems which had previously been considered to be outside the realm of Agile, including distributed team projects, very large teams, alignment with CMMi levels (up to Level  5), working in heavily regulated environments and life-&-safety critical projects.  The conference had sessions addressing all of these issues.

Another trend is recognition that some “design up front” is actually a good thing on many projects, and that most projects cannot afford to ignore architecture.  Finding the “just enough” point for architectural decisions – how much to do up front, and how much can be deferred until later, will be a key success measure in software projects.

Role and skill changes are also needed in the software testing area – testers on Agile projects need to have more technical skills, in order to contribute more effectively and utilise the tools for TDD (Test Driven Development to provide advice and input to developers building unit tests) and ATDD (Acceptance Test Driven Development).

All team members need to become more comfortable working across multiple disciplines and the “soft skills” of communication, empathy and collaboration will be more important to project success than purely technical skills.  The era of the lone programmer working in a cubicle without talking to anyone is fast coming to a close.  “T-shaped” cross functional skills are necessary for modern software development teams.

 
Leave a comment

Posted by on September 5, 2009 in Agile 2009