SnapABug, a tool that allows you to embed a screen capture help widget on your site, has taken advantage of the recently released new version of the Pivotal Tracker API (V3) to improve the integration between SnapABug and Pivotal Tracker. SnapABug can now automatically upload web page snapshots as Tracker story file attachments.

Read more about this feature and other improvements here.

We've added Zendesk to the list of applications that Tracker integrates with. Zendesk is a "beautifully simple", on demand customer support help desk system. This integration allows your development team to prioritize and collaborate around Zendesk tickets as linked Tracker stories, bringing development and support closer together in your organization.

To learn how to set up Zendesk integration for your project, visit the integrations help page. Once enabled, you'll see a new panel in your project, allowing you to see and drag/drop Zendek tickets into the backlog or icebox. Story comments and state changes will appear in the corresponding Zendesk ticket as comments.

Note: At the moment, the Pivotal Tracker target in Zendesk does not create linked stories in Tracker. We're working with Zendesk to enable that, and make the two integrations seamless.

Although we’re nearly done with Q1 2010 I thought it was high time to share with our clients and the world the very exciting new journey we have started this year with some changes to the team, vision and structure of Enthiosys.

Team: Having worked with me since 2004, first as a consultant, then as President of Enthiosys, starting in 2006, Scott Gilbert has been invaluable in growing Enthiosys into the leading Agile Product Management Consulting firm it is today.  After years of helping other companies and teams understand and succeed with Agile, he is going back into a senior product management role where he can practice what he’s been preaching, test out new ideas and move the Agile PM tribe forward.  This fits with the Enthiosys’ core value of being able to speak from experience, not just quote ideas and theories created by others.

Rich Mironov also excelled during his tenure as CMO for the firm. Rich was instrumental in honing our service offerings into a cohesive and coordinated set of engagements, improving our messaging, and providing terrific services to our clients. Rich is returning to his solo consulting practice, where he’ll continue to write Product Bytes, champion agile product management causes and work with Enthiosys on selected projects. On a personal note, I was proud to have Enthiosys sponsor the production and publication of Rich’s book The Art of Product Management. Rich continues to provide product management leadership for the upcoming Product Camp Silicon Valley and the product management stage at Agile 2010 – both of which were started and nurtured through Enthiosys. It is especially gratifying to see the amazing and rapid growth of Product Camps around the world.

I sincerely thank Scott and Rich for all of the help they have provided me and the firm during their time with the company and I wish them both the best in their future endeavors.

I welcome Jason Tanner to the staff as President. Jason spent part of 2008 and all of 2009 in the field serving two of our largest customers helping them transition to Agile practices. Jason lived the transition from a ‘traditional’ product manager to an Agile Product Manager and has leveraged his experiences into quality service to our clients. Jason has embraced Innovation Games® in creative ways to increase collaboration for clients and other groups from the Product Camp RTP to the DFW Scrum Users Group.

Vision: While we will maintain a focus on Agile Product Management, this year we plan to expand our scope to Agile product delivery. In 2009, our customers asked us for more than product management consulting. They desired more complete services to build and start exceptional teams with great product managers and terrific coaches. They asked for assistance with development and testing practices with longer time horizons for continuous improvement. As a result, we broadened our network of senior consultants to provide a targeted combination of services to delight our customers. This subtle and important evolution will continue this year. Our offerings will grow with a new selection of services, training courses and content to address customer needs. You should also expect to see us continue to leverage our partners to increase our ability to deliver a full suite of services. Our vision also include increasing the emphasis on our training offerings.

Structure: We launched online Innovation Games® last year and grew the games team to continue enhancing the platform while increasing adoption of the games. Along the way, we started to notice that our clients and other consultants were using the games to solve a variety of serious problems in areas of sales management & execution and corporate strategy—in themselves novel and exciting uses of the games. To better position ourselves to capture these emerging growth opportunities, this year we will spin out The Innovation Games® Company as a separate business entity.

In many ways, these changes reflect the natural evolution and growth of our organization, including the natural growth of Innovation Games®. We’re very excited about 2010, and look forward to serving you as you create breakthrough products and services.

Although we’re nearly done with Q1 2010 I thought it was high time to share with our clients and the world the very exciting new journey we have started this year with some changes to the team, vision and structure of Enthiosys.

Team: Having worked with me since 2004, first as a consultant, then as President of Enthiosys, starting in 2006, Scott Gilbert has been invaluable in growing Enthiosys into the leading Agile Product Management Consulting firm it is today.  After years of helping other companies and teams understand and succeed with Agile, he is going back into a senior product management role where he can practice what he’s been preaching, test out new ideas and move the Agile PM tribe forward.  This fits with the Enthiosys’ core value of being able to speak from experience, not just quote ideas and theories created by others.

Rich Mironov also excelled during his tenure as CMO for the firm. Rich was instrumental in honing our service offerings into a cohesive and coordinated set of engagements, improving our messaging, and providing terrific services to our clients. Rich is returning to his solo consulting practice, where he’ll continue to write Product Bytes, champion agile product management causes and work with Enthiosys on selected projects. On a personal note, I was proud to have Enthiosys sponsor the production and publication of Rich’s book The Art of Product Management. Rich continues to provide product management leadership for the upcoming Product Camp Silicon Valley and the product management stage at Agile 2010 – both of which were started and nurtured through Enthiosys. It is especially gratifying to see the amazing and rapid growth of Product Camps around the world.

I sincerely thank Scott and Rich for all of the help they have provided me and the firm during their time with the company and I wish them both the best in their future endeavors.

I welcome Jason Tanner to the staff as President. Jason spent part of 2008 and all of 2009 in the field serving two of our largest customers helping them transition to Agile practices. Jason lived the transition from a ‘traditional’ product manager to an Agile Product Manager and has leveraged his experiences into quality service to our clients. Jason has embraced Innovation Games® in creative ways to increase collaboration for clients and other groups from the Product Camp RTP to the DFW Scrum Users Group.

