Secret sauce of offshoring and distribution – summary of Scan-Agile open space session

This Wednesday on the first Scandinavian Agile conference in Helsinki I was running an open space session about what works and what doesn’t work with distributed and/or outsourcing teams. During the two hours we had an excellent discussion with many people in various roles from offshore customers to ones working in an outsourcing company to people being pushed to distribute, from product managers to Scrum Masters to developers.

A lot of the discussion results are intangible and stay in the heads of the participants and I didn’t record the excellent discussion on feature teams VS component teams VS functional teams in the case of distribution. Here is the brief summary of what was commonly acknowledged to be working and not working in cases of offshoring and distribution. Use at your own risk.

What doesn’t work

  • Distributing for cutting costs. Whatever attractive cost cutting might sound for business people, the problem is that value of software development is way more difficult to calculate, than the programmers’ salary and if your only motivation is to cut costs, you might be loosing way more, than you are getting without realizing it. Some studies report that with the careful calculation you may loose way more, than you are getting.
    • Also when many business people read the same cost cutting books and are pushed by similar shareholders, the demand for programmers in the "low cost" countries raises that quickly, that prices go up and it is not that low-cost anymore. Some companies started realizing that and are actually moving jobs back to the main site.. at least they were doing that before the current financial crisis.
  • They come, learn and go. For the same reason of high demand for programmers, the turn-over in the typical outsourcing countries can be that high, that any people you see are newbies who learn new technologies. Once they learn, they go for continuing their career in a different place.
  • Investing in coaching people in remote location. Because of the same high level of turnover, you might find out that you are investing into people.. who will go to another companies and position very soon.

What works

  • Expand globally, when you don’t have skills or talent available locally. For example, in Finland all the guys skilled in Linux programming seem to be hired by just a couple of companies. If you want to hire more people, you have to look in the other countries.
  • Get good guys only, Start with motivated individuals. Getting good guys is important in any kind of business, but it is twice as important in the case of distribution, especially in the start-up phase. Distribution is adding enough challenges on its own. Hiring the mediocre people might make it unbearably difficult.
  • Synchronization, synchronization, synchronization. Whenever you get a multisite configuration, there is a communication barrier and it is twice as important to make the problems and issues as visible as possible. Invest into daily or ideally continuous builds, extensive automated test coverage and communication tools such as wikis and video conferencing.
    • Invest into good communication tools. Tandberg video conferencing are expensive comparing to the telephone, but they make the communication so much easier that I would wholeheartedly recommend considering the video conferencing seriously (Note, I am not affiliated with Tandberg in any monetary way)
  • Small business. A particularly good type of a customer for offshoring seems to be small and very small business in the Western countries. The scale of the business makes such customer count money well, invest into making sure the development team understands what he wants and such customers are often eager to embrace early releases and provide continuous feedback.
  • Start together (meet live). When starting the distributed project it proved to be effective to colocate team or at least some members from remote and main site teams for a reasonable amount of time such as several weeks to several months. That helps building the common understanding greatly.

General conclusion:

General conclusion was such that outsourcing and distribution is rarely a good thing if you count actual costs really well. With the few exceptions, the only case when it works is when you distribute for getting local talent not available at your main site or when you expand to get connections to the local market. In any case it is more efficient to become efficient on the main site first and expand to many locations after that.

What is your experience in the distribution and outsourcing? Does it work for you? If it works, what is your secret sauce?

Video tutorial: Test Driven Development with Mock Objects


In this eleven minute tutorial I’m presenting TDD with mocking technique using JUnit 4.x and EasyMock library. This is more advanced example of Test Driven Development – video tutorial on basics can be downloaded from here: Test Driven Development in practice.

Source code for this tutorial can be downloaded here (you can find also Eclipse project files in this bundle, so it’s easy to import the project directly to your IDE – NetBeans users have to create a new project and add relevant classpath changes). Note that external.jar was built with Java 6 and thus you have to use at least JDK version 6 to be able to compile and run the example.

Enjoy and comment the video if you find it useful or useless. I’m really curious what you think about the video as well as about the mocking technique in general.

Finding a Partner to Trust – Using Competitive Sprints to Select an Agile Software Vendor

Some people would like to believe that building complex software
is like going to the grocery store: pick a candy bar off of the
shelf, ask what it costs and decide to buy it. You get no risk and
quick gratification. But building custom software is more like
building a race car. A special one-off product to meet exactly the
needs of its sponsor: win races.

As a customer, what are you really buying when you contract for
software development? You may think you are getting a solution. But
what you are really getting is an implementation team. And risk is
always part of the bargain. So what you really want is a team you can
trust to build your product and to minimize the risk of that choice.

In this article, I present a lightweight, lean approach to
selecting a software development partner which should dramatically
reduce the risk and cost to all parties.

Project Risk

A customer will often invest substantial effort into creating a
Request for Proposal (RFP). I’ve seen RFP’s whose size is measured in
binders and the effort to produce them measured in Man-Years. A
vendor will often invest a lot of effort into winning a big project.
On both sides, this effort produces mostly paper, i.e. artifacts of
no value except as means to the goal of selecting a vendor.

On the vendor side, this effort has to be amortized during the
execution of the project itself. As there is only one winner, the
others make a substantial effort and earn no money. So bidding on big
projects is expensive and risky.

Competitive bidding can mean offering ruinous prices. When
“winning” means producing at a loss (sometimes to the
point where the supplier
goes out of business
[English translation]),
even the customer loses. The supplier may have no choice but to play
the change-request game to achieve profitability.

