Running Agile

A Practitioner's View To Lean & Agile

Archive for January, 2008

a simple agile thermometer

Posted by Christophe on January 29, 2008

I’m often asked how to measure the agility of a new team. I have devised elaborated agility self assessment tools for team to reflect on their agility. Somewhat useful when taken for face value: an occasion to reflect on principles and practices and a base for an organized retrospective.

Result driven metrics like story point acceptance ratio, number of open defects at the end of a sprint or customer satisfaction are also very valuable and easy/cheap to track and can be used in the arsenal of tracking systems, as long as they are few in number and only used as guidance and leading to more conversations.

I am working with new scrum teams and have recently came up with yet a simpler thermometer for feeling the agility of the teams: the email inbox!

I have been flooded by an incredible amount of “communication” done through email. So I decided to correlate the team daily email threads and doneness level. Prior to switching to scrum, the team was trading a 100+ email per person per day (!) with a completed request level of 10% (yarrrk). In just on iteration, the volume of email has decreased by 20% with a story completion rate of 50%.

Yes, agile works on face to face conversations, because writing things down takes and lags time and is everything but clear. So my inbox is now my proxy for knowing when the team is struggling in communicating.

I now don’t even have to read emails in detail. When I get a lot of them, I just need to ask “is something wrong? what roadblock can I help remove?“.

Posted in Metrics, Tools | Tagged: | Leave a Comment »

Leading the Agile Way: Duty. Honor. Delivery.

Posted by Christophe on January 22, 2008

Here is a video about agile’s use in a governmental organization: at the 2006 APLN Leadership Summit Mark Salamango and John Cunningham looked at the problems and opportunities of introducing Agile in Army environments. True agile practices cannot be ‘commanded’ or ‘directed’ but frequent delivery offers Agile leaders a “soft” kind of power that is, in fact, very effective
–infoQ

Posted in APLN, John Cunningham, Videos | Tagged: , , | Leave a Comment »

Review process for agile team members

Posted by Christophe on January 22, 2008

Performance reviews and compensation questions are frequently on the front seat. It is possibly one of the most deeply rooted problem to get rid of when working with agile teams.

According to Jeff Sutherland, “surveys show that 90% of companies report ratings don’t work but they still keep doing them. It is kind of like the waterfall process. In the face of overwhelming failure people keep repeating the mistake.

Mary Poppendieck summarized this yesterday:

Using money as a motivator is like playing with dynamite because money is a VERY effective motivator. Monetary rewards motivate people to do EXACTLY what is being rewarded – not necessarily what the organization intended to reward, but EXACTLY what is being measured to generate the reward. Therefore monetary motivators have a long track record of generating unintended consequences. If there is any apparent competition for the money, money motivates people to get as much as they can for themselves. Thus monetary motivators have a track record of suppressing collaboration. Finally, bonuses for performance rapidly come to be an expected part of the landscape, replacing passion and dedication as motivators . These are things you probably cannot change about using money as a motivator.

A great book on the subject: Abolishing Performance Appraisals: Why They Backfire and What to Do Instead

So I asked Jeff what he is doing when you have to do performance ratings. He said that “you must take into consideration why they do not work in general and use a collaborative style to avoid the pitfalls.

Jeff wrote a memo in 1996 on how to conduct such reviews. After contemplating many options, I think his review process is best (if you have to do one).

I kindly clarified some sections to pass the approval of our employment lawyers. Please check Jeff’s original post for reference.

==========

Review Process for Agile Team Employees

Objective

  • Create a rating process to surface disparities between market perception, customer perception, company perception, team perception, manager perception, and individual employee perception of their own performance
  • Create a simplified process so frequent feedback can be communicated to employees (quarterly)
  • Incorporate a team score and an individual score into a performance score

The Review Process

The employee’s focus is to please the customer and meet their manager’s expectations in fulfilling their job responsibilities. This review process is forged as a collaborative rating system (360 degree feedback) and creates an accurate and realistic scoring without rating inflation by focusing attention on the user’s experience of the project or product being developed, along with time to deliver or market. The subjective experience of the manager is deemphasized. It requires raters to all work closely with one another to check ratings.

The Process Takes Three Meetings to Initialize

Meeting 1