Vision: While we will maintain a focus on Agile Product Management, this year we plan to expand our scope to Agile product delivery. In 2009, our customers asked us for more than product management consulting. They desired more complete services to build and start exceptional teams with great product managers and terrific coaches. They asked for assistance with development and testing practices with longer time horizons for continuous improvement. As a result, we broadened our network of senior consultants to provide a targeted combination of services to delight our customers. This subtle and important evolution will continue this year. Our offerings will grow with a new selection of services, training courses and content to address customer needs. You should also expect to see us continue to leverage our partners to increase our ability to deliver a full suite of services. Our vision also include increasing the emphasis on our training offerings.

Structure: We launched online Innovation Games® last year and grew the games team to continue enhancing the platform while increasing adoption of the games. Along the way, we started to notice that our clients and other consultants were using the games to solve a variety of serious problems in areas of sales management & execution and corporate strategy—in themselves novel and exciting uses of the games. To better position ourselves to capture these emerging growth opportunities, this year we will spin out The Innovation Games® Company as a separate business entity.

In many ways, these changes reflect the natural evolution and growth of our organization, including the natural growth of Innovation Games®. We’re very excited about 2010, and look forward to serving you as you create breakthrough products and services.

Trying to change an organization too fast or to too much tends to result in no change it at all. In fact, attempting to transition a company to a new method can cause an organization to go in reverse: it becomes less functional. In an earlier blog, How to Affect Change,I discussed this as the balance of the need for change against the fear of change. Extending these concepts, I want to look at...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

On the road to Agile adoption, I often get asked, “how do you get teams spun up on Agile fast?”  The short answer is to just do it. The long answer is that I believe there are 3 options. 1) Rally and other Agile coaching organizations offer programs that place a coach in your team to help with preparation, planning, estimating, setting norms, committing, tracking, daily stand-up, demonstrations and retrospectives. 2) You can take the DIY approach,  but watch out for the unintended consequences.  3) Finally, I think there is the intensive practice approach.  Let me give you some examples:

A Sprint Per Day for the First Week

While speaking and attending Agile Vancouver in 2008, Linda Rising facilitated a fishbowl exercise with a custom development firm in Vancouver.  Given they were starting and stopping projects and reforming teams all the time, they had developed an approach to speed the team through the formation process and inculcate new team members (employees and customers) to the process.  The would run a scrum sprint every day for the first week.  This intensive process would allow them to work through tons of issues in a very intensive week.  I would call a form of this preparation over planning.

A Sprint Every 90 minutes for a Weekend

If that is not fast enough for you, how about a sprint every 90 minutes?  That is what the folks at SnapImpact did last weekend in Boulder at their SnapCamp (based on the notion of Startup Weekend).

I heard about this from one of the organizers and fellow Sprint Triathlete Dave Angulo.  Dave is co-founder of the non-profit SnapImpact, a guerrilla non-profit that has a mission to “Make Doing Good Easy.”  They developed an iPhone application and Wordpress plugin to simplify how people learn about volunteer opportunities near them.  It takes feeds from HandsOn Network and soon All for Good. It is cool, I’ve been playing with it for a year.  Anyway, ran into Dave at a CTO lunch in the TechStar’s bunker today and he told me about the wild success they had with 90 minute sprint process through the last weekend.

To give some background, SnapCamp was the kickoff effort for developing v2.0 of All for Good, the platform which powers http://serve.gov and a number of other sites. It’s the largest single repository of volunteer opportunities in the world. Version 1.x was pushed into production quickly and, while it is up and running, there have been a number of technical limitations which have frustrated All for Good’s partners and limited the platform’s usefulness. SnapImpact offered to develop v2.0 of All for Good because of the close alignment of the two organizations’ missions and their desire to have a more comprehensive list of opportunities for their iPhone app.

Interview with Scott Stewart of Corporation for National and Community Service

Ryan – Tell me how the 90 minute sprint process worked at SnapCamp?

Dave - We started the weekend with dinner on Friday night to allow time for everyone to meet each other, learn about each other’s backgrounds, and have a shared group experience. We had people from all over the country as well as a great local contingent. Some were die-hard SnapImpact volunteers, others had only heard about us recently. The dinner allowed for folks to get to know one another in a casual setting without having to do it in between trying to get work done.

Saturday morning, we laid out the business problem, context, and goals for the weekend, then I announced we would do 90 minute sprints. The business teams (we had marketing, UI, and product teams as well), would adhere to the same schedule. The beginning of the first sprint for dev was spent laying out four areas of technical problems and having the team self select into what tickled their fancy. Everyone then got to work. I moved between the teams to discuss possible technologies for them to consider and dive deeper on the problems they needed to solve. The volunteers then took over and by the end of the first sprint everyone had a handle on their problem areas. Most even had a initial plan of attack.

Everyone has heard of Forming, Storming, Norming, and Performing. With 2 days to get work done, we had to get them to performing as quickly as possible. The dev teams were all about 3 people in size with differing skill levels and familiarity with the technology stack we were using. The 90 minute sprints forced a tempo which required the teams to get to performing quickly – no one wants to report out nothing was accomplished. Yes, some of the progress initially was small, but these were hard problems to tackle in a weekend. I had one team who’s requirements were being developed by the business team through the weekend, some sprints the deliverable was “received requirements from business and developed a response.”

By the end of Saturday, all of the development teams had produced something which was merged into mainline for the other teams to pick up. That was huge and everyone could see the bar moving.

Sunday started with a review and then everyone picked up where they had left off. The development teams reformed and started working before we even had the morning review. The pace on Sunday kept accelerating, merges occurring after every sprint, until late afternoon, when we started winding down.

