Agile in Primary Schools

Instructors in primary schools as far and wide as possible are starting to utilize Agile to make a society of learning. This disposition is the thing that has headed training pioneers, to integrateAgile learning into these schools. Agile learning focuses on individuals and associations over procedures and instruments, and meaningful adapting over the estimation of learning.

Despite the fact that a huge piece of Agile includes routine state sanctioned testing, it isn’t the sort of testing that measures substance knowledge–it’s the kind that measures considering. Genuine learning in primary schools means that young students will discover the importance of learning for the rest of their lives.

Over recent years since its first integration, the Agile philosophy has been found to energize ceaseless change. As of yet, Agileintegratedschools have been found to have a good number of qualities. For one, their most astounding necessity is to fulfill the needs of understudies and their families through ahead of schedule and ceaseless conveyance of serious learning. They convey genuine adapting often, from several days to a few weeks, with an inclination to the shorter timescale. Agile learning and the participating families cooperate every day to make learning open doors for all members. This is found to really help the learning especially in primary schools where confined spaces often result in restless children.


On Your Mark Get Set Go! Finish Line
(Notes) (Notes) (Notes) (Notes)

(Agile learning schools integrate a child-friendly version of Scrum, with terms such as “On Your Mark” and “Go!” making children look forward to work. It also makes them visualize the work they have completed. )

Agileintegrated schools also assemble ventures around inspired people, provide for them nature and help they need, and trust them to accomplish the employment. They perceive that the most productive and successful strategy for passing on data to and inside a group is vis-à-vis discussion. Primary schools that have Agile learning have courses of action push maintainability. Instructors, students, and families ought to have the capacity to keep up a steady pace uncertainly. This new kind of learning accepts that persistent consideration regarding specialized greatness and great outline upgrades flexibility. Interestingly enough, these schools have the specialty of expanding the measure of work done–is crucial. The best thoughts and activities rise up out of sorting toward oneself out groups. Finally, over the past couple of years, all primary schools that have integratedAgile learning have seen students be much more successful in all other areas of life.

Like traditional Agile environments, Agile learning in primary schools utilize the use of a “sprint”. A “sprint” is a period boxed length of time inside which classes focus on a set of conclusions to be attained before the end of the time-box. Much the same as a sprint in Olympic style events, it is a brief time with a beginning line and a completing line, aside from for this situation, it is not separate, the time it now, time. When one Sprint closes, the following one starts.

In addition to everything else, Sprints have taken care of the issue of young students becoming lost despite a general sense of vigilance and of instructors squandering time on misguided units of study that run for months on end without any huge evaluation of learning. In the long run, this sort of learning shows students that school is indeed a place that provides useful information and applicable methods. It teaches them that education has its merit, and no merely somewhere to escape their home lives and drone out the words of their teachers.

agile learning

(Agile learning often integrates small circled groups for interactive learning).

 Agile learning in primary schools has tacked the issue of separation such a large number of educators battle with. Groups have been shaped out of sets of combined educators. This has been communicated as being a conventional group instructing, as “visitor” showing where instructors exchange off heading lessons as per individual instructional skill, and is also achieved through cross-class movement. Cooperating for a considerable time of time and offering obligation regarding the same understudies has built the regular utilization of streamlined practice, and furthermore, it gives a lot of people more chances to educators to comprehend the students’ needs.


Agile processes have proven to be most useful in the workplace, especially with software development. Because this has occurred so nicely in these environments, scholarly pioneers have agreed to integrate these similar methods into primary schools. Using such tools as “sprints” and flexibility have a strong effect on young students and how they learn. Not only are they doing better in school; they realize how education – and learning – is a positive thing they should integrate in their daily lives (for the rest of their lives). This will also make children think positively about school and institutions, making them much less likely to turn to crime later in their teens and adulthood. It encourages teamwork, quick thinking, and focuses on learning more than the result. By the end, students feel accomplished and more ready to take on other world challenges. As a whole, the positive trend that Agile learning has created in primary schools is a template that many more schools should follow.


Summarizing AgileEncore 2014

It is all started when Deniss Alimovs pushed me to attend Agile encore 2014 event. I definitely believed that the invite was for him but he is so generous to share such opportunities with his team mates (That I call a sign of being a great leader).amit@agileencore

I thoroughly enjoyed this session and I am glad to share the following notes in my blog post.

PLEASE NOTE: I have excluded common messages that I presumed we all know. However, what you will get below is something new that I found could be beneficial to remind you.

