InfoQ Homepage Best Practices Content on InfoQ
-
Most Effective Team Structure
Agile talks about small team sizes with the magic numbers of 7 plus minus 2. Agile also recommends whole teams. Whole team is a concept that advises for having sufficient skills within the team itself to get the job done. Thus the development team has the testing skills, database skills, user interface skills, apart from the core development skills. Is defining the team structure this easy?
-
Rules for Better Retrospectives
James Carr recently published a list of five rules to help improve the effectiveness of retrospectives. The rules are based on his experiences in hundreds of retrospectives, both successful and not.
-
Comparing Velocity Across Teams
A common project management criticism is that since the story points vary across teams, there is no way to ascertain one teams progress with respect to the other. Amongst Agilists there is a general consensus that comparing velocity across teams is an anti pattern and is best avoided lest the overall productivity should suffer.
-
Overlapped or Synchronized Sprints?
When a Scrum project grows, so do the team members. The suggested way of managing a growing team is to split the team into multiple teams keeping in line with the Agile recommended team sizes. However, there could be multiple communication and coordination problems when each team starts working in a sprint of their own.
-
Reasons for Delay in an Agile Project
A delay, in general, is getting something done later than it was scheduled for thereby causing distress and inconvenience. Likewise, a delay is considered to be a waste in the Agile terminology. A delay causes discontinuity and thereby causes other wastes like relearning, task switching etc. A few Agilists discuss the common delays and ways to resolve them.
-
When Agile Success is Eventually a Failure
It is often assumed that once the pilot Agile teams are successful, the process of Agile adoption is on the right track. Dave Nicolette shares very intriguing insights into situations where the adoption failed even after very successful pilot implementations.
-
Tips to Select a Pilot Project for Agile Adoption
One of the most important factors which influences the success of Agile adoption is the set of learnings derived by applying Agile to a pilot project. These learnings significantly influence the organization to go ahead with Agile or fall back to their usual process. A wrong type of pilot could end up aborting, which would be a poor advertisement for the new process.
-
Who Moved Our Project Stakeholder
A project stakeholder for an Agile team is a person having a valuable stake in the success of the project and could also be potentially holding the cash strings for the project. However, sometimes it is very difficult to get time slices from the project stakeholder. In other extreme cases, the stakeholder might seem to be uninterested or completely missing in action.
-
26 Hints for Successful Agile Development
Keith Swenson, recently compiled a list of 26 hints for Agile software development. Keith suggested that he frequently collects nuggets of wisdom on various topics and the list is a distilled set of hints which really matter for Agile software development.
-
97 Things Every Programmer Should Know
The 97 Things series continues, after the architect and the project manager, with things every programmer should know. InfoQ talked to its editor Kevlin Henney.
-
Handling Project Termination
Terminating a sprint in Scrum is a rare event, but it does happen. An abnormal sprint termination can be called by either the team or the product owner. Most of the times terminating a sprint or the project leaves a sense of bad feeling. Robert K. Hurley and Joseph T. Jimmerson discussed the ways to deal with the trauma of a terminated project.
-
Measuring Agile Performance with the Agile Triangle
Traditional software development teams were supposed to work within the confines of the software 'Iron triangle'. The three sides of the triangle are Scope, Schedule and Cost. Jim Highsmith suggested that the Iron triangle, imposes a lot of constraints on the flexibility of the Agile teams and suggested an alternate Agile Triangle.
-
Slow Down to Speed Up Profits
General understanding suggests that, if everyone on the team works at top capacity then the team would be most productive. Contrary to this, Steve Bockman discussed that this assumption might not always be true. In some cases, it may be necessary to slow down and work at less than top capacity in order to boost productivity.
-
Rescuing Your Ruby on Rails Projects
Ruby on Rails has been around for about 5 years and in those years developers have created a lot of applications. Many of those applications were created while learning Ruby and Ruby on Rails and may not have used the best practices but yet made it into production web sites. These web applications can be problematical but a new book focused on the solution is available.
-
Resource Management in Agile Projects
Agile projects are known to address the problems of rapid change. These may be changes in market forces, system requirements or implementation technology. One of the change, that does not gel well with Agile projects, is the frequent change of people working on the project. The idea is not to disturb the high performing teams so that they can continue to deliver high velocity.