Strong scrum master is still a slave leader!!

Last summer, there was a re-organization and along with several ideas, a controversial idea was tried out where in scrum master will handle multiple teams. My manager came to me and told me that our organization needs strong scrum masters and they should be able to handle multiple teams.
I mentioned that the idea was controversial for some reason:
1. Most in the community didn’t go ahead with this idea. In the all hands, the popular feedback on the idea was that "A good scrum master manages multiple teams. However, the best scrum master manages only one". Perhaps, this is a blogging point for another time but for now let me focus on what i wanted to communicate.
2. Scrum is about team dynamics, empowering people to highlight the issues, pull the chain and stop the production until the issues get resolved. For this to happen, its very much required that pigs stay pigs and chickens stay chicken.
One of the best people managers that I know of told me on his first day : hey Jagan, in your day to day affairs, you will come across several people issues and its important that you, as a scrum master, don’t try to solve them and just bring it to the people managers for resolution. Also, he gave me an image of scrum master which till day has been my guidance. The scrum master’s ideal role is an image of a person with a sword in one hand and a broom stick in another hand. Broom is for cleaning after the team and the sword is for protecting the team from external disturbances. At any point of time, role of the tools shouldn’t change - the sword is not against the team and the broom stick for external use.
A strong scrum master should still be a slave leader for scrum to be effective and the team to take ownership. If the purpose of the tools change, then its very much likely that the scrum team doesn’t realize its full potential.

Traceability and leverages

Linking needs / ideas with requirements and inturn with the various deliverables in software development process is traceability. Traceability is often the least understood and addressed aspects in software engineering and there are frequent complaints from the community that adequate time is not spent in assuring the traceability.

Leverage offered by traceability:

1. Help facilitate the product and the process quality

     - By aiding test planning and management including reporting

     - Excellent tool for retrospecting which particular aspect of team / product / process is currently flawed. Like which component(s), which developer(s), how much is the scope change / cost.

2. For better management of changes during development

     - Map Baseline requirement versus the later additions

     - Directly feed into risk planning and relevant processes like for eg how late in dev cycle could the requirements by actually freezed and what was the impact?

     - Back up your reporting with data.

3. For audit, for better visibility of product in development

4. For efficient handling of maintenance / support and enhancements later on. 

     - Aids better estimation 

     - Better release planning and integration of delivery processes

Inspite of the benefits, its often an aspect which is left much to be desired:

1. Requires a bit of investment in time and cost and many projects compromise on the priorities

2. Skill limitations and the awareness of both quality assurance and control aspects which sometimes becomes challenging. 

3. Lack of understanding of what traceability could offer. Most find it important to control smoke than the fire underneath.

4. Practical difficulties in integrating the different systems like requirements, development, delivery.

What the community could be doing to promote this aspect:

1. Dont review it rarely. Setup a process where the traceability aspect is revisited frequently and the team is directly responsible for the same. For eg:

     - include it in doneness criteria via KPIs

     - Review it along with demo in sprint review

2. Cross train the team on how to maintain traceability. Its not just testers / qa responsibility

3. Setup a culture of data based decisions and empower the teams.

4. Integrate your orgs system and tools and bring out the issues and ask for mgmnt support.

Avoidable project manager's mistakes screw up projects

Of all the reasons the projects can fail, wrong estimation would likely be the first. By nature, estimations are expected to be prone to some variations and its a project managers responsibility to make it as close to reality as possible. More importantly, a project manager has to be communicate the risks, assumptions, dependencies and any other issues with the estimations and the resulting impact on projects.

Even if it sounds so easy, i find it often that not all the risky and assumptions get communicated. Many times, there is pressure from some decision makers to make the project manager own the risks by ridiculing or by other funny tactics. Its important for a PM to be strong enough to back up his statement inspite of political pressures and highlight the issues and take corrective actions.

Some of the repetitive mistakes, project managers in different companies have been observed to make:
1. RAID matrix doesn't get published and revisited periodically.
2. Initial estimations never get challenged if required. Accept the risk if the by default strategy by some unwritten rules in most companies (honestly scrum teams score better in this aspect)
3. Weaker PMs often say it quits when faced with tricky situation. This impacts the team more than anything else. I agree that project management is more political than most other disciplines however the PM still has to be skillful enough to put his point across and get the community moving.
4. Absence of variance from original estimates is hardly backed up in most organizations.
5. If the projects are run by multiple organization entities, I find it sometimes stranger that participating PMs even end up screwing the program success parameters in their effort to keep their territory cleaner. 

