Interview with Ryan Martens, CTO Rally Software Development

We recently did an interview with Ryan Martens, CTO of Rally Software Development. Ryan talked about what makes agile teams successful, tooling for agile teams, agile practices in general and agile adoption. He also discussed the greening of the IT industry and what we can all do to green our own IT practices. It’s an excellent interview and provides some great insights from a thought leader in the agile world. Check out the complete interview here.

XP Practice: Incremental Design

In traditional software development the design phase happens in the beginning of the project, takes quite a long no-coding or little-coding time. At the end of the phase, the design is considered being more-or less frozen. It might sound logical to plan ahead in a detail, however, in the case of software only the final source code is the real design – any diagrams or descriptions can at best be the higher level design abstractions. Therefore attempts to fix the design well in advance often lead to the wrong assumption and sub-optimal solutions.

The XP practice of Incremental Design is a reflection on the fact that the best design emerges from the trial and error. Incremental Design does not prohibit thinking about the highest levels of the system. However, it encourages the team to plan in detail only what is going to be constructed soon and to make the design evolve iteration by iteration based on the current customer priorities and discovered technical limitations.

Naturally evolving the design calls for adopting practices such as Test-First Programming and Continuous Integration that make it easier to change the code without breaking the existing functionality.


  • Is Design Dead? by Martin Fowler – a known article on how the software design can/should emerge in Extreme Programming
  • Emergent Design by Ron Jeffries – an XP guru on how XP’ers come to a good and simple design

This page is a part of the Extreme Programming overview

Many Backlogs for a Single Scrum Team

One of the mandatory artifacts of the Scrum process is a Product Backlog. In its simplest form it is just a flat list of things to do, quite often even without the complexity estimates. Its power comes from the strict order of elements. Customer can call many requirements equally mandatory or must-have, but in the list there is no way to position two items equally high. As a result a team is able to see the clear focus and sense the current expected direction of the project. Product backlog is not static. It changes over time: coarse grained items from the bottom are divided into smaller stories as team comes closer to them, some items are removed and some are added basing on the increased understanding of the area, technology and the market. Still, at any given point of time well maintained product backlog is the primary tool for communicating the current best understanding of the project direction.

Multiple backlogs for a team

Several times I’ve seen the situation, when there is no single product backlog for a team, but there are several “area backlogs” from which the top part of a real product backlog is dynamically assembled before or even during the sprint planning. Naturally it happens more often in the situations, when one team has to develop several projects simultaneously or many teams do many projects.

While this approach can work and sometimes you just have to do it (for example, if there are highly specialized people in the team that just have to support and enhance “their” projects) it always creates some clumsiness. Product backlog is supposed to be dynamic indeed, however, it is also supposed to provide at least rough perspectives on the project future. Many different backlogs are not a simple direction anymore and generate something what product backlog was invented to solve – unclearness about the priorities. If product owner is not able to generate a single priority list, the team is also not able to perceive the real customer priorities.

While having multiple backlogs can make sense in some contexts, in general it is a good idea to try avoiding a multi-backlog situation. Especially if you are not yet familiar with Scrum and are just trying it. Multi-backlog as well as multi-site or multi-team situations can work effectively, however it is not exactly easy.

Your experience

What about your team and the teams around? Did you see teams working from several backlogs at once? How well does it work in your environment?

The Cooper Syndrome

image Yesterday’s keynote speaker at the ESRI Developers Summit was Alan Cooper. Cooper is the author of The Inmates are Running the Asylum and About Face. His talk was entitled Post Industrial Management. Mainly, he discussed how to get non-technical people to have success and achieve their goals with software products. He did make some very interesting and valid points regarding the management and executive view of software development. In particular, he emphasized that organizational structure and technologies that worked in the past are failing today in the post-industrial bit-centric world. I completely agree on this point. Most of what passes for management today is based on industrial management, but the industrial age is over. We need a new wave of executives to find the right organizational cultures and management tactics to support the new post-industrial knowledge workers.

He also hit on one of the topics that I really think is an issue in software management today and that is the difference between effectiveness and efficiency in software development. I have written about this before and feel very passionate about it, and it’s worth mentioning again. Cooper provided a quote from Peter Drucker that I think really summarizes this argument very well:

