Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Deborah Hartmann on Jun 04, 2007 11:10 AM
Retrospectives are a tool that a team can use for positive change to shift from following a process to driving their own process, becoming self-managed. In this article, Rachel Davies, a founding member of the UK's XP community, offers help for teams who have ideas for improvements but aren't sure how to get them off the ground. This article covers the steps required to run a retrospective and implement its results.Expecting magic to happen just by virtue of bringing the team together in a room to discuss recent events is unrealistic. Like any productive meeting, a retrospective needs a clear agenda and a facilitator to keep the meeting running smoothly. Without these in place, conversations are likely to be full of criticism and attributing blame. Simply getting people into a room to vent their frustrations is unlikely to resolve any problems and may even exacerbate them.Davies proposes that thoughtful facilitation can help teams fearlessly talk about past experiences without resorting to blame. Strategies include setting ground rules, using the "retrospective prime directive" and allowing team members to attend voluntarily.
The power of regular retrospectives and regular exercise is that they prevent big problems from happening so there should be no war stories or miraculous transformations! Embracing retrospectives helps a team find tune their process at a sustainable pace.Read the InfoQ article: How To: Live and Learn with Retrospectives by Rachel Davies.
Effective Management of Static Analysis Vulnerabilities and Defects
Give-away eBook – Confessions of an IT Manager
Ebook: Scaling Agile with C/ALM
My (nurse) wife pointed out to me that a retrospective at the conclusion of a successful project should really be called a post partem because there was a birth, not a death. (And usually everyone feels like they've got the baby blues from the end of project stress.) It's also a more positive term. Post mortem is pretty morbid sounding.
I think part of the point is that having these exercises *only* at the end of a project is a bad thing. So from an agile perspective the analogy is not a bad one. By the time you get to a 'post-mortem' it is too late to make the necessary changes needed to save the project/patient...
I think that ther is a big difference between a retrospective and post-mortem. We do our retrospective after every 2 week sprint, and they work great, we tuned our development process and had some good success stories...
Great idea! :-D
Tell that to Rosemary and her baby :) Anyway, the trick (at least for me and Michał) is to review you process (and the iteration itself) just after the iteration. And even this way, the post-mortem still applies - after all who wants to miss the traditional blame party, when everyone goes home full of digitals from the finger pointing special moment ? Jokes aside, (for me) usually this practice must be introduced in a covert way, to not be perceived as an 'audit' by the team - the first 'sessions' often go great after a (no so) few beers during a happy-hour....
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
5 comments
Watch Thread Reply