I have run many volunteer projects. The SnapImpact team had actually completed one earlier in the week involving several hundred people with BDNT, and it’s absolutely critical volunteers feel like they are moving the bar. Given the scope of this project, it was going to be very easy to have volunteers lose sight of the progress they are making and give up. The 90 minute chunks with progress review and planning helped ensure the volunteers didn’t lose sight of the progress we were making that weekend. As project owners, we had goals of our own on what was going to be delivered at the end of the project. The sprints allowed us to keep moving in the direction we needed to go as well as identify trouble areas.

Ryan – What did not work so well or would do different next time?

Dave – Training – One decision I made was to use a relatively new technology stack, Scala/Lift, for the framework. Instead of holding a formal training session for those unfamiliar with it, I made sure there were experienced people in each group and let training happen “on the job.” I think next time it would be better to do a short training session, as given the pace, sometimes that training disrupted forward progress. Just the basics, so when a concept was discussed it wouldn’t be completely foreign.

Deliverables – We got sloppy during the reviews and didn’t nail down specific deliverables for teams. At times, it caused teams to lose focus during the sprint. The reviews were every 90 minutes, so the lack of focus was caught sooner rather than later.

Insert more fun – Because the tempo was so high, I’m not sure folks had as much fun as they could have during the event. I’m a big believer in fun being central to any successful project and I think teams could have bonded a little more and we may not have been as exhausted by Sunday afternoon. There was some fun, we just needed more.

Ryan – Tell me about the emergent end deliverable?  Can people see it on the web?

Dave – Our goal was a beta of existing functionality by the end of the weekend. We’re very close to that now, but some decisions made during the weekend prevented accomplishing that goal. The SnapImpact team is continuing development and once the existing functionality is in place we’ll start working on a host of new feature requests from the business team. We’re entering all of that information into Rally now and beginning the planning process. Folks will see v2.0 at http://allforgood.org in June.

Ryan – What did you do to prepare or plan for this process?

Dave - Preparation started weeks in advance. My role in this project is CTO and VP of Engineering. So, the 3 critical things I needed to accomplish before the weekend started was making sure I stacked the deck in my favor with some talented people, had a toolbox ready with possible solutions to the technical challenges we would face, and had stakeholders present to make decisions.

Given the new technology stack, I needed to recruit folks with some very specific skills. To enable that effort we recruited the leader and founder of the Lift project, David Pollak. He helped us motivate a few people with experience using the technology. We also had the SnapImpact team actively recruit their friends. The result was a very high quality team capable of getting the job done.

When the teams started work, they would spend too much time investigating everything unless I gave them a starting point. By bringing some ideas (not solutions) to the table to solve their problems, it helped define their playing field and allow them to make a decision quickly. Implicit in this was understanding the known business problems that needed to be solved.

We knew we would hit roadblocks during development waiting for business input on implementation details. So, we made sure to have some present the entire weekend. One of the stakeholders even brought a developer who was using the existing system. We embedded the dev in one of our teams working on implementing some external interfaces. Yes, that really accelerated the implementation decisions. Also, the stakeholders were really disappointed with certain aspects of the existing system. We had ideas to resolve those issues, but needed to ensure they met the stakeholders needs.

Thanks Dave for the great details on this event and example of agility at work!

Ryan Martens is a goat cheese maker,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

We recently stumbled across two flattering articles in the blogospehere that highlighted the Assembla website. 

The first article, Showcase and Tips: How to Create Effective Landing Page Designs, was in the popular website design blog, TripWire, and used Assembla.com as an example of great landing page design.   We're big fans of TripWire and appreciate the time that they put into aggregating and sharing practical advice on a large variety of design issues.

The second article, 50 of the Best Websites Developed Using Ruby on Rails, was featured on Setfire Media's blog, The Matchbox, and ranked the Assembla website as the 13th best site built using rails.  Setfire is a rails-centric development shop in the UK that has been building great software since 1999. 

 

Once upon a time, Frederick Winslow Taylor and W. Edwards Deming lined up across a ping-pong table and went at it.

“There is only one correct way to do any job!” said Taylor, smashing one of those real curvy, tricky serves at Deming.

“Let people contribute in the best way that they can envision,” retorted Deming as he calmly returned the serve from 8 feet behind the table.

“Employees are evil and lazy!” screamed Taylor as he sliced a murderous shot high into the air, the backspin causing a local singularity in the spacetime continuum.

“The success of the company is good for all, and people want to succeed,” offered Deming, backhanding a low shot with sideways spin just over the net.

“Managers are the ones that know the answers!” shouted Taylor, cutting his forehand all the way across the table.

“Hmmmmm,” said Deming, who could be a very thoughtful guy given the right circumstances, “the people closest to the problem are more likely to come up with a correct answer.”

“Supervision!”

“Empowerment.”

“Punishment!”

“Trust.”

And on and on. They never did finish the game.

Here’s the interesting thing: we’re still playing this ping-pong game.

Here’s another interesting thing: many people don’t seem to know it.

Many people make the mistake of viewing Scrum and Agile and Lean as sets of practices. “If I do kanban, I’m Lean.” “If I do sprints, I’m scrummy.” “If I do BDUF and most of my projects are late, then I’m waterfall.” (Oops, well, the last one is actually true, but the first two aren’t.)

The thing is, you’re not Lean unless your company commits to the two pillars of Lean: continuous improvement and developing people. You’re not Agile unless you create and foster self-organizing teams. You might be doing a lot of Agile practices, and you might even get better results than you used to, but you won’t be Agile. If you accept this limitation and you are doing Scrum, then you will be doing ScrumBut.

So I smile to myself (I think it’s to myself) when I hear management say things like “We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all. Lean and Agile fit into the framework of Deming’s System of Profound Knowledge. Plan-driven, hierarchical command & control methods descend from Taylor. You can’t follow both at the same time.

