Archive

Posts Tagged ‘development process’

Agile Outsourcing: Get It or Forget It?

January 26th, 2010 Olga Kouzina Comments

Bringing together agile philosophy and software development outsourcing has been one of the hottest topics over the last decade.  Lots of blog posts, discussions in social networks — people try to figure out for themselves if it’s at all possible to align agile methodology with the existing reality of outsourced projects.

How can vendors who practice agile gain new customers? How can customers as newly-converted adepts paste their vision of agile thinking on their existing outsourcing partners?

First of all, let’s look back into when and why actually did it all start with IT outsourcing. Manufacturing outsourcing existed since long ago, but IT offshoring only started at the end of 80’s - beginning of 90’s. Companies jumped at the opportunity to save bucks and use cheap labor not only for producing goods, but for producing software. So, the main point is that from the very beginning outsourcing has all been about saving money. No other notable motivation - just saving money and using cheaper labor.

homework

Next, along comes agile manifesto. People start seeing that the waterfall approach  they’ve been using with their outsourcing vendors is not that good after all.  Fixed price contracts do not guarantee real value (Scott Ambler writes very well on that in this article). Next, the more labor is outsourced to some country, the higher are the costs, so the main point for outsourcing which is cost savings makes no sense any more.

There’re other even deeper-lying consequences. On the one hand, the country which outsources - or businesses in this country not the country itself - they save bucks but lose in the long run as they do not grow their own engineering minds, let alone all the problems that you have working with remote teams - yes, we have all this telecom in place, but nothing ever will replace face-to-face communication. If you often go on business trips to the outsourced destination to talk to your team - again, it’s more costs.  On the other hand, outsourcing makes a dangerous long-term impact on the recipient economies as well.

But the point is not about how bad or good outsourcing is.  Vendors have written an array of blog posts on how to align agile and outsourcing - and that’s natural - they want to keep going, so they do everything to back up their point of view proving that agile goes well with outsourcing. This might work true in some cases.

The companies that outsource on the other hand - they have legacy outsourcing teams. They need to get going with them as well, to stand up to all the funds already invested in their outsourcing center/provider.

So with all this outsourcing in our hands - what do we do?

As an agile outsourcing vendor, you should be ready to invest lots of time and effort to educating your new customers on the value of agile and to building a solid relationship. This might be a very difficult task since some people just don’t want to get educated and prefer to stick to good old fixed price bids, logging and billing for gazillion of change requests, lack of communication and other “joys” of classical outsourced development.

As a company with established outsourcing facility, you’re better off. But perhaps you could be even better off if you started this relationship not with an overseas company, but with a guy next door at least.

Anyway,  you are where you are - so you would need to work with your outsourcing partner to practice the agile approach, since at the end of it all work with agile methodology brings real value, as opposed to counting short-term waterfall pennies and losing long-term gain.

TargetProcess TOP 10 posts in 2009

January 14th, 2010 Olga Kouzina Comments

January 13/14 is the Old New Year holiday. Seems like today is the latest appropriate time to look back  and recall the most interesting blog posts by TargetProcess in 2009 :)

dedmoroz-prozra4en-746252

Based on visitors count, the posts are ranked as follows (descending order):

1. Lean and Kanban Software Development Digest: In May 2009, this digest came along right on time as Kanban adoption started to grow. We’ve been sifting through the Lean/Kanban buzz and considering if Kanban might be a good tool for our development process, so this post has the most valuable findings we’ve made and shared with agile community.

2. Refactoring vs Rewrite: This post is a real train of thought of a Product Owner trying  to make a decision on how to proceed with product development — rewrite or refactor. Can well be used in textbooks for software product management :)

3. Mind Maps: Scrum, Extreme Programming, Lean: Another by-product of our research on agile development processes. The specific value of mind maps is that they help grasp complex things with visual representations.

4. Tale: Deadline and Technical Debt: Once upon a time…  Who could ever expect that the fundamental principles of product management can be outlined in a fairy tale ? :) There we go:  smart Arthur, the cunning king, quest for princess — the metaphorical expression of the danger of technical debt in software development.

5. 5 Wrong Reasons to Apply Kanban. For some reason (no pun intended), 5 wrong reasons ranked higher than 5 right reasons. Maybe it’s just human psychology — to go from “what’s wrong”  instead of  “what’s right” …

6. How We Use Kanban Board. The Real Example:  Once we figured that Kanban process is just the right thing for us and put it in action, we shared this  experience with our blog readers.

7. 5 Right Reasons to Apply Kanban: There they are :)

8. Zero Defects? Are You Kidding Me? : Can this juicy frog be sure that it swallowed the very last bug? This post is a warning against the so-called “zero defects mentality” in software product management.

9. Simple Rules, Complex Systems and Software Development: Complex systems function at their best when guided by simple rules. Look at ants, birds, space rockets and … software development.

10. BDD and User Story Specification: Examples — This post includes some real user story specs in BDD for TargetProcess product. Enjoy and use.

These are the TOP 10 posts  in 2009 from TargetProcess agile blog (click here for more)

Happy OLD NEW YEAR! :)

Our Development Process

Inspired by Kanban at Lonely Planet. I think it is a good idea to share software development processes from different companies. Maybe even it would be great to create a repository of the processes somewhere on a popular agile web site/blog.

Context

  • Product development (quite large web application)
  • Two development teams: Core (5 developers, 1 scrum master, 3 testers) and Integration (3 developers - one of them plays scrum master role, 1 tester)
  • Quite mature product: 4 years
  • Technology: C#, ASP.NET, ExtJS, NHibernate

Process

  • Development team has all the power to try new practices, keep working practices and remove bad practices. There’s a little push from scrum master side.
  • We do not use iterations.
  • We do use releases, but often it is just a set of all the features implemented last month.
  • We do not have iteration planning meeting, but discuss every user story JIT before implementation on a meeting with PO + Testers + Developers.
  • We do not estimate stories and bugs, just a very brief estimate like (”oh, this will be a large story, let’s split it”).
  • We split stories, but sometimes not as aggressively as required.
  • We release new builds every week (sometimes 2 builds per week). The goal is to release every day, but we do not have a good automated functional tests coverage so far.
  • Smoke testing of the build takes 3 hours (3 testers).
  • We have a limit of 3 user stories or bugs in progress.
  • We have retrospective meetings every 2 weeks.
  • We sometimes have technical user stories (for example, remove jQuery from application), but that is rare.
  • We use Kanban Board in TargetProcess heavily and have a large screen in development room.
  • We have a flat hierarchy in the company. There are only two layers and no boundaries between the layers. No formalism at all. Also we do not have positions like Senior Developers, Junior Developers, etc. All people are equal (however, there are informal leaders).
  • Average Cycle time for user story is 13 days and 5 days for bug.
  • We track spent/remaining time on tasks and stories.

Development practices

  • We develop each user story or bug in a separate branch. Master is always ready for release (after smoke testing). We use Git (switched from Subversion).
  • Pair programming on all user stories and complex bug fixes. Sometimes people work alone on smaller/simpler problems.
  • Developers switch pairs every day, even if user story is not completed yet. The goal is to a have fresh look, knowledge spreading and real collective code ownership.
  • Before story implementation, pairs discuss possible solutions. It is quite formal.
  • TDD. All the new code is covered by unit tests. Situation is worse on JavaScript side, we just started TDD adoption for UI.
  • We use Cruise Control and have quite many different setups. Smoke builds, release builds, etc. Functional tests run in parallel and it takes 1 hour to run them all.
  • Selenium. Automated functional tests are based on Selenium. We’ve created a framework in C# especially for our application to simplify tests creation. Tests coverage is not good so far, but we are working on it (there are 2 automation testers in our team).

ToDo

  • We want to add performance tests into automated builds.
  • We want to have 80% functional tests coverage to be able to release new builds every day
  • We are incorporating User Experience into development process. This is our main goal for the next year. It includes Customers UX Community creation, interactive prototypes for all user stories, usability testing.