Alan Cyment loves seeing software development from a human
perspective. He strives for honest, passion-driven,
great-but-not-perfect emergent design. For software for humans, rather
than machines; looking people in the eyes, rather than reading e-mail.
He organized the first open CSM certification in Latin America in
2006, created the largest, most active agile-software related
discussion group in Spanish, and co-organized the first all-agile
Latin American conference, that took place in Buenos Aires, Argentina,
in October 2008.

Alan is currently the only native Spanish-speaking CST in the world,
and is continually aiming at expanding the frontiers of Scrum,
especially in countries where agility is finding it hard to make its
way forward. He holds a Master Degree in Computer Science from the
Universidad de Buenos Aires, where he spent some time as a full-time
researcher.

Alan also worked as a developer for 8 years in a plethora of business
domains and development languages, until he stumbled upon Smalltalk
and the old paradigm simply fell apart. That was his first, real life,
contact with agility. Working with Smalltalk revealed the magic of
devising the simplest thing that could possibly work. And fate took
him somewhere else, where he had to go back to regular development: it
was .NET this time. There was no way he could possible keep being a
developer. Nothing could compare to Smalltalk. So he became a
full-time ScrumMaster. And then a coach. And then a trainer. And there
he is these days: trying to spread as much as possible the idea that
the answer to “how” is “yes”.

I can’t claim I’m following it closely, but I can’t help but notice the growth of software development and Agile practices in South America.
Indeed. With the increased use of agility in the US and Western Europe, customers have realized that awful communication is the main impediment to productive offshore development. Therefore Latin American countries have become a very sexy alternative to the usual players in Asia. Latin American countries are usually very near from the US and Western Europe in terms of time difference and cultural background, which has helped ignite an incredible growth of outsourcing companies using agile methods in the continent in order to cater for dollar/euro-funded projects.

What unique challenges do you see for software development there?
The pitfalls are common to most offshoring projects. Due to different reasons,
US/European customers usually distrust offshore contractors, especially new ones (and most of Latin American offshoring companies are recent players in the market). They do not state that explicitly, but rather try and compensate for that lack of trust by imposing some “really very ultra uber senior” X (architect, tester, BA, you name it) inside the development team. This person is usually put into place in order to exert some kind of (illusion of?) control over the remote team. Problem is customers don’t realize that there’s no such thing as unidirectional trust. Contractors feel this lack of trust and distrust their clients in return. Lack of trust hinders collaboration. Add to this that most projects that I usually find in this area are small to middle-sized, mostly because of this lack of trust. Projects this small usually have low budgets, which evaporates most possibilities of reducing the communication gap by sending ambassadors, getting all the team together for a couple of sprints and other techniques that partially compensate for the icy communication that team members can have using the different variations of IM. In short, there’s a lot of potential for fairly good offshoring (which will always be cumbersome, to say the least, when compared to co-located development) in Latin America. But in order for customers to make the best use of it, they have to embrace the spirit of agility and not just play by the mere rules they read from a book: a bit more trust, short feedback cycles, considering error as an investment, collaboration, pragmatism balanced with idealism and things could begin to flow a lot more smoothly.

Sometimes we get unique insights from the outside. Do you have any advice for mainstream Agile practice based on your experience and observations?
I’ll do my best: assume that some organizational cultures are simply incompatible with agility, caress and spread the spirit rather than the letter behind agile methods and be humbler when trying to help an organization move to agile methods: if too much oppression is in the air you might end up hurting both individuals and the organization as a whole.

Finally, are there any obstacles to growth and maturity of Agile practice in your country that people from outside might help with?
My take on this is that agile communities in developing countries should learn from their peers in similar communities. There’s a huge corpus out there that we try and make sense of, but I see the usual “hope that some expert who speaks English may visit our region this year” as a huge impediment to building a sustainable community. We have to have our own experts, our own story to tell. We need to change from always being the object to sometimes becoming the subject.

Someone asked me to tell them what I wanted to see most on the program… I couldn’t pick one, but I narrowed it down to two. (this, this and this were in the running for the top spot…)

One is a presentation of ideas that Agile needs to get to the next level, and the other is a presentation I always hoped someone would give, based on my experience with the both of these communities.

These two presentations are Jeff Patton’s ‘No One Wants Your Stupid Process‘ and Pat Maddox’s ‘Growing Up Agile‘.

Jeff’s focus is bringing great products to market. All the Agile in the universe can’t help if no one wants the product. He’s extremely thoughtful and thought provoking. I’ve been an admirer of Jeff’s work for a long time and we’re lucky to have him at Agile Roots (even though he lives in Salt Lake City, the man is in demand and constantly on the road).