How do you maximize trust and minimize risk and cost? Customers
are often willing to work with agile companies on a time and
materials basis, once the trust has been established. Trust greatly
reduces administrative overhead and enables a collaborative approach,
so establishing trust must be the first priority in a project. How do
you build this trust?

A Lean Approach

There are certainly many answers to this question, and some are
better than others. Asking for quotes and having talks with the sales
& consulting staff is not really enough to establish trust. Much
better are working together with the actual team and evaluating real
results. Deferring potentially expensive decisions until their
implications are clear is usually advantageous. Here is a 3 step
approach:

  1. Use Scrum to create a lightweight, agile RFP (see creating
    the Agile RFP
    and contents
    of the Agile RFP
    )
  2. Eliminate uninteresting vendors.
  3. Select the ultimate winner through a competition which
    produces an increment of working software.

Why is this a lean approach? By deferring the final decision until
you have actual experience with the candidates, you reduce the
likelihood of picking a candidate that “looks good on paper”
but cannot really deliver software. You reduce the risk of your
decision substantially.

Eliminate Uninteresting Vendors

Identify your candidates and send them the RFP. Ask them questions
which will separate the wheat from the chaff, for example:

  • Please present the team which will carry out the
    project. How much experience do they have with Scrum and XP (Extreme
    Programming)?
  • Are you willing to organize the project according to
    Scrum (as described in the Process chapter)? What experience do you
    have with agile projects on this scale?
  • What is your estimate of the of the overall complexity
    (size) of the system in Story Points?
  • What is your expected team velocity in Story Points
    per Sprint?
  • Given our target budget, how much of the functionality
    do you think can be realized?
  • Are you willing to participate in the competition to
    select the final vendor?

If the vendors are used to working on an agile basis, they will
have no problems with these questions. If they are not, they will
probably not even be able to respond, especially if deadlines are
kept tight.

You will need to meet with prospective teams for a day or so to
answer their questions about the user stories. Afterwards the vendors
should be able to size the system and answer your questions quickly.

If there are more than two vendors still in the running, you will
need to use the answers and the results of the interviews to trim the
field down to two vendors, who then participate in the competition.

Competition

Let us assume that you plan to spend $2.4 Million over 12 months,
or $200’000 / Month to develop the software. (You got this figure by
calculating what the project is worth to the company, perhaps using a
double
worst case analysis
).

The cost of picking the wrong partner is much higher than the cost
of working in parallel for a short period of time.

If you add one month’s effort to the budget, that would raise the
total by 8%. But productivity differences among teams can be a factor
of 3 to 10. Furthermore, the cost of delay while you take three
months to pick a partner without producing any usable software will
be much larger than the cost of redundant development for a short
period.

Running the contest:

Here are the ground rules. There are two vendors. Both are going
to start your project according to the process you defined in the
RFP. After one month, both players present an increment of working
functionality and you will decide which partner you want to continue
working with. The winner gets a full renumeration for the month and a
contract for the rest of the project. The loser gets 50% of the
renumeration for a month.

Here are the steps in the competition.

  1. Prioritize the backlog and, working with both vendors, create
    a set of fine grained stories which should be implemented in within
    a month.
  2. Agree on the definition of done. This probably should include
    points which confirm that the partner is capable of test driven
    development and continuous integration. You do not want to incur
    technical debt. The same definition should apply to both
    contestants.
  3. Agree on other playing rules, in particular the team members,
    who should be the same as communicated previously. Are non-invoiced
    staff allowed? Is overtime allowed? Who owns the software and ideas
    which are produced by the loser? You may need to ensure that quality
    does not get sacrificed for quantity as you will be producing code
    which one day will go live.
  4. Hold the first sprint planning meeting together with both
    contestants, so both teams get the same initial briefing. Both teams
    get one month to implement an increment of functionality.
  5. Finish the Sprint with a Sprint Review and Retrospective.
    This should only include the implementation team and the product
    owner, as it is part of the Scrum process. When the retrospective is
    complete, the competition is complete.
  6. If the teams want to give a sales demonstration, this should
    happen after the competitive sprint is finished.

You might want to adjust the sprint duration or the trial period
depending on the size of the project.

At the end of month, you have not just qualitative and
quantitative data on which to base a decision. You have a month of
experience working with your new partner. You have some working
software (or not). In short, you have much more information to base
your decision on.

And the winner is…

Everybody wins.

The risks and up front costs of producing and responding to the
Agile RFP are much lower than the traditional approach.
By working with the teams, you build confidence that you can work
with them and that they can build the software you need. You can judge the teams based on working software rather than
attractive presentations or other artifacts.

By starting to work on a solution early, you reduce your time to
market. You will probably get a better solution, because the competition
will spur everyone’s creative juices. Even the loser will have some
good ideas which become part of and improve the final result.

Epilogue

This concludes my series on Agile
Project Planning
in general and the Agile
RFP
in particular. This series was largely the result of a
customer project. These are the tools we used and this is how far we
have come. What (do I think) was novel in our approach?

  1. Using Scrum and User Centered Design to create the RFP.
  2. Double
    Worst Case Analysis
    to do sanity checks on budgeting assumptions
  3. Competitive Sprints to select the final vendor.

The proof of the pudding is in the eating, but I as write this, I
do not know if the customer will move forward with the project. So we
can’t taste the pudding (yet).

How would you implement competitive sprints? To what situations
would it apply well or poorly? Have you used a similar approach?

Conference fever

image

I like going to the conferences. Every year I try taking part in one major conference and one or more smaller events devoted to the agile movement. Reading the books, articles and web-sites like this one is important, but I find that getting together on the conferences and similar types of gatherings is an own indispensable experience. If you happen to be at least moderately social, couple of conference days, lunches and evening parties help you get to know so many people and teams that you would not be able to meet in a year otherwise.