Chaos a must use tool for scrum master

Chaos stands for orderliness, confusion, lack of pattern to make sense of. Scrum stands for basic minimum guidelines, a way to empower the community to create and deliver value. However, for a scrum master, these are the best friends and a must use tool to disturb the system and let it align itself for better.

Remember this, scrum is minimum process. Remember process has wastes and its costly to implement too in most of the scenarios. If we revisit the scrum basics, its about trimming the value stream for reducing wastes.

Years before, I was in a maintenance organization, the challenge it faced was that productivity wasn’t increasing even though the team was the same and the code base / the work was the same. The team had gotten used to the daily mechanics and there was no incentive to change this. The fear of politics was keeping many of the leaders from fine tuning the value chain. However, I saw something very different when we had gone for a outbound. It was for community service and the teams that were formed on the fly had to compete with each other on who does something fast. There was healthy competition, there were so much energy and the same fat ass bench warmers were at the peak of their lean journey that outing. What happened to the same group? Might be that they liked the work they did, might be they were looking for change after so much of monotonous scrum journey in office. Whatever it be but it was fluid.. very agile. Even if the requirement wasn’t clear, the team dynamics got them together, made them collaborate even if there was un-certainty and find out answers.

Now see, isn’t this the actual purpose of scrum?

We are humans, Monotonous execution bores us. Being process centric  takes away the incentive to collaborate. Time to change it and shake it up a bit. Let chaos do this nasty job.. introduce it, stop providing answers to every little crib and the team will have to constantly talk and innovate.

Continuous improvement and how to make it more effective

Lean production system is about delivering better value to customer and continuous improvement is a key pillar in lean. In simplest terms, in continuous improvement, delivery processes are constantly evaluated and improved systematically over time. However, after working with agile teams for a period of time, I have often observed that teams will be able to improve a lot of aspects apart including delivery processes as well using continuous improvements.

I am a big fan of Japanese discipline and way of life and hence my passion with kaizen, a popular flavor of continuous improvement. Following are what I consider the key aspects :

-       Small workable changes over big changes. Preferred that changes are visible in shorter term.

-       People participation and ownership is the key and ensure no one is left alone. Ideas should come from teams and feedback session is a tool to bring about this inputs. As the simplest form of evaluation, if after a period of time, if a couple of junior colleagues feel that their opinions are not taken in to consideration, that’s a symptom.

-       No quick fixes in general. Long term solution is preferred over small term quick fixes.

-       Multiple aspects -> Improvement in multiple parameters (rather than just delivery processes), improvement from multiple views etc.

How can you go about this key cycle:

-       Retrospective sessions after each and every sprint is a key tool for this. Its time reserved for team as a whole to sit together and reflect on the various aspects on the sprint and review the effectiveness of improvement points made in past cycles.

o    Each member should be given talking time and each of them should be equal for effectiveness.

o    Dig into the root cause.

-       Have feedback boxes and make them accessible to team (near scrum board) so that any one anyday can give inputs anonymously if required (however please understand the spirit of lean is openness and not anonymity. Use this if there is lack of openness and as a short term option only)

-       Feedback from multiple stakeholders in open forum – say product owners, quality managers, people managers, customer etc. Once  a month or so – so that team is aware of the perspectives of various stakeholders. Also, this will take away any resistance from team and bring accountability in making changes.

-       Share your knowledge with other teams in organization and make this culture an organizational culture.

Potential dangers in feedback meetings:

Time boxing is key aspect of this meeting and you could go crazy.

Expecting equal maturity from everyone. Their inputs and feelings are important but their maturity levels and knowledge might differ.

Lost trust in the improvement process. Participants should see results.

The sacred pond

Its important to look for messages from our history for the value of the things we have inherited and the values they signify. If you are a spiritual person, you would look forward to your religious symbols for guidance when you are looking for directions and as to how to live your life. Muslims today offer their prayers towards the Kaaba at mecca. Temple mount is the holiest place in Judaism. Mount Kailash is considered as one of the holiest places in Hindusim.