Really? Yes. Would those managers supervise and micromanage some employees while supporting and developing others? Would they dictate commitments and solutions to some while allowing others to determine their own fate? Would they trust the people on the Agile projects and punish the ones on the waterfall projects? Would they hold individuals accountable on waterfall projects while holding teams accountable on Agile projects?

Of course not.

What they will do is treat everybody the way they always have. They will beam with pride when teams gather in their little circles every day, and then they will dictate to them that the manager is actually still responsible for delivery and ask for lists of who will be assigned to which task in the next sprint. They will refuse to make priority decisions and instead direct people to work on multiple projects at a time, and they might even decide just how many design documents each team should have. They will do this because that’s how un-Agile projects do it and for some reason this makes management require it of all teams. (What has always seemed odd to me is that they won’t demand that waterfall teams release an increment of working software each month because the Agile teams do it. So I guess it only works one way.)

And they’ll wonder why this Agile thing gets so much hype, since it really doesn’t seem all that different from what they’ve always done. And really, the results aren’t that great.

You can’t be both Agile and not Agile. You can’t be both Lean and fat…er…not Lean. Not at the same time.

If your company is not fully committed to agility then you won’t achieve it, and your results will be a self-fulfilling prophecy of unrealized potential.

About the Author: Alan Atlas is a Soul Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

I smile because what that really means is that they’ll never be Agile at all. Lean and Agile fit into the framework of Deming’s System of Profound Knowledge. Plan-driven, hierarchical command & control methods descend from Taylor. You can’t follow both at the same time.

dzone_url = "http://www.targetprocess.com/blog/2010/03/fragile-teams-handle-with-care.html";

Recently I’ve read a very interesting post by Anna Forss called “Stupidity of the Team”.  While Anna concludes, that it’s healthy to introduce diverse opinions and invite opposing minds to dissolve the like-mindedness of homogeneous teams, I think there’s one important nuance that shouldn’t be overlooked.

Let’s think:  teams exist for some purpose. To resolve some goals. If it’s a small product development company - then this team exists to develop a product. Permanent rebels are not welcome in any group - because what they do with their rebels, argues, drawing attention to themselves - they blur the focus of the whole purpose why team exists. Of course, a team will naturally outcast this person.  Next, if a team is bombarded by controversial opinions and judgments, they will spend all their time evaluating and thinking if this is right or wrong. They will get busy sticking tags on new opinions instead of focusing on their work - and they will inevitably lose their focus.

Life in a small development team can be compared to living in a sheltered reality, with it’s particular culture. An isolated sheltered reality will not last for long if it’s completely isolated, so emerging on the surface for a gulp of fresh air is really needed.  As a member of a small team - can you remember when the opposed rebels and opinions really did help? When they triggered something that the team would not have thought by themselves? Well, of course, if someone comes up and says - “your UI is bad” - then another person comes up and says - “your UI is bad” - then you start thinking that it’s indeed something wrong with it. You’ve got this signal from outside world. You work on it. Basically, you know what you should work on. The outsider’s opinion has accomplished it’s task - the outsider’s opinion can now go, because you’re not interested in hearing variations of one and the same opinion.  You get to work, and you work to develop a nice new UI.

There’s no need to focus on outsider’s opinions and pay too much attention to them. Outsider’s opinion is just a trigger to team’s actions - it’s not something that the team should busy their brains with all the time. In a way, diversity of opinions may be even harmful. I guess that’s why we’ve got leaders - authorities who tell the crowd “THIS is your Holy Grail”.

My conclusion is: healthy vaccination with opinions opposing a team’s culture is  good. But don’t overdo with them. Too many opinions will not increase collective intelligence for this team’s specific purpose, they will blur it.

var dzone_style="2";

tweetmeme_url = 'http://blog.assembla.com/assemblablog/tabid/12618/bid/11982/RESULTS-from-the-Repository-Shootout-Survey.aspx'; tweetmeme_service = 'bit.ly'; tweetmeme_source = 'assembla';

Thanks to everyone that completed our Repository Shootout Survey. We had over 180 respondents. That's a great turnout.

After sifting through the survey results, many interesting facts and statistics emerged.  However, three stood out above the rest.

1. GIT was the Big Winner and Mercuriual was the Up-and-Comer 
   To borrow a page from Geoffrey Moore's playbook, GIT has definitely "crossed the chasm". Forty one percent of all respondents use GIT professionally at work with subversion being a close second at 38%.  I suppose that this is not surprising given that almost half of all respondents work in companies where only 1-10 people use an SCM system.  However, larger development teams are also leaning toward GIT and SVN.  Almost 1/3 of respondents work at companies where 50+ people use an SCM system and the majority of them use either GIT or SVN as well.
   
   Now, we also asked which SCM systems our respondents would use if the choice were completely up to them.  There were only two SCM systems that a significant percentage of people would like to change to - GIT and Mercurial.  Over 50% more people would use GIT if given the choice (113 vs 75) and almost double the number of people would use Mercurial if given the choice (17 vs 9).


2. Branching/Merging, Ease of Use and Security win the Features Race  "Support for branching" and "Support complex merges" were the most important features amongst our respondents with 90% and 78% respectively ranking them as "Important" or "Can't Live Without It".  This speaks to the fact that more and more people isolate sections of their codebase and only merge it back into the Master once they are certain that is is rock solid. Ease of Use and Security were also important to respondents with over 70% ranking them as "Important" or "Can't Live without It".
   
   So, who were the losers in the features race?  Slightly more people ranked a "Windows Interface" and a "Centralized Version Control System" as not important (the bottom two ratings vs the top two ratings).  And, virtually no one thought that "Subtree Permissions" was an important feature. 
   


