Was watching a rather interesting talk by the Wikispeed CEO  in the SDEC 12: Keynote.

So, we might have gotten to being agile, decades after, having taken a page from manufacturing. But surely, the software practices thereafter evolved much faster than its manufacturing counterparts. Now, however, it seems like the manufacturing world  should catch up soon . The presentation above talks about a whole lot things. Their process already seems to have embraced a lot of stuff we do, some adapted -

1. They call it eXtreme Manufacturing (XM)
2. Scrum - 7 day
3. Cross-functional teams
4. Swarming
5. Feedback - Showcasing often
6. Evolutionary design - starting with ugly&working&frugal products
7. Inter-changeable/modularized parts
8. TDD! and regression suites
9. Promiscuous pairing, even!! 

Wonder if it would be an interesting intro to the many non-IT clients we might encounter in the consulting world, I suppose - especially making the non-IT stakeholders see value in some of the practices we espouse? Not sure if these attempts are unique, but the extent to which these guys have adopted seems quite impressive - and then make it work? 100 mpg? 3-hour swarmed assembly? Awesome!

Seems like they also presented in Agile 2012 in Dallas - wonder what your takeaways were, if you were there.

Here is another, shorter, talk o TED by Joe Justice.

Below are couple of sample, real and typical job descriptions of business analysts, posted on career classifieds. What strikes you about these, at a casual glance? -

1. Sr. Business Analyst in a financial publishing house - "

• Collaborate with internal and external customers, software engineers, etc. to interview, research, analyze, and derive business, functional, and non-functional requirements for products.
  
• Translate business requirements into detailed functional and non-functional specifications.
• Contribute, as required, to the "look" and "feel" of the product including screen design, on-line text, and/or graphical user interface (GUI) consistent with company standards.
• Participate in the design and testing phases, including design and testing of prototypes and orchestration and sign-off on acceptance test results to ensure design integrity"
  

2. A pure play IT Business analyst - 
"

• Lead and facilitate the elaboration process for new system projects
• Analyze and design solution recommendations for system modifications/enhancement to meet the needs of the end users.
• Develop system requirement specifications for system projects and large strategic projects
• Act as an liaison between end users and IT departments
• Develop test plans and participate in system implementation of new or revised systems"

Do you see anything missing in the above? Of course, one could argue that the description is just as that particular firm wants it to be, and every firm has its own "right" role definition.  Be that as may, and in general, even if one may  say that the definition of a BA varies across the industry, are the descriptions still complete? 

Below is my mindmap of various areas that I think every Business Analyst needs to be looking at. The third level down (Brown) may be defined in context and specific to the prevalent practices, but are not the first two levels fairly generic? If a BA is not doing these, then can the resulting software product still be good? Consistently .

In my little  experience and in all the books that I have read (have read most on Retrospectives), I always see retrospective as a one-time event. There are many types of these though - a sprint/iteration retro, or a release retro, program retro - you name it.  Yet, though various in scope, they seem similar in structure - recounting experience for the duration that the retro covers. One uses various means to prepare the team, poll them for their thoughts, represent them in a visible information radiator and facilitate discussion. This is truly a great exercise that I have come to admire, that forms a wonderful feedback loop for the team.
Now, I have been trying to do this a little different recently - applying Systems thinking. How about, in the usual retro that you do, after collecting the various positive and negatives, you don't see them as individual issues but a chain of cause and effect. For every positive or negative, there is, if you seek into the audience another cause attributed - and soon you'd see an entire cycle emerge (Last build was slow - (why,  because) - the CI pipeline has become large  - (why,  because) - the QA had suddely added a lot of tests  - (why,  because) - we hadn't added enough functional tests earlier  - (why,  because) etc etc.. you see then the entire retro starts to make sense.

What do you think?