These symbols are our guidance, our beliefs and the inspiration in our lives. I have always spoken to my teams on a symbol in lean which encapsulates the philosophies and the perspective in which the symbol has to be seen. The symbol is a pond and is mentioned in books from Taichi ohno who is the founder of Toyota production system. The message that it tells you is - There will be stones in the pond and its your duty to jump into the bottom of the pond and rid it of the stone. The stones are the wastes. Train yourself to identify them – use the variations of muda, mura and muri to create healthy disturbances in the pond; every impediment that the team brings is an indication that there are more stones in the pond. Empower your team to jump into the pond and pick the stones out. Pond is a sacred symbol and jumping into it the sacred duty.

Scrum and innovation

Scrum is perceived in general as against innovation by many in community after it has been tried out over a period of time. Innovation is the heart and soul of a market leader and the success depends on how much of innovative game changing ideas come up and how successful we are in productizing and marketing the product. One aspect which is less spoken about is how involved the members are in the innovation process and this often has an impact.

Innovations could be categorized as 2 main types: incremental and disruptive. Incremental innovations are the ones where changes are made based on small incremental changes. Disruptive innovations are often the game changers and could be new products / technology etc. In general the observation & the feedback is that communities are more open to incremental innovation as compared to disruptive ones and I couldn’t stop wondering about the reasons why this could be the reality:

1.    Incremental innovation goes inline with the spirit of agile and gets addressed by the systematic and well integrated practice of kaizen / continuous improvement.

2.    The teams participation is more in incremental as they are generally the ones drive it and the ones accountable for it.

3.    The efforts / the cost is often not a constraint for most ideas coming in incremental direction and are often self governed by the teams.

4.    Psychological factors. People resent big changes and get insecure. This insecurity fuels the resentment further and its cyclical. A leader recognizes this and takes appropriate action.

However, there is a catch. Initially when the individuals have a lot of ideas, the no. of ideas coming on to bench are more. However, it eventually reaches a plateau after a few months where in the typical symptom is that not many ideas are coming though to table for a variety of reasons. This is where the leaders have to be more vigilant and have to motivate the teams to more outgoing and not contribute to situation where in the disease gets aggravated. Its pathetic sometimes that leaders eventually become the bottleneck in the innovation process as the ideas often get shotdown in not so nice ways and this impacts the team morale and their hunger for innovation. Also, the performance and reward system brings in its own bottlenecks and sometimes even end up encouraging & incentivizing the non-innovative behaviors.  One more most common reason is that most teams / leaders address the muda type of variation but not address the mura and muri and this is a crime. Give more to the teams and they will contribute more.

Now disruptive innovations. It’s a sin that its mostly considered a domain of eminent ones – visionaries, gamblers, ready to be killed maniacs etc. Retrospect further and you will see patterns – often “scrum” teams are not involved adequately in disruptive process. This is normally parent company’s initiative through tools like hackathon, 20-30% personal pet projects etc. Ask yourself is it coming into ambit of your scrum teams sufficiently? Answer will be no and you as a leader will have to take ownership for this. Second, how much leverage they have on effort and cost needed for this type of innovation? Make it easy, make it so basic a part of their success and integrate it into teams and people’ rewards and performance system without threatening them. The participation and accountability in innovation will improve. 

KPI madness and circus. Lost cause.

Why do you need KPIs? To measure & to visualize a state / performance of system, to have one source of truth between the stakeholders on certain system parameters, to link execution to strategy. Hence, its called the key performance indicator. Its an undeniable truth that good KPIs benefit an organization. Of late the question is what is a good KPI? How good it is? How well does it represent the system - how green or how red? I got this question after witnessing mad circus with KPIs.

1. Ours was a scrum team responsible for meeting the org set shipment KPIs on sprint review date. The KPI set for meeting the KPIs is 0 violations.

2. Until sprint review, all the KPIs will have serious violations. Sometimes, KPIs never got measured until last date. 

3. On the last date, the KPIs always are met and all the KPIs are green.

4. Product owners, responsible for accepting the product, often express surpises at how the KPIs have been met. However, hardly anyone questions. Behind the scene, there will be gossips that the 0 violation KPI is applicable for them too.

Whats the purpose of KPI if it doesn't serve purpose? This is widely practiced practice of KPI madness.

Manual testers are irreplaceable

One of my tester friend has built his career on manual testing and was telling to me that manual testing seems to be losing its place and is often considered as the easiest of jobs. Automation is becoming the order of the day.

How often one find these comments - Lets cut down on manual testers cost by hiring less qualified person. Not longer can one afford to be manual tester only and you need to have coding skills too. The focus is on delivering high quality product first time. Quality should be built in and not checked in.