I’m most familiar with Pat from his code and contribution to Ruby projects. I’ve met Pat in passing, but never had the chance to really have a conversation. Hopefully, we can fix that at the conference. If his talk at Mountain West Ruby Conference was any indication, this will be a great presentation.

As fate would have it, these two had recent conversation that resulted in Pat posting this on his blog: Are you punching your users in the face?

And if you are, who are you really hurting?

Well…

Are you?

(ok, that was probably gratuitous)

Between that post, and the comments (several of whom will also be at the conference), I’m looking forward to seeing these presentations and the conversations resulting from both of them.

Israel is recognized as the architect of the agile transformation at BMC Software. He holds a PhD in computer sciences from the Israeli Institute of Technology and an MBA from Clark University.

You have been practicing Agile in some form for a while, but I see you are also tracking a lot of new ideas and developments in Agile practice. What are your favorite recent developments in Agile?

I am very excited about three developments:

1. The coming of age of technical debt techniques: The ability to monetize technical debt establishes a clear tie between the output of the software process (the code) and the business outcome (the real value of the code). For example, something is not quite working if a technical debt amounting to $5M has been accrued against a net present value of $10M.
2. The use of Statistical Process Control (SPC) techniques in governing software processes: The enormity of the opportunity to apply the full richness of the SPC research that had been accumulating since the 1920’s to software development is breath taking.
3. DevOps: The expansion of Agile to IT Operations amplifies the value of the Agile initiative. To quote you, it is (software) delivery over development.

The mutual interaction between technical debt, SPC and DevOps is most promising. It facilitates progress from enterprises practicing Agile to agile enterprises.

What advice do you have for executives who are contemplating or in the middle of an Agile transition? What would you focus on first?

I would start with a simple software governance framework that the executive team accepts and commits to. Such a framework governs the software process through the outputs it produces and the outcomes it enables. It elevates the playing fields from the nuts and bolts of Agile (or any other software method) to the business of software – investment, risk, return, etc. By so doing, the foci for Agile become very clear: the teams focus on Agile proficiency; the exec on what Agile means in business terms. To succeed you need both: proficiency in Agile as well as effective governance.

From my experience Agile adoptions suffer when there is not alignment from the executives down and from the engineers up. (Frankly any methodology will suffer) You have published a lot of advice for executives in this regard, what advice do you have for the people on the frontline who are trying to get some executive understanding and support?

Identifying the pain(s) one tries to address through the Agile initiative and securing broad agreement about the criticality of this pain is the most important element in aligning the executive team with the folks in the trenches. Any Agile initiative of scale will sooner or later have to report what has been accomplished by the initiative. Accomplishments to themselves are not too meaningful unless the loop all the way back to the driving pain is closed.

Since you were at Agile Roots last year, what was your favorite thing from last year and what would you say to someone who is considering attending this year?

There was something special in the air in Agile Roots 2009. The experience was most gratifying to me and every participant I spoke with. You can certainly get a glimpse of Agile Roots 2010 by reading about it after the conference has been held, but there is no substitute to savoring it in person in Salt Lake City…

Israel’s e-book, ‘The Concise Executive Guide to Agile‘ has just been issued by the IEEE Computer Society. In addition to regularly publishing with the IEEE Computer Society and the Cutter Consortium, he posts frequently at his blog The Agile Executive and tweets as @agile_exec.

Register Now

Alex, we met last year at Agile Roots, where you gave one of the talks I got the most out of, but take a minute to tell everyone about your background in the software development process and Agile.

I’ve been doing agile development for almost 10 years. I had been been doing ad-hoc development before that. I stumbled upon XP, and had great results on a couple of projects. I was telling anyone who would listen all about Agile development, so I started coaching independently. I spent some time at Thoughtworks working with a few giant companies, and then switched to Rally where I coached a much broader variety of businesses. I had a chance to move into a Product Owner role, and I really wanted a break from travel, so I jumped on it, and that’s where I’ve been for the last 4 years.

Last year, you gave a presentation on facilitating a product council. My personal experience has led me to believe that product owners have one of the most difficult and least defined roles in the software process. (perhaps it is difficult because it is less defined) The Agile community has strong ideas about technical best practices, and how the product owner interacts with the technical teams, but the actual best practice for guiding projects and prioritizing features are somewhat immature in my opinion. Do you agree or disagree with that?

I think it’s because product management is extremely context-dependent – the activities are highly variable depending on your customers, your market, and your product. Also, it’s a communication activity more than it is a production activity. I very rarely sit down and “do product management” the way a developer would sit down and write code. When I do sit down and write out acceptance criteria for a story, it doesn’t matter that much whether I write them in a consistent way. But as a developer, how you write your code really matters.

There are some good basic tools for prioritization. Most people can prioritize a backlog into Must Have/Should Have/Nice to Have buckets, but no two people are going to do it exactly alike. Most companies rely heavily on the intuition of the product owner to do this right.

In “Agile Estimating and Planning”, Mike Cohn introduces some helpful techniques, like Kano analysis, that can help. Luke Hohmann has a ton of great Innovation Games for aggregating the intuition of your customers and stakeholders. Both of these approaches involve adding some structure to your intuition.

At Rally, many of us have been reading Don Reinertsen’s “Principles of Product Development Flow”, and we actually had him come in and work directly with us. Reinertsen is a strong proponent of developing an economic model that allows you to calculate the rough cost of delay associated with not doing a feature, and prioritizing the items with the greatest cost of delay first, and this is something we’ve been exploring.

I’m not sure there’s a silver bullet for prioritization. The tools for structured intuition seem to be most helpful when you’re launching a product and trying to figure out where to focus. We launched my product years ago, so we have a different set of challenges. I would say the most important thing is to have a clear vision based on the needs of focused market you’re going after.

Where do you find ideas or inspiration for improving your own process?

I used to spend a lot of time reading and on mailing lists trying to stay on the cutting edge. But in my role, making process changes generally involve convincing the team. So lately I’m focused on helping the team dig to root causes when we have struggles or production issues. If you go deep enough looking for root causes the solution often presents itself.

Are you excited by any progressive ideas in this space?

I’m still excited about kanban. I think Reinertsen’s book got me really focused on limiting work-in-process as a way to speed cycle time and increase throughput. We’re using kanban at the portfolio level (for product planning), at the team level (shipping features) and at the scrum-of-scrums level (managing multi-team issues, process change, and the like).

It is really hard to get all of your non-development work into the kanbans. In a growing company, almost everyone has a bunch of side projects they’re working on very slowly when they get a chance. If you can make those visible and manage the WIP, things go so much faster.

This might be my bias because of what I have done so far in my career, but I feel like there is much less of a reinforcing community of practice for product owners than there is for developers. If you think that is true, why is it true, and if you don’t, where can people go to get involved? How do you know if you are doing a good job?

At Rally, we have a great team of product owners and we work really well together, so we haven’t needed to reach outside the business a lot for support. But I think a lot of product managers bounce around like pinballs from customers to stakeholders to the dev teams. The role is really focused on being an information conduit, transmitting information from one person to another. Today at work I spent every single hour interacting with other people, moving information around. So sharing information and discussing outside of work is not my first priority when I head home.

Are your customers buying your product? Are they renewing subscriptions? Are they saying good things to their friends about your product? At Rally, our revenue is almost 10x what it was when I started as a product owner, so I suppose that’s good, but there are a lot of other factors involved. It is really hard to tell whether a product owner is doing a good job. It takes a long time to see whether your prioritization bets pay off in the marketplace. I like to say that I won’t really know whether I’ve done a good job until 2015.

If someone was just starting out as a product manager, what advice would you give them?

First, know where you are in the product lifecycle. Jared Spool talks about 4 stages of product development. In Stage 1, you’re in a new market, where the technology is worth the pain, so your early adopter customers will tolerate rough edges in order to get the benefits. In Stage 2, you’re building out features in order to compete line-by-line. In Stage 3, products have become bloated and you need to focus on the experience and simplifying. In Stage 4, you’re supporting a commodity, so you need to focus on scale and efficiency.

As a product manager, you need to behave appropriately for the stage you’re in, and slightly anticipate shifts. If you keep building out features when you should be simplifying, you’ll start losing users very fast. This transition can be hard to make; if you’ve been adding features for years, and had success with that, it can be tempting to just continue the way you’ve been going.

Second, it’s easier to start things than to finish things. Sometimes you can ship a feature with just the stories you’re sure about, knowing it will satisfy half of the target users but the other half will demand a few more stories. This is not necessarily a bad strategy if you circle back and finish the lower-priority stories once you get feedback.

But compared to the next big feature, the last few stories often don’t feel that important. It’s really easy to move on. Agile invites you to constantly re-prioritize your backlog, but just because you can, doesn’t mean you should.

There’s another important recommendation I have, but I’m saving that for the talk.

Thanks Alex, looking forward to it…

Join Alex at Agile Roots

