Základné a nadstavbové vzdelávacie programy pre tím.
Dlhodobá podpora tímov mentormi.
Spoznajte potenciál pre zlepšenia tímu.
Príprava a nastavenie tímu pre tvorbu komplexných produktov škálovaným Agile.
Ucelený a zmysluplný rozvoj tímu
Základné a nadstavbové vzdelávacie programy pre Scrum Mastrov.
Dlhodobé programy rozvoja schopností.
Identifikujte svoje potenciály pre ďalší profesionálny rozvoj.
Príprava Scrum Mastrov pre prácu v škálovanom Agile.
Základné a nadstavbové vzdelávacie programy pre Produktových vlastníkov.
Pripravte sa na prácu produktového vlastníka škálovaného portfólia produktov.
Vzdelávanie pripravujúce firmu pre zavedenie Agile.
Dlhodobé rozvojové programy pre zavedenie agilných praktík do firmy.
Hodnotenie agility firmy a identifikácia potenciálov pre ďalšie zlepšovanie.
Príprava firmy pre škálovanie agilných praktík.
Domov / Blog / Kanban or Scrumban
The Agile company can be recognized by a presence of Kanban boards with index cards of user stories which are put into multiple columns based on their status. Such board looks simple and easy to handle.
For agile teams, this is very welcome due to a low level of bureaucracy, high transparency, and easiness of usage. Win win win scenario for the team, business and project management as well.
But is Kanban board with user stories the best for your team right now?
The biggest concerns we observed in many companies which try to implement Agile are:
All these things often block teams. The question „What about to break down the requirement into smaller activities?“ Ends up in an impulsive answer „No!“. What are the reasons?
People think that such effort is just a loss of the productivity, effectiveness and adds more bureaucracy. But the facts indicate the opposite in most of the cases. Especially in the case of immature Agile teams with problems listed above.
An investment of just little more time in the breakdown gives the team more clarity in the discussion about the problems they try to solve together.
The domains which were specialties of only a few people will be possible to understand by others just because of a transparency and more details thanks to subtasks.
To illustrate gains let’s talk about the real life example we observed while coaching the new scrum team.
The team developed a core company system that must be able to offer an electronic payment.
There weren’t so many people in the team who understood the Visa payment process. Typical „expert bottlenecks problem“. In this planning session, we asked how they are going to implement the solution. The first answer was the same as in many other teams.
„You do not understand the problem so why to explain it. It is just a loss of the time. I’ll implement that in the same time instead.“
Exactly this behavior is the reason why you can’t go for vacation. It is the reason why you have to work at home even at night because of all the fireworks.
But once they realized, thanks to subtasks, there is necessary to develop some database table for the invoices, the payment transactions, and transaction status, suddenly more developers were willing to do that even without knowledge of the VISA payment process. Testers understood how the solution will be built and what exactly needs to be tested and how. The knowledge transfer has just been started by such a small step.
For new scrum team, we suggest starting with Scrumban board.
Scrumban board is based on the Kanban board (well kanban means a card ?) but comparing to the Kanban, the board keeps user stories and subtasks at the same time. User stories are put in the first column. Only subtasks are moved around the board to indicate the status.
Using this board your team will:
No way! I just want to say that based on experience new teams should start rather with Scrumban board first.
The kanban board is something you should deserve once you built up the discipline of transparency, willingness to work in unknown areas, and collaboration in the team.
When we started development of the ScrumDesk web edition, we started a new collaboration with a couple of freelancers we didn’t know at that time. We requested the one thing consistently. A transparency and discipline.
At the begging, our boards were full of subtasks. As business owners, we were able to identify how discipline are new team members, how the work is distributed among the team. How good are they in a discovery of facts which weren’t provided in the user stories. How much testing we had to do, how much effort we need to invest into code review, merging, deployment. We were able to measure the cost of non-development tasks as well. Even operation and support, meetings etc. Such transparency simplified budgeting of the sprints while still have consistency in the quality of results.
The impact is huge. The team completes user stories in planned order. We are able to deploy new user story nearly every 2-3 days.
There are 1-3 urgent bugs in average per 3 weeks sprint.
The team is more focused on new stuff which gives them better motivation.
We have much more facts before we have to change the Sprint. Shouldn’t we do that? Well, yes in Scrum, but after all these years now we are more Kanban house than Scrum.
Kanban is the next level for Scrum teams. Deserve such simplicity first!
Kedy zaviesť Agile? V článku priblížime, ako sa rozhodnúť, v akých situáciách má zmysel zavádzať Agile. Článok...
Projektový manažment sa vzhľadom na zmenu fungovania firiem smerom k Agile mení a prispôsobuje. Pripravovať podrobné...
Co dát komu pod stromeček? Otázka, která mnoho z nás straší pomalu od října (či chcete-li od októbra). Máte mezi...
Nenechajte si ujsť výber toho najlepšieho z Agile, s čím sa stretli naši mentori. Nielen zo sveta produktov, vývoja, tipov a trikov, ale občas aj humoru. Posielame pravidelne, raz za občas :) #QualityOverQuantity