Jira and GreenHopper for agile project management

I previously blogged about using Jira with some open source tools for managing agile projects, and concluded that it was not a great solution - without GreenHopper. I've been using the latest version of Jira with the GreenHopper agile plugin extensively now, and I like it. It is lacking some features, which I'll describe later, but here is an overview of the main functionality.

The first thing I like is the Planning Board view, which is aimed at Product Owners who spend lots of time ranking and re-ranking backlog items. The GreenHopper planning board allows you to drag and drop items to either change their rank or to move them from the backlog into a particular iteration or sprint (version, in Jira lingo).

Above: dragging a user story from the backlog to a sprint. (Click image to see it full-size.)

For the development team, GreenHopper's Task Board view is just that - it simulates the physical task board that so many co-located teams use. It's easy to drag the virtual cards to columns to update their status, just like you would do with a physical board. Very nice. It also does something you can't quite do with sticky notes; double click to see more information, or click on the item ID to see all the detail.

Above: The Task Board in summary view mode (Click image to see it full-size.)

Above: See more of the task board without scrolling - the List view (Click image to see it full-size.)

Above: Dragging a card from "To Do" to "In Progress"

Above: Double click to see this expanded view of any card on the board.

An advantage of GreenHopper over sticky notes on the wall is that your burn down charts are calculated automatically: in hours, number of items, and story points. The screen images below show these. The red line is the ideal burn down and the green line is the actual.

Above: Burn down in hours (Click image to see it full-size.)

Are you a bleeding-edge adopter of kanban? GreenHopper is decent for that. The columns on your kanban board are customizable, so you can create any columns you want. You can also set a WIP limit for each column. You can't, however, set up horizontal "swim lanes" for different service level agreements (SLAs), such as a row for items that need to be expedited.

Above: The column turns red when the WIP limit is exceeded

The Jira dashboard also offers a reasonable approximation of the cumulative flow diagram (CFD) that replaces burn downs in a lean / kanban process. It does show items created vs. resolved, but it doesn't graph items in-progress. The chart also counts sub-tasks as items, which you may not want.

Above: Almost a cumulative flow diagram. Close, but no cigar.

GreenHopper is an add-in to Jira, so you still get all of the Jira functionality unchanged. Like Jira itself, GreenHopper is extensively configurable; almost annoyingly so because there are so many options it's hard to know what to do with them. Fortunately the default configuration is reasonable, although there are some setup steps required to enable item ranking, which is so fundamental that it should have been done out-of-the-box.

What is it lacking?

1. If you're a large organization with a portfolio of inter-related projects, Jira + GH doesn't do much to show you the big picture across multiple projects.
2. Although you have a hierarchy of versions, such as a release containing multiple sprints (described here), it doesn't do much; the planning board simply indicates that one version is a "master" of the other. GreenHopper doesn't offer a timeline view showing the version hierarchy.
   
3. You can create a hierarchy of backlog items, for example to have large-scale epics that contain many user stories, as described here. However, this feature isn't enabled by default and requires an adminstrator to configure it. As an alternative, or in addition to the "epic" feature, you can create associations between items for this purpose, but there is no easy way to visualize the relationships. There is free task hierarchy plug-in that will show the hierarchy, but only for one top-level item at a time. 
   

Overall, especially for smaller teams without portfolio management needs, I give the tool high marks.

Definition of Ready (DoR)

All good agile teams have a Definition of Done (DoD) - the common set of criteria that every feature must meet before it's considered complete. I wrote about the DoD previously in this post. But what about a Definition of Ready? How do you know when your backlog items are ready for the team to accept them?

Serge Beaumont spoke on this topic among others at the 2009 Scrum Gathering in Munich in his presentation Practical Tools for the Product Owner: Focus, Value, Flow. He describes the Definition of Ready as a negotiation between the Product Owner and the team, where the team ultimately decides if a backlog item (user story) is defined well enough for the team to estimate and implement. His checklist for the DoR for backlog items includes:

• Why? Business Value
• What? Outcome vision
• How? Implementation strategy & cost
• Does the backlog have enough items for 1 and half to 2 sprints?
• Is the size (granularity) of the backlog items acceptable?

I would personally aim for a smaller number of items in the "ready" state; 2 sprints worth of items increases the risk that time will be spent analyzing items that end up in the trash heap.

Serge also advocates using a kanban board with 4 phases to track the readiness of backlog items:

• New
• Preparing (going through analysis)
• Ready
• In sprint

I'll be adding the DoR as a standard part of my Scrum implementations.

SourceMonitor for .NET code quality metrics

A tip of the hat to Paul Rayner for recommending SourceMonitor for .NET code quality metrics. I gave this freeware tool a spin today on a C# project I'm working on for a large client, and was very happy. It's easy to use and within a few minutes I had it installed and ran the analysis on the whole project, gathering these metrics for the whole solution, and for each C# file within the solution:

• number of statements
• methods per class
• calls per method
• statements per method
• average and maximum complexity
• average and maximum block depth (number of levels of indentation/curly braces)

This is a great tool to quickly find potential problem spots within the solution, so you can identify the components that would likely benefit the most from some refactoring and additional testing.

Agile vs. Waterfall: The NetFlix analogy

The following is a fable to compare traditional waterfall projects to agile/lean projects...

---

Announcing my new movie rental service, NetPix! Here's how it works.

• You get 60 movies each year, delivered on DVD in the mail.
• When you first sign up, choose 60 movies you want. When you finish choosing your movies, we'll confirm that it's really the list you want.
• Over the next 12 months, NetPix will tirelessly collect your 60 DVDs, and at the end of the year, we'll deliver all 60 movies to your home!
• Price: $60 per year (just $5 per month!)
  

The fine print:

• DVDs will be delivered 12 months after you complete and confirm your list of 60 movies. 
  
• After confirming your movie list, any changes you make to the list in the first 6 months will incur a charge of $2 per movie. 
• Any changes in your movie list during months 7-12 will result in a charge of $3 per movie, and a delivery delay of 1 month per movie changed. (We have to lock down the list at some time, after all!)

---

Now suppose I order, say "Weekend at Bernie's", both I and II, on the advice of my high school buddy, Steve. A year later, I watch "Weekend at Bernie's" (the first one), and I hate it! Steve usually has good taste, so I trusted him, but he must have been smoking crack when he recommended this one. I don't even wanna watch "Weekend at Bernie's 2", but I already paid for it and it's sitting in a cardboard box next to my DVD player. Damn!

And to top it off, eight months into the year the studio released a remastered, Director's cut, collector's edition of my all-time favorite movie "Blazing Saddles", with never-before-seen outtakes! If I want that it'll cost me an extra $3 (5% more) and I'll have to wait an extra month for all of my DVDs! Double damn!

Would you buy this? "No," you say? Well why not? This is the way software customers have been buying software for decades! Customers have to figure out everything we want before we even start working on it, and they can't change their minds later without paying dearly for it!

Alas, much to the chagrin of NetPix, along comes an upstart disruptor, NetFlix! Now customers can get the features (DVDs) they want every month instead of waiting a year! And they can change their priorities (movie list) at any time! And they can watch "Weekend at Bernie's I" before deciding if they want to invest 90 irrecoverable minutes of their lives watching the sequal. The demise of NetPix is written on the wall!

More tips for better retrospectives

At last night's Agile Denver meeting, I facilitated an open space discussion and one of the topics was conducting more effective retrospective meetings. The group had some great insights and advice that I'd like to share here. Thanks to everyone who participated!

1. Rotate responsibility for facilitating the retrospective. Get fresh perspectives and creative ideas. Don't let it get stale.
2. Hold your retrospective over a happy hour.
3. Read Agile Retrospectives by Esther Derby and Diana Larsen
4. Instead of asking "what were the problems", ask "what could we have done better."
5. Follow through with an action plan. If you have lots of improvements, rank them and work on the top priority issue.
6. Have a virtual buyer/seller transaction at the end of your iteration to determine if stakeholders are willing to "pay" for what you delivered.
7. Do shorter iterations - fewer issues to discuss
8. Set the stage with expectation that it's not about blaming. Participants must describe the effect of the problem, not the person they believe caused the problem.
9. Take collective team ownership over problems. It's the team's job to help every person on the team.
10. Start the meeting by having participants write issues on cards, then post them on a wall and group them. This can effectively elicit input from shy people who are hesitant to speak in a group.
11. Ask creative questions, like "if this iteration were a car, what model would it be?"
12. Keep a retrospective board where team members can at any time write down issues they want to discuss in the retro.
13. Is there an elephant in the room that nobody wants to talk about? If so, get it out!
14. End on a positive note. Everyone must say one positive thing.
    

Open source agile project management tools

I authored a comparison of five open source agile project management tools: Agilefant, IceScrum, Agilo, eXPlainPMT, and XPlanner. The article is posted on Open Logic's Wazi site. I welcome your feedback!

Seven tips for distributed agile teams

Agile methods were originally intended for small co-located teams. Can they work for geographically distributed teams? In fact, due to the challenges of working with distributed teams, I believe the fast feedback and validation afforded by agile methods provide a distinct advantage for distributed teams because problems are found sooner. I have experienced great success with teams split between the US, India and China. In this post I share some tips on making distributed agile teams succeed.

For a more in-depth treatment of this topic, see my presentation on Distributed & Offshore Agile Teams.

1. Prepare your collaboration infrastructure

You may need phone, web, & video conferencing, wiki/intranet, source control, VPN, remote desktop tools, SFTP for large file transfer, testing and integration environments, and project management software. Obtain high quality full-duplex speaker phones, headsets, and webcams.

2. Have an agile coach or agile champion at each location

In addition to providing agile training to every team member, you want ongoing guidance at each location from an experienced agile practitioner who can establish an effective team culture.

3. Be extra disciplined in your technical practices

The technical practices from XP (pair programming, TDD, refactoring, continuous integration, coding standard, simple design) are fundamental for any high-performing agile team, but when people are scattered across the globe, they become even more important. These practices ensure that quality is built in from the start, they enable knowledge sharing, and ensure rapid feedback.

4. Do cross-location travel throughout the project

Get the entire team together in one location at the beginning of the project and again at each release. Establish a rotating travel schedule so each team member visits another location for 1-2 iterations. This face time will reap big returns in establishing trust, sharing knowledge, and maintaining an effective team culture.

5. Maximize opportunities for real-time communication and collaboration

Even with a time zone difference, find at least a few hours every day when all team members are available by IM & phone for real-time communication. Share time zone burdens fairly between locations. Hold daily stand-ups and iteration planning meetings with the entire team using video and web conferencing. Many studies have shown that the majority of information shared in a conversation is non-verbal, so use video chat & conferencing often. Google, Yahoo and Skype offer free 2-way video, and Paltalk has free video for up to 10 parties. Webex and many other commerical services offer multi-party video conferencing.

6. Facilitate cross-cultural communication: speak slowly, avoid jargon and idioms

If your team members don't all share the same primary language and culture, be sure that everyone speaks slowly and avoid using jargon, idioms or expressions - they usually don't translate well. Announce your name each time you speak on a conference call: "This is Sally..." Start each meeting with a virtual seating chart as described by Jean Tabaka in her book Collaboration Explained. Appoint a facilitator to ensure each meeting is effective.

7. Find effective, lightweight tools for distributed collaboration

Intranets, wikis and source control systems allow easy information sharing. Virtual white boards such as scriblink, skrbl, and dabbleboard enable remote collaboration. Many web conferencing systems such as ReadyTalk have drawing tools allowing free-form annotation of a shared screen. Instant messaging supports both one-on-one and group chat. VNC, remote desktop and similar tools even allow cross-continent pair programming. For iteration planning and task tracking, share photos or video of your physical task board, or make the leap to an electronic tool. There are numerous open source agile tools plus commercial tools, most with trial or free editions, but choose a lightweight tool unless you truly need the more advanced features.

Eight tips for better retrospectives