Shall we play a game?
(image from great post about Innovation Games at http://www.philmontgomery.com/ Click the image to read more...)

I believe your work is familiar to most people who are tracking the edge of Agile, but please introduce yourself and your work for those who are not.
My name is Luke Hohmann. I’ve been active in the Agile Community for many years, focusing on the use of Innovation Games® to help organizations solve complex problems across the product lifecycle. Innovation Games® are fun ways to collaborate with customers to better understand their needs. They have been used to improve holistic design thinking, prioritize backlogs and project portfolios, discover new business opportunities, drive strategy and product road map decisions, improve the effectiveness of sales and service organizations, fine tune marketing messages, and create more intimate, durable relationships with your customers.

Prior to my focus on Innovation Games®, I was a Product Manager and Vice-President of Engineering at various companies. I’ve also written three books that cover a range of cognitive psychology, organizational behavior, and business issues associated with creating great organizations and products.

I see your innovation games being applied to all sorts of problems in some really impressive organizations. What are some of your favorite applications of innovation games and organizations to work with?
It is hard to remember all of the many applications of Innovation Games®. Here, though, are some of my favorites:

• Watching several trained Innovation Games® Facilitators do a great job helping the APLN develop their strategic roadmap using both in-person and online Innovation Games®.
• Facilitating a set of global online Innovation Games® to help the Scrum Alliance identify and prioritize new project opportunities.
• Working with customers of Qualcomm to identify a new business opportunity in Business Intelligence.
• Working with customers of Cisco to prioritize hardware and software features for a new product offering.
• Helping VeriSign prioritize a complex IT portfolio through a global set of online games.
• Facilitating several very large in-person games in Monterrey, MX and Mexico City, MX.
• Helping facilitators from Israel, China, Germany, South Africa, India, Mexico, and Korea all integrate the games into their Agile practices.

What part of your work do you find most fulfilling? most surprising?
I love the “aha” moment when deep understanding of customer problems leads to strategic breakthroughs.

I’m always surprised by how creative people can be when you get out of the way and let them.

What do you find is the most common impediment to innovation in organizations?
I can’t think of a “common” impediment. Every organization has its own unique impediments.

Do people ever resist ‘playing games’ to solve serious problems?
Sometimes people are a bit hesitant or cautious to play the games – until they start playing! Then the power of the games kicks in and they genuinely enjoy the experience – while they are solving problems. It helps when people realize that these games aren’t “silly” like going to a Water Park or “humorous” like a joke.

You have worked out dynamics for quite a few games. Do you feel there is a uniting principle to them? and how are they all unique?
The unifying principle of the game is that real collaboration is always rooted in a verb: We want to prioritize a backlog. We want to envision a project plan or a future outcome. We want to understand relationships and boundaries. We want to identify opportunities for improvement. Verbs, in turn, need tools. Not generic tools like chats or Wikis, but specific tools. We have created a powerful set of very specific in-person and online tools for the most common kinds of collaboration verbs.

Anything else you think people should know?
You can do this. And yes, it is fun.

Come and share the Agile Roots experience…
Register Now

Basic


<a href="http://www.agileroots.com/" title="Agile Roots 2010 - Building Great Software">
<img src="http://www.agileroots.com/wp-content/uploads/2010/05/ar2010-badge.png" alt="Agile Roots 2010 - Building Great Software" />
</a>


Attending


<a href="http://www.agileroots.com/" title="Agile Roots 2010 - I'll be There">
<img src="http://www.agileroots.com/wp-content/uploads/2010/05/ar2100-bethere.jpg" alt="Agile Roots 2010 - I'll be There" />
</a>


Sponsor


<a href="http://www.agileroots.com/" title="Agile Roots 2010 - roud Sponsor - We'll be There">
<img src="http://www.agileroots.com/wp-content/uploads/2010/05/ar2010-wellbethere.jpg" alt="Agile Roots 2010 - Proud Sponsor - We'll be There" />
</a>


There is old advice that says, “Be like a duck. Calm on the surface, but always paddling like the dickens underneath.”

The last few weeks we’ve been working on sorting out the program. There might not have appeared to be much movement, but let me just put this out there… choosing the presentations was extremely difficult. We had almost 5X as many proposals as we could reasonably accept. Once we got it down to a pile that we all wanted, there were still roughly twice as many as we could squeeze into the program.

In the midst of that process, between Nate, Kay and myself, two of us started new jobs and the other moved an office across town… which might be why it seemed more like a duck diving…

I’ve never been the one making the decision about what talks to accept before, and I found it sad that there were a lot of good presentations that won’t be seen at Agile Roots this year. If your presentation didn’t get accepted, it doesn’t mean we didn’t like the idea. (I can’t claim that the process was better than arbitrary at some points… I realize now that’s just how these things have to go.)

The good news is I believe we have another great program for this year. We did our best to pick talks that we feel match the theme and complement each other. The lineup includes world class speakers, in addition to new voices providing unique perspectives, in a relatively intimate setting.

There are a few talks on the program that are the ones I always hoped someone would give… (but I’ll keep what those are a secret for now)

We hope you find the program compelling, and in addition promise to deliver good food, the opportunity to make new friends and two days focused on great software… to the best of our abilities.

Wish us luck…

Now back to paddling…