Based on the culture foundation we have set up in a previous blog post, we are always working on developing our selves and the ones around us.
Thus, one approach we follow is research on a given subject, followed up by a internal presentation and a blog post.
In this way, the researcher:
- learns something new and exciting
- consolidates his new-found information during the preparation of the internal presentation
- sharpens his public speaking skills followed up by a debate with the rest of the team
- shares his research done to the outside world to be publicly available
while the rest of the team:
- engage in the presentation by learning about the topic and discussing it
- reach a conclusion regarding what aspects need to be included in the platform or the work environment
In a nutshell, it's a win-win situation for everyone which emphasizes on learning & sharing being part of the working schedule.
Taking the previous context into consideration, the topic we discussed a while ago but only made its way on the blog just now 😄, is the framework we use to organize ourselves on the software engineering side and on the business management side.
The topic came up organically from a point of discussion from our monthly internal retrospective where we analyze all the feedback written down by all the team members, on a broader perspective through the lenses of the start-up .
Based on the point of discussion we have identified applied a four step analysis methodology in which we identified the problem, extracted the root cause and reached a consensus regarding the solution that needs to be implemented.
I will not go through all the details of the presentation but instead will stick with the solution and show you how we implemented it.
We believe there are three key aspects that defines a good startup long-term:
- the key to doing agile right is embracing a mindset of continuous improvement
- experiment with different practices and have open, honest discussions about them with your team
- keep the ones that work, and throw out the ones that don't
Given the fact that as a start-up we are both equally focused on software engineering and business management, we have agreed to use Scrumban using the following practices:
- iterations (sprint) of one week
- the sprint contains work items from both domains: business and software
- adopted the following ceremonies: sprint retrospective, sprint demo, sprint planning and daily stand-ups
- adopted the following roles: distributed product owner, scrum master by a weekly-rotation
- work in progress limit of 2 work items / person
- cycle time expressed in hours
- because we also do business management, we decided to switch from a push system to a pull one, in order to allow all of us to be focused on our work and keep the distractions away
- the push-to-pull shift is implemented through the scrum master which checks every morning 30 minutes before the stand-up for anything new that appeared (such as e-mails, social media, chat, blog and so on) and creates new work items which are put in the backlog by default
- during the daily stand-up, if a work item has a higher priority that needs to be addressed this sprint, we switch it from the backlog to one from the sprint that can be moved to the next iteration
In order to apply these practices, we have chosen a new tool, Jira, taking into consideration the following aspects:
- setup time
- managing time
- learning curve
- framework practices
- retrospective capabilities
Thus, we now have two boards in Jira which enables us to organize ourselves in our Scrumban style 🎅🏻
Subscribe to GoHelpFund Blog
Get the latest posts delivered right to your inbox