Our Development Process: 1.5 Years Later | Targetprocess - Enterprise Agility Solution
10 years ago

Our Development Process: 1.5 Years Later

Brief summary of this article:

1.5 years ago I wrote a post that described our development process. It is interesting to see what's changed. 


  1. Survived
  2. Removed
  3. Added


  • Product development (quite large web application)
  • Two development teams: Core and Integration Several Mini-teams.
  • Quite mature product: 46 years
  • Technology: C#, ASP.NET We are moving to full Javascript front end, ExtJS jQuery, NHibernate, ESB


  • Development team has all the power to try new practices, keep working practices and remove bad practices. There's a little no push from Scrum Master side.
  • We form mini-teams for every Epic. A mini-team includes 2-3 developers, tester and designer (half-time). It is fully responsible for Epic implementation. Usually mini-teams live for several months.
  • 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 plan releases.
  • 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. It is still our weak side. Sometimes user stories are too big.
  • We release new builds weekly (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. Automated tests have been improved significantly over the last 18 months. We've migrated to Jenkins recently and parallelize tests aggressively. Now all the tests run ~40 minutes and test runs on every push.
  • Smoke testing of the build still takes 3 hours (32 testers).
  • We have a limit of 3 user stories or bugs in progress.
  • We have retrospective meetings every 2 weeks. We run JIT meetings instead of retrospectives. We have an Issue Board, limited to 3 items. When the limit is hit, we run a meeting.
  • 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).
  • We track spent/remaining time on tasks and stories.We don't track time anymore

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.
  • Pair programming for all user stories and complex bug fixes. Sometimes people work alone on smaller/simpler problems. Pair programming is used for complex tasks only.
  • 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. We eliminated pair swapping, it appeared to be distracting and annoying for people.
  • Before implementing a story, 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 have strong JavaScript testing suite now. Also we use BDD as much as possible.
  • 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. We use Jenkins now and it takes about 40 minutes to have a new build with all the tests completed.
  • Automated functional tests are based on Selenium. We've created a framework in C# especially for our application to make tests easier. Tests coverage is not good so far, but we are working on it (there are 2 automation testers in our team).


  • We still want to add performance tests into automated builds. We have performance tests running already, but not as a part of new build so far.
  • We want to split user stories better. Much better.
  • We are incorporating User Experience into development process. This is our main goal for the next year. This  includes running a UX community for customers, interactive prototypes for all user stories, usability testing. We are making steady progress here and we have defined our UX process. However, UX injection takes more time than expected. As usual.
Capterra Top 20
Capterra Top 20
Project Portfolio Management
GetApp Category Leaders
GetApp Category Leaders
Project Portfolio Management
GetApp Category Leaders
GetApp Category Leaders
Software Advice FrontRunners
Software Advice FrontRunners
Product Management
Software Advice Recommended
Software Advice Recommended
Product Roadmap
Software Advice Customer Support
Software Advice Customer Support
Project Portfolio Management Software

Subscribe to the latest updates

Thank you!

Сheck out latest blog posts: Show all

Or contact
a sales representative

Get a live
product demo

Let one of our product specialists create your account
and shape Targetprocess for your company needs.