3. Hosted SCM Solutions Win on Ease of Use and Reliability    
   Because Assembla is a hosted SCM solution, we were curious to see what the market views as the relative strengths and weaknesses of hosted SCM solutions versus installed SCM solutions.  It was heartening to find that respondents believe that hosted solutions are more reliable and easier to use. 
   
   But, we also learned where we either need to work harder or market our existing features better as respondents felt that installed SCM solutions handled permissioning and continuous integration better.     
   

Thanks again to everyone that participated.  We hope to do more of these surveys in the future.

 

April 9, 2010
Cary, NC
Embassy Suites Raleigh-Durham/Research Triangle
Register: enthiosysroadmapping.eventbrite.com

In fast-moving environments, product development teams can get lost in the gulf that often exists between strategic roadmaps, technical roadmaps and detailed project workplans. A good communication structure bridges this gulf and ensures that corporate strategy feeds technical roadmaps and detailed work plans.

In this interactive session, Enthiosys President Jason Tanner will provide a methodology for developing a comprehensive, collaborative product roadmap that ties together elements of strategy, product, technology, marketing and resources into a complete picture that can easily be communicated internally and externally. The session includes an opportunity for attendees to begin creating their own roadmap, leveraging the Enthiosys-proven approach to planning success.

I have been an Agile Coach for over 6 years now.  I’ve learned a lot during this time, and I’m still learning.

Here are 78 things I have learned so far:

1. Number of people to whom you ask to describe “Agile”  = Total number of Agile mental models  + or -  2
2. Distributed teams need love and a ScrumMaster at each site
3. A foosball table may be one of your best Agile tools
4. Geography is more than a timezone issue; it needs infrastructure support
5. It’s massively worth the effort to stay engaged in the Agile community through local events, online lists, conferences, and casual meet-ups
6. Having a Product Owner is non-negotiable
7. Avoid Cargo Cult Scrum at all costs!
8. Agile teams need to have fun
9. The best Agile teams and companies rely on Servant Leaders
10. Embracing a real Agile culture is often more than one team can create on its own
11. Agile development can only cut costs if you are willing to spend time and money on it
12. A great approach to agile maturing and scaling is Flow Pull innovate guidance from Lean
13. Burndown charts are about the team commitment to doneness, not about individual performance or time tracking
14. Ensure your sprint backlog reflects the delivery of product value
15. Escalation doesn’t serve either the Agile or Lean community in continuous improvement of practices
16. You need to have more than checkbook buy-in from your Executive to be successful
17. Mature your Agile team practices before attempting to scale to more teams
18. Not having a clear signal to end your stand-up can lead to problems
19. The Lean principle on Flow guides Agile teams on how to tighten up their practices
20. Get everyone in your Release Planning meetings if you want true commitment to the Release’s vision
21. Command-and-control ScrumMasters reduce the intelligence of their teams
22. Co-located teams move to being high-performing, high trust teams far easier and far faster than non-co-located teams
23. Frequent communication through site visits, IM, Skype, email, Facebook, Yammer, video conferencing and other technologies help distributed teams gel and feel the love
24. Agile teams invite healthy conflict in order to become great, enduring teams
25. Velocity: it’s about the team not the individual
26. Kanban is helping teams find new measurements for constant flow of value -  so let’s pay attention.
27. No product owner or too many product owners add up to the same Agile adoption smell: no definitive decision on ranking or acceptance
28. A Product Council is an effective way to manage stakeholders and minimize backlog churn
29. Story points help teams separate calendar hour and number of team members from the story’s complexity, effort, and doubt
30. Stories have relative sizes to one another; only tasks take on effort estimates
31. A well-written story (small, about benefit to a role) doesn’t lie; requirements do by their shear volume of content
32. A product backlog is ALWAYS ranked
33. A product backlog is not a task list; tasks only appear after estimating and planning by the team
34. Agile improves the quality of life for employees
35. Great teams are made of collaborative team members
36. Agile doesn’t create the messages it exposes them
37. Pair programming raises team awareness and code integrity
38. Use consensus, not forced compromise or command and control, to gain full team commitment
39. Effective team meetings require structure and discipline
40. Commit to Agile values and principles; your practices will follow
41. Transparency is an Agile virtue not a punishment
42. Agile is about commitment not tools; tools support those commitments and make them visible
43. Product owners who make their decisions in a vacuum are not Agile
44. Agile teams invoke respect and kindness even in stressful times
45. Teams that don’t retrospect are not Agile
46. Retrospectives are not about blame
47. Retrospectives bring continuous improvement of process and working agreements
48. If you don’t have team working agreements, create them now
49. If you don’t hang your team working agreements on the wall, put them up there now
50. Aggressively cap your utilization capacity until you know your velocity
51. Blog your Agile experiences; more people want to hear them than you think
52. Test driven development doesn’t just create better code; it creates better conversations that create better acceptance
53. Agile Architects and Product Owners work side-by-side to rank product backlogs
54. Give your Agile teams a break such as a “hackathon” built into the cadence of the team’s release schedule
55. High capacity utilization is deceptively evil
56. Quality is everyone’s responsibility
57. Small increments quickly inform us about our work and produce feature sets faster
58. Lean has had a great impact on my Agile language
59. “Hiring the best” can be yet another cliche in Agile
60. Hire wisely not cheaply
61. When hiring new members, team consensus is a must
62. Use 5 levels of planning: Vision, Product Roadmap, Release Planning, Iteration Planning and Daily Planning
63. Release planning is one of my favorite Agile activities
64. Teams and stakeholders invite release planning to see beyond the next iteration
65. FYI, good brainstorming requires lots of post-it notes and sharpies
66. Pay attention to your facilitation skills so that you don’t takeover decisions and don’t let others do the same
67. Keep Agile meetings focused, stick to the purpose and timebox
68. Turn your electronics off in Agile meetings; focused meetings are productive and end on time
69. The biggest cost cutting lever in Agile is prioritization
70. Don’t be afraid to try new practices; your velocity and quality may thank you
71. Agile is useful beyond software; take it up and out the organization
72. Old tools stand in the way of new tricks; MS project is not the way to go Agile
73. Team identity is important, individual heroics are dangerous
74. Individual appreciations in retrospectives are a great way to create space for the growth of Agile team trust
75. Agile maturity is NOT about a CMMI-like maturity model
76. The war between Agile and Waterfall is over; get on with your continuous delivery of valued items
77. Agile asks us to slow down in order to speed up; just do it
78. I love Agile.

