Good Agile Karma

Posted by Gunjan Doshi & Deborah Hartmann on Jan 25, 2007 03:01 AM

Community

Agile

Topics

Teamwork,

Change

Tags

Continuous Improvement,

Planning,

Retrospectives

It has been few months since your teams started using Agile or aspects of Agile process. Everyone in the organization is very happy with the rollout: developers, product managers, information architects, QA, upper management. You think your team has developed an optimal process and can now cruise on auto-pilot. Not so fast! If you're not careful, the party could be over sooner than you think.

This article will focus on behavior patterns that enable teams to realize the most benefits of Agile rollout and sustain the experience. This article assumes that you have already implemented Agile process in your organization.

Successful practitioners will have noticed that Agile relies heavily on discipline, rather than genius. For this reason, there is an emphasis on the practice of the basics: putting people first, focusing on value, delivering high-quality work frequently, and reflecting regularly to continue improving. Average teams, even in the early stages of Agile implementation, can achieve dramatic performance improvement if they are disciplined. As we do these things, the effects of our words and actions actively create, and re-create over time, the environment in which our teams and projects operate.

Many have noted that learning often follows this pattern.¹:

• First, we do things somewhat by rote, without fully understanding the disciplines.
• As we continue to practice the disciplines and learn from our mistakes, we think more about what we are implementing.  We observe how these practices operate on a deeper level, in relation to one another and in the face of unique obstacles.
• When we reach mastery, we forget about the practices and simply do what we know is right, having internalized the patterns that make up this way of working.

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.

Enter 'Agile Karma', to borrow an idea from an ancient tradition.

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.

Good karma looks different for different teams, and for different players on the team.  This is because, while the underlying principles remain the same, each team will find different ways to enact them.  That's why it's important to do retrospectives, and not only to look at what's broken, but to answer the question: "what went well?" or "what do we want to keep?"  Such an exercise helps the team surface and celebrate the things they are doing, perhaps unconsciously, which actually play a key factor in the success of their teamwork.

We start here by looking at some examples that we'd consider good Agile karma for the customer team, and work our way through the different team roles. What would your team's good karma profile look like?

Customer's good karma

The customer is the "driver" of the product or project, maintaining and tuning the vision, and communicating it to the team and providing feedback as they work. Usually the customer team is made up of Product managers, Information architects, QA, Usability engineers, member services etc.

• Always keep the end in mind: Agile software development does not stop you from having an over-arching vision. Have a clearly thought-out story-board for the product. Communicate the vision clearly and continuously.
• Do your homework before the iteration: You are supposed to have completed the following before the iteration planning meeting:
• Clearly thought-out goal for the iteration
• Clearly defined stories for visual design, front-end and programmers. Each story has
• Has a clear specific objective.
• Has a clear acceptance criterion.
• For programmer stories, have story tests ready before the iteration plan.
• When working on new products, provide interaction and flow diagrams like the paper prototype or wireframes.
• Respect the team's iteration plan: Do not change the scope once the iteration plan is finalized. No new features must be added to the iteration plan mid-stream.
• Insist on frequent demos: Before a new iteration begins, the team demonstrates to the customer the working software from the last iteration. Customers can work proactively with the programmers throughout the iteration to accept the iteration's stories before the next iteration begins.

Developers' good karma:

The development team consists of not just coders, but everyone whose skills are required to create a potentially shippable product at the end of iteration. This team makes decisions about how to provide the functionality requested by the customer.

• Think of customers as partners: Before you start working on a story, understand the customers' vision. Advise the customer team on better approaches and designs. Once you finish the story, update the customers and gather feedback.
• Communicate early: Do not wait till the end of the iteration or release to communicate any issues or risks. If you find something that change your estimates inform your project manager immediately.
• Update the plan: Update the iteration plan with your estimates and the status of the story at least once every day.
• Respect business priorities: The business may have a different agenda than yours. Focus on continuously delivering business value - when uncertain about their priorities, ask, don't assume.
• Respect the quality of the codebase (Do not cut corners)
• Keep practicing test-first development and refactoring.
• Chant the "do not repeat yourself" mantra.
• Integrate frequently and continuously.
• Run all the tests before committing your code.
• Do not ignore a broken build.
• Do not ignore architecture.
• Work as a team
• Frequently ask for input
• Offer help even when you are busy
• Signup for tasks that no one wants to sign up for.
• Publicly recognize teammates' contributions.

Internal Coach or Technical Lead's good karma

The Tech Lead probably knows the team and the technology better than they know Agile. This lends them an advantage over the Consultant Coach in highly political situations, and may balance their lack of expertise with the Agile practices.

• Coach Resolutely: It's tough work, especially if you are being compared to an external consultant coach. Have patience and you will be accepted over time. Do not give up - do what is right and respect will come.
• Hone your technical skills: To be an effective coach, it is important to still be a team player. If your technical skills are rusted, sharpen them a little every day.
• Don't read too much:
pick a basic text or two and pass their knowledge on to the team before moving on to the next book.
• Find a mentor:
more senior coaches have benefitted from the help of others and may in turn be happy to answer your questions and offer their insight. It can be a sanity saver when caught up in the undertow of the paradigm shift. An online discussion forum can be a good place to look for such help if there's no local Agile interest group.
• Keep key players and management in the loop:
Do not get carried away with your authority. You are still accountable to your boss and other important players. Keep them in loop to develop their trust for the new approach.

Consultant Coach's good karma

The Consultant Coach is an experienced "hired gun" who can shepherd a team or an organization through the challenges of Agile adoption. This may shorten the learning curve and smooth the way, but it is no replacement for the team's own learning, which will remain and guide the process once the coach leaves.

• Customize to the need: Learn to customize the process to meet the goals of the business and to accommodate the company culture, within reason. If the company culture makes having iterations impossible, have two week iterations instead, but make sure management is aware of risks introduced by significant compromises
• Listen more, learn more: An effective coach is a good listener and learner. Do not rush to enforce your learnings on the team.
• Learn to value the Critic: Yes, there are some people who do not like Agile, but you cannot afford to ignore their ideas or concerns and promote only people who support your ideas. Critics provide important information and can become valuable team members.
• Stick to your guns: When a team insists on abandoning a basic practice, ask if they understand how to compensate for its loss. Help the team acknowledge the risks they court. If they persist, it is better to say 'I have not done this before. Let us solve this together' than to make up unorthodox advice for the team.
• Facilitate Respectfully: Guard and restore the self-respect of all participants.
• Know when to back off: As teams start adopting Agile and take more initiative, learn to back off. If needed, let them make, and learn from, their mistakes.

Project Manager's good karma:

This role proved tricky to define - it can look so different in each context - often it's really several of the other roles mixed together. We've decided it warrants separate treatment, and have put it aside for now. (In the meantime, we'd be interested in reader suggestions).

Upper Management's good karma:

Upper Management is a key stakeholder in every project, but has the least control over what gets delivered. By providing strong support to the implementation effort, management can keep the channels of communication open and be in a position to respond rapidly to major obstacles when they arise.

• Openly Support the initiative: In your town-hall meetings or quarterly meetings, offer your support to the process openly. This will promote buy- in.
• Do not expect miracles: "I've spent so many dollars and nothing happened". Teams need time to customize and grow their process to see the final results. The greater the organizational challenges, the longer this may take. And keep in mind: good process cannot solve the problems of a bad team.
• Avoid the temptation to be date-driven: "Just get it done" bravado needs to change to "Let's see if we can change the scope to meet the date".
• Do not be in a rush to roll it out across the company: After initial success, you may be eager to spread the process throughout the organization. Make sure to understand the implications and limitations of the approach before rolling it out.
• Take time to really understand Agile before talking about it: Now that the teams are Agile, you want to go and talk about it to your friends, other companies. This might be a good time to do a little reading, first. Agile interest groups can be useful at this point, to meet peers who are a little ahead of your own situation.

Hopefully this has got you thinking - what is your team doing now that you'd not want to let drop when the pressure starts?  Why not take a few minutes at your next retrospective and make a new information radiator for the team room!  Don't forget to update it as things change - and you know they will!

About the authors

Gunjan Doshi works as the Vice President of Product Development and Process Excellence for Community Connect Inc., a social networking company based in New York city. He is responsible for the managing and leading a team of 30 programmers, project managers and quality assurance analysts. In past, he has customized and rolled out agile methodologies across several teams at various organizations. He is passionate about continuous learning and growth. He blogs at http://www.gunjandoshi.com

Deborah Hartmann is an Agile practitioner and coach living in Toronto and working in Canada and the US.  Deborah is passionate about making work both valuable and enjoyable.  She's been the Agile Community Editor for InfoQ.com since April 2006.

Photo credit: photo by william biscorner www.creations-photos.com.

---

1. Back to top

   Project Manager role

   Jan 27, 2007 10:55 AM 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.

   Reply

2. Back to top

   Re: Project Manager role

   Jan 30, 2007 8:59 AM 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.

   Reply

3. Back to top

   Re: Project Manager role

   Feb 23, 2007 6:45 PM 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

   Reply

• Older >