Show mobile menu

Blogs

Lots of our people have lots of opinions. Here are just a few of them

ThoughtWorks embraces the individuality of the people in the organization and hence the opinions expressed in the blogs may contradict each other and also may not represent the opinions of ThoughtWorks.

Agile and User centred design

Can they work together?

read more

Blog post by ThoughtWorks Studios
21 May 2013

Original Link

Agile and User centred design

Can they work together?

read more

Blog post by ThoughtWorks Studios
21 May 2013

Original Link

Creating automated test scripts with Ruby and WATIR

To document the general process of creating automated test scripts for web applications with Ruby and the WATIR testing module. The intended audience of this document is QA engineers/testers that are going to be either creating automated test cases for their applications or testers that are going to be running and maintaining already created tests. This document assumes that the reader is already familiar with the basic methods and syntax of the Ruby language and the components of an HTML based application (links, forms, JavaScript, etc..)

 

read more

Blog post by ThoughtWorks Studios
21 May 2013

Original Link

Facilitating Collaborative Design Workshops

 

A step-by-step guide for rapidly creating a shared vision for execution

So how do you do great design in a rapid, multidisciplinary and inclusive way? How do you set up new projects for success in a fast moving, agile environment? How do you ensure shared understanding and ownership of new initiatives in just a few days?

 

I now focus a lot of time on facilitating collaborative design workshops, and other methods focused on quickly creating a shared understanding of objectives and buy-in for and execution approach.

read more

Blog post by ThoughtWorks Studios
21 May 2013

Original Link

photostream 46

Longwood Gardens, PA

Blog post by Martin Fowler
21 May 2013

Original Link

Expansion to DIP in the Wild

Brett’s article on the Dependency Inversion Principle (DIP) and how it works in practice has been a popular read on this site (over 24,000 views since it was published at the beginning of the month). Brett has now expanded the article with two more examples from his delivery experience: questioning requirements and handling time.

Blog post by Martin Fowler
21 May 2013

Original Link

the 4 Ls: Liked – Learned – Lacked – Longed For

The 4Ls is a great data gathering activity for recurring retrospectives. The Ls stand for: liked,  learned, lacked, and longed for.

Running the activity:
1.   Split the canvas in4 areas (or use 4 posters:
  • Liked – things you really liked
  • Learned – things you have learned
  • Lacked – things you have seen the team doing, but consider that could be done better.
  • Longed for – something you desired or wished for
2.   Ask the participants to individually write notes on post-it for each of the L areas.
3.   Group conversation about the notes

This activity

Blog post by Paulo Caroli- Agileretroactivities
20 May 2013

Original Link

Using points is not the point

I have done 3 projects in a row where we did not use story points and simply counted stories. I’m a big advocate of that approach. Let me explain why.

I'm an estimation geek who loves the nuances of estimation, and have used function points, use case points, COCOMO, and story points for over 10 years. Over time, I’ve become convinced that the more we estimate past the very initial point, the less accurate we get. Additionally, long-drawn, “scientific” estimation exercises generate wrong expectations of certainty.

Thumbnail: 

Blog post by ThoughtWorks Studios
20 May 2013

Original Link

My Life with Code Reviews

In a previous life, at an R&D engineering company, there was a comprehensive culture of code review. I saw three different approaches across three teams while I was there.

The first team was a mix of embedded systems and embedded applications. This team had a very strict, very rigourous code review process. Every task had an associated review. All reviews were pre-commit (completed before merging work into trunk.) Reviews typically had two reviewers. Reviewers were assigned by the tech lead, based on a combination of appropriateness and load. All reviews were conducted using a dedicated newsgroup (remember those?)…

Blog post by Giles Alexander
19 May 2013

Original Link

Coming to Angular from something else

There’s a recent blog entry on the ArtLogic.com site about learning Angular. One aspect of it resonates with me:

“Quit jQuery for a While”

It’s true. You could well be used to having ‘on click’ equivalent event that mutate the DOM, and think that you could well mutate Angular models instead. That’s the path to more JavaScript than you need, and you’ll never know the low/no JavaScript idiomatic to Angular at entry-level.

I think of it this way: With Angular, model objects (POJOs) can drive views without JavaScript being involved. Similarly, views (via Angular’s expressions/bindings…

Blog post by Paul Hammant
19 May 2013

Original Link