A rule generally refers to the defined standards for an activity. It is required to be adhered to. In other words, a law, may informally be called a "rule". Guideline on the other hand attempts to streamline a particular process according to a set routine. By definition, a guideline is never mandatory.Should Agile teams talk about rules or can we have just guidelines?
Once all your teams use Agile and are busy implementing local improvements, what happens to the larger organization formerly called "IT" or "Systems Development"? A coach with a large Agile program shared the strategy they designed to let the larger community spot trends and benefit from all this learning. Paulo Caroli calls it "Retrospective of Retrospectives".
In this interview filmed during Agile 2008, following the presentation "Who Do You Trust?", Linda Rising shows how prejudices can affect the relationships between team members. According to Linda, we all have a tendency to categorize others based on characteristics like race, religion, sex, but also based on more trivial characteristics, and many times we are not even aware we are doing it.
Having difficulty prioritizing the backlog? Luke Hohmann has described a method to make quantitative decisions about which backlog items should be considered first. In addition to the usual attributes such as implementation effort, Luke suggested adding attributes to measure stakeholders needs, strategic alignment and to ask whether the item is driving profit.
Struggling with Agile Adoption? Amr Elssamadisy ran a session on what makes adopting Agile processes difficult. He provided the audience with three models for understanding the problems seen during adoption.
The relevance of a traceability matrix is to easily perform impact analysis to a changed requirement.However, does a traceability matrix have a place in an Agile project? The post looks at various view points across blogs and mail groups to find a solution.
Joseph Pelrine has come full circle: from university studies in Psychology, journeying through SmallTalk, XP and Scrum, and now back to broader questions: Why and how does Agile work? In this interview, Joseph talked about Complexity Science, and how story-telling, "sense-making," network analysis and speed-dating's gut-feel approach may prove more useful than our old toolkits for managing teams.
At NFJS Venkat Subramaniam, co-author with Andy Hunt of "Practices of an Agile Developer," shared his pragmatic approach to some of the important technical and non-technical factors contributing to project success, including: coding, developer attitude, debugging, mentoring and feedback.
What does it take to create a high-performing team? According to Doug Shimp and Samall Hazziez, a "Well Formed Team" exhibits the following characteristics: follow Agile and Lean principles, use an adaptive system with a feedback loop, are focused on the business vision, are passionate and hyper-productive.
Kirk Knoernschild shares his thoughts about Design and Code reviews. He mentions that such reviews promise to improve software quality, ensure compliance with standards, and serve as a valuable teaching tool for developers. However, the way they are performed affects their value. In some organizations they might really add whereas in others a review might just be a part of the bureaucracy.
Sometimes, management encourages adoption of Agile but fails to help remove the overburden that cripples teams and keeps them in non-productive patterns. In his article, Roman Pichler looks at the "3 M's" of Lean, and how the concept of removing "muri" (overburden) provides help for Agile adoptions, by encouraging teams to give up wishful thinking and commit to their actual capacity.
It's easy to agree with "anything more than 'barely sufficient' in is waste," but it's more complicated when we actually need to customize a process for a particular project. At Agile2006 Todd Little shared a model to help leaders choose the right flavour of Agile based on project and team attributes, and he emphasised the need to actively steer projects as development progresses.
Guest interviewer Jim Coplien chatted with "Pragmatic" Dave Thomas at QconLondon 2007, covering everything from 'agile' publishing and academia to staying limber with code katas. Dave's career advice: Cultivate the passion of a 5-year old!
In the beginning Agile was largely a developer-driven initiative, sometimes improving development processes only to find the real bottlenecks lay outside developer control. In his latest InfoQ article, Kenji Hiranabe analyses Lean manufacturing's "Kanban" visual tracking tool, how it differs from the Agile taskboard, and how it helps identify more far-reaching improvements.
Partnership Coach Michael Spayd tells us that both contractors and permanent employees can find themselves playing a "consultant" role, and should consider using consulting contracts or "designed partnerships" with their clients - not regarding the exchange of money, but to create a climate for stellar results for the client, while also communicating their own values and preferences.