Agile Development

Scrum and Kanban: Where’s the Synergy or Incompatibility?

admin — Fri, 23 Apr 2010 20:25:32 +0000

There’s an interesting discussion going on in the Scrum Alliance Google group about “Scrum and Kanban” which was raised by one of the members (who coincidentally raised this topic last month – but called it “Scrum vs. Kanban”). Does this tell us anything about his position? At any rate, within a few days over 100 comments have been posted as people passionately debate the topic. Some feel that Scrum and Kanban are at odds with each other, while others see a possible synergistic relationship. Others feel that even if you could mix the two processes it dilutes the value of both. Even if you wanted to combine the processes, it is not clear how they can be mixed since, as one person said “Kanban is continuous flow, with no iteration planning, whereas timboxing and iteration is essential to Scrum”. How can this be mixed? Are they fundamentally different things? Michael James, a Certified Scrum Trainer, cautions that we be careful in our definitions as he says in Toyota, kanbans are just cards with ID numbers and barcodes for replenishment. There is a movement in the Agile software development that unfortunately calls itself “Kanban” though it is based on other ideas such as continuous flow and limited work in progress (inventory).

Agile Development Practices East 2010

admin — Wed, 17 Mar 2010 23:46:41 +0000

Hey, agile enthusiasts! Speaking submissions have opened for Agile Development Practices East 2010. Like Agile 2010, this conference is a great place to connect with other agile practitioners and attend sessions with some of the industry’s heavyweights. This year, the conference is happening in Orlando, Florida, November 14 through 19. That might sound far off, but speaking submissions are due by March 29th, so if you’d like to share your process expertise with the attendees, you should get started today.
Head here to submit your proposal!

Tips for Successful Open Source Development (Here’s a Hint: Try Scrum!)

admin — Mon, 18 Jan 2010 18:13:53 +0000

As Open Source development becomes increasingly common, it represents a whole new host of questions and potential challenges for traditional project managers interested in incorporating those practices into their daily operations. Luckily, Andrew Till of Information Week has provided a useful breakdown of how organizations can utilize Open Source development without running into too many headaches.
Scrum and agile users will be interested to read that Till advocates pairing Open Source development with a like-minded project management approach: namely, Scrum or agile. He writes:
“Leveraging open source software isn’t just about finding free code on the Internet and integrating it into your project. It has implications for your overall development model. Instead of traditional waterfall development models widely in use at large companies, open source projects often use Agile or Scrum iterative development methodologies where cross-functional teams collaborate to come up with requirements and solutions.”
Take a look at the entire list of nine tips here: http://www.informationweek.com/news/development/open-source/showArticle.jhtml?articleID=222002603

Are There Warring Tribes at Your Organization?

admin — Fri, 13 Nov 2009 17:23:00 +0000

Over at Dr. Dobb’s, Tim Low uses the metaphor of a “jungle” to describe the current state of application development and likens the tension of competing management methods to warring tribes. For those familiar with these issues, Low’s description of how the “Waterfall tribe” has fallen out of favor with the “Chiefs” and replaced by the much more mysterious “Scrummies” will be an amusing read. And though the article is intended to be humorous, there’s plenty of insight in his extended metaphor.
Certainly, development in today’s rapidly evolving can be quite chaotic, even subject to occasional spikes in influence with management frameworks like Scrum. In other words, “it’s a jungle out there.” And—as I’m sure many readers can attest—developers tend to have strong feelings about which management strategies work and which ones don’t. Many would gladly do battle with those co-workers who disagree with their perspective.
But my favorite part of Low’s article is his description of Scrummies living on an island. Not only does this allude to the fact that Scrum teams self-organize and complete their work in relative seclusion from the managers and stakeholders, but it also gets at how truly different Scrum is from more traditional project management practices. In other words, Scrum’s not even in the jungle! Part of this separation has to do with Scrum’s unique terminology and processes, but I’d wager that the island metaphor also has to do with perceived mysteriousness on the part of traditional managers. Because Scrum demands development teams break from traditional management strategies and truly reorient their mindsets to embrace agile’s values, it can seem like another world altogether.