I am often surprised at how many self-described agile teams don't hold retrospective meetings every iteration. For those team that do hold retrospectives, I often find they have a lot of room for making them more effective. An attitude of continuous improvement is fundamental to successful teams, and the retrospective is the primary mechanism for improving, so it follows that effective retrospectives are one of the key elements of a good agile team.

In this post, I offer five tips on how to conduct more effective retrospectives.

1. Review notes & actions from the previous retrospective

This is step #1 in the retrospective, which of course implies that you must first record notes from your retrospective meetings. (See tip #8) Use a projector to display notes & action items from the past meeting. Keep it short - five minutes at most. If you have remote team members, use a webinar and/or video conferencing so everyone sees the same screen. If you find your team bringing up the same problems as in previous iterations, ask why - five whys, actually (see tip #5).

2. Ask what problems, successes and opportunities you have with the team, the product, and the process

The facilitator will ask the team, "What did we learn about the team, the product, and the process? What were our problems, successes and opportunities to further optimize?" Capture these items in a grid as shown below. Use a white board if everyone is in the same room, or take notes in a wiki or other electronic document - preferably the same one you'll use to archive your retrospective notes (See tip #8).

	Problems	Successes	Opportunities
Team
Product
Process

3. Let each team member speak without discussion

The facilitator gives each team member the opportunity to speak without any group discussion; no one else is allowed to comment on anyone's opinion - yet. Only clarifying questions are allowed at this time. Discussion will come later when the team is discovering the root causes of problems. (See tip #5)

4. Vote on the most important items to take action on

You may not be able to immediately address every concern raised in the meeting, but you certainly need to prioritize them. Every team member is allowed to vote for 3 items that he/she believes are most important to take action on. Tally the votes and add the items to your process improvement backlog based on priority. Note that some items may not require any further action. Even successes may need action however; for example, a good pattern or practice may need to be documented in the Definition of Done or added to the coding standard.

5. Use "five whys" to discover the root cause of problems

For each of the highest-priority problems identified, the facilitator will ask "why did that happen?" Once an answer is given, ask the same question again, repeating the process five times. This should lead you to the true root cause of the problem.

6. Create an action plan for your top priority items