Effectiveness is more important that efficiency. Business can decline and even fail at the same time that process reform is dramatically improving efficiency by saving money for the company.

I would agree and would argue along with Cooper that ignoring effectiveness to focus on cost reduction is a primary cause of software construction failures.

Cooper also made some great analogies to describe the way software is developed. He doesn’t see software development as an industrial activity. He believes it’s more like a pre-industrial craft in that things are made one at a time, they’re not formulaic, and they are complicated and nuanced. But, he also see’s it as a post-industrial craft with more pieces, built by disparate teams, with abstracted notions and massive interaction between the parts. He described the post-industrial craft of software development as existing in a brittle environment with invisible or intangible products, and working in a world of rapidly evolving tools. I agree with most of that, except I’d like to believe that the products we produce aren’t invisible to our end users.

I really liked the points discussed above. However, I found the remainder of his talk to be a little off-base and very biased to a waterfall or modified waterfall approach to software development. In addition to promoting a waterfall approach, he made several misstatements about how agile teams work and plan. His first comment was about planning. He advocated that to successfully manage software projects, you must have detailed written plans. He also claimed that contrary to engineers’ claims, requirements don’t change. He went on to slam agile practices by saying that agile practitioners say that “We shouldn’t plan because things change so rapidly”. Anyone who has managed a software project using agile practices knows this is a huge waterfallacy (a fallacy about agile spread around by waterfall advocates). Agile teams do plan at many different levels. In fact, studies show that over the life of a project, agile teams do more planning that traditional development teams…they just do it iteratively.

Where Cooper really began to diverge from an agile approach to software development was in his description of what he called The Software Construction Blueprint. Here are the required elements of Cooper’s “blueprint”:

  1. A narrative description of user personas and scenarios
  2. A behavioral overview in narrative form
  3. Detailed form and behavior specifications document
  4. Detailed code examples showing how software will work
  5. Detailed schedule and test plan

According to Cooper, by definition, blueprints are buildable and biddable. If you build the blueprint described above, Cooper wholeheartedly believes that you can give a fixed price bid that you are confident in. Now, I don’t know about you, but I’ve worked on many projects that produced blueprints or whatever you want to call it, but it was heavy up-front requirements analyses. They were not successful! On top of that, our customers are not paying us for all of these narratives and specifications…they’re paying us for working software. Now, according to Cooper, an interaction designer builds this entire blueprint and distills everything anyone needs to know about building the software and hands off the design to a production team that actually builds the software. Because the interaction designer does his job and divine’s every requirement exactly, there should be no questions or problems negotiating the software development minefield on the part of the production team.

I have several issues with this line of thinking. First and foremost, I believe this sets up serious silos within the development organization. It says that the production team has no input on design and design has no real input on production beyond initial design. I really believe that teams shouldn’t have different titles and divided responsibilities. The team is the team, period. Break down these silos and strive for more cross-functional teams. It builds a better understanding of the various project roles and makes for more effective teams.

A side issue I have to throw out there is the fact that Cooper is an interaction designer and really came across as selling his services in the keynote (something I found rather distasteful). Afterward, someone asked Cooper if he or his organization ever builds what they’ve designed. He answered “No, we don’t”. I won’t elaborate here, but I’m pretty sure you’re thinking what I’m thinking.

The bigger issue with his line of thinking is that all requirements can be defined up front and that they don’t change over time. We’ve all worked software projects before and we all know this isn’t true. Customers essentially have some idea of what they want, but as the software is developed and demonstrated, they begin to understand what they really want. In agile, we can address those new ideas or changes without any worry that our big upfront design and planning would have been wasted. But, after asking Mr. Cooper about customer involvement in the production phase of his development model, I completely understood why he believes that requirements don’t change. My question was simple, “Where in the production process do you share completed functionality with the customer and how do you manage the change that is inherent when a client begins looking at what has been developed?” Aside from the relative hostility with which he answered this question, it was evident that in his model, there is no communication or collaboration with the customer in the production phase. Apparently, it is possible for an interaction designer to not only define every last requirement up front, but they also have the innate capability to anticipate every change the client would make and addresses them in the blueprint. I guess it would stand to reason that if you ignore your customers and not allow their voice to be heard in the production phase, you’d think requirements don’t change too!