Tomorrow I am going to Scan-Agile (short for Scandinavian Agile Conference) that is the first large conference in the Scandinavian area (except for XP2006 that was also held in Finland, but was not a regular Nordic gathering). I am going to run a couple of open space sessions: on the outsourcing-related tips’n’tricks and on extreme experiences of software development. If some of you are are coming to this event, we can meet on these sessions or elsewhere on the conference. If you are interested, put a comment here and Ill try looking for your name on the badges – feel free to say "hi" to me if you recognize me. Typically I look similar to the guy on this video.

What is your attitude towards the conferences? Is it an academic tourism or a useful activity for you?

My First Agile Project Part 9: Choosing A New Tool – VersionOne

Picture courtesy of VersionOne and me

In my previous post, I talked about my team’s experience using ScrumWorks as our Scrum backlog management for the first year or so of our project. After our vendor’s license for ScrumWorks ran out, we thought we were close to the end of our project so we stopped using any tool for tracking tasks beyond our bug repository. As I’ll talk about in this post, a combination of factors led us to start looking for a new backlog / taskboard tool and the one we’ve settled on is VersionOne. Read on for more details about why we chose VersionOne and how we plan on using it, even once we’ve moved on our first agile project.

First, a word about Part 8 of this series, where I outlined the things my team and I didn’t like about ScrumWorks. I didn’t intend that article to be a review of ScrumWorks at all but more of a look at how we used it and why we didn’t like it at the time. It expanded and was seen by some as too harsh on ScrumWorks, especially since I was talking about an older version. It appears that ScrumWorks has done some good updates and fixed a lot of the issues we didn’t like about it. But some of the problems are philosophical and I’ll get to those in a bit. But if you’re looking for a Scrum tool, make sure you do your own evaluation and don’t take my word for it. Every team is different.

Also, just so there’s no misunderstanding; neither I or Agilesoftwaredevelopment.com have any connection to any tool I mention here beyond using them.

Time To Find A New Tool

Our license for ScrumWorks running out happened about the same time we thought we were nearing the end of the project and we refocussing to work strictly on bugs that came up during testing. We all had bugs related to things we’d worked on so we didn’t see a big need to track things and do sprints like we had been doing. There’s more on this phase of our project in Part X of this series. But overall we liked the Scrum process and had been laying the groundwork for making sure we kept doing it even after we moved off of this project, the one that had introduced Scrum and Agile to our company. To do that, we knew we’d need a tool so we looked around a little for one while continuing work on the existing project. A few months later I went to the Agile2008 conference in Toronto and found a couple of good alternatives to ScrumWorks.

Picture courtesy of VersionOne

At the conference I saw a couple of products but was most impressed by VersionOne, by far. Everything was done in the web browser, which I was specifically looking for after disliking ScrumWorks’ use of a web browser and desktop app for different tasks. The UI looked easy to use and didn’t get in your way. It looked very easy to add different projects to keep the various tasks we had in our company tracked together. Part of my search for a new tool was one that was easy enough to use that it wouldn’t take too much maintenance or setup. I was trying to get our department and company to accept wider use of Scrum and Agile methods and a tool that would add a bunch of work would just be an impediment. Another very cool feature was their open API that allowed people to write integrations and tools on top of VersionOne. We use Jira at work for bug tracking and VersionOne has a synchronization tool for Jira that looks like it’ll fit our workflows very well.

When I returned from the conference, I setup a trial with VersionOne that allowed us to use the tool for a month to really get a feel for it. I used it to run a small sprint we were doing on a bigger integration piece we needed to get done quickly and it handled that very well. I also imported all of our Jiras as a different project as a test and although the importing process had some problems it worked well (there’s an XML importer but no example XML I could find and the CSV importer didn’t appear to allow importing notes from Jira which we use extensively). I didn’t setup the automated Jira synchronization due to a lack of time. If you’re looking at Scrum tools, I’d encourage you to get in touch with VersionOne and try their demo, it’s very enlightening to actually get your hands dirty on a tool and it’s easy to setup with them.

Picture courtesy of VersionOne and me

Working with VersionOne, the biggest thing that stands out is how it doesn’t try to force you onto a specific path. ScrumWorks tries to keep you on the strict Scrum path, which according to the product manager who kindly responded to last week’s post, is their intention. That’s fine but just didn’t work for us. I’m not a big fan of strict processes and like the ability to go the way that suits us best without having to work around things we don’t need. We want a way to keep track of tasks, make sprints, etc. We don’t care about a lot of the stuff other teams might want or need and VersionOne doesn’t force us to. I think the only required field by default on backlog items and tasks is the title. Other than that it’s up to you.

Transitioning from one agile project to many

As I mentioned, I’ve been working on convincing our department (and by neccessity, our customers in the rest of our company) to move to a more Agile process. Before starting on this big Scrum project, our process was pretty much non-existant. We didn’t even really do waterfall, we just came in every day and worked on bugs and issues from Jira. Luckily for me, I was only with the company a few months before we started using Scrum on this project.

What I’m hoping to do, and I’m pretty sure I’ve convinced my manager and director that this is the way we should be going, is to do Scrum on a multi-project basis. Instead of almost all of us being on this one big project, we’ll make 2 week sprints out of issues from the various projects in Jira. VersionOne’s Jira integration will allow us to keep having people enter tasks in Jira like they always have, then we’ll pull them over into backlog items and defects and enter them in sprints to work on. Priorities will be set by our manager, in a modified Product Owner roll, and we’ll be removed from the management back-and-forth of those decisions in a way we weren’t in the previous process (we hope anyway, we’ll see how that works in practice :)). This will let us work as a team on multiple projects at once, without having to multitask and switch projects based on which department manager is at our desk that day. Or we can put all of our resources on a big project for awhile to get big chunks of work done. It’s a very flexible system and I think will work out well for us once we can get everybody on board.

But the reality of the situation is that I’m just a programmer with ideas, a big mouth, and a genetic inability to keep quiet about things. My management tends to listen to me but we’ll see how these plans work out when they hit the corporate reality. I plan to write more about how this transition is going in real-time once it gets closer and I finish out this My First Agile Project series.

As I say every time, thanks for reading. If you have any comments on any of this, please use the comments form below.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks

Weekly Agile Reading. Pack 19

Here is the top writing that caught my attention this week.

You might like having a look at the previous link packs as well.

» ScrumShocked How similar symptoms can result from the different reasons. Context is everything.
» Agile Game Development: Scrum is not for everyone Some people are incompatible indeed. Think about that when deciding to adopt Scrum (or any other method).

How to Talk to Project Managers

This week, I have had the distinct pleasure… the rare opportunity… to attend the PMI Global Congress in Denver, Colorado. I missed the deadline to propose a talk but there are at least 5 agile presentation happening over the course of the event. That is really good news. The PMI crowd is interested and trying to understand what this agile stuff is all about.

This week, I am working the VersionOne booth, so while I have a full conference pass, I will probably not going to make any of the talks… bummer.

Talking to Project Managers

It has been really fun talking to all the folks that have come by to see our software. The people that stop to talk to us have already been exposed to agile on some level, so my perspective might be biased, but there are many more agile friendly people that I expected. Again… people are interested and want to know more.

After my first full day of meeting and greeting the conference attendees, there is one thing I would like to share with the agile community. When you talk to a traditional PM about agile project management, you need to be prepared to speak their language. While teamwork and collaboration are important, that is not the language of the PMI crowd. Empowerment is essential but can be very threatening to someone that is accustomed to being “in control”.

I’ve found that a good place to start is with a discussion of the triple constraints.

Managing the Triple Constraints

Most traditional projects start with some assessment of scope; an assessment of what the stakeholders want to be built and what they are willing to invest money to have. From there the team does some analysis, figures out how big the request is, and what will be involved in building it. We do an assessment of the team, understand who is available (and when), and begin to lay our dependencies and calculate the critical path. From there we determine a date.

Ask your PM friend if that sounds much like their personal experience? They will inevitably nod ‘yes’ because that is what project managers are taught to do. Next ask them what happens after they communicate the project costs and delivery date of the project? I would bet money that their response will be somewhere along the lines of: we are given a date, we are given a budget, and then we start de-scoping the project.

Sometimes, if management really does not care about successful delivery, they are just given the date, and the budget, and are made to deliver all the requirements anyway.

Our Real Project Drivers

This is where you can explain that they are given the date and the budget because those were really the project constraints to begin with, not the requirements. We pretend the requirements are the constraint because, like most people, stakeholders hope that we will be able to get everything we want for what they are able to spend. Most of the time that is not the case.

So… where do we go from here? I will typically explain that agile project management starts with time and cost as the primary constraints and introduces techniques that enable the business, in partnership with the team, to decide what is the best set of requirements to build. After delivering this line, be prepared for the blank stares.

But I Have to Deliver Everything

The blank stares are because project managers are trained that they have to deliver everything. The executives demand it and the stakeholders cannot take the product to market unless they have everything. Now it is time for more questions. Ask them if that approach ever works? The answer is always ‘no’. Ask them what happens when projects start this way. They will answer that the project is always late or over budget.

The reality is that by demanding ALL the scope, in the face of data that says otherwise, the business is making the implicit decision that their project will be late. You are generally not rewarded, or very popular with your stakeholders, if you bring this to their attention. Project managers are often incented to keep their heads down, do their best, and take their lumps when things are late.

As a quick aside… this is the main reason most project managers rely so much on process and documentation. It allows them to cover themselves and be ‘successful’ in an impossible situation.

Most Project Managers Don’t Make the Call

The reality in many businesses is that the project managers are not empowered to make the time, cost, and budget decision; and even if they bring these issues to the attention of senior management, they may be forced to proceed with the project anyway. This is your hook to talk about why agile can be such a valuable addition to their PM toolkit.

Delivering in short cycles and measuring done gives you real data about the health of your project. Managers often assume the team has overinflated the estimates. They assume the team is sandbagging. Agile gives you real empirical data about the status of your project and what the team is capable of delivering. Agile gives the business real data, and real options; options that go beyond just how late and over budget do you want the project to be.

Put the Business Back in Control

Agile gives the business the opportunity to effectively de-scope on the fly, to change their mind, to increase the cost of the project, to lower the cost of the project, to deliver early, to deliver late, or to kill the project all together if the business objectives cannot be met. They get this information early, when there is still time to deal with it and make a rational business decision.

The senior managers I have worked with will make good decisions when presented with good data and real alternatives. Bad decisions are made in low trust environments with poor information.

Now Let’s Talk Agile

So… with that groundwork in place, you can start talking about teamwork, collaboration, and empowerment. You can start talking now about pair programming, continuous integration, and test driven development. Those things just don’t mean much to the PM community until you help them understand how agile will fundamentally put them in a position to deliver quality projects: on time, on budget, and with the highest value that can possibly be delivered.