This is far from a comprehensive list. I still have plenty more to learn about Agile. I’d love to get some insight from you about what you would add to the list.

What have you learned in your experience practicing Agile?

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

It is essential that teams understand what the business value of the stories they are working on is. We must always remember that the software we are developing is useless, in and of itself. What is useful is what it enables – either by our customers (if we are a product company) or by our own staff using it (if we are in IT). Stories always need to be pieces of the business solutions – either...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

dzone_url = "http://www.targetprocess.com/blog/2010/02/agile-ux.html";

Kai Gilb started a series of posts that challenge Agile Software Development. Part 2 is about creativity and “how well” focus in software development. While I agree with the problem, I strongly disagree with the solution. Kai recommends to write requirements (the format he uses doesn’t allow me to call it “user stories”) in a form that does not contain solution:

As a buyer, I want to place a book in the shopping cart vs. It is required that a buyer, by next Feb, can complete a book order of three books, in 1 min.
If by next Feb. it takes more than 6 min., this project is a complete disaster.
On the website it is replacing, it takes 10 min.
Our main competitor has a system, where it takes 7 min.
And after last sprint (if Scrum) we measured our latest version to 6 min. Developers Are Not Product Owners

Then developers should creatively find the ways to implement this requirement, to invent the solution and to solve the “how well” puzzle. We’ve got a huge problem here indeed. Most developers can’t invent solutions at this high level. They can create beautiful architecture and build the quality in. They can write tests upfront and use powerful tools to speed up development. They can do many things, but often they can’t invent a “how well” solution that will make customers happy. Why?

1. Most developers know nothing about User Experience (and don’t care).
2. Most developers can’t create usable design.
3. Many developers barely know a problem domain and in any case don’t want to dig into much details here.

In short, most developers are engineers (so far?), so what Kai proposes will not help. It is just a theoretical solution to “how well” problem. It’s the same like trying to grow 4 hands and 2 heads to double your productivity (well, sacrificing beauty maybe…)

In Scrum Product Owner is responsible for writing User Stories. It means he should invent solutions and care about “how well” thing.  I don’t see a significant problem here. Of course, it’s great if developers are interested in requirements handling and solutions investigation process, but if they are not, Product Owner can do that alone or with special people who care. Who they can be?

Those people are UX specialists. They know how to solve “how well” problems effectively. They know many things about design patterns and all new trends in interfaces. They like to explore problem domain and talk to customers. If you have such people among developers — you are SO lucky! But often this is not the case.

We, at TargetProcess, try to instill UX culture into development process. We started in August, now it’s February and I can’t say we’ve had much success. Sure there are significant improvements, but to be honest most developers are not so interested in UX staff, they like BDD, DDD, C# and SOA more. I expect it will be a long process that will take years. And our company is quite small. I can’t even imagine an effort for such a radical shift in a huge company.

Broad Requirements Are Not Testable

I wonder how you can write BDD scenarios for broad requirements as Kai suggests. How the hell can you test anything, if you don’t have any clue on how it should work? So broad requirements can’t replace user stories obviously. They can live in backlog, but developers should deal with concrete requirements that are testable right away.

I can agree that you can split backlog in 2 parts. The first small part contains detailed stories that can be put to development asap. The second large part contains broad requirements without solutions. That might be a good idea. But we should clearly separate UX phase and Development phase. During UX phase we should solve “how well/how cool” problems, and during development phase we should solve technical problems only (with some corrections in “how well” for sure if required).

P.S. Kai, I hate gray text on gray background in your blog. It is not user friendly.

var dzone_style="2";

This is #3 in a Series on the Culture of Innovation with guest blogger Lee Devin.

Plan to do what you want. Prepare to do what you must.

Don’t get us wrong, we value planning: it’s important and highly creative work. But in the Culture of Innovation preparation means much more.  In a world that defines success as a result and failure as a step along the way , we plan regularly as we adjust to results, outside stimulus, and feedback.  Preparation marches us up the stairs faster and ensures that we’ll arrive someplace new and valuable.

Planning is an exercise for imagination and not spreadsheets.

In planning we figure out what we need to accomplish this task.  It‘s a process of creative thinking, dialogue, narrowing to convergence, healthy skepticism, and risk mitigation.  In planning we need to treat difficulties as a challenge; to resolve a creative tension between reality and what we want.  Teams brush away perceived limits as they press toward understanding by asking WHY?  Thinking in the 5 Why’s of Fishbone diagrams, these teams do not simply work with WHAT and HOW.  Once done and aligned, the plan becomes a communication of intent and result and NOT a goal or commitment.   Dependable results come from a focus on the limits to throughput, sources of failure, and lack of preparation.

In our experience with Agile teams, we see advanced Scrum teams begin to let go of some planning practices as their expertise grows. The benefits of pull-based planning and smooth flow delivery create new space for them in the market.  As a result of their growing confidence, they increase their ownership of their process, a key step on the way to a culture of innovation.   That culture creates, not just one off innovations, but an environment ready to take advantage of opportunities and happy accidents.   A big part of creating that environment comes from a focus on preparation.

Let’s consider preparation. Teams and managers must learn and practice a set of skills that taken together can help them create a culture of innovation. These skills often seem off the subject, not to the point, and therefore difficult for teams and managers to make time for. We think of preparation in three main categories: for collaboration and leadership; for comfort in ambiguity; and for daily productivity. In this brief introduction we won’t suggest a detailed program. Instead, we’ll outline an abstract of the culture, seen through the lens of preparation.

Collaboration and leadership

You can prepare for collaboration (innovative team work) and leadership (team direction and support) by learning and practicing release and concentration. Teams and their leaders need release from tension, as a way to increase available energy and flexibility; and release from inhibition and vanity for freedom, to include the work of others in their own and to regard the success of the team as their own success.

Take a look at athletes for good examples of release from tension; at actors in a play or movie for good examples of release from inhibition.

Watch Sharapova’s face as she looks up at the ball she’s about to whack; see the pitcher take a big breath and whoosh it out before he throws the ball. Look at a still photo of what the pitcher does to his arm in the delivery: it’s not hard to imagine what would happen to those muscles if they weren’t completely released, free of any kind of tension. Look at Paul Newman’s famous eyes blaze with rage (as Harry Manning, dumped in the river: Where the Money Is) or fear (Buffalo Bill astride a fractious horse: Buffalo Bill and the Indians).

We’ll use a story to illustrate what we mean by concentration. Once upon a time two students of Zen walked along the lake shore. They spoke as follows:

First Student: “I have the world’s most amazing Master.”
Second Student: “Have you?”

First Student: “He performs miraculous deeds. The other day he walked right out on this lake and spoke to us, standing on the surface of the water. Then he walked back, and his shoes weren’t even damp.”
Second Student: “That’s certainly amazing. I congratulate you. My master, however, can do something much more important and amazing.”

First Student: “No way.”
Second Student: “Yes way. My master can do one thing at a time.”

Who among us can do one thing at a time?

As you plan your week next Monday, think about these questions.

• What is the #1 Thing you have to get done right this week? Be clear about that to yourself and with your team and put your best time and focus on this one item.
• What preparation or practice can you do to release tensions with regards to this item?
• Who can you collaborate with to make this an outstanding result?
• What can you do to celebrate the results of this effort?

What might you do to prepare to execute these choices? What kinds of practice might you build into your daily, weekly, monthly, routine?

Comfort in ambiguity

Accident, serendipity, new things. Innovation confronts the team with all of these sources of ambiguity. What’s gonna happen? What should I do? What on earth is this thing? How do we know when it’s complete?

How does preparation contribute to comfort in ambiguity? It gives us grounds for confidence in our ability to manage the new, the surprising, the unpredicted. We don’t need to dread the uncertainty of innovation because we know that we can make good use of whatever comes up.

Teams and managers who do innovation find ways to live with uncertainty about the outcomes of their work. They know that outcomes will be unexpected and surprising. If they could anticipate them, how new could they be? Preparation will involve getting free of the reflexive invocation of the past: “That isn’t how we do things here”; and embracing the uncertain future: “Let’s see what happens when we do this.”

Preparation will sometimes replace planning.

Of course we plan, so that we can do what we need to do. We plan to have the materials we need, space to work in, the right people on the team, to make an efficient schedule. Planning creates sequential progress toward a known goal. Preparation, on the other hand, aims at collaborative iteration toward an emergent outcome. No one can predict the results of a true collaboration. We prepare to cope with whatever happens. In a culture of innovation, whatever happens is likely to be new. It will elude any kind of sequential progress toward a known goal. When an outcome doesn’t seem to have any immediate value, we recognize that nothing is lost: we set it aside (Might come in handy some day.) and press on.

The notion of emergent design conditions any serious innovation.  At Rally Software, we do a number of things in the context of Agile software development to keep from planning too much and to hold space for reaction to ambiguity.  First, we acknowledge multiple levels of planning with less precision as the time frame goes out.  Second, we insert free time into our schedule in the form of slack and programmed innovation time.  Third, we work “sets” of designs through a narrowing process to keep from choosing the design before we learn.  Finally, we do not plan until after we have closed the last cycle: We check the results of that last cycle and consciously review our goals.  We “Plan to get lucky” and provide room for that to affect our next cycle.

We took a young engineer to visit an acting class at People’s Light, the theatre we know best. A bunch of teenagers were practicing improvisation. One sat on a bench in the park. Another passed by, stopped to talk. A story began to develop. Suddenly from the class a third jumped up and walked into the park, joining the two. This newcomer brought an entirely new slant to the story. After a moment the first actor remembered an appointment and left the other two. Someone else from the class joined in. And so on. The story grew, got elaborate, got simple, got turned inside out: the kids never repeated themselves, never stopped. No one ever refused the new material offered by an other. The engineer turned to us and whispered: “This is exactly what my guys need to learn how to do.”

This kind of practice fairly closely resembles the desired skills. Engineers like to look for an answer in the back of the book; they need practice in making up answers out of the available material. The kind of preparation we’ll call exercise strays from the skills it prepares for; it’s off subject, away from the actual work. Athletes exemplify this kind of preparation. “The champ,” goes the saying, “is always in the gym.” Larry Byrd was famous for staying in the gym after practice. Why? To shoot 100 free throws. To build a reflexive confidence that supports the hectic innovations of the game. What’s more, the champ has decided, has made the choice, to like being in the gym; how could he do the work otherwise?

As you plan your week next Monday, think about these ways of practicing or preparing for emergent innovations:

• Schedule some creative time into your schedule to spend in a creative place and time.
• Step back from your #1 item for the week and ask yourself a question about its value: What other things could I do to deliver even more of this value?
• Find one example of yourself closing down to new solutions based on the concept that “This is the way we always do it.” Can you release that constraint?
• Ask yourself: What is the most important thing I have to do this month or quarter?  Not urgent. Important. Do I have enough time, support, and space to do this right?  Try removing less important or merely urgent things from your calendar to make room for this.