Manager meets with employee and goes over the document. The employee is then asked to write his own individual review after the meeting by responding to the key individual performance questions (see below) and rate him/herself. The employee should be specific and concise and cite specific examples where appropriate. This review is designed to minimize the amount of writing that is general or vague.

Meeting 2

The second meeting occurs when the employee returns the review (along with soft copy). The manager discusses the employee’s perceptions to get a good understanding of them. After the meeting the manager carefully edits the review to incorporate his/her, the product team, senior management and customers’ perception of performance.

To gather the individual performance from the team, the manager sends a rating request using the rating scale below.

The employee’s 360 feedback will be a rating score based on the following percentages:

  • Team performance as per executive management: 25%
  • Team Rating of Individual’s Performance: 25%
  • Manager’s assessment of performance: 50%

Meeting 3

The third meeting occurs after the manager has finished editing the review and the ratings. The updated document is discussed with the employee. Any differences in perceptions is discussed and noted accordingly. If there are disagreements regarding assessments, the employee will have an opportunity to give feedback. If there are any changes in the assessments they will be incorporated into the final review and signed off by the employee and Supervisor. The employee’s signature does not imply agreement but acknowledges receipt.

Team Performance

Performance Objectives will be determined by senior management and will be appropriate to the Team. The score will be based on the rating score below.

Team Rating of Individual’s Performance

Each selected individual will be asked to give an assessment of the employee’s work performance based on the rating scored listed below. The score is calculated as an average.

Manager’s Assessment of Performance

The manager rates the employee on a set of questions that drives the review process away from a standard list of items accomplished. These items are used to justify responses to the questions. These questions are designed to focus the performance review on the issues that are critical to company and department success. The questions lead the discussion away from the reviewer’s personal opinions and focus the discussion on the impact this person has on the work or the department.

In most circumstances, the rating scores of the manager, the team and senior management will be close. When this occurs the weighted average will be the final score. If ratings are widely different, the most extreme rating supersedes the lower.

Customer’s ratings supersede senior management, who supersedes the team who supersedes the manager.

Example 1:

  • Manager’s score: 5
  • Team’s score (of individual as an average): 7
  • Senior Management’s score: 5

We treat a 5 as no opinion. Team determines the result with a 7.

Example 2:

  • Manager score: 5
  • Team score (of individual as an average): 2
  • Senior Management score: 3

This person did not meet expectations of the team or the senior management. He/She is a 2 or 3. This appears that the manager is not managing the employee. How can a person meet the manager’s expectation but not meet the team or senior management’s expectations. A discussion with the manager is needed by their Supervisor.

There may be a unique case where one bad event is exaggerated and the manager feels the person is being treated unfairly. In this case, the highest score would be a 4 and the employee would be informed that this is an action item that they and the Supervisor would need to work together to devise an action plan to get the team members to raise the score.

Rating Scale

10. Trade and blog journals are writing rave reviews about employee’s work saying it is best in its class

9. Customers (externally/internally) are writing rave reviews about employee (must be documented in writing)

8. Exceeds expectation of the company senior management

7. Exceeds expectation of Product Owner and Tech Team

6. Exceeds reviewer’s expectations

5. Meets reviewer’s expectations / no-opinion

4. Does not meet reviewer’s expectations

3. Does not meet expectation of Product Owner and Tech Team

2. Does not meet of the company senior management

1. Customers are complaining about employee

0. Employee work is externally criticized by members of the technology community (e.g. PC Week)

Under this system, the manager can give a 4, 5, or 6. Any other rating requires outside input from the development team, the engineering group, senior management, customers, or the press.

Key Individual Performance Questions

The following questions can vary slightly from team to team. The manager rates the employee on a set of questions that drives the review process away from a standard list of items accomplished. These items are used to justify responses to the questions. The questions are designed to focus the performance review on the issues that are critical to company success and growth. They lead the discussion away from the Manager’s personal opinions about the person, and focus the discussion on what business impact this person has.