Also keep in mind that that these are my interpretation, my observation and it may not be 100% same as speakers' said. (I am still trying to learn - how to listen over hearing.)

agileencore2014 banner

James Brett, Founder, Curiously Lenka Bednarikova, Scrum Master, Commonwealth Bank Lachlan Heasman, Agile Coach Scott Kinder, CEO, The Kinder Group Sandy Mamoli, Founder, nomad8  Dipesh Pala, Agile Capability Lead, IBM John Sullivan, Product Delivery Manager, Business Division, MYOB
To read about specific speaker, please click on their photo.

Four things we need to know about teams – Lachlan Heasman, Agile Coach


Lachlan started with the statement that there is a difference between group and team. Team is something we should emphasis on building it. You can build a great team by knowing some of the commonly known models in the market such as Tuckman and Poole. Then he took me on motivating team. He also emphasized on Outcomes over Processes and ended his four points by stating that you don’t need a title to be leader.

Let see what these four points means to me.

1. Development Model

The following productive team build development Model was discussed – Tuckman and Poole. Here is my understanding with these two:

Tuckman Model

I already knew about Tuckman model and you can read it at my previous blog post –

However, the bottom line about tuckman model is about giving you a leadership tool so that you can build a well collaborative team (it is all about communication).

Poole Model

Poole’s model put forward several tracks for the group communication and also stated the tracks can repeat or can happen at any time of the communication process. This model consists of the various tracks used for interpreting the communication styles that a group follows.


Poole's Model

2. Motivational effects

Lachlan labelled some managers’ as “Free rides” i.e .those Take the benefit of someone else work.

Another tag he had referred is “Social Loafing“. Social loafing began with rope pulling experiments by Ringelmann, who found that members of a group tended to exert less effort in pulling a rope than did individuals alone. Thus he suggest that team work is important however, each of us should put their own efforts to reach the goal.

The major motivational efforts he talks about is Kohler Effect  i.e. leaders have to set examples for others so that others can try to achieve the same. At the end, no one wants to be left behind in the team.

3. Outcome vs. Process Focus

You can focus on any process (including Agile), however the main objective is the outcome. So the message came across is thus it is good to have a process, but the process should be introduced to produce required outcome. Thus, outcome should be our main focus, and process comes along with it.

4. Leadership

The main message came cross is – You don’t need a title to be a leader, which it remind me about this book.

Managers needs to provide required tool and environment to produce leaders; thus making outcome focused team.

Unleashing the full potential of your Agile team, Dipesh Pala, IBM.

Whatever makes you happy will make your team happy. So what you want to feel, you should reflect the same.

“Be the change that you wish to see in the world.” ― Mahatma Gandhi

He asked a question – What makes you happy in life?

Audience believed that the following will make them happy:

  • Achieving something,
  • Being recognised,
  • Having Hope,
  • Trust in people around us
  • Being rewarded,
  • Being loved and respected
  • Always learning
  • Making other people happy,
  • Being challenged, simulated
  • Sharing your fruits with others.

What he was emphasizing – “What will make you happy will also make your team happy”.

Understanding individuals what makes them happy will lead you to make a good agile team as well.

To make a better team it is important to understand that leaders should provide supporting environment that makes the best team, producing better outcome.

He asked a question again – what makes you think which item is the most important for them?

  • Providing Clear Goal
  • Providing Interpersonal support
  • Providing reward and incentive.
  • Providing support for making good team (it is the main)
  • Providing recognition for good work

Managers ignores “Providing Support” where as their thought is on “Recognition for Good work”. Get the small wins be celebrated within team, thus makes you a best team. This is what Managers must do i.e. Peace loving environment.

“If you cannot fly, run, if you cannot run, walk, if you can't walk, crawl, but by all means keep moving - Martin Luther King.

Leader should be inspiring small wins. Leaders must remove the control of information and let it flow within his team. Agile team works only with the trust. Project Managers should be promoting transparency thus there is a great visibility and trust is build.


To check the status of of your team, he recommended this check list for leaders.

Agile and Special Forces: Leadership that lives disruption, James Brett, Founder @ Curiously, Scott Kinder, CEO, the kind Group.

There was a great comparison of Agile Manifesto with the way Military operates. Scott comes from US Military background and with the help of James, he has did a great live comparison. Their presentation is good to see as well.

The important message was, instead of emphasizing on skill sets, like you find in any job advertisement, there should be more emphasis on finding people with the right attitude. And then train them by empowering them with the tool set.