What really perturbed me was that Cooper said he doesn’t believe that the customer even knows what they want, and that the interaction designer knows better than anyone what they need. I take real umbrage with this assertion. Essentially, his opinion was ignore your customers, you know what they need. This to me is a real problem in the software industry. This kind of thinking is exactly what leads to the 65% of features in most software that are rarely or never used (Check out the Standish Group’s CHAOS Report). Having someone of Cooper’s stature stand up and advocate this is not going to do anything good for the software development industry. And, considering the already low rate of agile adoption in the GIS development world, the last thing that we needed to hear in a keynote session were these toxic, old-school notions of software development. I’ve been searching for a term to describe this way of thinking and thanks to the keynote speech at the Dev Summit this week, I think I have one now…The Cooper Syndrome. Maybe at next year’s Dev Summit, Dave Bouwman, myself, or someone else can give the agile counterpoint to the Cooper Syndrome.

If you want some more insight on the keynote, check out Brian Certain’s blog post on the keynote.

Certified Product Owner – interview with Mike Cohn

Last week while taking the Certified Scrum Product Owner course in Oslo I had a pleasure to have an interview with our trainer Mike Cohn, an author of Agile Estimating and Planning and User Stories Applied. Mike shared his point of view on the value of yet another certified Scrum Alliance course and provided advices for those going to become Scrum Product Owners.

Artem: Certified Scrum Product Owner class is brand new Scrum Alliance offering. What’s different from the Certified ScrumMaster class and who needs to go to the Product Owner class?

Mike: The Certified Scrum Product Owner class is for anybody who seems to be more in the business side of a project. Product Owners, analysts, people who might be working on what XP would call a customer team – those are the target audiences for the Product Owner class. I see the biggest differences in that ScrumMaster class is really oriented at both ScrumMasters and teams. The Product Owner class is aimed more at the customer side of things, meaning less focus on solving team problems, overcoming impediments, and doing those kinds of things. In the Product Owner classes I teach a lot the focus is on user stories, managing the product backlog, using the backlog as a scoping tool. It’s about prioritization, optimizing value delivery, things like that.

Artem: Why would anybody want to go to the Certified Scrum Product Owner class?

Mike: I hope that somebody would want to go to the Product Owner class so that they could learn how to those things. There are a lot of Scrum teams these days that are doing well, but just being good at Scrum doesn’t mean you are headed at the right target. So a Product Owner class is going to help somebody learn how to aim his or her team at the right goal. If you are going fast but not at the right goal, you are not going to get where you want to be.

Artem: What is it that is “certified” about this class? What the certification is about? Am I going to be the better product owner after this class?

Mike: Well, I hope you’ll be a better product owner from this class, but I think that’s independent of whether it’s called “certified” or not. There are a lot of people who like the word “certified”, want to use it as a distinguisher. I think all that the certification really means is that the class is the Certified Scrum Product Owner class. You know that it’s being taught by a Scrum Trainer who has been approved by the Scrum Alliance. I think that’s the main part of the certification. At least you know you are getting quality training. I don’t know that if somebody goes to a class but barely pays attention (which can be hard for the trainer to know) is going to be a whole lot better. But somebody who engages in the class and participates in exercises and discussion will be a better product owner.

Artem: Do you mean that the word “certified” is actually more about the quality of the class, than about the skills of an alumni?

Mike: Yes, right now I think it’s more about the quality of the class, than about “you have attended a class and I as a trainer certify you as being a wonderful product owner”. I can’t do that in a two-day class. All I can do is to try making somebody better.

Artem: About your personal product ownership experience. What’s the biggest product you product owned or helped to product own?

Mike: The biggest one was a health care application for which I was the product owner, did essentially the entire product owner responsibility for that. That was probably the largest one.

Artem: Something life critical?

Mike: Oh, it wasn’t life critical. Well, sometimes. It was a triaging application – people would call and speak to nurses and get medical advice. It wasn’t something like running an ambulance or heart monitor, or something like that – it was about giving a critical advice for people.

Artem: How big was it? Twenty people, one year?

Mike: That one grew to, I think, about fifty people at the most on that project. I was involved for six years but it continued after I moved on.

Artem: What was the most difficult product to product own an why?

Mike: The most difficult product that I was a product owner for was one in a bioinformatics domain, where we had a chief scientist, but he couldn’t really speak to developers. So I had to take the requirements from him and act essentially as the product owner. He in all senses should have been the product owner, but he was in another city and couldn’t relate to the developers, so I had to kind of fill that role. It was very difficult – I am not sure how well I did it, because of the challenges of the remoteness of the chief scientist and the domain. It was just incredibly complicated – I am not a scientist, so working in a bioinformatics, where I didn’t understand most of the vocabulary even, was very difficult to me.

Artem: You were telling couple of times that whenever there are a lot of interests in the organization, a product owner should better be a single person and that a team should concentrate on a single product, but what will you do if team just has to support several projects with sudden bursts of maintenance needs for the previously silent projects? Do you think that a common backlog and single product owner still make a lot of sense if the team just has to support several projects?

Mike: A team can support multiple projects, but they really need to be getting their guidance from one person. They can’t go to three people and say “what do you want us to work on next?” There has to be one person who is setting the relative priorities of those three products. So I can be a team member and work on a number of different things as long as somebody is setting those priorities for me and telling me “this one is the most important. If you have time, work on this other one.” Some one person has to do that. It is unfair to put a team in a position of having to balance its projects against each other.

Artem: In my own history I had a situation once, when there was a single team, single product owner, but then they had to support several projects. They tried putting everything into a single backlog, but then it became a huge mess, when items from really different projects came into a single list and then they just had to split it into several smaller backlogs that were dynamically assembled into a single list by the moment of sprint planning.

Mike: There has to be a one product backlog. I don’t really care about the mechanism as long as there is one person who can adjust the priorities for the team whatever mechanism they use for it. I’ve seen that done with one backlog, I’ve seen that done with multiple. I like falling back into kind of programing concept of Model-View-Controller. I’d like to have one backlog, but I’d like to have multiple views into that backlog. Sometimes you need to see it as a one backlog, other time it’s too confusing to see that – then I’d like to see just my part of the backlog.

Artem: What are your top three tips for the new product owners?

Mike: A product owner has to prioritize. I want product owners to take it very seriously, but I want them to listen to other opinions. I want them to talk to architects who may have opinions about technical risk and programmers about why it’s easier or better to do something. So I would tell product owners to:
1. Take prioritization very seriously
2. Make sure you don’t do it on your own. It’s not all just business value. There are other things: technical risk, the amount and significance or what we’ll learn by doing a feature and so on.
3. Not to disengage from the process. It’s very frustrating for the team to be trying to go as fast as possible and not have access to their product owner.

Artem: Where the new product owners should start?

Mike: I think product owners should start by figuring out a backlog for the product. That’s normally where I would start. I like user stories, so I would start up by writing the user stories that describe the product. Typically I would try getting my own head around the product. I’d involve the team, we’d get our heads with what the product is going to be and then very likely do something like creating a vision box describing what we think this product is going to be. Writing an elevator statement or designing a vision box is what that helps us glue the vision in everybody’s heads. Then I would write stories.

Whether Certified Product Owner class is worth taking

Disclaimer: I came to the class, because I already knew Mike as one of the best trainers I’ve ever seen. I have also been to several other classes by him. It might have made my opinion biased.

Since after I went to product management and found out that Scrum Alliance started offering the Certified Product Owner (CPO) classes I was thinking about taking this class, but was not really sure. After all I did know what Scrum was about, had quite some practical and consulting Scrum Master experience, I was even educating some Product Owners around. What new could the Product Owner class offer to me?