Until then, people are just not going to get it. So next time you are talking to someone with a PMP next to their name, make sure you are speaking a language they can really understand. The traditional community is willing to listen, we need to make the most of our opportunity.

Agile Success Story: interview on how Agile movement helps company to grow and succeed

Picture courtesy of M. Keefe@flickr

Last week I had a great fun and honour to interview Janusz Gorycki who is a partner and a team manager in an Agile Software Development company – Spartez. Janusz is also the author of the open-source screen capture and painting utility for Windows named Mazio.

In this interview I’m asking Janusz about how they founded their company and how agile movement helped them achieve success. I’m also asking how they see their agility, what problems they have and how they deal with them. Janusz also answers why you can be CMMI-compliant using agile methodologies and recommends steps by which you can start applying Agile practices in your company.

Is this interview about yet another agile company? Not really – Spartez is an extraordinary company composed of ordinary engineers who were not afraid of making their dreams come true. Their determination, team work, a bit of luck and an extreme agile spirit helped them be and work together and become successful. This is a real-life example how cross-functional team, where each member is an expert in some areas, is able to deliver any software to any customer. And how do I know this? I used to be a part of this team at Intel and know this team as well as each member pretty well, however I’m not affiliated with them anymore in any way.

If you are interested in getting to know how they started, what and how they do now, this article is for you. Maybe you will follow their dreams and ideas – I think it’s worth.


List of questions:

  1. As far as I know you worked together as a team at Intel which is huge corporation. I also know that you were not using Agile from the beginning. So, how did this all start?
  2. What are you working on now and how Agile methodology helps you?
  3. What Agile techniques you use (Scrum, XP, etc.)? What principles and activities you utilize and which one you abandon? Why? Don’t they work for you or you consider them obsolete/unnecessary/unimportant?
  4. What tools do you use? Can you be Agile without them? What do you gain/lose using tools?
  5. Do you want to tell our readers something more about your development process? What makes you successful, what would you like to recommend trying?
  6. What are, in your opinion, three most important things that make Agile methodologies successful?
  7. What are three most important problems you encounter with Agile techniques? I won’t believe it’s always cool and problemless. How do you cope with them?
  8. You are familiar with CMMI as well and worked in huge corporations. Can you accommodate CMMI and Agile?
  9. Was it good decision to start thinking Agile? What did you gain as people, engineers and team?
  10. How would you encourage other companies and teams to start investing their time in Agile methodologies?


Przemyslaw Bielicki: As far as I know you worked together as a team at Intel which is huge corporation. I also know that you were not using Agile from the beginning. So, how did this all start?

Janusz Gorycki (Spartez): Yes, we have started our work together as a team at Intel‘s IT. The team consisted mostly of Intel newcomers and I was a long-time Intel employee (more than 10 years in one company, but in a different division), so I got appointed as their manager. Very soon after the team was formed, it became apparent that traditional software development methods, which I was used to while working at my former team, and which more-less worked acceptably well there, were hopelessly inefficient, unpredictable and very costly when applied to the internal IT environment. It was not uncommon for a software project at that organization to be more than a year late, and during that time deliver hardly any business value at all.

So we have started, at first in the “stealth mode” (without telling any higher-ups), to look for more efficient alternatives. Agile methods were, at least partially, known to some members of the team, so we decided to try them out. The productivity boost just from time-boxing our development and defining exactly what we will work on during each iteration was immediate and obvious. And as far as I remember, we have initially decided on a three-month iteration cycle – unbelievably long by normal agile standards. Encouraged by this success, we tried more and more practices.

But the real, no holds barred, use of agile methods, started after we all left Intel and created our own company – Spartez. We basically established the company as a place with agile spirit from the very beginning.

Back to list of questions

PB: What are you working on now and how Agile methodology helps you?

JG: We were able to launch Spartez, because we have managed to find a strategic partner – a company from Sydney, called Atlassian – the makers of excellent software such as JIRA and Confluence. Most of the software we develop is written for them and we are also resellers of their products. The main software product we are working on, and actually 100% own its development, is an open-source IDE Connector, integrating Atlassian web-based software into IDEs such as IntelliJ IDEA and Eclipse.

The development of this tool is done as a series of 2-week-long Scrum sprints, with almost each sprint’s results actually released publicly, with downloadable and installable binaries. Each sprint delivers an increment of value to users of the Connector. I don’t think we would be able to successfully launch Spartez and remain in operation for a year, without any initial funding whatsoever, were it not for agile methods – Atlassian folks were astonished that we were actually able to release a usable piece of software after just two weeks of work. Obviously, compared to where we are now, the functionality of the release was extremely limited and primitive, but the point was – we were able to prove to our customers from the very beginning that their investment was justified, because we are able to deliver on our promises.

Back to list of questions

PB: What Agile techniques you use (Scrum, XP, etc.)? What principles and activities you utilize and which one you abandon? Why? Don’t they work for you or you consider them obsolete/unnecessary/unimportant?

JG: Sometimes we do get tired of this or that practice, becuase the downside of these practices is that they require quite a lot of discipline. The funny thing is, we get in trouble each and every time we abandon or do too little of some practice.

An example: we have agreed to release (internally) the new version of the software every second Thursday, dogfood it for a bit and launch a public version the next Monday morning. It so happened a couple of times, that we told ourselves “let’s not release on Thursday because we need to finish this or that story”. That proved to be a mistake every time we did this. By breaking the release cycle, we were forced to shorten a subsequent iteration and not only we delivered less functionality the next time around, but we broke our velocity measurement and lost control over one of the most vital metrics we had at our disposal.