For each top priority item, decide what to do, and who can do it - which may be more than one person. Any actions requiring work by team members should be planned and assigned during iteration planning. (See tip #7) Actions assigned to members outside the team must be coordinated and scheduled. Of course the action plans should address the root causes of problems, not just the symptoms.

7. Explicitly allocate time for improvement actions

Maintain a backlog of improvement actions. At each iteration planning, pull the top improvement actions into the iteration. Improvement items should be prioritized along with product backlog items based on overall value to the organization, but teams should reach an agreement with the product owner on a percentage of their time to be spent on improvements.

8. Record your retrospectives & actions

Maintain two artifacts: (1) a process improvement backlog and (2) retrospective notes. The notes may be captured in real-time during the meeting using a wiki, intranet, or other electronic document. Record just enough information to support a review at the next retrospective (tip #1). Appoint someone other than the facilitator to take notes. For the process improvement backlog you may use the same tool you use for product backlogs; this backlog can be owned by the scrum master.

Metrics for agile projects

Yesterday's Agile Denver meeting was a panel discussion on metrics for Agile Projects. In the end most of the discussion was about software metrics in general, and the discussion produced some good insights that apply to all software projects, not just agile projects. Some highights:

Kevin Sheen from Perficient said you need to know what's important to your customers: deadline, budget, scope, requirements flexibility, product scalability, etc. Use that to decide what metrics are important.

Paul Rayner explained that diagnostic metrics such as code complexity should be initiated by the team, owned by the team, and not reported upward in the organization. He used the analogy of a hospital patient who has his heart rate, temperature, & blood pressure measured. Those metrics are used in combination by doctors and nurses as diagnostic measures, but not reported up to the hospital's board of directors. The problem is that most managers don't understand those metrics and managers generally shouldn't care about them, either. The metrics reported upward to management should be ones needed to make management decisions - about budgeting, schedule, scope. Kevin Sheen pointed out that generally when higher level management wants to "open the hood" and look at these metrics it's because they don't trust that the development team will meet it's estimates, and additional metrics give them a false sense of control over projects.

Brian Boelsterli said that a project's reporting metrics (distinguished from diagnostic metrics) should be clearly rolled up to corporate KPIs. Each project should be able to demonstrate how it is contributing to those KPIs.

Several panelists and audience members spoke about that potential dysfunction that can result when diagnostic metrics are used as carrots or sticks to measure or evaluate individual team members. To avoid dysfunction diagnostic metrics should be chosen by and valued by developers. Even when measured at the team level, compensating metrics should be used: for example if you collect a productivity metric then you should also collect quality metrics so that people don't sacrifice quality for apparent productivity.

Paul Rayner said that he likes the following diagnostic metrics at the development team level:

1. Cyclomatic complexity - average per namespace and per method
   
2. Total lines of code - monitor the trend over time. Should level off or decrease with refactoring.
3. Coupling - to find classes that have too many dependencies

Richard Lawrence mentioned that he uses Coderush's "maintainability" metric. Visual Studio has it's own maintainability metric which uses a combination of other metrics to arrive at an overall score.

These technical metrics in my view are very valuable indicators - they help you decide when and where a qualitative analysis is required. For example, if you want to know where to get the most bang for your buck on refactoring, look for methods with high cyclomatic complexity or classes with high coupling.

Survey on distributed agile teams

The User Experience League has created a survey for geographically distributed agile teams. If you have experience in this area, please respond to the survey here.

Agile games & exercises

Tom Perry has compiled a list of games and exercises for teams on his Agile Tools blog. He has links to a variety of exercises to teach not only agile & lean principles & practices, but also leadership concepts and team building. You can read his blog post here.

Execution: The Discipline of Getting Things Done

Here is my synopsis of the book Execution: The Discipline of Getting Things Done by Larry Bossidy & Ram Charan.

"To understand execution, you have to keep three key points in mind:

• Execution is a discipline [akin to Six Sigma], and integral to strategy
• Execution is the major job of the business leader
• Execution must be a core element of an organization's culture"
  

Every business has three core processes which the business leader must not delegate, but be deeply engaged in and build the system and discipline for execution. They are:

1. The people process (the most important of the three)
2. The strategy process
3. The operations process

The 3 core processes must be tightly linked together, and the leader must ensure that high-level objectives are translated into realistic, concrete steps for action in order to be executed.

There are 3 building blocks of execution:

1. The leader's seven essential behaviors
2. Creating the framework for cultural change
3. Having the right people in the right place (no leader should delegate this job)

Building block 1: The leader's seven essential behaviors

Behavior 1: Know your people and your business.

Meet as many people in the organization as you can. Give your view on the state of the business but spend more time listening to them.

Behavior 2: Insist on realism

Create a culture where openness and honesty are rewarded. Compare your company's goals with other companies as a measure of realism.

Behavior 3: Set clear goals and priorities. Focus on no more than 4 priorities.

Behavior 4: Follow through

At the end of every meeting, establish a schedule for follow-up meetings with milestones to be met at each one.

Behavior 5: Reward the doers

To change people's behaviors, link rewards to performance and do it transparently. Reward people for performance against objectives and for their behaviors; for example, reward collaboration. Be sure to regularly record specific instances of people's behaviors, both positive and negative.

"Differentiation [in rewards] is the mother's milk of building a performance culture."

[My commentary: I am deeply skeptical that a performance evaluation process can be designed to eliminate the dysfunction and unintended incentives they often breed. I've written more on this topic in this blog post. I agree with the authors that any such system must evaluate people's behaviors, not just their performance against objectives, but even so there is great potential for mistrust, fear, and promoting competition over collaboration. I also believe it's critical that people receive constructive feedback on their performance much more often than once per year. I recommend bi-weekly reviews if you truly want people to improve their performance quickly.]

Behavior 6: Expand people's capabilities through coaching

Teach others how to get things done and how to lead. Create a deep bench of leadership succession within the organization.

Behavior 7: Know yourself

A leader must have the emotional fortitude to "accept and deal with your own weaknesses", accept differing points of view, deal with conflict, and "be firm with people who aren't performing".

Building Block 2: Creating the framework for cultural change

A company culture consists of it's "hardware" (org structure, compensation structure, communication systems, etc.) and it's "software": values, beliefs, and norms of behavior.

How to create a culture of execution:

First you tell people clearly what results you're looking for. Then you discuss how to get those results, as a key element of the coaching process. Then you reward people for producing the results. If they come up short, you provide additional coaching, withdraw rewards, give them other jobs, or let them go.

A company culture is based on the collective beliefs of it's employees, and their behaviors are their beliefs turned into action. If people believe that they are in competition with their peers for rewards, they will act accordingly. If they believe people are not held accountable, then they won't expect to be held accountable either. The behaviors exhibited and tolerated by leaders trickle down through the organization.

My commentary: The authors, perhaps unintentionally, have revealed the difficulty with traditional performance evaluations here; they put employees in competition with one another to get the biggest slice of the rewards pie, reducing collaboration. Perhaps by adding collaboration and similar behavioral criteria, rather than solely results-based criteria, to the evaluation process, this effect can be mitigated. But can it be eliminated?

Building Block 3: Having the right people in the right place

This job can't be delegated. Larry Bossidy spent 30-40% of his time in the first 2 years at Allied Signal hiring & developing the leadership team. Developing leaders should be a core competency and the company should fill most leadership positions from within. Provide people with various job opportunities matched to their skill sets and potential.

It is critical to know the 3-4 specific key skills & qualities required for a job and to ensure the person has those skills via interviews and reference checks. Specificity is important. For example, the specific skills for a Chief Marketing Officer might be: (1) ability to select the right mix of promotion, advertising, and merchandising; (2) proven sense of what advertising is effective; (3) ability to execute the marketing program with the right timing and sequence in coordination with new product launches.

Determine how the candidate accomplished particular results. Did she sacrifice long-term success to achieve short-term numbers? Did he succeed due to luck? Did she fail to meet an objective due to outside circumstances but still do better than others in the same situation?

The People Process

The people process is the most important of the three core processes, and it must be tightly integrated with the strategy and operations processes. Determine your talent needs over time - they may be different in the future. Know the number and types of people you need in the short, medium and long terms based on strategic milestones. Develop a leadership pipeline with retention risk analysis and succession depth analysis.

When evaluating a person, meet with five other people to candidly discuss the person's strengths and weaknesses. (My commentary: Note that this requires a culture of trust where mistakes are treated as learning opportunities.) Determine when someone can improve via coaching and/or a different role.

The Strategy Process
The strategy must be linked to the people process and operations process. A strong strategy addresses the following questions:

1. What is the assessment of the external environment?
2. How well do you understand the customers and markets?
3. What is the best way to grow the business profitably, and what are obstacles to growth?
4. Who is the competition?
5. Can the business execute the strategy?
6. Are the short term and long term balanced?
7. What are the important milestones for executing the plan?
8. What are the critical issues facing the business?
9. How will the business make money on a sustainable basis?

The strategy review meeting should be interactive, lively, open and creative. This requires a culture of trust that values and rewards honesty. The business leader must regularly follow through to ensure execution toward the strategic goals.

The Operations Process

The operations process must be tightly linked to the people & strategy processes. It "breaks long term goals in to short term targets", specifying how to execute & achieve results. It should include plans for product, marketing, sales, manufacturing, productivity improvement, and contingencies. It is critical to have an open and robust dialogue and debate on the the assumptions underlying the operations process. The budget should be prepared based on the operations plan, not vice-versa. Use quarterly reviews to update the operations plan.

Performance Evaluations

What do performance evaluations have to do with agile & lean software? As a core component of an organization's culture, they have a huge impact on the way individuals, teams and the whole company operates. I found a great blog post on this topic entitled Performance Evaluations, Business Strategy, and Agile Methodologies. It discusses both the proponents (e.g. Jack Welch) and opponents (e.g. Deming) of the "rank and yank" evaluation process.

In an accompanying discussion on LinkedIn (Agile Alliance group), the blog author Henrik Martensson writes:

Two things to consider are that for rewards to be effective, the feedback loop must be short, and the rewards must be linked to behavior, not results. This is basic behavioral science, but most corporate reward systems miss it. Lean is an exception. Lean companies explicitly use Management By Means (MBM) instead of Management By Results (MBR). MBR practically guarantees dysfunctional behavior, regardless of the reward system used.

No doubt the controversy will continue, but I hope the discussion will cause leaders to challenge their assumptions about performance appraisals and develop better ways for improving the system used to deliver value to customers.

Team Estimation Game

Estimation: wouldn't it be nice if we didn't have to do it? Well, maybe we don't. In a mature agile or lean/kanban development system where prioritized value is flowing at an acceptable rate, and in a context where knowing both the scope and date of a delivery is not necessary, estimates don't provide much if any value. So don't blindly assume that you must estimate your features/stories. And if you do evaluate the need for estimates and determine that they are worthwhile, you need to determine how much value they provide so you can be sure the effort spent estimating is commensurate with that value.

One of the best-known ways of estimating user stories is planning poker, first described by Mike Cohn (as far as I know anyway). I've used planning poker very effectively, but I recently came across an alternative approach: the Team Estimation Game, originally created by Steve Bockman and described here by NetObjectives (you may need to register to see the link).

In a nutshell, the team starts with a stack of cards containing stories or features. Over the course of the game, story cards are physically arranged linearly according to size: small stories on the left side of the board/table, and larger stories farther to the right. Stories of the same or similar size are stacked together in a group. Taking turns, each member of the team may either (1) place the top card on the stack in the place where he/she believes it should go, or (2) move a card previously placed by another team member, explaining the reason why it was moved. At the end of the game, you can assign story points to each group of cards.

One of the strengths of this game is the emphasis on relative sizing; it makes it more easy and obvious to compare all the stories you're estimating. I also like the tactile nature of the paper cards and the physical involvement of people moving and interacting versus sitting still like they would in planning poker.

Diarised - tool to pick a meeting time

Is it a challenge to find a meeting time that works for your whole team? If your team is distributed and not all using the same calendar system (e.g. Microsoft Exchange Server), you may not be able to view everyone's calendar. Enter www.diarised.com - a free online site where you can propose multiple meeting times and all the participants can select the dates & times they prefer. As organizer, you can then see which times receive the most votes.

A few things I don't like about it:

• You must enter each person's name and email address individually. There is no way to paste in a list of multiple email addresses.
• There is no timezone information - receipts will need to know what timezone the organizer meant.

Can't complain for a free service, though.

Comparing Scrum and Kanban

Henrik Kniberg has posted a good comparison of Scrum and Kanban here. Thanks, Henrik!

Summary of Lean Kanban 2009 talks

Mike Cottmeyer was busy capturing notes on his blog during the Lean Kanban 2009 conference. See his posts from May 6-8, 2009 at www.leadingagile.com to get a summary of all the great presentations.

Lean Kanban Conference

Follow the Lean Kanban conference in Miami in real time on Twitter with the hash tag #lk2009. Some great insights from lean thought leaders.

Great summary of kanban

Thanks to a tweet from Brian Marick, I found this fantastic summary of the Kanban system for software development posted by Jeff Patton. Jeff not only succinctly describes kanban but also sets it in the context of agile methodology.

Lean Thinking: an executive summary

When reading a book I like to boil it down to it's essentials and write a summary. Here is my summary of Lean Thinking: Banish Waste and Create Wealth in Your Corporation, by James P. Womack and Daniel T. Jones.

The 5 lean principles:

• Define value
• Identify the value stream and eliminate waste
• Flow
• Pull
• Perfection
  

Define value

• "The critical starting point for lean thinking is value", which is defined by the customer, in terms of a product and/or service that meets the customer's need.
• "Lean thinking therefore must start with a conscious attempt to precisely define value in terms of specific products with specific capabilities offered at specific prices through a dialogue with specific customers." Align the organization toward products with dedicated product teams.
• Producers tend to continue making what they already are making, and customers tend to ask for products they are already getting, or minor variations thereon. Challenge this way of thinking to discover what customers truly need and want. Example: car manufacturers make cars, dealers sell cars, and customers ask for cars; however the actual product the customer needs is personal mobility. How can the extended enterprise better deliver personal mobility to customers?
• Determine the target cost of the product based on the resources required if all the muda (waste) is removed from the process; work toward achieving the target cost, allowing for reduced prices and/or better product features - leading to higher profit.

Identify the Value Stream and eliminate waste

The value stream is all activities necessary to deliver a product to customers

• Problem solving: Concept to design and production
• Info management: order taking, scheduling, delivery
• Physical transformation of raw materials to delivered product

Identify valuable activities vs. waste (muda)

• Type 1 muda: create no value but unavoidable with current technology
• Type 2 muda: create no value and are avoidable

Example value stream: a can of soda. The stream is dominated by the production of the aluminum can. It takes 319 days to deliver a can of soda to a customer, and only 3 hours of that time is spent actually adding value to the product. The product-in-progress spends more than 99% of its time waiting for the next processing step and being transported - rather than flowing toward completion.

Flow

• After eliminating waste in the value stream, make the value-added steps flow together continuously, with no stoppages or rework.
• Just-in-time production
• Eliminate specialized departments and batches of work done in those departments
• Instead of having large, high-speed machines and putting all machines of the same type in one location, use smaller machines and put all the different machines required to produce a single product into closely located "cells" in the exact sequence required.
• focus on the end product itself and the steps required to complete a single product - via dedicated, cross-functional product teams
• Ignore existing boundaries between companies, departments, and individual roles to envision a lean enterprise focused on "removing all impediments to the continuous flow of the specific product."
• Redesign processes and tools to eliminate rework, scrap and stoppages so production of the product can flow continuously

Pull

• Deliver only what the customer wants, when the customer asks for it, rather than pushing products out and hoping customers want them
• "No one upstream should produce a good or service until the customer downstream asks for it."
• Downstream activities use kanban (simple signals) to indicate to upstream activities when more is needed.
• Right-size your tools and process so you don't need to produce massive quantities of intermediate parts; be able to switch tools and machines so they can be quickly adjusted (in minutes) to produce different parts or product.

Example of flow: Bumper Works (a Toyota supplier) reduced time to produce a finished product from 28 days to 2 days, with much higher quality, by reducing batch sizes, using

Consider the counter-example of a printed book. Publishers produce a batch of books based on forecasted demand to fill the sales pipeline. Result: Long delay between orders and delivery, product shortages, or over-production.

Perfection

• The improvements process never ends: you must always strive to offer a better product while reducing waste.
• Do kaikaku - radical transformation - to eliminate the largest sources of waste, and then do kaizen - continuous incremental improvement - to move toward perfection
• "Form a vision, select the two or three most important steps to get you there, and defer the other steps until later." Keep your efforts focused for better results.
• Don't settle for merely being better than your current competition; eventually someone will come along and beat you.
• Transparency across the entire value stream (suppliers, integrators, employees, distributors, etc.) is required to discover opportunities for improvement

Case studies

The book includes a series of case studies of companies that made the lean transformation, from small family owned operations to huge companies in the US, Germany, and Japan. The case studies focus on manufacturing, but also include product development and order taking aspects of the business.

Revolution in Product Development process at Lantech

How does lean thinking apply to product development? Lantech made a single person clearly accountable for the success of a product over it's entire lifetime (profitability and customer satisfaction). The annual planning process ranked the major projects for the year. Lantech created dedicated (full time), cross-functional development teams for the year's top 2 projects. Teams included marketing, mechanical engineering, electrical engineering, manufacturing engineering, purchasing, and production (including hourly workers from the kaizen team), co-locating all team members.

Wiremold

• Manufactures wire routing systems and power protection devices
• 1400 employees in USA and Canada
• Unionized workforce (Int'l Brotherhood of Electrical Workers)
• Tried TQM (Total Quality Management) and JIT without success before adopting lean

Results of Wiremold's lean adoption over 5 years (1990 to 1995):

• Sales per employee from$90,000 to $190,000
• Time to produce avg product from 35 days to 1.5 days
• Product development time from 3 years to 5 months
• Space required reduced by 50%
• Profit increased 500%

Pratt & Whitney, the jet engine manufacturer

• 29,000 employees and $5.8 billion revenue
• 1993 loss of $262 million, 1995 profit of $380 million, even with sagging sales
• Throughput time fell from 18 months to 6 months
• Inventory reduced by 70%
• Quality problems reduced by 50%
• Unit costs for parts reduced by 20% in real dollars even as production volume decreased 50%

Porsche (Germany)

• Combined lean thinking with German technik - the concept of superior technology

Porsche's results from 1991 to 1997:

• Product development time reduced from 7 years to 3 years
• Throughput time reduced from 6 weeks to 3 days (from welding to finished car)
• Inventory reduced from 17 to 3.2 days supply on hand
• Effort to assemble Porsche 911 or its successor: from 120 hours to 45 hours
• Defects per vehicle reduced by 75%
• Profits in DM: 1991: 17 M; 193: LOSS of 239 M; 1995: 2 M

Showa manufacturing (Japan)

• Makes boilers and radiators, using large batches with long intervals between tool changes
• Invited Taiichi Ohno from Toyota to help in 1983
• First step was to "convert coil making and assembly from a batch process to single-piece flow"

Results in one week of Showa's lean transformation for coil making only:

• eliminated half the plant space required
• reduced in-process inventory by 95%
• Reduced human effort by 50%
• Reduced coil manufacturing time by 95%
• Improved quality

Toyota

• Taiichi Ohno began formalizing the Toyota Production System in the 1940's
• Established the Shusa (chief engineer) product development system under Kiichiro Toyoda in late 1940s
• Began extending TPS to their supply chain in 1969. By demanding continuous price reductions from their 1st tier suppliers, those suppliers in turn pushed lean techniques farther down the supply chain.
• Applied lean thinking to parts production starting in early 1980s
• With the proliferation of different car models, having one shusa per product became unmanageable. In 1992, Toyota re-organized products into 3 product families to share common components, each group led by program managers
• Through Toyota persistent effort at improvement over many decades, it has achieved higher productivity, quality, and on-time delivery rates than it's Japanese, US and European competitors

How to put lean thinking into action

"The trick is to find the right leaders with the right knowledge and to begin with the value stream itself, quickly creating dramatic changes in the ways routine things are done every day. The sphere of change then must be steadily widened to include the entire organization and all of its business procedures. Once this is in hand and the process is irreversible inside your own firm, it's time to start looking up- and downstream far beyond the boundaries of individual firms to optimize the whole."

The authors prescribe finding a change agent with a core of lean knowledge, and say it helps to have a crisis to serve as the catalyst for a change. Start with a map of your value stream(s) and be determined to kaikaku (make dramatic change) quickly to produce results the organization can't ignore. Reorganize the company by product family and value stream.

Comparing agile methodologies

Scrum and XP are by far the most common flavors of agile methodologies - in fact the combination of the two together is the most popular. But what about the others? I found an article that compares Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Lean Software Development, Agile Unified Process (Agile UP or AUP), Crystal, and Dynamic Systems Development Method (DSDM). Part 1 covers XP, Scrum, FDD and lean, while part 2 covers AUP, Crystal, and DSDM.

Tools for distributed team collaboration

Although agile development was originally intended for small, co-located teams, many organizations have now successfully extended agility to multiple teams in distributed locations. The only one of the 12 core agile principles that is contrary to distributed teams is that the most effective method of conveying information is face-to-face conversation. One of the biggest challenges with distributed teams is overcoming the barriers to communication and collaboration. Here are some of the tools I've found useful for that purpose.

• If you're using a physical task board at each location, post digital photos of each board on your wiki daily. Better yet, keep a web cam pointed at your task board at all times so remote teams can see it whenever they want.
  
• Did I mention a wiki? Make it as easy as possible for teams to capture and share written information with a wiki or intranet. Host your own mediawiki, use Confluence, Sharepoint, etc. Or let someone else host it, SaaS-style - plenty of companies offer this service.
• File sharing and collaboration sites. Google Sites and Google Docs is a powerful, free combo for teams to share information. Box.net is another hosted file sharing solution.
• If you're sharing large files between locations, you'll probably need an (S)FTP or SCP server.
  
• Full-duplex speaker phones are a must-have so you can hear all of the conversation.
• Each team member should have a decent quality headset for clear, hands-free audio on one-on-one calls.
• Video conferencing. Many studies show that the majority of information conveyed in a conversation is non-verbal. WebEx allows up to 6 video feeds in a conference. PalTalk is free and it allows a video conference with up to 10 participants. There are many other reasonably-priced video conferencing services, such as iVisit and Megameeting.
  
• Virtual white boards. Nothing beats a white board for a design session or brainstorming. Scriblink, Skrbl, and Dabbleboard all offer free online whiteboards.
• Web conferences with freehand drawing/whiteboard tools. Readytalk has a great feature for drawing right on top of the shared screen in a web presentation.
• Online Planning Poker for estimating work. Thanks to Mike Cohn!
• Scrumworks - the free basic edition is very slick and intuitive for all the basic needs. The Pro version has lots more to offer. I prefer Scrumworks over XPlanner.
• Rally - the free community edition has limited functionality and supports up to 10 users, and the Enterprise edition is very rich and sophisticated if you have greater needs. VersionOne is a competitor to Rally with similar features and editions, but I don't have personal experience with it.
  
• Jira? As I wrote in an earlier post, with some free add-ins you force-fit Jira into an agile process, but it's not ideal. Greenhopper is a reasonably-priced agile add-in for Jira that beats the free add-ins.
• TangyOrange is an online agile task board for less than $5 per month, but it doesn't have the agile project management features of the other tools.
  

Presentation: Distributed & Offshore Agile Development

The slides and a webcast of my presentation at Agile Denver on Distributed & Offshore Agile Development are available on my web site. Many thanks to Amit Malhotra for recording and editing the video!

Definition of Done: UI standards

If you are developing an application with a UI, I recommend adopting a set of UI standards or guidelines to ensure a consistent, high quality user experience. The standard forms a baseline expectation for the team and product owner eliminating the need to explicitly define mundane details for every screen for aspects such as tabbing through controls, initial cursor position, tool tips, progress bars, etc. Instead, those generally accepted best practices can be included in the team's "definition of done" (DoD) for each story / feature.

Here is a list of UI guidelines from Microsoft that can serve as a checklist for your UI. There are others out there, too. If you know a good one, please let me know.

Visas for travel to the US

Why a post about Visas on an agile software blog, you ask? Well, if you have a distributed team with members around the globe, and you believe in the agile principle that the most effective method of conveying information is face-to-face communication, then you might need to have some people hop a plane. Here is a summary of the types of US Visas that you might pursue for offshore team members.

• B-1: for conferences, meetings, business events

These can typically be used for visits of 2-4 weeks, and they must not involve US employment. In the past many companies got away with much longer visits on B-1, but the government has cracked down on that abuse recently.

• H-1B: for temporary employment in the US

Only about 65,000 H-1B visas are granted each year, and most of those are claimed by large companies. Visa holder must be compensated at US market rates.

• L-1: for intra-company transfer to a US-based branch.
  

For L-1 The US & foreign company must share common ownership, and applicant must already be employed by the foreign affiliate. Larger companies can obtain blanket L status.

• H-3: for training at a US company that is not available in the applicant's home country*
  

* Many restrictions apply ;-)

• J-1: “exchange” visitors in pre-approved areas of study.*

* Again, many restrictions apply with the J-1 program.

For all types of visas, applicants that don't have strong ties to their home country (such as a spouse, children, and property) may be denied. There is a Visa waiver program for visits of 90 days or less from 27 countries (mostly European, also Japan, Singapore, NZ).

Allow lots of time for visa applications to be approved, too. Plan on several months for applicants from places like India and China.

Are you thinking about pushing your luck on a B-1 Visa? Tread carefully. Attempting to obtain a visa by the willful misrepresentation of a material fact, or fraud, may result in the permanent refusal of a visa or denial of entry into the United States.

On the bright side, it's very easy for US citizens to obtain visas to almost any country - unless your offshore team is in Cuba, that is.

Problem with Windows Vista VPN resolved

I've been using a PPTP VPN connection from my Windows Vista box for a while, and suddenly it just stopped connecting, and throwing error code 800. After many hours of banging my head against the wall and googling for a solution, I finally found it at this link. It turns out to be related to Microsoft Virtual PC 2007.

"If you have installed Virtual PC 2007 on your machine, it can happen that some windows update (I would really like to know which one) destroy some kind of mapping between VPN connection and WAN Miniport driver."

To fix it you need to uninstall "Virtual Machine Network Services" on your physical network adaptor properties.

Arghhhh.

Jira for agile projects? Get GreenHopper

I previously blogged about trying to use Atlassian Jira as an agile project management tool. My current client already uses Jira across multiple projects and they are reluctant to change tools or spend for new tools. We use Jira "versions" to define iterations. Jira items without a "Fix for version" are part of the product backlog. We installed the free Jira plug-in Custom Issue Order which lets you set the absolute order (rank) of items in a list. Here's a screen shot of it in action, with the "Rank" column added.


We also installed the free Agile Velocity Tracking plug-in.

So far, I must say I'm not particularly happy with the results. It works, but I find myself yearning for a tool that was truly designed to accomodate agile development. Some specific things I don't like:

• I can't drag and drop items to change list order. As a product manager, I'm frequently re-ordering the backlog and it needs to be fast and painless. With the Custome Issue Order plug-in, you have to move an item one position up or down, or type in it's new rank, but either way the page refreshes each time. With a Jira server on the opposite side of the planet, the latency is killing me.
• If the backlog is too long, each user must customize the page size to be able to view all items in the list. When it's split between pages, you can't move an item from one page to another.
• Suppose the team is starting iteration 3.0.2 (2nd iteration toward release of V3), and a defect is reported on V2.1 that must be fixed in a V2.2 release. You can't include this defect in the 3.0.2 iteration backlog because it's based on Jira's "fix for version" 3.0.2, and this item will be fixed in Jira version 2.2. So you have to manage these items separately.
  
• You can't "collapse" a single story to show/hide it's subtasks in the list. This is a feature of ScrumWorks that I really like.
  
• The agile velocity tracking plug-in isn't very intuitive. It might be more useful after our project has more iterations completed, but for now the data isn't very helpful.
• No burndown chart. We tried a free plug-in from Laughing Panda but couldn't get it to work. The closest things Jira has is the progress bar: go to Reports -- Versions -- (a specific version) and you get a graphic like this:
  

The burndown chart is far more useful since it clearly communicates the estimated work remaining (in hours) and the trend line for completing it by the end of the iteration.

My recommendation for co-located teams is still to use a physical task board. If you have a distributed team, or you've tried the task board and have specific reasons for moving to an electronic tool, then I'd recommend Jira + GreenHopper, ScrumWorks, XPlanner, or the free editions of Rally or VersionOne. When I first wrote this post, I hadn't yet tried GreenHopper, but now I have, and it's a great tool. Read about it here.

Kanban in action

Kanban is a Japanese term common in the lean literature meaning a signaling device: downstream activities signal to an upstream activity when they have capacity to do more work, enabling value to be pulled through to a customer in continuous flow. In software, it starts with a ranked backlog of stories/features to be done, just like in agile. But instead of fixed iterations or sprints, the team pulls items the highest priority items from the backlog as soon as it has capacity. Software may still be released on a regular cadence, and the release includes whatever backlog items have been completed on the release date.

This blog post is a great primer describing how kanban was applied at Corbis.

I have always thought that the schedule pressure of short iterations can have a positive motivating effect on team member and keep them focused on the goal, but I realize now that it can also have negative consequences, invoking feat and causing developers to feel pressured to make short cuts and bury quality problems under the rug in order to give the appearance of completing tasks on time. David Anderson addresses this issue eloquently in this post on the kanbandev discussion group. In a nutshell, David describes how the objective in a kanban system is to reduce cycle time while maintaining quality. With those measurements in place, the team is motivated to continually improve but the system is tolerant of missteps and underestimation on individual features. Done properly, a kanban system should eliminate the potential negative motivations that can be caused by iterations.

New generation of collaboration tools

One of my session proposals for Agile 2009 is titled Collaboration Tools 2.0 - Which is Best? I plan to have an interactive workshop comparing the merits of tools like Basecamp, Huddle, Zoho Projects, Sosius, and Google Docs. If you have experience with these tools or others in the same genre, please let me know.

Agile 2009 session proposals

I've submitted proposals to present 3 different sessions at the Agile 2009 conference in Chicago in August:

• Agile Outsourcing in China: A Happy Family
  
• Collaboration Tools 2.0: Which is Best?
• Strategies for highly effective distributed teams

I'd love to get some feedback - positive or negative! You can find my proposals here.

Forrester Research Survey on Impact of Agile

Forrester Research is conducting a survey on the impact of agile processes on technology companies. They are looking for feedback from both technical and business people within organizations. It takes only about 10 minutes to complete the survey, and I encourage people to do so. Take the survy here.

Lean techniques to repair humvees

As reported on NPR, the US Army turned to lean manufacturing techniques, inspired by Toyota, to deal with the large number of war-damaged vehicles that need to be repaired and rebuilt. The repair facility at Red River Army Depot uses a takt time of 16 minutes - producing a completely rebuilt vehicle every 16 minutes, for a total of 32 per day. If that's the true takt time, or course, that would imply that the Army needs exactly 32 rebuilt humvees per day. The NPR story doesn't state if that's the case, but it does say that the vehicles are parked everywhere around the base - let's hope those are the wrecked ones, and not repaired vehicles sitting unused. We all know by now that an inventory of product that isn't being used is muda (waste).

Balsamiq Mockups

What do you use to create mockups of your UI? I prefer a very lightweight approach using a good ol' whiteboard or even sketches on paper. You can capture a whiteboard mockup with a camera, or scan a paper mock up. For distributed teams, though, you can't collaborate very well with either one of those approaches. I just discovered Balsamiq Mockups and after trying it out, it looks like a good solution. It also has a sweet integration with Confluence, Jira, and XWiki.

Using Jira for Agile

I'm working with a team that has been using Jira and wanted to see if they could use Jira for the product backlog and iteration tracking. There are a set of customizations and add-ins for Jira that can make it work, as I found at this informative site. The basic idea is to use Jira versions for each iteration, un-versioned items become the product backlog, and add-ins let you fine-tune the ranking of each item and produce burndown metrics.

I'm still a proponent of using a physical task board when the team is co-located, and I think other tools like XPlanner and Scrumworks are better suited to agile development, but I'll give this setup with Jira a try and report back on how well it works.

How projects really work - a cartoon

I found this great cartoon satirizing how projects really work - or perhaps it should be titled "Why waterfall projects don't work". Funny. Clear. And right on. The cartoon shows what happens when you have handoffs between different people or teams without fast feedback to ensure you're building the what the customer really needs.

TangyOrange: funny name for online scrum board

For co-located teams, it's hard to beat a physical board with cards or sticky notes for tracking iteration status. Put it in a prominent place and it's an ever-present reminder to the team about what needs to be done. It's a rallying point for the daily scrum. If you have a distributed team, however, it doesn't work so well, and web-based tools often are necessary. There is a new online scrum board tool called TangyOrange, which has the look and feel of a physical scrum board. You can use a simple version for free, or pay just $5 every 40 days (strange billing period, I'd say) for the full-featured version. You can play around with it here.