Tuesday, 26 November 2013

Characteristics of a productive development team

In Agile Fluency article, Diana Larsen and James Shore have mentioned that Agile teams develop through four distinct stages of fluency. They have defined one star, two star, three star and four star team based on the team Agile fluency. It is an interesting article. If you take all the attributes of one, two and three star team (I will not include four star as it is bit difficult to find a four star team) then you will see that they are the characteristics of a productive development team.
A good and productive development team needs to follow some kind of Agile methods. It may be Scrum or Kanban. Ideally they have a product backlog. They use retrospectives to find out what has gone well and also what hasn't gone well in last iteration. They should keep on doing what has gone well and at same time try to avoid what hasn't gone well. They should write good user stories. A good user story solves many misunderstandings since it involves you to interact with different stackholders of your organization.
Practicing Scrum or Kanban without test-driven development (TDD) is rubbish. Martin Fowler calls it FlaccidScrum. One of the characteristics of a productive team is that they write self testing code. It helps them to reduce their technical debt. Now many teams are also practicing behavior driven development (BDD) along with TDD, which is really good. Main point is, a good team should focus on values and qualities. It is about collective ownership or shared responsibilities.
A productive team simply just don't stop here. They automate their build process. They follow practices that are required to do continuous integration effectively.
Another interesting attribute of a productive team is frequent release. They release as frequently as possible. It helps them to get rapid feedback on new features they have added. These feedbacks are important to build the right product.

Sunday, 10 November 2013

Media Types

Contracts define how different parts of a distributed system should interact and media types play an important part in contracts.

 A media type is a combination of formats, processing model, and hypermedia controls.

We can use many standardized media type specifications or create new media types to fit our domain.
Standardized media types (e.g., XHTML or Atom) are well-defined and widely understood. Since many systems support these standardized media types, interoperability between them can be easily achieved by using them.
Custom media types help us to add application specific semantics on the top of generic media types handlers. Jim Webber mentioned a nice example in his blog about custom media type:
"For example, if you get an Atom representation, then you automatically understand (globally) how to interpret the atom:link links within; with a custom hypermedia type (... application/restbucks+xml) you automatically understand (within the Restbucks context) how to interpret links; but for application/xml you have no idea how to extract hypermedia controls unless you have some prior knowledge of the schema."
Reference: REST in Practice - Jim Webber, Savas Parastatidis and Ian Robinson