Another example – unfortunately we don’t unit test enough. Sometimes unit testing some functionality is prohibitively difficult when you write a plugin for some other software (like IDE), because there is no way to properly mock or stub some piece of code that you depend on. Well, we could probably try to mock them, but we decided that we would not, as we would have to rewrite half of the IDE. This has immediate negative consequence on the quality of the code. There is no doubt that the pieces of code that are unit tested (because they are not tied to the IDE), are of much better quality and easier to extend and maintain, than the pieces of code that are not unit tested. We are aware of this problem and we are long overdue addressing it adequately.

I can honestly say that all of the agile practices are important and they represent a coherent system. Abandoning some XP or Scrum practice may sometimes be necessary due to unforeseen circumstances, but I would recommend sticking to them as much as possible. Therefore I will not try to list the ones that are of more or less use.

Back to list of questions

PB: What tools do you use? Can you be Agile without them? What do you gain/lose using tools?

JG: This is the beauty of it – you don’t really need sophisticated tools to successfully do agile development. At Intel, we have started with a cork board, sticky notes, scissors and pencil. And it turns out, these remain to be our most important tools to this day. This, a version control system (I would recommend SVN in most cases), a bug tracker and a continuous integration server are the only crucial tools you will need.

You should use other software tools only after you know which aspect of the agile software development you want to optimize in your particular situation. We are in a very lucky situation, where Atlassian has supplied us with an excellent software tools that nicely compliment each other. We use JIRA bug tracker for planning, tracking and bug reporting, Bamboo build server for continuous integration, Confluence Wiki for knowledge sharing, and Crucible for source code reviews.

Other tools? I would recommend getting the largest LCD screen you can buy (and they are dirt-cheap these days), computer with enough juice in its CPU to not frustrate you, plenty of RAM and a comfortable chair.

Some folks also like IDEs – like the IntelliJ IDEA that we happen to use. And I would agree that they do help, but I am tempted to also say that they sometimes help you too much – and instead of spending your time thinking about your design – you Control-space through your code, often times making it overly bloated and unnecessarily spaghetti-like. I sort of long for the days when you were limited to just bash and emacs (vi users – I am sorry, your way is wrong, but you will see the light some day). Not because I am a ludditte, but because in the absence of the powerful IDE, you have to stretch your mind more to make the code simple, elegant and concise.

Back to list of questions

PB: Do you want to tell our readers something more about your development process? What makes you successful, what would you like to recommend trying?

JG: Before I try to describe what we do, it is important to understand that these days, the eight of us work on at least four different projects. This means that some teams are actually one-person teams. And such small teams actually do not need any formal process – after all, the only reason for the existence of a process is communication – and if you are alone in what you do, you don’t need much communicating. Except of course with your customers.

For the bigger projects, we start with a release planning session, during which we size all user stories that we have been able to gather from the customer. The stories are already prioritized by the product owner in some way – unfortunately sometimes only roughly. We play planning poker for each story and after the session we enter the results into JIRA.

After that, every two weeks (on Monday) comes an iteration planning session. During this session we commit to a subset of stories, trying to pick the ones from the top of the backlog, but sometimes for architectural or other reasons we also pick stories form the middle. Obviously, we also have bugs – and they tend to be quite hard to properly size, so in their case there is a lot of guessing involved sometimes. So what we do is try to have at least a 50-50 distribution of bugs and user stories for every iteration.

Then, every day we do daily stand-up – 10am sharp. We try hard to make it no longer than 15 minutes, but sometimes we fail (and this is all my fault as I lead these meetings).

Sprint demos are quite problematic in our case – our customer is in Australia and it is not realistic to actually do live presentation. What happens instead is we try to educate our product owner (who is in Sydney) what we delivered – he just looks into JIRA and he can monitor what’s going on. He would then do demos for the end users (who are at this moment mostly developers in the Sydney office).

How we do actual development? That sort of depends on the task at hand. Sometimes we pair-program. Actually we should do much more of it than we do now, but this is a pretty intensive activity and therefore not everybody naturally chooses it. We have a Bamboo continuous integration server checking our code, so all of our commits get sanity checks, the code is always compilable and unit tested. For the more problematic, tricky and complicated code we do code reviews – using the Crucible tool. We do try to “dogfood” our own product as much as possible – if the required functionality is available (even if it has bugs), we try to do as much interactions with the tools using the IDE Connector that we are developing. That way, we know if we like the UI that we have just created and we are able to detect bugs before they hit the customer.

Would I recommend our ways to everybody? The elements of it – yes, all of them. The whole process? Not necessarily. In reality, you should use a process and methods that suits your team. Ours attempts to be optimal for us. It will probably not be optimal for you.

Back to list of questions

PB: What are, in your opinion, three most important things that make Agile methodologies successful?

JG: Let’s tweak this question and answer this one: “Why are agile methods better than non-agile ones?” Let’s try to answer that question. I would begin by this observation: software development is a chaotic process. By “chaotic” I mean “the one where slight modification of input parameters causes huge changes to the results” (I guess I could give a lot of examples here, but I don’t want to make this interview even longer than it is now). The only way to control a chaotic process that we know of is by using empirical methods. Agile development give you means for empirical process control. You get your process checkpoints every day, every two weeks, every release. You can actually measure (as opposed to just guessing) how effective you are and what your real (as opposed to perceived) pace is. There is no “perpetual 80% done” syndrome in agile development. You can actually tell how much you have done so far and be certain that you are “done” working on something.

Second, agile software development give your customers better control over how they spend their money. They get results fast, they can check at any moment the health of the project they invested in, and they can stop the project at any moment when they determine that the investment does no longer brings expected results. Usually, 20% of the features give your customer 80% of satisfaction. With agile methods, you can deliver these 20% in 20% time, instead of being 2 years too late.