Another key message throughout this presentation was “Disruption”, which should be seen as opportunity. So whenever, you see a change is happening consider it is for good. You will be injected with a new knowledge or an area that you might not have seen is better.

It is like you can replace “Excuse” word with “Opportunity”.


Let the right one in, Lenka Bednarikova @ Commonwealth Bank.

The cost of getting it wrong person is higher then expected. There is a financial cost however there are other costs that must be looked at.

Cultural cost – We should be finding people from company future projection of view so that the future can become reality.

Financial cost – Of course by hiring people with current culture point of view, you might end up spending lots of time on teaching them your future and there is a great possibility that they will leave your organisation.

Traditional Hiring Vs. Agile Hiring

The bottom line is instead of selecting people with Buzz words, let people comes in for face to face conversation and select those people that can bring right passion. Please don’t select people because they are awesome in .NET and passion means – people will do the right thing rather doing something.

Most importantly, your organisation should be prepared for the passionate conversations.

Another interesting thing that I found Lanka said is to hire freshers. The reason is because they are bringing a fresh air, with no assumptions and new views. They create an environment that people need. Potential over Experience is something has been emphasized.

Portfolio Kanban: Seeing the bigger Picture – Sandy mamoli, Founder, nomad8

Doing too many things at once can slow an entire organisation down. Every successful organisation will have more great ideas than they have capacity to build, and it is tempting to start too many of them at the same time.

The more we add the more we become unstable.

The moving parts for any organisation is:

  • Work
  • People

Thus, you must fix work by showing an entire Portfolio.


Guerilla Re-transformation John Sullivan, Product Delivery Manager, MYOB


  • Don’t focus on Agile Manifesto, instead focus on key principles.
  • He transformed MYOB team by bringing right people and change happens at managerial level.
  • He also suggest that to hire permanent employees over temporary employees.


Lastly, after knowing Lisa Frazier @ CBA, I am proud to feel that leaders @ CBA understand the value of human resource, and it makes me feel that I am as important as others.

This is my outcome of yesterday’s session, what is your?


Click on this link for original presentations

How to do team meeting in an agile way – Explaining Lean Coffee ™

If you have been implementing Agile in your organisation, you must have been involved in one (or many) of the following meetings:

  • Sprint Planning Meeting
  • Daily Scrum Meeting
  • Sprint Retrospection Meeting
  • Random meetings.
  • Technical Meetings and so on…

Majority of times I feel that meetings have one (or more) following flaws:

  • Missing Direction,
  • There is no outcome,
  • Unexpected Discussion,
  • Meetings are over-timed,
  • All (important) points are not discussed.

Meetings like, Sprint Retrospection, has been time boxed. However, it has never been concised.

Lately, I went to one of Scrummasters discussion forum at CBA (CommonWealth Bank of Australia). There, the lean coffee ™ meeting was introduced.

I found very fascinated with this concept. I discussed the same with my Manager and then to my entire team. I am glad to tell you that all of my colleague got very excited with this concept. I thank them to accept my suggestion and here are some outlines that I would like to share with all of you.

What is Lean Coffee ™?

Lean Coffee ™ is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. Jim Benson and Jeremy Lightsmith founded the Lean Coffee ™ movement in Seattle in 2009.

The Lean Coffee ™format is essentially an approach to facilitate learning and collaboration through group discussions. The ‘Lean’ part of the name has its roots in Lean Thinking and the ‘Coffee’ part of the name obviously comes from thenice drink that we drink to live.

How it works

The protocol, borrowed and modified from the Sydney Lean Coffee group and Limited WIP Society, is as follows:

  1. Create a small Kanban board with four columns – To Discuss | Discussing | Discussed | Outcome.
  2. Brainstorm topics that everyone would like to discuss and note down each topic on Index card (or sticky note). Everyone presents his or her topic in a couple of sentences.
  3. Use dot voting (or initials) to vote on each of the topics.  Each person gets two-three votes. You can vote ones or more than ones per topic.
  4. Add all topics to the “To Discuss” columns on a Kanban wall, with those that received the highest votes at the top.
  5. Do a quick calculation on the  time in hand divided by how many topics you would like to cover. Decide the length of conversation per topic.
  6. Discuss each topic in turn. Move the index card for the topic into the “Discussing” column. Initially, ask the proposer to explain the topic, then go round the table to give an opportunity for everyone to provide an initial comment followed by open discussion.6.1 When the topic is done, move on to the next one.  The topic proposer decides when the topic is done, and moves the index card to the “Discussed” column.

    If someone disagrees, then a quick vote can justify to discuss it further Otherwise, if the majority disagree to discuss any further then mark the topic as “Discussed” on board. The outcome can be noted down on the wall for further actions.

  7. At the end of the overall Lean Coffee ™ session, run a quick retrospective.  What did you like? What  you did n’t like? What are ideas for improvement?