This week I devoted two days of my Oslo trip to the CPO class by Mike Cohn and can share the impressions with you. The class goes deep into the needs of the Scrum Product Owner and covers pretty much everything a decent agile leader would need. It includes general overview of Scrum, techniques for coming up with the vision, building a solid product backlog, effectively guiding a cross functional team, etc., etc. There is nothing like the practical experiences and plenty of exercises included make you feel the real “product ownership” as much as it can be done in a classroom.

The bottom line for me is that the CPO class is well worth its money and is clearly distinct from the old good Certified Scrum Master (CSM) class. CPO won’t provide you with as solid understanding of the Scrum process mechanics as CSM, but will arm you exceptionally well for playing the Product Owner role efficiently. It is hardly possible to start implementing Scrum with the amount of knowledge offered by the CPO class. However, once you get the process started, CPO will help you get most of the development effort. Highly recommended for those in charge of the success of the software based products.

What is in it for you?

What would you expect from the CPO class? Also if you are interested in knowing more about the course, feel free to ask in the comments, I will try replying as accurately as my memory allows for.

DTS Agile launched today

We’ve pulled the trigger and launched DTS Agile, a new division of Data Transfer Solutions.

DTS Agile was founded with a vision to share our knowledge of agile software development patterns and practices with others. The team at DTS Agile is an active software development team that has completely embraced agile practices to deliver high value, high quality software to our customers. Whether we’re building custom enterprise GIS systems, helping organizations fix problems that other development teams have created, or helping organizations improve the effectiveness of their development teams, we use agile practices to guide our work. We have built the agile foundations of collaboration, transparency, feedback, and reflection, into every aspect of our work; from software development to project management practices, from executive management to accounting.

Through our real world experience, we have gained valuable insights into what works and what doesn’t work. We’ve made the mistakes and learned from them first hand. We want to share our experience through agile training, coaching and consulting services with others in the software development community so that they can break free of the detrimental patterns and practices of outdated software development methodologies and truly deliver value to their customers.

Check out our new website at for more information about our cool new venture.

Results of Agile GIS Survey 2008 available

Well, the polls have closed, the results have been tallied, cross-tabulated and graphed for the Agile GIS Survey 2008 (and unlike the Democratic primary race here in the U.S., we have a conclusion).  A complete whitepaper detailing the survey results and conclusions is available here.  A summary of the survey results is available here.  A version of the whitepaper has also been published by Directions Magazine on their website and is available here.

Bonuses in an agile organization

How do bonuses work in an agile organization? Is it better to do iteration or project based bonuses? Get some great insights into this topic from Bruce Scott, one of the co-founders of Oracle. Bruce provided me with real world metrics from some of his current development teams that he provided “Agile” bonuses to. It’s very interesting and worth taking a look at. Check out my personal blog for the details, or click here to view the post directly.

Value of Agile Certification

Today in the evening I am leaving Finland for the Mike Cohn’s Certified Product Owner (CPO) course in Norway. The last couple of years I was mainly focused on the in-team part of Scrum and after moving to product management I feel the need to refresh my knowledge about the external side of the process. Mike is an excellent trainer and is a very pleasant person himself. Every time I meet him I learn much from his talks about both the theory and the practical experience.

Agile certifications

It reminded me about a number of recent discussions on the value of certifications in the agile community. The proponents of the certification processes usually argue that both community and companies want to have means for distinguishing amateurs from the specialists. The opponents typically point out to the fact that agile principles are that intangible and people oriented, that it is hardly possible to craft a test for verifying the relevant skills. And even if it was possible, the most widely used form of agile certification – Certified Scrum Master (SCM) certification doesn’t include any kind of examination – you only need to take part in the session.

Certified Scrum Master

I became a Certified Scrum Master about a year ago. During this year I’ve convinced many colleagues to go for the CSM certification and was all the time gathering references (the positive/negative reference rate by the moment is about 7/1). The bottom line for me is that the word “Certified” in the name of the course should actually be applied to the quality of the course and the trainer, not to the fact that the course alumni is automatically a specialist. I came to the conclusion that Certified Scrum Master courses provide extremely consistent and comprehensive knowledge delivered by the experienced professionals and nothing more.

Your opinion

What is agile and Scrum certification for you? Are you going to take the CSM or CPO course? Or if you took it, how useful was it for you?