Third, agile methods give your team frequent and regular small successes – you release your software every second week or so, somebody is using it, giving you feedback, and the feedback is very likely to be positive, as you are building the software to exact specs of the ones you are working for. This builds confidence, enthusiasm and sense of working on something useful.

Back to list of questions

PB: What are three most important problems you encounter with Agile techniques? I won’t believe it’s always cool and problemless. How do you cope with them?

JG: The problem with agile methods is that they require much more discipline than “traditional” ones. The simplicity of the process definitions and “obviousness” of the practices is very deceptive. Agile methods require you to keep your pace day in and day out. There is no “quiet period” after a “death march”. At first that may be problematic to some people. You will have to be effective as a developer, and your effectiveness is easily verifiable, every day of the year. The good news is that once you get accustomed to the routine, it becomes natural. Moreover, once you prove to yourself that you are able to deliver at an acceptable pace, your confidence improves. The question is – what if you _are not_ able to deliver at an acceptable pace? Well – XP has built-in mechanism for improving skills of team members, the best of which is without a doubt pair programming. But you have to be aware of the skills of everybody and react to people’s deficiencies as you discover them. This is not always a pleasant exercise.

More dangerous than the first threat is lack of feedback from your users. This will surely cause you to get derailed, as user feedback is of paramount importance. Agile team has to do everything that is in their powers to get feedback. This is not only the responsibility of the ScrumMaster and the product owner – everybody on the team has to be aware that the feedback loop has to be maintained and supported by all means possible.

Third threat is lack of flexibility. Agile processes are meant to be improved. You are supposed to tweak, modify and fix them to your liking and to the precise needs of your team and its customers. There are sets of “best known methods” in Scrum or XP, but they are just that – “best known methods” and not a bible. It is important to understand that there are no “sacred cows”. The process itself must not become a holy grail – it is just a means to achieve a goal and nothing more than that. If it makes sense to break the rules that you learned at your ScrumMaster training, go ahead and break them. Just be aware that you are breaking them and that you are doing it for a reason.

Back to list of questions

PB: You are familiar with CMMI as well and worked in huge corporations. Can you accommodate CMMI and Agile?

JG: I have somewhat mixed opinion about CMMI. On the one hand, the principles of CMMI are actually great – the central goal of striving for ordered, dynamic process, that has built-in mechanisms for self-improvement is something that I like, and which is also exactly what the agile methods are all about. On the the other hand, I am yet to see an implementation of CMMI that is not hopelessly heavyweight, overly complicated and and that is not making your life as developer miserable.

I suppose the reason for this is two-fold:

First, the only successful processes are ones that are built bottom-up, as a response of actual, painful needs development teams, designed and tailored by the teams themselves and modifiable by the actual users, without having to go through the huge bureaucratic hassles. CMMI however, is unfortunately usually introduced from top down, at the request of the higher management – more often than not quite isolated from, and unaware of, the gory details of day to day development work.

Second, the successful process has to be simple, intuitive and so natural that you would naturally resort to it when working under stress. Unfortunately, all CMMI implementations I have seen so far are heavy, complicated and impossible to fit in the head of a mere human. So what people tend to do is work around the complicated process in many cases, giving the false impression that they follow it, while in reality their real process is quite different from the “CMMI-defined” one. I have seen this evolution from “let’s follow our CMMI process to the letter” to “let’s pretend to follow it and get stuff done somehow, because our defined process does not actually work” happen a lot.

Having said that – I think agile methods can be basis of a complete CMMI implementation (up to level 5, no less). Just notice that some of the core agile principles are precise, empirical measurements (story size estimations, velocity), formal contracts between stakeholders (prioritized backlog) as well as built-in self-healing and self-improvement of the process (Scrum demos, retrospectives, daily stand-ups, pair programming).

Back to list of questions

PB: Was it good decision to start thinking Agile? What did you gain as people, engineers and team?

JG: I think it was the best decision that we as a team have ever made. The decision actually started us as an independent, and so far quite successful company – something that many of us dreamed of but before we met, had no guts to actually decide to do. Agile methods gave us discipline, they allowed us to easily share knowledge, improve ourselves, understand what we are capable of and what are our realistic and objectively measurable abilities. This is not to say that we are perfect – far from it, the team seems to be in a constant state of internal turmoil – and I think this is a good thing. But we seem to be, as a team and as a company, in control of our lives and we are able to “make our own luck” in stead of totally depending on the decision of others.

Back to list of questions

PB: How would you encourage other companies and teams to start investing their time in Agile methodologies?

JG: I would advise to start small. Don’t make a “big bang jump” to an all-agile software shop. For example, it took us about three years of incremental improvements to get to where we are now, and we are still very far from perfect. Stay cool, stay calm, have guts and courage to try new things, pick and choose whatever seems to make natural sense.

Also – do not try to spend most of your money on fancy tools. Like I said – at first, paper, pencil and cork board will be all you need. After you understand what it is that you need, you will know what fancy tools to buy. And I hope you will turn to us to sell them to you, because we sell good stuff.

Back to list of questions

PB: Thank you very much for your time


Few facts about Spartez

Website: spartez.com
Location: Gdansk, Poland
Operational range: global (currently working with customers in Australia, USA and Europe)
Areas of development: IT systems integration (B2B, SOA, middleware), aeronautics and GIS, telecommunication, low-level and embedded systems in the following technologies Java, C# (.NET), C++, C, assembler

Finding a Partner to Trust – Writing an Agile RFP to Outsource a SW Development Projects