I am delighted to tell you that it has been a major success after implementing this process. Here is a small snippet of our meeting.

  • Because every step is time-boxed. There are very limited possibilities for time wastage,
  • Every topic was appreciated and important points were discussed first.
  • The attendees collectively  ensured that the session was a safe space where opinions were respected. There were no stupid questions and nobody lambasted anybody for what they had to say.
  • There were disagreements but those were discussed in a grown-up manner rather than becoming heated arguments.
  • There was no moderator to make this happen. The attendees moderated themselves.

So if you were waiting for the perfect time to seize the opportunity of building an effective meeting session, the time is now.

Get lean coffee process works for you.



Some sites for Lean Coffee ™ Meetups around the world:

Seattle Lean Coffee ™.

Lean Coffee(tm) San Francisco.

Lean Coffee(tm) Sydney.

Lean Coffee(tm)Toronto.

The most valuable Asset – Agile team – Rules


  1. Be conscious of your current level of productivity and happiness and make continual changes to grow.
  2. People are at their best when they are healthy, energized, focused and at ease. Design your day to day activities to enrich your mental, physical and professional selve.
  3. Work on yourself just like you do on a project. Plan the necessary disengagement from the project just as carefully as you’d plan the time you work on it. If you can systematically improve and expand your skills, then whether the project works out or not, you’ll always be in an increasingly better position as the weeks and months pass.
  4. Share early in the decision process to avoid big revelation.
  5. Focus on listening rather than responding. Take the approach that everything is a hypothesis and you could be wrong. You are suggestive rather than instructive, replacing phrases such as “certainly”, “undoubtedly” with “perhaps”, “I think” and “my intuition right now”.
  6. Talk, code, design and write in a clear way instead of being clever.
  7. Admit when you are wrong.
  8. Respect each other’s time and space, if someone has their headphones on don’t physically disturb them, ping them on Chat or through another onilne medium, create a task if you have a question.
  9. Make decisions based on facts over rank.
  10. Open to be responsible over blame culture.
  11. Remove any negative thoughts over the coffee/ tea or a beer – we are family.
  12. Open to change. We may know what is right but may be there is a better way to do something.
  13. Wake up fresh and work with clear and focused mind over working that extra hour in the end of the day. Always aim to be fully engaged in an activity or rest instead. Focus on expanding the capacity of your mental, physical, emotional and spiritual energy (yes, spiritual).
  14. It is everyone’s responsibility to make every day fun.
  15. Don’t be afraid to actively seek out and provide constructive criticism.
  16. Have the courage to think differently and discuss your inner thoughts with others.
  17. Committed to excellence in everything that we do and a clear understanding that the only way we can get there is as a team.
  18. Always try to put a positive spin on things.
  19. Do what we say we are going to do.
  20. Be humble.
Teamwork without email
  1. About to write an email. Write a task comment instead.
  2. Need to ask a question or get an updated file. Create a task.
  3. Have a team announcement. Publish on a blog or Wiki.
You are the business
  1. You are run your own business and just like any business owner you want your business to succeed. Share your thoughts on how you believe the business might succeed.
  2. Fix the problems even if they are not yours.
  3. Don’t complain, suggest solutions.
  4. Treat “failures” as opportunities for growth.
  5. Understanding the bigger picture of the business even if it is not directly related to the work we do.
When we miss a deadline we ask questions
  1. We underestimated the time it would take. Why? We didn’t have the right tools. Why? By the time you get to your fifth why you get the root of the problem. Then you can better avoid the same issue in the future.

“Scrum Shortcuts without Cutting Corners” – What’s new for me ?

I have been reading this book and I am fond of the way Ilan has managed to mix a right combination of his experience in Agile and his sense of humour. It feels like he is sitting in front of me and teaching the same.

This book is small and sweet.  If you have been an Agilian like me then I would prefer you to have this book on your shelf.

Although, I have learned many new thoughts in this book, and I would like to highlight the top 5 points that I felt is quite interesting.

1. Define Your Technical Tasks as User Stories

Whenever I have been assigned a user story, I tend to create tasks in the form that one technical person would like to hear. However, it is quite interesting to read in this book that there is an another better way to define your tasks, i.e. Define your technical tasks such that it make sense to the Business (Product Owner) as well.

