Problems with Mingle Project Management

I like Mingle, but it's not perfect. I've posted a few times about the benefits of using Mingle, so now I'll mention the problems.

We had read of performance issues, but I experienced where the cliff is. We have Mingle running on a virtual server with 4 GB of memory. We created a custom project using one tree and approximately 15 fields in the card. As we approached 1200-1500 cards in the project, performance dropped significantly. Users could count to 10 - 30 before items loaded, especially in grid view. As we neared 2000, grid view failed completely. Users new to Mingle started asking for another tool. Stakeholders in planning meetings would lose their patience waiting on it. My advice is find a way to keep bugs and features separate. Delete old, fixed bugs, and be disciplined to keep the features list (product backlog) short. Why keep low priority items when there are months of highs in the list?

Exporting data is a pain. Cut and paste text into Excel gets you by, but you can't use any filters (WHERE clause) nor choose what fields to include or exclude. You get it all. Massaging it into something useful for management can become hours per week if you have large backlogs.

As far as I can tell, you can't enforce data integrity. I tried without success. And garbage in\garbage out feeds the two items above that can become a monster.

The project templates look wonderful (XP, Scrum, Agile Hybrid), but there's only one thin page of documentation on their site for each one on what comprises each template. Trying to figure out how to use them (what the workflow is, the objects, details) is essentially up to you. Don't get me wrong - I really appreciate these views into how Thoughtworks does agile project management, but as I kept poking around, feeling like I was trying to put together the lifestyle of some ancient race based on artifacts, I kept thinking, "The creator of this template could have taken one day to document it and the whole world would be ready to go." As is, the whole world will play Sherlock Holmes and my guess is many will give up and go to what they know and lose out on a great agile mind-share opportunity.

agile, scrum, xp, extreme programming, project management, mingle

Agile Planning Poker Rules

I posted earlier on planning poker, and since it's a popular post, I thought I'd post again on it.

One item that came up in a recent sprint retrospectives (in the "Where do We Need to Improve?" list) was getting better requirements and estimates. So, after the following planning meeting, where the CEO selected his highest priority items, the team met to review those items.

The meeting seemed to be another poor meeting of nothing definite or different being done - lot's of "Well, I'll need to look at that one more," or "Well, management says it needs to be done by next week, so what does it matter how long I think it will take?". I was ready to call the meeting until Martin asked about the planning poker cards (shwag from Phil Scott at the Agile Panel Discussion at the LA Code Camp). He hadn't used them before so we walked through the instructions:

1. Each team member is given a set of cards.
2. One person read the item to be estimated.
3. The team & customer discuss the item.
4. Each team member privately selects a card representing his/her relative estimate.
5. After all have chosen a card, everyone shows the chosen card.
6. If all estimates match, that item's estimate is complete.
7. If estimates are not the same, the group discusses the differences (focusing on the outlying values).
8. Repeat until consensus is reached.

Few notes on modifications we made to the rules -

• We don't have any business members there, but call in the requester if needed.
• We re-estimate until within one card value of each other, or take the median value if there's a majority.

The team really enjoyed, and benefited from the experience. The secrecy of each persons' pick not only made it fun for them, but it got each person so plugged into the task at hand. There was kidding of those who's estimates were way outside the norm. For outrageously low estimates, we rewarded the low-bidder's confidence by giving them that task, but with an agreement that if they met the estimate, we'd buy them lunch. It was particularly enjoyable to see how much this engaged Jeoff, our only team member with the strength Competition. There was great discussion on all the tasks the team had ahead of them, and we left the meeting with a lot more shared knowledge, both where we're weak and where we're strong.

You can buy planning poker card sets from Mike Cohn's Mountain Goat Software site.Technorati Tags: agile, scrum, project managment, software, team building

Agile Leadership Coaching Quotes

I was at a leadership coaching event and had these quotes as good takeaways. Although the training wasn't specific to agile environments, I think they all apply quite well.

• It's a leader's job to make the goals clear, and the team's to make it work. 
  
• In a dynamic environment, it's more important to have strategic positioning than strategic planning. 
  
• The fix for bad leadership isn't teams or teamwork, it's good leadership. 
  
• You don't know what you're capable of. 
  
• There's often a gap between information and application. 
  
• What are your growth hashmarks? Because speed acclimates and it will be hard to tell if you are growing as a leader or not.
  
• The ideal situation is the right job [or role] + the right mindset.