A number of SOA authors and analysts have been making their predictions for where SOA will be going in 2009. Common amongst them are the increasing use of small-scale bottom-up SOA developments, cloud meeting SOA (and maybe taking over some of its hype) and the adoption of open source as a way to cut costs as well as drive adoption.
Advice from Esther Derby, George Dinwiddie, Jo Geske, Mike Sutton and Ilja Preuss on how to make retrospectives better. The ideas include tips for the facilitator/Scrum Master and new ways to use the burndown chart.
Kevin Schlabach discusses using a "Snake On The Wall", a lightweight approach targeted at helping your team get a better handle on the things that are slowing the development process.
In the Wall Street Journal, Sam Culbert argues that annual performance and pay reviews are at best dysfunctional. He sees their primary purpose as "intimidation aimed at preserving the boss's authority and power advantage". Jeff Sutherland, Mary Poppendieck, ... offer alterantives
Agile teams may find it easy to talk about change during their retrospectives, but not so easy to make that change actually happen. Esther Derby, well-known thought-leader on the human aspects of software development, recounts an experience from her personal improvement efforts to illustrate this and offer a few suggestions on how to succeed with making change actually happen.
In this presentation filmed during Agile 2008, Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away. Tim has a personal perspective on Agile practices and shares from his own experience.
In this presentation filmed during QCon London 2007, Boris Gloger speaks about retrospectives. Agile development teams learn and improve by inspecting and adapting. High performing teams inspect and adapt not only their code and tests, but also their methods and interactions.
Andy Hunt's interview last month talks about his progression from pragmatic programmer to Agile development to his latest interest – Pragmatic Wetware. "Wetware is the stuff in your head. That's the thing between your ears that's really where all the action is – that's where all the software development actually takes place."
What are the typical problems that Retrospectives suffer from? What do we do to avoid them?
Scrum defines an impediment as "anything keeping the team from being more productive" and clearly stresses that teams establish means to remove them as continuously as possible. Joe Little proposes an impediment's scope may be better established as being anything keeping the organization from delivering value.
Even the very greenest of agile teams clearly recognize the word 'Retrospective'. But, alas, it is often overlooked that a retrospective may be a wasted effort if not used to initiate an actual improvement that the team follows through on. Jim Shore gives advice on how to make the most of your retrospective and reminds us of the activity's ultimate place in the agile heartbeat.
The involvement of customer in an Agile project is taken for granted, however in many situations, intentionally or unintentionally, the customer may not follow the Agile practices. An interesting discussion on the Extreme Programming group tries to decipher the situation and find possible solutions.
Trying to explain the benefits of Agile Software Development to your CIO? Does your boss want some outside validation? Esther Schindler asked more than 50 developers and Agile practitioners one question: "If you could get the boss to understand one thing, just one thing, related to agile development...what would it be? Why that?".
The 'Retrospective Prime Directive' is commonly used in retrospectives to encourage deep learning without recriminations. But what do you do when you *can't* agree that you "understand and truly believe" that everyone did their best? In this InfoQ article, a group of senior practitioners discusses the benefits and difficulties of using this practice.
What value do teams get from measuring velocity, beyond the ability to reasonably estimate commitments for the short-term future? J.B. Rainsberger proposes that teams spend less energy scrutinizing velocity and more energy thoughtfully identifying and eliminating areas of waste in their projects.