You can read the post in its entirety here.

Advice on Feedback for Retrospectives

admin — Tue, 15 Sep 2009 17:35:39 +0000

How do you tell a teammate when they’re not pulling their weight? When is constructive criticism helpful? When is praise harmful? If you are on a Scrum team, then these are likely questions you’ve asked yourself when attending retrospective meetings. After all, we all want our teams to excel and improve, but none of us want to hurt our team members’ feelings.
Well, as InfoQ reports, agile guru Liz Keogh helped kick off the week of activities at Agile 2009 on Monday with a presentation entitled “Giving and Receiving Effective Feedback.” To lead her discussion, she focused on a fictional employee, George, who receives a range of feedback. Using these examples, she went on to explain how feedback that is simply positive or negative is not entirely useful. That is, glowing praise may actually encourage an individual to assume that there is no opportunity for growth or skill development, thereby keeping him from advancing beyond the status quo. Of course, venomous feedback is equally counter-productive, as it can discourage an individual to the point of legitimate failure or foster acrimonious relationships among co-workers.
Below is Keogh’s list of positive ways to communicate feedback. According to her, effective feedback:
• Is about the recipient and not the person giving feedback
• Is only from the point of the person giving feedback and not any third parties
• Addressed directly to the recipient
• Includes the things that the person giving the feedback values and not just areas for improvement
• Makes suggestions and doesn’t just complain
• Uses examples and doesn’t speak about generalities
• Talks about things you’ve seen and heard i.e. instead of saying “the whole team was happy with your presentation”, say “the whole team smiled after your presentation”
• Talks about the impact on you
• Asks the recipient for help in making any changes that need to be made
• End with a bright future, the positive goal that everyone is working towards

What have your experiences been with giving and receiving feedback? What strategies do you utilize to make sure it is a productive exchange and not blind praise or one-sided criticism?

Addressing Organizational Dysfunction

admin — Wed, 09 Sep 2009 17:26:42 +0000

There’s a common refrain in agile circles when discussing the dysfunction that keep successful development from occurring at organizations: “The biggest obstacles are always cultural.” That is, there’s no organization that can’t adopt agile or reap the benefits of the process improvements it realizes, there are only those organizations whose people are unwilling to do so. Certainly, dysfunction can refer to any number of behaviors and attitudes which prevent an organization from moving forward and ensure that it maintains a status quo approach to development. In that sense, dysfunction is simply any organizational practice that strands a team in stasis, incapable of the kind of ongoing change and improvement that has made agile so popular in recent years.

