agile@mimacom
agile@mimacom describes our way of working with scrum within projects. In this blog post I want to share our mindset about scrum with you in order to give you an understanding of the mimacom way and how we are striving to improve our way of working. The foundation of the mimacom way is built by our modules in detail mimacom pathTM method scrum.
In inhouse projects we are implementing the scrum framework according to agile@mimacom guidelines. Similar to the Scrum Guide they are divided in different topics:
- Roles
- Artifacts
- Events
- Glossary
- Miscellaneous
Roles
In our process we are defining some additional roles as for example the project leader which is not existing in pure scrum. To have a dedicated person to control and be there for escalations helps the project as well as the team to focus on other things. Moreover, if we do HERMES projects a Project Leader is needed according the framework. However, most important thing is to define the roles for all project members from the very beginning.
Project Leader, Scrum Master, Requirements Engineer and Architect are in contact with the customer. We are also making sure that these key persons are located in the same country as the project. In some projects, our RE is even more a proxy PO. In such projects our customers are not fully able to focus on their roles as PO (ex. due to their availability or size of the project). Thus, our RE helps them to enable as well as to improve.
Artifacts
We are improving our artifacts almost with every project. One important tool is our working mode agreement with the team. In this agreement we are defining with our team how we want to work together. For example, in the setup week we are deciding together about the daily time as well as other meeting intervals. The decisions are written down in the working mode agreement. The counterpart for the collaboration between mimacom and the customer are the project guidelines. They are agreed and signed with customer at the very beginning of a project.
An additional artifact is the point "Issue type definition". As Jira is used differently in many companies and projects, each team member might have a different understanding of Jira issue types, based on personal working experience. Thus, we need to have a mutual agreement within mimacom.
I don't want to bother you further with the standard scrum artifacts. But if you have questions, feel free to contact me.
Events
We split up events as following:
- in traditional scrum ceremonies: planning, daily, story time, review and retrospective
- and in our additional ceremonies:
- setup: includes our setup week which takes place at the beginning of the project with the whole team in one place. Sprint setup; for example, we are usually preferring 3 weeks sprint - but this need to be defined. And the project coordination meeting with PL, SM and Customer as well.
- combat testing: whenever possible all engineers are testing the features of the others and vice versa.
- tech meeting: in order to do knowledge sharing and discuss difficult technical solutions, we are coming up with (regularly scheduled) tech meetings. In these meetings the engineers are discussing technical questions as well as solutions.
Depending on the project, we are coming up with some other meeting or there might be some customer wishes.
Glossar & Miscellaneous
In our glossary and miscellaneous we are documenting the most important definitions as well as tips and tricks and other inputs which might help.
The most important point in agile is to inspect and adapt. With agile@mimacom and our paths we do the same on a company level - we are developing a project where we are improving from sprint to sprint and then we are improving our whole process with our learnings.
As a learning culture we always strive to improve! Do you help me to improve? Please, give me a feedback about my blog post.