Feedback for a line Employee

  • Individual Contribution to Product Delivery: How effectively did this person produce deliverables required to bring product to the company or department? 20%
    • Past quarter feedback
    • Areas of growth next quarter
  • Individual Contribution to Process Improvement: How fast did this person learn and implement new technologies and processes required for producing better product, shorter time to deliver a finished product, which is live in production for the customer’s immediate use and lower costs? 20%
    • Past quarter feedback
    • Areas of growth next quarter
  • Individual Contribution to Organizational Flexibility: How flexible and adaptable was this person to changes in processes, organization, or personnel required to deliver products in Internet time frames? 20%
    • Past quarter feedback
    • Areas of growth next quarter
  • Individual Contribution to Group Learning: How well did this person transfer learning in the development team? Can their work easily be supported when this person is absent? 20%
    • Past quarter feedback
    • Areas of growth next quarter

  • Individual Contribution to the Product: How good was the product that this person brought to the client/department/company? 20%
    • Past quarter feedback
    • Areas of growth next quarter

Feedback for a manager

  • Individual Contribution to Product Delivery: How well did this manager influence the product/project/team to be customer (internal and external) focused? How effectively did this manager’s team produce deliverables required to bring a finished product to the customer or company? 20%
    • Past quarter feedback
    • Areas of growth next quarter

  • Individual Contribution to Team building: How good was this manager at selecting A players, coaching and redeploying B/C players? Are teams under this manager empowered, self-organized, inspired and accountable? 20%
    • Past quarter feedback
    • Areas of growth next quarter

  • Individual Contribution to Enterprise Collaboration: How effectively did this manager (and by extension his/her team) collaborate with other managers (and teams) on cross functional / team issues? Can he/she listen to other point of views, negotiate and be sensitive to others and aware of office culture? 20%
    • Past quarter feedback
    • Areas of growth next quarter

  • Individual Contribution to Process Improvement: How much did this manager influence (not dictate) and implement new technologies and processes required for producing better product, shorter time to market, and lower costs? 20%
    • Past quarter feedback
    • Areas of growth next quarter

  • Individual Contribution to Group Learning: How well did this manager transfer learning in the development team? Can their work easily be supported when this person is absent? 20%
    • Past quarter feedback
    • Areas of growth next quarter

Overall Rating:


Career Goals:

What does this person passionately want to do?

The overriding objective of managers should be to identify what the person really wants to do and align job objectives accordingly. If this is not possible, the person should be encouraged and coached to find opportunities that will unleash energy and creativity. Super-performance teams can only be built with people who are passionate about their work. The greatest challenge of a manager is to creatively align the inner driving force of an individual with the corporate objectives required for success in the marketplace.

Training Needed:

What training is needed to move toward career goals?

Goals for next rating period (3 months):

Posted in Jeff Sutherland, Management, Mary Poppendieck, Quotes, Team Performance | Tagged: , , , | 3 Comments »

Quickies: sticky notes 2.0

Posted by Christophe on January 19, 2008

Post-it notes are possibly the best tool for agile teams. Versatile, cheap, simple. The result? Magnificent colorful interactive scrum boards.

Scrum board

The drawback? Post it notes are very easy but they can become overwhelming and don’t provide much help for managing large implementation across multiple teams.

Online scrum board management tools (rallydev, versionone etc) try to fill in the gap by providing dependency management, search capacity, burn down charts and more. While they definitively bring a lot of value, they also fail at keeping the team engaged. Nothing beats facing the physical board.

Researchers are about to bridge the gap with Quickies. The technology integrates RFID, Artificial Intelligence and ink recognition technologies can make it possible to create intelligent sticky notes that can be searched, located, can send reminders and messages, and more broadly, can help us to seamlessly connect the physical and digital worlds.

quickies1

quickies2

Flying cars by 2010? No, but finally something to be excited about!

Check out the video here.

Posted in Tools | Tagged: | 2 Comments »

Agile Quality: A Canary in a Coal Mine

Posted by Christophe on January 12, 2008

Scrum co-creator Ken Schwaber spoke at Agile2006 on code quality as a corporate asset. InfoQ presents video of his talk, The Canary in the Coalmine. Schwaber discussed how a degrading core codebase paralyses a team and negates any Agility gained through process improvement. He proposed strategies for management to identify, track and stop this downward spiral.

Posted in Agile2006, Ken Schwaber, Quality, Scrum, Videos | Tagged: , , , , | 3 Comments »

Leading a new scrum team? Limit self-organization!

Posted by Christophe on January 6, 2008

Managers new to scrum often ask what their role is leading self-organized teams.

