1.5 years ago I wrote a post that described our development process. It is interesting to see what's changed.
- Product development (quite large web application)
Two development teams: Core and IntegrationSeveral Mini-teams.
- Quite mature product:
- Technology: C#,
- Development team has all the power to try new practices, keep working practices and remove bad practices. There's
a littleno 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
- 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
alluser 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.
- 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.