There are several software development methodologies out there. Few of them come forward like Agile, Kanban, XP, Lean, Scrum etc. Especially around first-time implementers of those methods, you can see several cases in which organizations focus too much on the methodology. This over-focusing makes the methodology a ‘goal’ rather than a ‘tool’ that it should be.
Here at Kuika, we have gone through several iterations since the day we’ve started. As a startup we obviously started out with a greenfield project, built up on plain scratch, did a lot of researching and made decisions on what and how to implement. At every milestone we have evaluated our dynamics and needs to find the best suiting methodology. That led us to cherry picking of principles from different schools. Throughout this period we composed our own implementation which is still constantly evolving.
Starting With Kanban
While it was difficult to make plans or estimations about what we would be doing in the following few weeks, we picked principles from Kanban. At those periods we focused on work item break down and moving those work items to ‘done’ without overloading our capacity. Work items would focus on researching, decision making, proof of concepts and implementations.
We had sprints even when ‘Kanban’ was dominating. We picked items from the product backlog, filled them into the 2 weeks sprint plan. At the end of a sprint what is not finished would simply be passed onto the next one. The ‘sprint’ concept was more like to visualize the work plan in a rather smaller scope.
In time certain parts of the project were clearer that we could plan in detail. Therefore we brought Scrum properties to the mix. We continued working in 2 weekly sprints and now sprints meant a little more than what they previously did. Sprints are now our scope of release cycle. They have their own focus. We dedicate ourselves to the sprint. Sprint is not only to visualize the planning but more to establish goals and re-prioritize in iterations. It is to release iterating functionalities.
Eventually we had the need to know how much time things would take. So we started making estimations for each work item. This enabled us to plan the sprint and each developer’s time more precisely.
We still set goals for a sprint and divide them into half for each week of the sprint. We pick the work items from the product backlog that are needed to accomplish each goal. We know how much we can plan through estimations based on our capacity.
Each sprint content is a strict scope, meaning no modifications of content/goals during the 2 weeks period. Exception to that must be a very unusual obstacle and still has to convince the whole team on making a change in plans.
Each goal and set of work items are a complete set; meaning at the end of a sprint there are no loose ends. Features might be limited or not very rich, but they are fully functioning and releasable.
XP, the forgotten good old friend
There were a few times that some of us got lost during the development of a specific task. We experienced that trying to solve those problems with a team-mate was extremely efficient. Then we adapted two principles of XP which are
- pair programming,
- not implementing features until they are actually needed.
We will dive into the details of pair programming in another blog post. For now we can say that we try to plan work items for ‘pairs’ as much as possible. It distributes the knowledge and experience among the team.
Pair programming exponentially speeds up the development of a work item: a pair of developers wrap it up faster than double the pace of a single developer.
When we are planning a sprint, we question each work item (or goals, features etc.) if it really is required at this point. Even if it is really cool and would dramatically improve our product’s abilities, we still postpone it until someone says “I need this, can’t go further without“.
Overall we do not do Scrum, Kanban, XP or anything else; We do them all. At the end of every sprint, with the whole team we re-evaluate our methods and update them, so it keeps evolving and growing. As we grow and gain experience, our systems do so along with us. We do not have strict roles defined. Everybody is a developer and everybody is watching out for the methodology.
In short we do not follow a certain cult in development methodology, but rather compose pieces of anything we run into to a system that gives us the maximum benefit.