The scrum model doesn’t ask for managers. 1 product owner, 1 scrum master, a cross functional delivery team. That’s it.
On the other side of the spectrum, lean thinking praises for strong functional manager (rather than process leaders). A lot has been written on the subject; I won’t go into it here. Check out Mary Poppendieck’s books for more on the subject.

Here’s a radical new idea about why new scrum teams need managers: to limit their self-organization.

In his book “The Paradox of Choice: Why More Is Less Barry Schwartz provides a stunning vision that increasing choices flood our brains, increase stress and ultimately restrict our ability to make decisions.

Inexperienced scrum teams are often overwhelmed by the new “freedom” provided to them the self-organizing aspect of agility. I am formulating the idea from Schwartz research that managers could enable such teams succeed faster by actively reducing the huge number of things to do to a small number of good ones. Any choice would be successful and rewarding. In such an environment, it would be easier for the manager to teaching the team how to make more difficult decisions (introducing less desirable choices).

Is letting a newbie scrum team totally self-organize itself really the best way to show respect and creating the best environment for its success? Or is reducing choices a strong coaching technique with the fastest path to high performance? Worth trying, isn’t it?

======

Video: the paradox of choice by Barry Schwartz.

Posted in Leadership, Lean, Scrum, Videos | Tagged: , , | 1 Comment »

Emergent architecture

Posted by Christophe on January 5, 2008

I often find teams having a hard time with the idea of emergent architecture, even so called long time agile teams.
The question of emerging vs up front architecture has some roots in the philosophy teams follow to manage their planning.

How is that? Many agile teams have switched from waterfall project management to some flavor of iteration based project management. The important word here is that those teams are still working in a project management environment as opposite to a product development environment.

The difference? Projects are remnants of a time when decades ago companies were developing their applications through consulting companies as one off solutions. Projects have a start date and an end date, and stop when finished. In product development, we have a start date and hopefully never have an end date. Great products or their variation can stay on the market for dozens of years (I’m not saying by any means that product management doesn’t drive to dates – release dates are here for that).

How is that pertinent to emerging architecture? Teams that still have a project mentality (with an end date) tend to want to define architecture in advance. Teams that have really embraced product development (i.e. the continuous improvement of a product to serve their customers) tend to use emerging architecture. In project thinking, up front architecture can work well. Project over, next project. But how does this apply to product development thinking? What happens the first day of the 2nd release cycle? Will the team re-architect the whole thing from scratch? What about after 10 years? I believe building successful products with longevity requires mastering emerging architecture. This can only be achieved by frequent practice (constant refactoring). And the better time to start this? From the very beginning, when complexity is null.

As Allan Shalloway puts it, “The purpose of architecture is to minimize the effect of changes. Creating an architecture too soon has the following risks: 1. Over-building the architecture which leads to complexity 2. The temptation to trust the architecture instead of code quality (which always needs to be maintained)

A third risk I want to add to this list is that early architecture assumes a range of possible changes. With time, the chance for a need not covered by the core architecture grows. It’s a matter of when; not if. With the need for large refactoring and absence of practice is often the death of the product; even the greatest.

The philosophy of deferring commitment for dealing with the unknown has successfully enabled the most difficult journeys. Alan Hubert, planning the longest ever crossing of the arctic basin by foot and kite would not disagree:
Much of the [Arctic] traverse will be on sea ice, which is always moving. It’s impossible to know what will happen in the coming hours. But as soon as we get to the ice cap on Greenland we expect to sail
[across the ice] quite a lot. You quite often get bad weather, but it’s good because then you get the wind.”

Posted in Architecture | Tagged: | 5 Comments »

New year, new gig

Posted by Christophe on January 2, 2008

Personal update:

After spending the most part of the internet life time building Shopzilla, the biggest shopping search engine, I am moving on to running the technology at Gorilla Nation, the largest online ad sales rep firm.

I’m looking for talented engineers (developers, testers, sys admins) and team leaders looking at joining a fast growing company with a wide variety of cool products (fun web sites, video distribution, multi-media advertising and more) and technology (PHP, django/python, ruby, java, Flash, QA, CM, sys admin, network and more) in a strong rapid development / scrum environment. If you want to own and launch products, and make a real difference, drop me an email. Oh, and this in sunny LA :)

Posted in Uncategorized | 1 Comment »

 
Follow

Get every new post delivered to your Inbox.