There have some suggestions made for how to resolve this issue, including leveraging the Human Resources Department (http://www.scrumalliance.org/articles/125-human-resources-and-scrum), but it still remains a pervasive impediment within the field—even among agile teams. In an article on Agile Journal (http://www.agilejournal.com/articles/columns/column-articles/889-how-agile-practices-address-the-five-dysfunctions-of-a-team), Tathagat Varma discusses this problem by first invoking Patrick Lencioni’s The Five Dysfunctions of a Team: A Leadership Fable, which identifies the five dysfunctions that damage an organization’s bid for highly performing teams:

• “Absence of Trust: Team members who are not genuinely open with one another about their mistakes and weaknesses make it impossible to build a foundation for trust.

• “Fear of Conflict: Teams that lack trust are incapable of engaging in unfiltered and passionate debate of ideas.

• “Lack of Commitment: Without having aired their opinions in the course of passionate and open debate, team members rarely, if ever, buy in and commit to decision.

• “Avoidance of Accountability: Without committing to a clear plan of action, even the most focused and driven people often hesitate to call their peers on actions and behaviors that seem counterproductive to the good of the team.

• “Inattention to Results: Inattention to results occurs when team members put their individual needs (such as ego career development, or recognition) or even the needs of their divisions above the collective goals of the team.”

Insofar as agile practices are designed to create transparency—in its emphasis on communication, collaboration, and self-organization—they directly address many of these issues. Of course, if an individual is unwilling to participate, the benefits agile promises are negated. How do you deal with individuals who remain stubbornly averse to change, even when it means realizing drastic improvements at your organization?

Scaling the Scaling Problem

admin — Tue, 08 Sep 2009 16:37:10 +0000

I just attended an online demo of Danube’s new ScrumWorks Pro 4 and I’m happy to report they’ve gone to great lengths to address those issues facing today’s complex development environments managed using agile techniques. Namely, Danube has built a flexible yet robust system that can accurately model cross-product development. For those of you who have creatively utilized existing agile tools to achieve a similar (though—now that I see what this release can do—far inferior) result will immediately see the value in the release planner view and “epics” potential. In short, these new features allow organizations to monitor progress from a level above the product (usually called “program” or, in ScrumWorks Pro 4, “epics”). Most notably, it allows users to monitor the progress of the multiple constituent components which make up the program, thereby accurately tracking the overall progress of the program. In all, this powerful functionality provides very valuable information that can help shape release date forecasting and prioritization.
I highly encourage you to read more about this release here (http://www.danube.com/scrumworks/pro/release/4.0) or sign up for a trial here (http://www.danube.com/scrumworks/pro/trial).

ScrumWorks Pro + Tasktop = Productivity

admin — Tue, 25 Aug 2009 15:53:47 +0000

I know I’ve mentioned how my team uses ScrumWorks Pro here before. I just ran across a story on eWeek about a new integration that connects ScrumWorks Pro task management functionality with the inclusive IDE Tasktop Pro, which runs on Mylyn. It’s a powerful integration that would allow developers to streamline the relevant applications, documents, and source code within a single IDE. In fact, with the ScrumWorks Pro connector, Tasktop Pro users will be able to quickly turn emails or calendar invites into Product Backlog Items.

Tasktop already employs a groundbreaking piece of technology called the “degree of interest” model, which tracks developer behavior to only present the most relevant artifacts and information to the PBI being tackled. That level of focus allows developers to zero in on the task at hand, effectively ending the cycle of searching that can significantly disrupt productivity.

You can watch a screencast about the connector here.

Complexity Theory and Scrum

admin — Wed, 12 Aug 2009 16:43:56 +0000

If you’ve ever looked into the agile management paradigm Scrum, you’ve likely discovered that the framework was informed by many practices with no direct connection to software development. For example, its most immediate roots are actually in new product development and Lean manufacturing processes popularized by Japanese automakers such as Toyota and Honda in the 1980s. If you dig a little deeper, you’ll find that many agile luminaries also bring up complex systems theory when discussing the origins of Scrum. According to the Wikipedia entry, “complex systems” refers to “a new approach to science that studies how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.”

I just ran across a great article on Scrum’s origins and complex systems theory by Laszlo Szalvay of Scrum company Danube Technologies. You can read it here. Within the article, Szalvay makes the connection between Scrum and complexity theory very clear. To oversimplify the discussion, think of the evolution of human life. Just as humans have had to adjust to survive in a rapidly changing and often unfriendly world (dealing with climate changes, predators, and so on), so, too, must software development react to survive during chaotic development stretches and a tech market that’s changing faster than ever before. There’s much more depth in his discussion, so I’d encourage you to take a look at the full article.

Corporate Culture as Impediment

admin — Wed, 29 Jul 2009 17:23:47 +0000

Talk to any experienced practitioner of Scrum or agile and they’ll all tell you the number one impediment to organizational adoption of agile management techniques is a company’s culture. Change tends to make people nervous. They assume that if change is being implemented, it’s a direct response to their own shortcomings as employees. But the fact is that, when agile or Scrum is introduced, it’s usually leveraged to address a much more deep-seeded problem with how work is being managed. That is, it’s not so much a matter of how individuals are performing as it is about flaws affecting the entire management system. So when organizations suddenly mandate that their employees rethink how they do their jobs, they get scared. Sometimes they get stubborn—refusing to embrace the change or even give it a fair shake.

I just ran across this article by Vin D’Amico discussing the topic. It’s a good start to the conversation, but there are a lot more factors to consider. A great piece I’ve read on the subject is by Laszlo Szalvay of Danube Technologies, which actually advocates leveraging human resources to minimize cultural resistance. You can read it on the Scrum Alliance website here.