Well technically it makes no sense that Business People would like to know about these tasks. However, I guess it will be good to speak their language so that they can understand that we are doing tasks to accomplish actual User Stories.

Let’s put it in a simple way that every task should aligned with Business Value. Otherwise, it should not exists.

An Example:

As a user I would like to create a shopping basket so that I can checkout more than one item.

Instead of defining your tasks as

  • Database Layer
  • Create Functional Test
  • Generate Test Data
  • Create HTML PAGE WITH CSS classes for Links and Button
  • Create Server Side Component for Card Management

You might want to reword your tasks as:

  • Develop a mechanism that persist the basket against loggedin user (including test design and automation)
  • Develop a Add Remove Functionality along with number of items, that will add remove items from current user basket (including design, test, sample data).
  • Develop Navigation Page Functionality.

The main benefit of this approach is, after a task is done you can actually show it to the Product Owner. It is because the user story has been divided into sub tasks that can work independently. 

2. Definition of Done (DoD)

So far all I knew that “User Stories” needs “Definition of Done”. However, as per IIan book there are two other places where definition of done can be beneficial:

Task Level

We should define DoD for Tasks as well. This way the performance against User stories can be measured. This can be used as a measurement tool within the team that specific tasks are done.

Release Level

Release should have Definition of Done as well. That includes:

  • All code related to the release has been successfully deployed to the production level.
  • The smoke testing has been executed.
  • End-users have been trained,
  • The release has been accepted by the Product Owner.
3. GIFTS – Daily Stand-up Meeting

IIan has referred few techniques to remember his messages. One of it is: GIFTS.

Good Start, Improvement, Focus, Team and Status.

Making SCRUM meeting (infect any meeting) productive is as important as delivering a right product.

GIFTS emphasises some qualities that can be implemented for Daily Standup meeting.

Good start: Daily Scrum meetings should be about giving energy to the team; so don’t take debates or make your stand-up meeting as a problem-solving session. Instead, the energy should come from each member through the sense of purpose that they are working on and the urgency of delivering the same.

Improvement: If I ask you to remember the last question that Daily Stand up ask is – “Do I have any impediments or blocks?” This question is commonly ignored when there is no blockers. It is advisable that Scrum Master keep a note on that this question has been answered by everyone; even if it is “NO Blocker”.

After all, we cannot fix problems that we don’t know about so a large part of stand-ups is about exposing problems to allow us to improve.

Focus: Please keep your meeting to the point. There is always going to be some points, suggestions, that needs to be discussed. However, the focus of this meeting should be on current tasks in hands i.e. Sprint.

I also liked his idea of using ball (play ball) between meeting so that everyone is active in the session. Another point he has emphasis on making sure that the speaker is addressing entire team rather speaking to scrum master only.

Team: My way is right way – well technically I heard this point many time and I hate that when one cannot adapt on situation. I guess IIan is mentioning the same about having a good team is all it matters to have a successful sprint. Hence he is emphasizing on communicating, working, and helping each other by sharing obstacles.

Status: Here is an interesting take from his book:

The status (What did you do yesterday?) should have two sub-questions:

  • How is the work progressing?
  • Is there anything else interesting that the team should know?


Read more about this idea on page 108. And you will find on Page 110 that he has shared some thoughts on giving an award to the person who broke the build  🙂

4. Risk Takers and Mistake Makers

Five years back when I first got to know about Agile Manifesto, I honestly felt that what is so new about in Agile?

I’ve been improving since Age 1.
I have been communicating when I need food; either crying (baby milk) or by earning a bread.

One way or another Agile Manifesto has been here. But what has made Agile so special? And most importantly why people are not adapting Agile?

IIan has answered very well.


He has further shared his knowledge about how Facebook devs’ face the fear. There is a fear of Change, Fear of cross-functional team. Even I would say that Fear of Failure has made us to write lengthy technical documents so that we don’t leave any corners’; and we all know about how effective waterfall is!

Another fear he has talked about the Fear Of Exposure ; Some developers just like to be left alone in a corner to focus on their work and can become quite defensive about perceived regular inspection of what they are working on.

Agile emphasis on – What you make should be aligning to the Business Values. Thus, Agile and TDD goes side by side. TDD is about Test Driven Development that always force you write what is required. Agile is also the same thing about getting Business Values. Thus you will write code but only if it is required.

Fear of Making mistakes – Let me be honest here that I have been told that there should not be any bug in my code, otherwise, there is a performance concerns.

