This document explains about how to build your Software crew and some best practices that could make your Shift to Agile a smooth sail. If you had not read my Part-1 of the Document, you can do so A Novel Approach to Agile Software Engineering Process - Part 1
Building the crew
The ideal step in building the crew should be the form of knowledge sharing. Here the pyramid multiplication rule works fine.
The knowledge of the product development is shared by the Lead Developer into the fellow developers, each new developer who joins are put along with an existing developer to learn the art of the trade. The roles played by the developers are also flexible.
- Lead Developer – Initiates the Training to the fellow developers and creates more lead developers
- Developer – Develops the product on his own, takes help from the peers and lead developers as necessary, mentors new developers and makes them into a full blown developer, becomes a Lead developer
- New Developers – Does testing at first, learns about the platform and product. Does bug fixing before doing actual development, becomes a Developer.
Things to bring to plate
The following are some of the things that can be brought to the plate, these can be incrementally added to the cycle of Product Development.
Ownership of the Product
The ownership of the Product should be taken by the Developers, they should take pride in crafting the product rather than developing it. All the updates/Testing/Code Quality and Commits should be done by them without the need of any intervention.
Time to Market vs Time to develop
Time to market is important for any product, First in market is king, but also delivering the Quality product is as important as the time to market, so both Time to develop and market should be balanced, All tiers of Product Development should support this.
Avoid Bugs at the Development stage – Internal Bugtrack
Avoid any major bugs at the Development stage, frequently occurring bugs across products can be noted and eliminated before the development starts. Also a master Test sheet can be used to check common bugs for every products and fix them at start by the developers
No importance Hierarchy
There is no importance hierarchy, all are important in the product with each playing their role in getting the product completed on time with highest quality and necessary functionality.
Build the Pyramid
In order to build the pyramid, necessary trainings, peer knowledge sharing and mentoring is needed, never break that for the work pressure.
Sprint Meetings and Spark meetings
Sprint meeting happen every day for 15 min, at their respective place along with all the developers, Project manager and the Lead developer. They answer the usual sprint questions and report on the process or the problems of the Product.
Spark meeting happen every Friday for 30 min within the developers. The lead developer along with other developers share their knowledge, have a tech talk and even things unrelated to the project (this helps them grow and should never be avoided)
Monthly Workathons
Workathons are times where the developer sits for hours (one day +night till next morning). This can be done at the 3 week Friday and helps in pushing the limits and getting the fun of developing as team. Company sponsored snacks for the night with mild fun is encouraged and this time is meant for the creativity of the developers as they do R&D and build some cool ideas which can be sold off as product
DevOps culture
DevOps culture should be followed where the whole team does everything (each one is a project manager, developer and a tester for himself). This new trend is followed by major companies and by product development startups.
From Agile to Automattic
Things should flow automatic for the product development, with each one participating in it. Best inspiration would be this.
http://www.fastcolabs.com/3035463/how-matts-machine-works
The Agile involves not only the development, but also people, process and standard to be followed. Be sure to follow to know more about Agile Software Engineering and Best practices on implementing them.
- SAP Managed Tags:
