Posts Tagged ‘Kanban’

Three Days with Damon Poole on Agile Development and its Components

August 3rd, 2010 by kenglert

Agile 2010 is fast approaching, and AccuRev is excited to sponsor andDamon headshot Three Days with Damon Poole on Agile Development and its Components support the Agile community involved with this conference.  However, our excitement is partly due to the fact that Damon Poole, AccuRev’s CTO, was chosen as a featured speaker for not one, not two, but three sessions during the conference week.  I sat down with Damon to chat about his Agile 2010 plans, the ideas behind his session topics, and ultimately, the unrelated topic of my recent exposure to Star Wars.

Star Wars aside, Damon has some great talks about Agile development and components planned for Agile 2010.

Damon’s Discussions on Agile Development and its Various Components

Damon’s first Agile 2010 session will take place on Tuesday, August 10th at 1:30 PM and is titledScrum and Kanban- Like Chocolate and Peanut Butter.”  Here Damon proves Scrum and Kanban are not in fact mutually exclusive, but play well together, much like chocolate and peanut butter.

KE: “So Damon, how did you come up with the chocolate and peanut butter concept?”

DAMON: “I have witnessed infighting within the Agile community, between Scrum advocates and Kanban advocates.  Agile is a way of thinking, and the community wins when there is a synergy between camps.  I want people to recognize that not only can Kanban and Scrum co-exist, they can actually be a very beneficial combination to development teams.”

KE: “Who might this session be best suited for?”

DAMON: “I would say this session is for folks that are already doing Scrum and are curious about Kanban.  I will address Kanban basics, how Kanban can help with real-world process problems, how to apply one-piece-flow to Scrum, and the value of work-in-progress limits applied to Scrum.”

KE: “Since it’s about chocolate and peanut butter, will there be Reese’s?”

DAMON: “You bet.”

__________________________________________________________________________________________________________

The following afternoon, Wednesday, August 11th at 1:30 PM Damon will present “Getting Managers and Agile Teams Out of Each Other’s Hair.”

KE: “This sounds like an interesting Agile pain point that lots of us can relate to.  How do you approach this topic?”

DAMON: “Well, one of the most talked about, but least understood components of Agile is the ‘self- organizing team.’ There is little research published on this concept and I spent a lot of time looking outside of software development for information and advice on self-managing teams.  I came up with new perspective on this concept by examining external roots of the practice.  What it is, what the benefits are, how it works.  I will share my advice on manager roles and responsibilities, aspects of self-organization enabled by multiple Agile development components, and challenges that teams face.  It should be a good session, I have given it before and it’s always well-received.”

_______________________________________________________________________________________________________________________________________________________________________________________________________

The third day with Damon is on Thursday, August 12th at 9:00 AM. He will present “Managing Growth Pains on the Way to 40 Scrum Teams

KE: “Forty Scrum teams is getting up there.  How would you recommend managing such large amounts of teams?”

DAMON: “You’re right, 40 Scrum teams is the sign of a large organization.  I have interacted with lots of large Agile shops that operate with many more than 40 Scrum teams, and noticed issues with Agile weren’t all that different from shops with smaller teams.  By recognizing trends and patterns sooner than later as the organization becomes deeper involved with Agile, teams can start following certain practices to eliminate issues.  When it comes to addressing issues, the sooner the better.

Agile 2010 Badge Template.jpeg Three Days with Damon Poole on Agile Development and its Components KE: “What best practices have you recommended to larger-sized Scrum teams in the past?”

DAMON: “Multi-stage Continuous Integration, small story size, collocation, cross-functional teams… a few more.  This is a good session even if your organization doesn’t have 40-something Scrum teams today.  It teaches you about growing pains and prepares you for future growth.

Well, Damon sure sounds like he has a busy week lined up at Agile 2010.  Make sure to check out his sessions- they are featured on the Agile 2010 schedule and under the “What’s Hot” tab in the Agile 2010 app for iphone and Droid, so don’t forget to add Damon’s sessions to your schedule via these apps!

Follow AccuRev on Twitter @accurev for Damon’s latest updates from Agile 2010!

Blending Agile Practices Into Your Traditional Development Process

June 16th, 2010 by damonpoole

When talking about Agile development, people often ask me, “but why would I want to change to a new methodology when traditional development has made so much money and created so much value for so many people for such a long time? Why mess with success?” That’s a great question!

After hearing that question for the umpteenth time I finally realized something.  It isn’t traditional software development that has provided so much value! It is the software itself. Imagine calling a travel service prior to the advent of software. You call them up and say “I’d like 100 or so options for travelling from Boston to San Jose. I’ll also need a bunch of 3 or 4 star hotels in San Jose and mid-sized rental cars to choose from.  Could I get that in 5 seconds please?”

In today’s world, of course you just go to a site like Orbitz.  It isn’t traditional software that provides that value, it is the software itself.  It almost doesn’t matter what process you use to produce that software, the value is so high. When you are only competing against somebody that doesn’t have software, that’s one thing. When you are competing against other organizations that are also using software, then the exact process you use can make a big difference from a competitive standpoint.

It isn’t traditional software development that has provided so much value it is the software itself.

What do we mean by “traditional development?” After having been involved in the process of literally thousands of software development organizations, I can safely say that there isn’t really any such thing as “traditional development” or even “waterfall.”  That is, if you look at any two organizations developing software, there is no standard for what comprises traditional development.

In the end, organizations adopt individual practices that make sense for their circumstances. This same approach can be used when adopting “Agile.” There really isn’t any such thing as “Agile.” It is a combination of values and practices which can be adopted by any organization and does not require wholesale adoption in order to provide value. Yes, there are packaged solutions out there such as Scrum, XP, Kanban and others, and they do provide value.  But so do the individual practices.  So, instead of thinking about “how do I switch to this new thing,” consider Agile as a new set of tools that you can add to your existing process on a case by case basis. Worry about “being Agile” after you’ve gotten some experience under your belt with some of the practices.