Let me be honest here again that if you are going to give me such environment that produces fear then my whole energy will drain into saving myself. I will not be any creative at all.


5. Some meaningful Matrix

IIan mentioned about the importance of two more matrices. These are:

Sprint Interference: That assists teams with their sprint capacity planning:


Interference Matrix

Remedial Focus: That enables team to gauge how much of their collective effort is being spent on bug-fixing as opposed to working on new requirements.


In conclusion, This book  is simply a collection of breath taking truths that you have been facing in implementing Agile. There are many other good tips present in this book, such as – The Seven P’s – Proper, Prior, Planning, Prevents, Piss, Poor, Performance. However, I found that the above five points are quite interesting to read and I would like to implement this in my next Agile Journey. 

And remember, you are learning, you are planning, and it is an ongoing process…

… Be Agilian, Be Productive…


Combining Kanban with Scrum: A Practical Approach

In the past there have been many debates on whether or not Kanban or Scrum is more powerful. Although both make their own solid points; points so different that it would seem rather impossible for one to dovetail them, there is, in fact, a way to combine both Kanban and Scrum. Let us examine how these two methodologies can work together with a practical approach.

When it comes to both practices, you can sum it up as such: perceivability & restricting work in advancement. Kanban is light to the point that it doesn’t give sufficient direction to groups embracing something else such as fell improvement. There have been groups that have not been equipped to adapt to the entire procedure themselves. Because of this, groups need a method for social occasion necessities, as well as a way to solve issues with group development while conveying business esteem and handling money issues.

Scrum, on the other hand, works really well for software development. It is a great process for building fantastic groups, especially when it is accomplished in the correct manner. Unfortunately, it is not often done so. But, because of it its potential, it is worth trying to integrate it with something such as Kanban.

Finding a way to integrate the greater part of this would take immense measure of time andexertion, whichcould often be squandered under ill care. This is, naturally, not the desired effect of the combined Kanban and Scrum.

What would work, then? The answer now lies in the work of analysts.

In the first test, analysts took the basic theories behind each approach to test out a way to make both of them work together. In order to do this, Scrum and Kanban had to be consolidated. In the test, they took both a Windows sysadmins that upheld lab system and Linux sysadmins that backed working system, as well as associations between destinations. There were even 1700 clients that were taken into the study to figure out how the consolidation of each was to effect workers. This was necessary for this test, but made it exceptionally harder for the analysts to track specially appointed work, which was later assessed for half of the aggregate limit.

To do (Windows Team)(notes posted on wall) To Do (Linux Team)(notes posted on wall)
On Hold Person A Person D On Hold
Person E Person F Person B Person C
Done Rejected

(A representation of how work was divided on the board with the first test)

There was an organized board in the space where the combined theory was truly tested out. There were lines that separated the work that the Windows team was to do, and the work that the Linux team was to do. This was called the queue. People were to then place their note, or job, in their square while it was in the process. Essentially, this is the influence of Kanban.

In the test, the problem laid in the integration of Scrum. This is because Scrum handles maintenance in a poor way. Even when they try to provide a solution, it often results in unpredictability for the team. As such, analysts had to switch to a new method.

This new method dealt with three teams instead. This dynamic would include two teams that worked using Scrum, and one that worked with Kanban. Instead of what was done above, these members were rotated every sprint. The developer was a part of the Kanban team every third sprint, and the Scrum teams, instead of honing in on the support pot, put their attention on user stories. At the same time, Kanban handled support and maintenance, taking that job away from the Scrum team. As a result, the developers better understood the work they were putting out there, and why it is being created. It created a high responsiveness that yielded to happy users, which ended up with more profit in the end. By continuously working, the sprint backlog was improved. All in all, this method proved to be much more practical in the long run.

repeated sprint cycle

(Illustrates the sprint cycles of the second test)

Still, even the most practical methods have a downside.Unfortunately; this method disallows members of the Kanban team from being able to depend on the task being completed by the other team.


By having a two Scrum teams and one Kanban team, with developers overlooking Kanban progress in every third sprint, users eliminated such hindering processes such as failure demand and support pot found in Scrum. As a result, the teams were able to hold an objective outlook and were allowed to use which ever method they believed to be most effective at the time, whether it be whiteboard architecture, pair programming, or other methods, making the work group more agile than ever. Even with the downfall of both teams not being able to depend on the task of the other, this second test proves that there is, in fact, a practical approach to combining Kanban with Scrum for everyone to benefit from.