BT

InfoQ Article: Reflecting on Success: Good Agile Karma

| by Deborah Hartmann Preuss Follow 0 Followers on Jan 25, 2007. Estimated reading time: 2 minutes |
When working as a team, the effects of our words and actions actively create, and re-create over time, the environment in which our teams and projects operate. Why do some projects shine, while other spiral downward? The answers are as complex as teams are different.  The tool for really answering this is the retrospective, wherein we can determine not only what went wrong... but also what went right, things we want to reinforce and continue doing. This article InfoQ article, Good Agile Karma, elaborates on an October blog entry by Gunjan Doshi, of which he said:
Agile teams crank out lot of code in short time. I have seen that if teams are not reminded they tend to slip back to their old habits. I created a list for our teams to keep their agile karma good.
Some teams use retrospectives to focus on what's broken with their process, skipping over the questions "What went well" and "What do we want to continue doing?"  The article suggests that opportunities for success may be lost when teams don't reflect on their best contributions to process.  Borrowing an idea from an ancient tradition, Gunjan Doshi and Deborah Hartmann use the idea of Good Agile Karma to look at the ways in which consistent team behaviour can enhance both project success and individual work satisfaction - and help sustain the experience, which is always a challenge. 

Agile Karma: the cosmic principle according to which the experience of project participants improves or degrades in each iteration according to their actions (or failure to act) in previous iterations.

Their idea is that teams should take the time to identify and celebrate the things they do "right" - the things that enhance Agility.

As we keep practicing Agile disciplines like pair programming, TDD, and plannning with User Stories, we build up a web of interrelated, mutually reinforcing behaviours which together yield more than the sum of their individual parts. These can have more far-reaching effects than we might at first have imagined. Once we have experienced some of these compounded benefits, the question is how do we sustain the benefits and keep improving? The tool for answering this is the retrospective, wherein we can determine not only what went wrong... but also what went right: things we want to reinforce and continue doing.
Good Agile Karma looks different for different teams, and for different players on the team.  This article simply presents some examples of Good Karma, in the eyes of the authors, and invites teams to develop their own list.

Read Good Agile Karma.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Project Manager role by Paul Oldfield

There are many variants on this role. I usually suggest the common denominator is that the PM provides the team with resources and priorities, and takes away from the team obstacles and results.

Re: Project Manager role by Michel Löhr

Normally Project Manager is not a role but a function.

Regarding to Scrum, the Scrum Master should be the Project Manager, e.g. there should NOT be an extra Project Manager next to a Scrum Master. Because in Scrum tradional project management has shifted into coaching. Anyway look up a description of the Scrum Master role.

Re: Project Manager role by Deborah Hartmann

> Regarding to Scrum, the Scrum Master should be the Project Manager

Depending on your definition of PM, true enough. On the other hand, in some environments, where Agile is a really different paradigm from the status quo, a ScrumMaster can really use a "blocker" in management, to tackle sticky organizational obstacles and let the ScrumMaster get on with the work of helping Product Owners and Teams deliver software. I guess I'm thinking of a "champion" role... sometimes it's helpful to turn the PM into this champion, and put a a second person in the ScrumMaster role. Hopefully, over time this duality is resolved and one of them can move on to new challenges :-)

Again, how you define PM influences what happens to the PM role when you go Agile, imo.

deb

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT