Loading...

Follow Agile Guru | Agile Project Management Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid

To understand what ScrumBan is, we first need to revisits what Scrum and Kanban are.

Scrum:

Scrum is based on six principles:

1: Empirical Process Control: (transparency, inspection, and adaptation). Every Scrum ceremony has its core based on these 3 Empirical Processes. In the sprint review we inspect the product that we are developing; in Retro, we examine the development process. In daily standup, we check our progress towards our sprint goal to make sure we are on track. We adapt where needed.
2 Self-organisation: The team needs to be able to self – organise. There should not be anyone telling them how they need to do the work. The team should be empowered.
3: Collaboration: The collaboration is the secret ingredient in scrum teams and to improve the collaboration within the Scrum team, it is recommended that ideal team size should be 7+/- 2 because this is the perfect size for most collaborate groups. To improve this collaboration, companies like Zappos, (the online retailer which got brought out by Amazon) expects its managers to spend 20% of their time in social activities with their team members.
4: Value-based Prioritization: Work on the highest value items first.
5: Time-boxing: sprint length is 1-4 weeks, plan for small time-boxes, and every Scrum ceremony is time-boxed as well. Example: daily standup – 15 mins.

6: Iterative Development: Build and release the product in smaller batches with highest value items first.

Kanban: Principles:

1: Start with what you do now: no new processes or team structures. We have our current process for a reason and let start with them as they are.
2: Respect the current process, roles, responsibilities, and titles: you don’t have any new fancy role or titles like Scrum Master, Product Owner, Pigs and chickens
3: Agree to pursue incremental, evolutionary change as opportunities are discovered. Baby steps towards greatness.

Six Practices:

1: Visualise: make your process visible to the team and everyone
2: Limit WIP: limit the work in progress.
3: Manage flow.
4: Make policies explicit.
5: Develop feedback mechanisms at the workflow, inter-workflow, and organisational levels:
The Kanban has its origins from Toyota and in Toyota when there is a fault found in any car in the production line. The production line is stopped, and everyone works to fix the error there and then. This means that whoever caused the issue has become aware of it without any finger pointing. You might think that stopping the production line is a waste of time and must slow them down. However, this is not the case, as on average it takes Toyota 17 hours to manufacture a luxury car. On the other hand, BMW fixes fault at the end of the production line, and it takes BMW on average 57 hours to produce a car. That is not the only thing, on average there are only 34 defects found in every 100 vehicles Toyota makes whereas in BMW on average 78.7 defects are found per 100 cars.
6: Improve collaboratively using model-driven experiments.

Each methodology has some inherent weakness and difference.

• Scrum doesn’t prescribe specific ways to help measure or manage problems and dysfunctions before they manifest themselves –
• Scrum teams often become mini waterfall within the sprint.
• Doing all requirements, design and UX within a sprint is not feasible anymore. I know that nowadays the Scrum coaches recommend that designer work one sprint ahead of Dev, but this has some complexities as well.
• User stories have become large documents
• Kanban doesn’t have any planning
• Kanban allows multi-team ownership of the board whereas Scrum is for one team
• Scrum must have a matrix team with all the discipline within the team.
• Scrum has defined roles, and Kanban relies on existing organisational structure
• And the most prominent and strongest criticism on most scrum teams is that with short sprints they get so focused trying to cram work into a sprint that they don’t focus on finding innovative solutions to the problems they are handed.
What is ScrumBan
Scrumban is basically taking the parts of Kanban and Scrum that help your team become more successful and put them together to form a new process.

Issues before Scrumban implemented this team:

Like most teams, we were doing 2 weeks sprints. We found that two weeks sprint kept the team focused but trying to get everything from a story on an indexed card to working code that is deployed in prod a challenge. We were also trying to make sure our site was completely user-friendly, and every decision was based on research and not our gut feeling.
Work stayed in progress for too long, and progress wasn’t visible:
The Scrum board usually only has three columns, to do, in progress and done. Items stay in the in-progress column a long time, and there wasn’t that much transparency to see what is happening. Scrum usually deals with this issue with team members holding each other accountable during the daily Scrum but as the team grow above 12+ people, trying to pick up hidden problems can get tricky.
There were a lot of work items blocked in the sprint and blocker not visible on the board
We were regularly missing our sprint goals. In most Scrum teams, not completing all the stories in the sprint is normal. However, this can lead to teams having low self-confidence and confidence of the stakeholder in the team getting shattered.
Having a regular flow of stories being designed and user tested before being developed.
Fitting in the full life cycle of the story within a sprint : (Refinement, design, user research, content creation, development, testing, and deployment to prod.) Some Agile/Scrum coaches suggest that Designers and UX people work one sprint ahead of rest of the team, which get slightly tricky in sprint planning because the team is now planning for two sprints. Also with the team working on two sprints, you get disconnection between the team.
New team members come into the team and old ones leave regularly; this has a significant impact on team dynamic and team collaboration.
Larger team size 12+
Having external people who were required to sign off certain items like legal
Keeping a constant follow of stories designed and User tested before moving into sprint

Solution:

Our solution was to keep all the Scrum ceremonies and principles then sprinkle some kanban Principles lightly on top. Our solution was still havely based on Scrum, but Scrumban is very flexible in this sense so that you can create your own unique flavour of Scrumban. We kept the product backlog and the product roadmap to guide us. We kept the retro, review and daily standup.
We made the sprint planning more ad-hoc in the sense that we did sprint planning only when we had less the three items left on the backlog.
Stories would come into ‘to do’ column, then they would be picked up by designers; each design would be user tested.
Three avatars for each team member, (Personal WIP limit for each team member)
Column WIP limit as well.
Physical board
The team was dedicated and cross-functional, and everyone was picking up everything to a certain degree. Designer and UX were doing testing – Developers and tester were doing UX. We wanted to make sure that everyone within the team had exposure and met the end users.
The personal WIP limit insured that no one was picking up multiple items and no one was trying to do multitasking. Generally, straight after the daily standup, the team picked up any testing tasks that were on the board.
The column WIP insured that there were no bottlenecks and everything flow through the smoothly. All stories with external dependencies were highlighted by different colour card and blockers highlighted on the board by having its own column on the board.
By having stories with the external dependency of a different colour made everyone aware that this item is at risk from delays (caused by the 3rd party). These stories need extra care and attention from everyone. We would give earlier dates for the external teams to come back to us then required so that delays they have on their side don’t have a major impact on the team.
We also used the space around the physical board to put up team agreement, policies, DoD, Retro points, etc.

Outcome:

The most significant advantage of this approach was that issues were highlighted well before they would have become a problem. The team had real-time progress visibility on every story in the pipeline. Bring in new team members was a lot smoother and team members on leave didn’t cause a significant impact because the team was cross-functional.
Over time we were able to experiment and refine our WIP limits.
We also were able to run experiments as we were not under too much pressure to do everything with the sprint.
Our sprint planning became shorter as we are bringing in stories more regularly.
The stories are following through more smoothly as both designer and Dev are working closely on the same board.
Everyone knows what is coming up in the next weeks and there is no surprise. Bug and Critical issues can be added to the to-do column at any point, no need to wait for the sprint planning. Generally, the PO can mention the issue at daily standup and bring in new items.
‘To do’ column had a WIP limit as we didn’t want the ‘to do’ column to snowball out of control.

Would Scrumban work for you?

The answer is not a straightforward yes or no. It depends on the firm and the team. Some work so close that this would hinder the collaboration between the team members other would appreciate this. Before jumping into this first check if your current process is working for your team and if it isn’t then what is the underlining cause. Sometime people will jump for something that is new and shining without fully understanding what it is and if it will fix your problems.

Points raised on Scrumban:

If you read the Agile forums, you will found so many negative comments about Scrumban and teams that are doing ScrumBan. Comments like that Scrumban is done by the teams that can not commit to either Kanban or Scrum. Firstly Scrumban has now evolved from its earlier days to become mythology in its own rights. Borrowing ideas from methodology to improve your own process is not a bad thing. Even those team that call themselves pure Scrum or Kanban teams will be borrowing items from Extreme Programming camp. To be in true sprite of Agile manifesto, you should follow whatever process that helps you deliver working software in small increments

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Term Agile mindset has become a ubiquitous phrase in our daily life but what does it mean? Is there a checklist where we can try to measure ourselves to see how agile our mind and belief are? If you google the term Agile mindset, you will get hundreds of results with all different answers, and I realised in the discussion a few weeks ago that I didn’t have a definitive answered to this question myself. If someone asked me what agile mindset is, I understood that I couldn’t give them a detailed answer to encompasses the generic list that people can use.
Also, to me, Agile Mindset isn’t something that is for the work environment but is the attitude that should be used to succeed in personal life, and it is used every day in our life as a habit. If you have a recipe for success then why only use it in your professional life and why not use it in your personal life to make that a success as well.
To me, the Agile mindset is a set of habits and attitudes used by super successful people in their everyday life. Those attitudes and habits are:

Respect:

Successful people know that if they want anything done, they need to treat people with respect. Respect something that builds cultures of hap[pines and openness. If you wish to your Scrum team, Kanban team or any other group of people to genuinely get something done then you need to treat them with respect. The opposite of respect is disrespect, treat even a child disrespectfully, and they will become angry, rebellious and dysfunctional. You would be able to make a child do something when treating them disrespectfully then how do you expect that adult will work in a team without respect?
This year in April, I met this fantastic gentleman called Clinton Wingrove, and in the discussion of the dysfunctional organisation, his told us of his real experience of going into a completely dysfunctional organisation as a consultant where every one of extremely unhappy. Customer support was poor, and the company was about to go bust, and everyone was leaving. The only change he made to the organisation was to coach the company CEO to be respectful towards his employees, and within a month the company culture changed. The company became prosperous again. It shows to value of being respectful, and I would recommend reading his book to everyone.
Super teams using the principles of RESPECT by Paul Marciano and Clinton Wingrove

Continuous learning and growing:

According to the latest research, some think tanks believe that 60% of today’s job functions will get replaced by AI. We are going to face another revolution in the workspace as we did when computers and robots took over work from factories and manual jobs. However, this revolution is expected to be a lot faster and more widespread than any we as a human race have ever experienced before. Continuous learning and growth mindset aren’t just going to help you in your Scrum team but making sure that in 20 years you will have a roof over your head and that you will be able to feed your family.
Within the Scrum team, the Continuous learning and growing are looking at the best practices and techniques to implement. Scrum Framework doesn’t tell you how to write your code or what best practices to use; it expects that you will Continuous grow as a team and personal, you will keep up with the latest trends and practices.
I strongly recommend that you take this habit and attitude for the rest of your life. Invest time in reading upskill all the different skill set not just technical but your communication, financial and invest time in your welling being.
I have committed myself to read a complete book every week, and I alternate between books that help me in my role of Scrum Master one week and next week I would be reading a book about other skill sets to improve other areas of my life.
If we look at hugely successful people like Bill Gates and Warren Buffett, then we find that they spend a considerable amount of time investing in themselves. Warren Buffet is known for reading 1000 pages every day and is the most successful hedge fund manager ever and the 3rd richest man in the world.

Inspect and Adapt:

Scrum is based on the empirical process model. Those who don’t know, the Empirical process has three pillars: transiency, Inspect and Adapt, and every single Scrum ceremony is based on these three pillars. Inspect and Adapt is the reason for Scrum Framework Success, Inspect the Sprint plan every day in daily Scrum and adapt accordingly, We inspect the Product we are developing in Sprint review and adapt according to the stakeholder review every 2 weeks. We inspect the process and team way of working in retro and adapt to the action of the retro. To successful within an Agile team you should inspect the tool, techniques and way of working regular and adapt to the changes as and when required, but moreover, you want this process for rest of your life. Why only do this within Scrum team, why not follow through on inspecting and adopt at your home, your finances, your time, hobbies, health, etc. experiment with new ideas and if work adopts them and if they are not the leave them. Make inspect and adopt a regular part of your life. When doing research on Agile mindset, you come across many other habits and attitudes that are part of agile mindset but to me these three are core, and if you have these you will gain all the other habits, skills and attitudes required to be useful. Some other attitudes and habits mentioned in articles and by other Agile coaches are:

  • having fun
  • Knowledge sharing is done willingly
  • collaborate and communicate
  • Focus on Delivering Value
  • look at failure as a learning opportunity
  • Pride in Ownership

Some Books I recommend reading:

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview