Following is a list of all interesting Agile posts that I contributed to InfoQ throughout 2009. Now what is interesting might be a subjective thing. I categorized interesting on the basis of those news posts from me which got high readership / higher number of comments as compared to other.
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.
A ScrumMaster as the name suggests is the guardian of the scrum process. He is a change agent supporting his team and socializing Scrum throughout the organization. He ensures smooth functioning of the team by eradicating impediments and keeping the team shielded from distractions. However, in certain scenarios, Agile teams feel that the Scrum Master is the biggest impediment.
Software testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test. However, this definition does not talk about sapience which brings about a subtle difference between testing and checking. Michael Bolton talked about this difference and the reason why there should be a difference between the two.
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.
The goal of refactoring and rewriting is to improve the sanity of the system by improving the code readability, structure and clarity. A clean code would be easier to maintain and enhance. However, on many occasions Agile teams have a tough time deciding between the two.
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.
Micromanagement, often has a negative connotation associated with it. It is a management style where a manager closely observes or controls the work of his or her subordinates or employees. Usually Agile development and micromanagement may seem to be opposite ends of spectrum however, they are more related than what meets the eye.
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.
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.
The term “technical debt” was coined by Ward Cunningham. It describes the obligation that a development team incurs when it chooses a design or construction approach that is easy to implement in the short run but has a larger negative impact in the long run. Agilists provide their view point on what should be considered a technical debt and how it could be classified.
Feedback is a situation in which an output from an event of the past has a potential relevance in the future. Agile places a lot of importance on soliciting and providing feedback with every step in order to build a quality product. On the other hand Feedforward is, to give someone suggestions for the future and provide help in terms of future direction.
Kanban’s aim is to minimize WIP (Work-In-Process), or inventory, between processes by making sure that the upstream process produces parts only if its downstream process needs it. Of late, Lean and Kanban are growing in popularity. More and more companies are setting up Kanban Boards, limiting WIP and eliminating Muda. Michael Dubakov investigated the wrong and right reasons for applying Kanban.
There is a constant, long drawn debate on the benefits of using either story points or hours for sprint planning. Mike Cohn is big on breaking User Stories down into tasks, which are then estimated in hours. Jeff Sutherland on the other hand suggested that some of the best teams that he has worked with burn down story points.
Context Switching is defined as changing focus and attention from one task to the other in relatively short periods of time. It is widely considered harmful for the team member and the project that he is working on. Charles Miller mentioned a few ways of how they handle context switching at Atlassian.
Agile retrospective helps the team examine what went well during the past sprint and identify the areas of improvement for the future sprints. However, sometimes the exercise of conducting a retrospective ends up as a futile effort due to lack of preparation. Moreover, key members of the team end up either not attending or not participating in the meeting.
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.
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.
Knowledge transfer is characterized by transfer of understanding, about a context, from one unit (individual, team, department, organization) to another. In a series of interesting experiments, Steve Bockman tried to figure out the best way to transfer knowledge in an Agile project.
The Agile Manifesto suggests “ Working software over comprehensive documentation”. This has led many teams to believe that there is no need for documentation in Agile projects. Critics of Agile use limited documentation in Agile to showcase the weakness of Agile methodologies. Eelco Gravendeel suggested that there are just two types of documentation in Agile.
An implicit assumption made by most Agile teams is that ‘value’ is directly proportional to the ‘velocity’ of the team. While this may be true in some cases, however mostly, the team velocity gives little indication on the true value delivered.
Backlogs have been under constant criticism for quite some time now. Mary Poppendieck suggested that the product backlog should be eliminated if it is not satisfying the desired purpose. Serge Beaumont suggested an interesting way of partitioning the backlog such that it maps to a flow and makes the backlog worthy for existence.
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.
Self organization is defined as a phenomenon in which the internal organization of the system increases in complexity without being guided or managed by an outside source. However, successful self organization needs the right level of support from not only the team members but also the management and the organizational environment.
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.
Mostly usability of a system is ascertained on gut feel rather than being based on some statistical analysis. In a recent discussion on the Agile Usability group, members discuss various ways to evaluate system usability in an objective manner.
Politics is an integral part of all organizations.Generally, technical people have a distaste for politics because technical matters are mostly precise and can be stated in black and white where as political matters generally involve shades of gray, which are not always easy to decipher. Recently, members on the Scrum Development group discussed ways to deal with politics.
In a presentation about Shock Therapy, Jeff Sutherland mentioned that Hyper-Productivity is at least Toyota level of performance which is four times the industry average. In a recent discussion on the Scrum Development group, members debate whether it is both fruitful and possible to accurately measure productivity across sprints.
This post is a compilation of recommended Agile books by various Agilists. The recommendations try to cover the entire spectrum of process, people and technology related to Agile. The idea is to make the process of Agile adoption easier and fruitful.
Recently, Dave Nicolette consolidated a list of recommended TDD tutorials from a discussion on the Extreme Programming group. Here is a sneak peak at the consolidated list with categorization for quickly getting started with Test Driven Development.
The daily scrum is an important meeting within the Agile team. According to Scrum, only the pigs are allowed to speak during such meetings and chickens should just listen. Is there a limit on the maximum number of chickens, who could attend the daily scrums?
The need for dedicated testers on an Agile team has been long discussed and debated. In many Agile teams dedicated testers play a pivotal role where as in others developers double up as testers. A recent discussion on the Scrum Development group tries to revisit the need for having a dedicated tester on the team.
The daily stand-up meeting helps the team members make a commitment to each other about what they aim to achieve in the day and identify obstacles to progress, if any. However, many Agilists believe that the conventional stand-ups break down quickly as the team size increases.
There have been a lot of discussions and debates about the optimal team size for maximum productivity. While most Agilists agree that smaller teams are more functional and productive as compared to larger teams, however defining the optimal team size is still a challenge.
Many Agile teams face a dilemma when picking up a new story towards the end of a Sprint. There is some time left but this time may not be enough to get a story done-done.
One of the frequent questions in Agile adoption is related to the ideal iteration length. Teams usually gravitate between iteration lengths ranging from a week to two months. Choosing the right iteration length is an important decision and the success of Agile adoption depends a lot on the right iteration size.
Performance Engineering is an important software development discipline that ensures that applications are architect-ed, designed, built and tested for performance. However, mostly in traditional projects the scope of performance engineering is limited to performance testing. This is a sure cause for concern.
Traditional project governance is used to describe the rules and processes that need to exist to ensure a successful project. At first glance the concept of governance and Agile seem to be incompatible however, most Agilists would agree that just enough governance might do more good than bad for the Agile project.
Mapping traditional software development roles to just the three roles in Scrum can be challenging. Mike Cottmeyer attempts to provide an effective mapping which would help the teams.
Backlogs have been under criticism for some time now. Mary Poppendieck goes to the extent of suggesting that product backlog should be eliminated if it is not satisfying the desired purpose. On similar lines Jeff Patton suggested using story maps instead of flat backlogs which help focus on the system being developed.
Risk management is an activity directed towards the assessing, mitigating and monitoring of risks. Agilists suggest ways to effectively manage risk and use it to make better commitments to the stakeholders.
Unit and Integration testing often get more importance in Agile teams as compared to acceptance testing. Gojko Adzic and Lisa Crispin suggest approaches to efficiently include acceptance tests as a part of development.
A major goal of sprint planning is to make a commitment to what is intended to be delivered by the end of the sprint. However, many teams either over-commit or over-deliver. Both situations are considered as smells and lead to lack of predictability along with other related pitfalls. The team is required to walk a fine line between the two.
Traditionally, software release is considered to be a handshake between engineering and business where a release made by engineering is passed on to the external world by business. In an interesting article, Israel Gat suggested the reason to split the software release into ‘internal’ and ‘external’ release, for the benefit of both engineering and business.