My customer wanted to find an external partner to
develop
their new software product and develop using Scrum. So we needed to
evaluate
the potential partners, but how? The classical approach is to define
the
application “exactly”, then ask some potential vendors if they can do
it and
how much it will cost (and then haggle over the price). This is not
very Scrum
like, but it represents a starting point which is well understood by
customers
and vendors alike. What is different about an Agile RFP? How can a
fundamentally
non-agile bidding process be adapted, so that the transition to
agile development be as easy as possible?

This article is Part 2 in the Agile RFP Series

Last week, I described how my team and I used
Scrum to create an Agile RFP. This week, I will describe what we produced. Will
this be
a valid template for your project? This question is very difficult to
answer,
since the contents of our RFP were based on the needs of our project
and our readers.
The agility in Agile comes from empirically determining the best way
forward, not
blindly following some predefined template or process. So caveat
emptor, let
the buyer beware!

An Agile RFP is something of an oxymoron: an
inherent
contradiction. The development team should be involved from the early
stages of
conceiving the product to create the vision, identify the users, and
write the
user stories. But the team doesn’t exist yet and cannot exist until the
vendor
has been selected. So the Agile RFP should serve to bootstrap the
process.

Based on our understanding of our readers, we
created the
Table of Contents:

  • Company
  • Goals
  • Budget Considerations
  • Development Process
  • Current State
  • Desired State
  • Selection Process

Company

This chapter was just some boilerplate from the
corporate
web site to provide context for companies who were not familiar with us.

Goals

This section is also known as the Project Charter.
What are the overriding organizational goals? What should the product do for the
company? What should it do for its users? We used a Mission Statement
and an Elevator Pitch to answer the product related questions.

Budget Considerations

Our goal was to ensure that the target cost fall
within a
range that ensures a satisfactory return on investment, even if the
costs and
benefits don’t work out as planned. It can be difficult to come up with
a
believable model. For each consultant out there with a spreadsheet, there is a
manager
who has been burned by believing his models.

So we simply framed the problem. How many
employees will be
affected by the system? How much more business could they process if
their
productivity were raised by 5%, 10%, etc. Or how much money could be
saved?

Applying the double worst case analysis to the various scenarios provided a first approximation of a reasonable budget.

Development Process

A classical project charter will describe the
roles and responsibilities
of the key personnel, so an Agile RFP can simply insert Scrum as the
development process. We found it helpful to recapitulate the essential
points and
to include our company specific practices:

  • Product Owner and ScrumMaster and who will provide them
  • Sprint Planning & Demo Meetings
  • Burn Down Charts
  • Additional metrics (test burn up charts)
  • Escalation procedures

Scrum itself does not define relationships beyond
the Scrum
team. So we included a “Management Oversight Committee” modeled on Ken
Schwaber’s
Enterprise Transition Team. This should be an effective alternative to
a steering
committee. The MOC should meet (at least by phone) regularly and
resolve
impediments raised by the ScrumMaster.

Some issues aren’t directly addressed by Scrum.
How do you
ensure system maintenance over a 10 year period? This is both a
financial
question and an engineering question. These issues are best raised with
the
suppliers in the RFP.

Current and Desired Situations

An RFP should describe the current and desired
state. An
Agile RFP should describe that state in terms of what the users
currently do
and what they will be able to do with the new system. User Roles and
User
Stories is the basis of this discussion.

We augmented the user stories with a flow analysis
of the
current state (inspired by simple Value Chain Diagrams) and functional
diagrams
of the desired state. The flow analysis identified potential
productivity
improvements and the functional diagrams highlighted new functionality
and new
business potential.

We wrote a complete set of user stories for all
major users
of the system. The result was 20 pages long, so we moved them into an
appendix.
In the main document, we included a top level description of each user
role, his/her
duties and what that role expects from the system.

Who will buy the system?

Brainstorming on the users and their expectations
led to
some important discoveries. For example, optimizing the work of primary
(full
time) users of the system are prerequisite functions. If that is not
effective,
no one will want the system.

But the primary users are not the buyers. The
users’
managers, the suppliers’ and customers’ sales, marketing and management
and
even our own top management will decide to the system’s fate, even
though they
are ‘only’ occasional users. By giving these users value, we can create
Exciter Functions for those users who are most essential to success of the product.

Technology – not

We did not specify any technologies in the RFP.
The desired functionality section focused on what, not how. We did however list
some technologies that we thought might be of interest and provided links to
some applications in a similar context that we liked.

Retrospective

Did we specify too much? In an agile process, the
objective
is to create the specification just in time through direct
communication
between team and product owner. This is not possible before a supplier
has been
selected.

Writing user stories was a good compromise. We
have the
basis for a conversation about the entire system, with development,
with
management, and with our users. We have a thorough definition of what
the
business wants. We learned a lot about the desired application (which
lead us
to shift its center of gravity in ways we would not have expected). By
writing
the stories ourselves, we remained business focused.

But should we really have written 20 pages of user
stories?
I am not sure. I had the feeling we were over-specifying. The more we
produce,
the more we will have to communicate to the implementation team.

This approach is a step away from a classical
submission
process, but is not yet purely agile. On the plus side, the vendor will
be able
to size the system and give us a reality check on our budget goals.
We’ll see
how this works when we start talking to vendors.

Next Steps – Selecting the Partner

So now we have an RFP. How do we find the right
partner to
implement it? Tune in next week for Part 3 of “Finding a partner I can
trust”

Other Articles in the Agile RFP Series:

  1. Using Scrum to Create an Agile RFP
  2. Contents of the Agile RFP
  3. Selecting an Agile Outsourcing Partner