I pity the situation of manual testers who should find it insecure and often feel that they have made a wrong decision by choosing the profession.

There are obvious truths in the changing trend in industry and the need to be cross functional. I beg to differ in the aspect that manual testers are becoming less relevant.

1. 80% of defects in organization have been reported by manual testing.

2. There is truth in automating high ROI scenarios / use cases and in perspective of regressions. However, the reality is not just about ROI scenarios if the risks around scope, time and costs are not addressed appropiately and unfiromly across the organizations. Mistakes will be made during the process of so called quality code and they will only go undetected by performing organization. 

3. How robust is your automation coverage? How are you ensuring coverage of not just statements but also all conditions and branches along with so many permutations and combinations which often need to be validated? How about platforms and combinations and risk of dependency on simulators during automation?

4. In most of the development projects, there is not adequate development effort to spend on automation while developing. Also the truth is that when the code base is continually changing there is no point in automation from end user perspective. You could try TDD and pair programming but dont forget the fact that its not fool proof. Infact its often less then effective without adequate development team participation.

Having too less of manual testing effort and over reliance on automation is a sure shot way for poor quality.

Scrum master, the limitations and the favourite boxing sack

Scrum master is the most funniest of roles you could encounter but its also the most responsible.

You are paid to be scrum master and get beaten for being one :):

1. You are not the leader buddy :Scrum master is not the leader of the team. However, he / she is accountable for the delivery of the team.

2. Different hats at different time : People say scrum master should be emotionally intelligent and should have soft skills to handle the say to day issues that the team faces. Moreover, scrum master is a slave leader (thats when the role is most effective) who will help remove the impediments that the team faces. However, people hardly understand that team's efficiency improves with time and the scrum master's role (inspite of definitions) will practically vary from time to time.

3. Lead by example : Its obviously enough from role's perspective for scrum master to do scrum master responsibilities. Obviously being a slave leader takes away a bit of your flair (if your natural energy flows differently). The motivation in lean is to dirty your hands to understand the team better. The expectation from team will be that scrum master pulls up some tasks and delivers them too instead of just asking questions :) and this will be coming out in retrospective.

4. Pull vs pull : Most serious of topics in my perspective. Ahem.... you are supposed to be a slave leader and if you start pushing tasks, you will be not be perceived as one. The question before you is : Do you wanna allow your team to take the intiative / do you wanna show you do?

5. Silence as technique : Be ready to be silent, be ready to pretend you dont know the answer. Let the team discuss and find out the answer. Let them make mistakes and be ready to learn from it. However, in that case, keep a watchful eye on other opportunistic people / your higher ups who could kick your balls.

When agile becomes fragile - part 2

This is in continuation of my previous blog titled "when agile becomes fragile - part 1".

My friend,  my fellow PM invited me with sarcastic "we are fragile experts". That was scary for me as I had expected things to be far better in terms of maturity in lean,  employee satisfaction,  other critical value creation steps in development cycle. So I started to pay close attention to how healthy the system felt by listening to its heartbeats more.

1. When the life is precarious for an employee, the area to look for is attrition.  How many are leaving the organization? The same friend came to my rescue again.  "The people are ready to give the papers straight to my hands when I ask for status of work". The cat is out of bag.  It became claret to me that almost everyone is looking to jump out of given an opportunity.

2. How is am employee feeling about it?  What's his view of things?  In discussion it became apparent that weekend work was norm.  If a person didn't turn up on weekend,  it resulted in immediate escalation.  Why would a person, who had made up his mind to quit,  care to turn up and care to bother about escalation?

3. If a team says no to requested story,  it was crime. There were mindless threats from management! Where is the empowerment?

4. The agile formalities happened just for the heck of it.  Any seriously motivated team wouldn't be struck with kids syndrome.

5. How was the team work?  Pathetic.  Pressure cooker.  To many cooks.  These are some of the terms that people used. People were ready to back stab each other for their success.  Some teams felt they haven't received recognition for long time in spite of surviving in this environment for long time. There was no fun,  no cohesion and no feeling of unity.

6. How was continuous improvement?  There was none.  There were no retrospectives and how wok there be learnings?

I set about the task of string up things in order then which I will summarise in the days ahead.

It's a misconception that scrum is against documentation

Is funny to hear people feeling that documentation is not required as per scrum.  How often have I heard this thing?  I was once involved with tool development for sun microsystems.  The scrum master and product owners then choose not to create stories with this comment.  I could quote one more instance where in an mm it was a question in scrum master all hands that teams spend a lot of time in writing documentations like high level design,  low level design,  customs documentation etc and this is against lean principles.

Hey guys hold on!  Can you spot which mean principle tells you that lean is against documentation?  Lean is about delivering value. Systematically identify activities which don't add value and eliminate them to enhance profitability in long term.

Ask yourself if a particular piece of documentation ads value?  If yes,  lean is never against it.

Test driven testing, KPI syndrome and other challenges.

What do you do when you have less than too little testing effort for a huge agile developmentteam? Can you turn out high quality product with so limited testing efforts?

Part of the answer lies in using your team's strengths to your advantage and use the dev skills to do testing. What if you could do it without boring the developers to do "much of" manual testing but could set the expectations clearer that they are accountable for the quality? Test driven development is the key in such cases.

Here:

1. Test cases are written before the code is written

2. Simultaneous regression test suite is getting developed as you write the code and this will bring down the cost of quality.

3. Integration with continuous integration system will ensure that regression suite is being run as frequently as possible to bring out regressions in related areas.

How you could approach this:

1. Select a unit test tool which goes well with your programming environment.

2. Complete the required setups to properly integrate it with your dev and build environment.

3. Start developing the intended program features by:

     - First write a unit test for the feature to be developed. Run and verify the suite for failed TCs and this unit test will fail.

     - Develop the feature inline with the assumptions made in test case. Run and verify the suite to see if the test case passes.

     - Repeat the iterations as you fine tune the code and develop new modules.

In its simplicity, this is what the process is all about. However, there are dangers too: Unit test suite remain as one of the least reviewed dev artifact till date. The quality of the unit test suite often goes under monitored for the simple reason that quality manager, accountable for  quality, often is not accountable for the exhaustiveness of unit test cases. Example of what this could lead into is that :

     - many of regression scenarios become irrelevant over a period of time. Eg: instead of consuming real time data, the unit tests do have hardcoded data (this is criminal violation of quality principles in most cases). This will return false positives and will not bring out the regressions.

     - Unit tests might not be exhaustive. Al branches or all decisions / loops couldn't have been covered. Many integration dependencies might not be covered.

As an end result it happens that unit tests are run just for the sake for meeting KPIs and lose actual purpose. When things are done for the heck for meeting KPIs, i call it the KPI syndrome and is the most dangerous risk to the quality and to the continuous improvement pillars of lean.

Collaborators and distractors

I have to quote this tweet from Jeff Sutherland on March 13 :

Learning to negotiate was a vast improvement over war. #Collaboration is a vast improvement over negotiation.

These are such golden words from the expert. If learning to collaborate is a challenge, its even more challenging to trust the people who collaborate and to invest in a system which rewards the collaborators.

Its people who make the scrum work and scrum is about empowering them systematically and allow them to progressively own accountability for their actions and for the value created.

It’s a open challenge to every one – for the team, to collaborate more and become more accountable for each other and for value. For the scrum master, to remove impediments from the system which prevent them to collaborate more. For the management to identify collaborators / team value adders over selfish individuals and reward their behavior. For the management to identify and empower the people who are most likely to be gatekeepers and angels for maintaining such a system.

As system, system, system is what its all about and there is no word else to describe it. It’s a paradox that many times the people who are the angels for encouraging such a system are the ones who end up doing damage unconsciously.

Bad apples and the people manager

Bad apples are the difficult employees. Bad apples bring down a team, negatively ‘inspire’ other team members, are a liability in a scrum team, bring down the productivity of the team. All of us would have worked with bad apples and there is adequate literature available on handling difficult personalities.

It’s a very common lean setup to have product, people and project responsibilities split up and this would mean there is a people manager whose sole responsibility is to handle the people topics like career, performance, hikes and most importantly handle the delicate people issues. I have had the honour of working with several people managers and a couple of them the best.

The people management vs the bad apples is normally a closely monitored topic in any team and often carries a emotional baggage with it. Somehow bad apples have the tendency to appeal to people more who look up to them more often than not as the brave rebel why couldn’t afford to be. It doesn’t take long to identify a bad apple but often difficult to treat them as how our body is unable to cure a cancer for the simple reason that they are caused by most insulted member and isn’t alien to body so as to be detected by immune system.

Often times, its inefficient strategy not to handle the bad apples. Though it’s the easiest option to reject those negative people, it should be the last option for people managers. The solution is to turn to bring about a positive turnaround in the behavior by having open talks, highlighting ideal people and rewarding them, understanding the root cause of this bad apple and offering the right rehabilitation path. I understand that this takes time and offers its own risks. However, the purpose of agile is long term benefits over short term benefits and that’s the leadership people managers can show.

Scrum masters will have to intelligently involve people managers at the right time without breaking the bridges that the team members have built with in the team.

Inconvinient truth.. Scrum is not for fixed price contracts

Like many of you, I have always believed that scrum works fine anywhere. I had this project of mine where in the contract was fixed price and was aggressively bid too. This meant that there is a wafer thin profitability and not much chances to experiment and allow the team to take control. Scrum is effective framework for product development and for T&M contracts. Unfortunately it also brings to table certain challenges like little bit further rampup time, employee first approach, time where nothing should be planned for including the planning and retrospective timeslots. It required time for team to self organize and fixed price projects are almost always constrainted in time too. When it comes to profitability vs anything else, scrum loses out in fixed price projects.

Cross functionality is not a natural skillset for scrum teams and lets accept it

Its in scrum basics that scrum teams are cross functional. However, its not that as soon as scrum teams are formed the team members lose their identities of core competencies and take the badge of scrum team member.

Its one of the pep talks which any scrum master gives to the scrum team and its that scrum team is cross functional. However, ever wondered why would a .net developer be ready to start doing testing? Why would an ABAP developer start learning CQ? Why would a documentation expert share his / her bread and butter skill with someone else?

Even to start with scrum isn’t a cake walk and you should be more than willing to open a can of worms and clean it up. To properly make a scrum team cross functional and empower them too in this process, it requires a kind of patience for the ‘slave leader scrum master’.

Reality 1 : You will face resistance from team to become cross functional and actually start delivering. A supportive organization culture and grooming period to learn and to make mistakes is a pre-requisite.

Reality 2 : Not every one is going to be onboarded on day 1 and some might never be onboarded. You will have to actually make them win to get their commitment on cross functional tasks.

Reality 3 : Plan for smaller battles. For eg : you might not be able to make a dot net developer start writing code in java. However, they could start writing documentations. Similarly, giving opportunity for doc expert to share his knowledge with team is going to get you better support than to share tasks.

Reality 4 : Reward the cross functional team members rather than punish the ones not ready for the same as it might scare them away.

Indians sacrifice sometimes gets taken for granted

Historically India has been preferred destination because of the low cost that it offers.  The cost advantage is often so much that in India it takes only a part of the cost it takes onshore to deliver the same.  The trace of though is made at several levels.  Ever heard of a 8 million dollar project getting done at 4.5 million bucks?  In our efforts to stay competitive and ensure that business opportunities improve,  we have shown the tendency to negotiate beyond profitability sometimes and ensure that project comes here.  However,  the matter also to be considered is that the salaries have increased in India and it sometimes becomes not very profitable from organizational perspective to take up a project (though often it gets picked to make better utilization of bench resources.

See,  life in India is not always fair for a vast majority.  There is competition for any thing and everything here from toilets to schools to job. A vast majority of our population still lives in slums and do struggle for daily bread and butter. Its kind of normal for us to work like hell and do something for money which others can just dream about.  Am not here to tell that those lives quality shouldn't be improved.  However in the name of cheap labour if we don't get the fruits of hard work and lack the backbone to project why it is really a difficult job well done,  then we won't be respected for the right reasons too. 

Let's get over this attitude of donkey job and enter creative domains more.  We have to find solutions for our problem and losing one eye for an other is not the solution.

Art of crafting the scrum boards!! Can you make scrum more interesting?

I came across this practice of crafting the scrum boards and the challenge was up to all the scrum masters and we got loads of interesting ideas. Obviously at an org scale, not all teams are at the same pace and the agile implementation could by itself be at different levels contributing to the varied result. However, that’s the beauty of the setup and some of the teams did manage to pull up their socks and discover new ways of representing their progress and achievements and make scrum more interesting.

One of them came up with this beautiful little idea of representing the scrum like a race track of F1 and the other came up with how during his visit a traffic light like representation was setup in Toyota factory.

A few new cooks did come up with a restaurant like menu card and order status. There were even more crazier ideas and which could  border on the creative insanity J.

Moreover it did break the ice between them on how they run their daily business and raised their awareness of the topics where could work with the other teams.

Have some interesting looking scrum boards? Do share it here.