Daily productivity

In a culture of innovation, everyone chooses a professional obligation to work happily, enthusiastically and at maximum energy.

Artists and athletes again serve as models. Neither group can do what they do unless they’re totally fired up. High morale and physical readiness are basic conditions of their work and they must learn how to create and maintain them, no matter what. An actor arrives at the theatre well before the half hour call (On time is already late.), and begins the day’s work with an extensive warm up. Vocal exercises, calisthenics, stretches, lines; actors have routines they follow religiously.

An actor we know told us this story. He used the 30 minute drive to the theatre as his time for vocal warm up. One night, distracted by some domestic emergency, he only got through part of his routine by the time he arrived at the theatre. In rehearsal he had discovered a way of saying one of the lines in the 2nd act that every one liked a lot: his voice got deep and sexy, very nice moment. On this night the performance went very well, in spite of the truncated warm up. Until that deep sexy part. He said that line exactly as he had done dozens of times before. But instead of deep sexiness, what came out of his mouth was tired little squeakiness. The audience were too embarrassed even to laugh. You can bet that actor never missed another warm up.

In software development, this is akin to doing some manual work outside the scope of your automated build, deploy, test cycle.  It can seem quicker to do a simple, one-off integration or system test outside that environment, but unintended consequences always catch-up .  In our experience, cutting the preparation corners usually costs 10X more in the whole lifecycle than it saves in the short-term. Beyond the interrupts of customer-impacting defects, the team loses a bit of the pride and belief necessary for the Culture of Innovation

Team work demands a no less total performance than acting or tennis playing. It needs, but rarely gets, the preparation of a warm-up. A basketball team combines individual warm ups (stretches, shooting around) with group work (lay up and passing drills). Why should knowledge work be any different? Imagine the energy available if your morning stand up included a vigorous warm up led by a different person each day. Jump back!

As teams and organizations reach an Innovate level of Agile adoption or Ri , they take ownership of their process and environment.  Their improved throughput, collaboration, and preparation have brought them to a place where many of the vanilla iteration, planning, and estimating practices of Scrum and XP stop serving them.  These structures helped the incremental transition down a path of increasing agility, but in a Culture of Innovation, where smooth, continuous flow of one thing at a time is the goal, the focus moves from planning to preparation.

Next up in our series – Options, Fall-back and Design Sets

About the Authors: Ryan Martens is a goat cheese maker,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

Lee Devin is a dramaturg at the People’s Light and Theatre, a Senior Research Scholar at Swarthmore College and a senior consultant with the Cutter Consortium. These activities often interfere with his fishing, and cause him to neglect his grandchildren.

Subscribe today to get free updates by email or RSS.

tweetmeme_url = ' http://blog.assembla.com/assemblablog/tabid/12618/bid/11932/Do-you-prefer-SVN-GIT-or-another-SCM-system-Take-our-quick-survey.aspx '; tweetmeme_service = 'bit.ly'; tweetmeme_source = 'assembla';

At Assembla we are always trying to learn more about which development tools (online and offline) our users prefer and why.  Please help us out by taking this quick survey about the SCM system(s) that you use and prefer.  As soon as we get a meaningful number of responses, we will share the results on our blog.  Thanks.

dzone_url = "http://www.targetprocess.com/blog/2010/02/elegance-is-an-attitude.html";

Recently I’ve come across a post on harmfulness of analogies with martial arts. Indeed, there’s a handful of posts comparing software development, or agile adoption, or product development  with  martial arts  - Aikido, Karate, Judo etc.

If you make a direct analogy of software product development and mastering some martial art, it would not be exactly accurate. I guess  people revert to the analogies as they try to project their copies as romantic martial arts disciples into their usual lives as software developers, managers etc.  Perhaps, they’re making the image of their lives more mission-filled this way since there’s not too much space for showing primeval qualities of warrior in software development. But the need to exercise this attitude is still there, as it turns out.

We don’t have beasts to fight, bloody battles and mortal combats. This wrap-up for courage, strong will, persistence in achieving goals and readiness to fight has remained in the past largely. With no wrap-up, people forget that there’s lots of space to exercise these qualities in their usual life.

Let’s go back to analogies. Roger Federer is an unbeatable specimen of mastered elegant performance to me. Look at the way he plays. No waste. He knows, what to do, he knows when to do what. It’s a perfect flow,  the model for effective lean production with no waste and -  the model for perfect warrior  in our modern life. Elegant, no blood on his hands, but he fights, has pitfalls on the way,  stands up, recovers, marches on and wins gracefully.

But he’s just a guy in red T-Shirt. As many software developers

Another point is that it’s much harder to fight, win and achieve goals when there’s no immediate physical danger involved as in tennis.  Soo much room for elegant warriors, isn’t it ?

The point I’m trying to make is - let people compare their lives and their jobs to whatever they want. If it inspires and motivates them, makes them feel good about their lives and their work - and makes them feel like warriors, achievers, believers, fighters, winners.

P.S.  February 23 is a perfect day for such a blog post Wish you well, guys!

var dzone_style="2";

I had an interesting conversation with Masa Maeda of Shojiki Solutions a few days ago. Somewhere in the conversation the observation that a kanban board was a value stream map (VSM) was mentioned. A value stream map shows your workflow as well as the time it takes to do the work. Here is a simple example: I have been using value stream mapping for 5 years or so. I have seen organizations get...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Humor me. Try this. Find a private place – a small conference room will do nicely. Stand in the center of the room and imagine that you are a boat in the middle of the ocean. The BIG ocean. First imagine that you are a dinghy. [...]

There's a notable difference between working for a start up and working for a large company. One major distinction is focus. Start ups that aren't focused don't tend to last long. Large companies can afford to go many directions at once. But they often do so at a cost. By fighting against themselves with cross purposes they lose some of the leverage that their size could provide.

read more