Should I start thinking about switching from Scrum to Kanban?
 

I want to release anytime, I don’t want iterations, I want to skip estimation, I have challenges with self-organizing teams, I want to change my priorities,

I need better visualization, I want to process that is more adaptable, Scope creep is my major concern, I am want to handle support tickets,  I am afraid of sprint failure and end of picking less work, I can’t break down stories enough to complete within the sprint.

Before I get into details, review below carefully, this would suffice the need for moving to Kanban over Scrum or XP.

  1. There are teams that have a more responsive nature of work like maintenance, fixing customer bugs, run time day to day requests, etc.
  2. It may not be a good idea for these teams to plan the sprint or iteration since a lot of activities will become overhead. In addition to that, we need to break the Agile principles for instance constantly adding items to sprint during execution, not doing refinement in advance, accepting back-to-back sprint failure, and more.
  3. Not doing Scrum does not mean they would not publish the work. They are still expected to commit approx work (Preferably in terms of story points) in a given time period.
  4. They commit to goals and SLA based on the past data

Scrum is great while the world is not a perfect place. You can always overcome challenges associated with it but if you have another Agile method is even more flexible there is no harm in leveraging that. I see many organizations are switching to Kanban and getting wonderful results. I don’t have the intention to move you from what you have been doing while I am just trying to initiate a thought process and philosophy around Kanban.

Let’s understand the above in more detail with real-time scenarios. A group of project managers gathered to discuss the challenges they have with the existing process with senior management.  Let’s look at some of the interesting areas what they have put forward on the table (I am sure you can relate one or more areas if you have managed agile teams)

 

Project Manager 1: (Team is afraid of Sprint failure) My team has very fewer items in sprint compare to what they can accomplish as they are scared of sprint failure.  Despite that, I don’t have successful sprints as one or items roll most times as we get blocked. I can’t allow my team to pick more middle of a sprint

Project Manager 2: (Prod issues; Lot of support to other teams) My team builds new features while I am expected to support some of the other teams for whom we provide back-end services. The requests coming from them is our top priority whenever it’s related to prod for them.  The amount of work that comes from different teams vary and we cannot assign fixed bandwidth to deal with those issues. Most of our Sprint we have one of these two situations

  • The sprint fails because we need to focus on supporting other teams.
  • We are done much before the sprint ends.  Pulling new work is not allowed mid-sprint hence we use that time for learning while this is not a great idea all the time.

Project Manager 3: (Support work; Tickets) I have all the support work. The estimation has been a challenge most times. A bug takes a day or a week, it all depends on the product I work for is huge and we have most of the newer members.  How can I make sure my sprints are successful and at the same time, we as a team don’t under commit?

Project Manager 4:  (Adaptive to more adaptive) My team hates too many ceremonies and processes. They think of having a lightweight process which is more adaptive over-prescriptive,  is much better. All of them are experienced/committed and understand their roles and responsibilities.

Project Manager 5: (Time and material; Longer stories; Unpredictable work) We built adapters and I don’t see the benefit of breaking down and doing that in parts. We have a deadline for every adapter and we kept getting blocked. We are fine to wait as we are on the “time and material” contract. Getting blocked from the customer end doesn’t harm as billing doesn’t stop.  How do I fit in a work which takes a few weeks to a couple of months?

Project Manager 6: (Frequent priority shiftOur priorities changes very frequently.  Many times we literally have to stop what we are working on and start something else. Getting new work done in the next sprint doesn’t help as the work we are doing becomes useless even if that’s completed due to change in priority.

Project Manager 7:  (Customer or Sprint successOur company’s top priority is to manage customers and their expectations while we always focus on velocity and sprint success. This becomes challenging as in order to manage customer priorities, we compromise Scrum priorities or vice versa. Both are not good ideas. In the first option, you are disregarding a process resulting in low team morale and an unpredictable outcome.  The later is not acceptable anyway 🙂

Project Manager 8: (The product owner struggles) The PO struggles to lock down the requirements for a week. He keeps adding work to sprint throughout the week, changing existing requirements, and even providing/updating acceptance criteria during the sprint.

Projects Manager 9: (Team experience or complex work) My team has challenges with breaking the requirements or estimating the work.  The sprint success matters most to me (Why-Sprint-Success-is-Important). I end up being unhappy most times.

Kanban could be one of the solutions for most of the problems listed above. The comparison of Kanban with Scrum/XP and some of the core frameworks is available here

Sprint success is really important when you talk about Scrum. The Sprint fails due to a variety of reasons like team experience, The challenges with breaking down stories, unpredictable work, Customer focus precedes team priorities, support work, and many other challenges as listed above. Many times either we run too much to having a successful sprint (By means of slogging or patch up work) or do not think of a successful sprint at all. Both are not good options.

In my upcoming blogs, I would be talking in detail about how to use Kanban, best practices, myths, and an easy shift from the existing process to Kanban. Please provide your comments below. This would help me to cover all aspects of my next set of blogs on Kanban.

 

 

 

Why do people say SAFe is a top-down command and control approach
 

 

SAFe Agile is extremely prescriptive, works only with command and control from the top management – Is this a Myth?  – Let’s explore to know the answer

is SAfe safe

Before I share my thoughts, let me add a disclaimer

  • I have a strong faith in SAFe
  • I am very much inclined to SAFe values, principles, and practices

“If you are on agile, scaling agile becomes relatively easy”

Let’s say your company is running on broken agile processes or is on a waterfall methodology, you can still be successful with SAFe but the chances are reduced significantly.   The SAFe suggests significant benefits in 3-5 years while you will hear from people that the magical outcome in productivity, quality, employee morale, etc would come in 3-6 months.  Let’s explore slightly deeper:-

I think you would agree that most of the transformations begin with top-down command and control for the simple reason that change is not easy and it needs a real push if it’s not small.  This would shift unorganized functions to be more organized, pushes people hard for delivery, teams start running on cadence and synchronization if it’s SAFe resulting in higher productivity, quality and so is the outcome.  The KPIs, Metrics, and rigid processes make people do more. There is a forced innovation in the beginning as well. But remember that this would not go long run. The management started believing that we have showcased better outcomes hence let’s not stop. They go with 100 percent utilization which is a disaster (SAFe says so, and I completely agree).  The fall begins within 1 or 2 years and it becomes very tough to manage it.  The command and control is fine at the start but it should be strictly looked into in six months to a year. The management needs to focus on generative culture, autonomy, and decentralized decision making.

We need to have a relentless improvement in not just the outcome but employee well-being, morale, and learning. We should ensure that we stick to SAFe values and principles.  One of the main reasons I have seen for SAFe failure is organizations do not invest much after little success or Org is not ready to move to SAFe but they want to be part of the rat race.

People talk about only success stories while there is a good number of failure stories as well which probably is not taught anywhere. I met many people who ask the interviewer whether the company they are giving an interview is on SAFe or planning to adopt in near future. If the answer is yes to any of these two questions, they don’t want to join the company. There is a myth and perception created while that doesn’t seem to be true. The management truly has to involved at ground level in order to break the myth and move their towards the real benefits of SAFe.

We should all remember that identification of value streams and ARTs, Identification of EPICs are core challenges while implementing SAFe while organization alignment still remains the priority.

Scrum vs Extreme Programming (XP)
 

Scrum vs XP

Both are very similar that are aligned with each other and complement each other.  If you walked to a team then it very is very hard to recognize which practice team is using if they are using one of the above practices.  XP is Scrum with technical practices. It’s mindset/behavior and a more prescriptive approach with a strong feedback loop.

Scrum
XP
The iteration is between 2 to 4 weeks. The iterations are 1-2 weeks or less. For very aggressive teams, it can go up to a day.
In Scrum product owner prioritizes the product backlog but the Scrum team has a privilege to chose a lower priority item in a sprint to work on before the high priority XP teams must always work in priority order as features to be developed are prioritized by the customer.
Changes in the sprint are not allowed XP Teams are much more amenable to change within their iterations, but change can only be made if the team hasn’t started working on a feature and at the same time the change is of the equivalent of the swapped item.
The validation of the software is completed almost at the end of each sprint, (i.e. Sprint Review) The software needs to be validated at all times, to the extent that the tests are written prior to the actual software.
Scrum doesn’t prescribe any engineering practices The XP does.
The Scrum Master is responsible for what is done in the Sprint, including the code that is written A developer can modify or refactor the parts of the code as and when the need arises.

 

The teams start with Scrum and move towards XP. There is lots of focus on Self Organizing teams and XP encourages that to a great extent. The Maturity model that we have prepared for CDK has more focus on Scrum up to level 3 and further, the direction is to adopt XP in order to get on to level 4 and 5.

The original XP is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices as listed below

The Planning Process

The desired features of the software, which are communicated by the customer, are combined with cost estimates provided by the programmers to determine what the most important factors of the software are. This stage is sometimes called the Planning Game.

Small Releases

The software is developed in small stages that are updated frequently, typically every two weeks.

Metaphor

All members on an XP team use common names and descriptions to guide development and communicate on common terms.

Simple Design

The software should include only the code that is necessary to achieve the desired results communicated by the customer at each stage in the process. The emphasis is not on building for future versions of the product.

Test-Driven Development

Testing is done consistently throughout the process. Programmers design the tests first and then write the software to fulfill the requirements of the test. The customer also provides acceptance tests at each stage to ensure the desired results are achieved.

Refactoring

XP programmers improve the design of the software through every stage of development instead of waiting until the end of the development and going back to correct flaws.

Pair Programming

All code is written by a pair of programmers working at the same machine.

Collective Ownership

Every line of code belongs to every programmer working on the project, so there are no issues of proprietary authorship to slow the project down. The code is changed when it needs to be changed without delay.

Continuous Integration

The XP team integrates and builds the software system multiple times per day to keep all the programmers at the same stage of the development process at once.

40-Hour Week

The XP team does not work excessive overtime to ensure that the team remains well-rested, alert, and effective.

On-Site Customer

The XP project is directed by the customer who is available all the time to answer questions, set priorities, and determine the requirements of the project.

Coding Standard

The programmers all write code in the same way. This allows them to work in pairs and to share ownership of the code.

How do you pass SAFe SPC Certification with high score (Implementing SAFE) – Download questions for free
 
SPC 5.0

SPC 5.0

The SPC is a SAFe program consultant (Also called as Implementing SAFe). This is probably the highest level of certification SAFe has and undoubtedly highly valued in the software industry.  I am fortunate to have it cracked within 3 days of effort plus 4 days of a class. I definitely would like to write this down so that it would become easy and you don’t need to wonder how would I go about not just passing but scoring high marks.

I feel you should first decide whether you truly want to do it. If you just want to add another certification to your profile, probably I would say you don’t need to go for it.  If you aspire to be an Agile coach and/or know that you would be implementing/supporting SAFe then it’s the perfect thing to go for.

I have cleared a SAFe Program Consultant a couple of weeks ago.  I am going to share tips that would focus more on learning but at the same time, you will clear the exam with an excellent score.

  1. Read the material given by SAFe at least two times. If any concept is not clear then refer to scaleagileframework.com. The explanation there is far better than any other place.
  2. Click on the big picture and understand every item. The better way to do is to click on the item and read about it.
  3. The specific links are given in exam preparation material, read them all at least twice. Create notes only for high-level titles that would help you to connect with questions.
  4. The practice test must be done and if you score less than 80% then you need more preparation.
  5. The exam guide clearly states the most important chapters. The way you determine is based on the number of questions that appear from the respective chapter. Anything above 10% is very imp and every concept should be understood well.
  6. I got some good material that would almost be guaranteed that you would clear the exam if done properly. If you really need that you can send an email to me at srsagilechamps@gmail.com with your phone number. I will provide you the details.
  7. Avoid searching answers for questions on the internet during the exam.  You may find the question while the answer available on the internet may be wrong.  Study well and go by what you think is right. The questions are prepared with very well thought processes and I am sure you should be able to answer. If you want to score try trust your judgment. Remember certification doesn’t have lots of value while knowledge does. 
  8. The questions what I found on the internet are

9. I would recommend reading Get SAFe Now book before even you go for training or start reading materials from SAFe.   The book is for beginners and explains the concepts in layman language. The questions after every topic make you think a little deeper.  It helped me a lot to hit high scores in a bunch of certifications I did.

The above is just for basics while if you want to be really confident then I would recommend reading the below book (SAFe distilled 5.0) instead of going through the website and reading random links. This book is organized so well that everything seems to be a story.

I will be adding more blogs with cheat sheets and more informative ideas and content soon

The sample questions available on the internet may help you to prepare further

 

 

Agile Myths
 

Myth 1. Stand-up is a status meeting
Reality – The Daily standup is a Planning Meeting. It promotes Collaboration, Self-Organization, Enables inspection and Adaptation, Focus on achieving the outcome.

Myth 2. Pair programming decreases the productivity
Reality – The pair programming increases the productivity in majority of the cases if done in right way.

Myth 3. Agile doesn’t need project manager
Reality – The Scrum Master plays a role of a project manager.

Myth 4. Agile is another word for Scrum.
Reality – The Scrum is one of the Agile framework. There are many more like Kanban, XP, FDD etc.

Myth 5. Agile is faster than Waterfall
Agile is less about delivering software faster, and more about delivering value faster.

Myth 6. Agile means no documentation
Agile doesn’t do documentation for documentation’s sake. Documentation is like any other deliverable on an Agile project. It gets estimated, and prioritized like any other user story.

Myth 7. We’re a self-organizing Agile team, so we can do anything we want
Reality – The core principles are not allowed to be tailored. It is a lightweight process while the core practices are expected to be followed.

Myth 8. Agile is a silver bullet
Reality – The projects done in Agile do fail. It cannot be an excuse to stop thinking. Agile promotes fail faster philosophy so that one can learn from it.

Myth 9. The story points can be exactly translated to hours.
Reality – When the team gets mature, you can translate it to approx but not exact hours.

Myth 10. The product owners, developers and scrum masters get to do what they like.
Reality – The Agile is very disciplined framework. Every role has set of responsibilities. The core responsibilities should not be switched.

Myth 11. There is always a right size for a user story.
Reality – Every team is different hence there is no right size of the user story. The team producing 30 story points can be more productive than the team doing 45 story points.

Myth 12. Agile means no planning, no design
Reality – Agile typically needs more planning and design than waterfall. Both of these activities happen throughout the development.

Social Experiment : Do we need a Scrum Master in a self organising team?
 

In a typical agile team, the scrum master is the coordinator/facilitator who makes everything going in the team properly. However, when the team is highly self-organising, do we even need a facilitator? We have a detailed post on the role of a scrum master here.

We have asked this question to a group of experts in different social forums and we have received around 1200+ responses. Here is a quick stats around the same.

  • 9% feels we don’t need scrum master at all.
  • 14% believes that the SM is a full-time role.
  • Rest 77% strongly believes that full-time SM is effective in the start, or in an immature team.

This survey reflects what we have observed in our agile projects.

When we are building a team or team is immature(staffing changes etc), we need SM to help and coach the team by asking right questions.  As the team grows up in maturity, the individual team members know how to organize themselves and hold each other accountable. This is one of the important reason why SM role becomes redundant after some time. And this is also the reason why organizations prefer to hire technical people who can play scrum master role. But in order to attain this maturity, the team members will have to be open for new learnings and continually improve.

Here we have picked some (not limited to) of the comments from the experts we did experiment with. The question being asked was

Do we really need a scrum master in Scrum project? If so, does it have to be full time? Isn’t self-organizing team killing the concept of SM? 

Comments from experts

1. Yes….as much it seems like an oxymoron to have both concepts in concert with each other, you need to have the “check and balance system” embodied by having a separate SM from the team. The team is made up of humans, who are fallible and will attempt to take shortcuts over time. The SM is a check against the scrum team’s desire to “get things done” and circumvent the scrum process.

2. Ideally any team member can be called as a Scrummaster. I can only call the SM designated as a process expert contributor.
The key responsibilities certainly needs a defined role to drive it so it reduces the burden on either the Manger or team.

Also , with value and business ask in mind its challenging for the Manager to inspire, create value, and follow the princple 5 ” build projects across motivated indivduals and trust them that the job can be done” whilst if it can be done, it can be tried out.

3. Scrum is a smallish change to jow people work. 5 hours a week. That said…if you’re running scrum in a not friendly to agile work environment….scrum is essential. However, if you’ve got a long term agile team, whose environment lets them work, the role is less necessary.

Really…the scrum master role as practiced is NOT about scrum, but rather about making the team work effectively together. Once that’s good…?

The XP model creates agile team functionality differently, by shifting work patterns for 35 hours a week, rather than scrums 5 hour change. Honestly, that changes team culture far faster than scrum, and the tech practices shops dont find the role necessary.

Without a deep established culture or hardcore paired-tdd-ci practices, you want a scrum master.

4. Real professionals don’t need a SM. It will save them time.

5.  Once the team is self reliant, scrum masters role becomes redundant.. Either scrum master has to be one of the tech leads or a contractual role to train the teams.

6. Looking at this link, we need SM to fix these scenarios.

7. That depends on the nature of the project. If it is a fairly large sized project with multiple dependent upstream and downstream systems, there would be a fair amount of communication and coordination required. This should happen before, during and after sprint planning. Team members do not need to worry about all these administrative work. They can concentrate on actual tasks. Also, in my personal experience, however well planned you are, things do not go smooth as planned. In that case, there is a need to capture details around any delays by our own team or any other dependent systems and review and revise the integration tests, release plans, deploys to higher environments and finally present the cost of delay and value being delivered to business. This is all just a few tasks for an SM when the project is fairly large sized with up/downstream dependencies. Other typical tasks include, communications with end users whenever required, challenging and motivating teams, conducting team building activities which helps team not only build relationships but provides some relief from day to day and hour to hour work.

8. However mature teams are, if a candid discussion happens during grooming, planning team members need someone else to facilitate their conversations, disagreements and help them come to an agreement. SM can apply various techniques in these situations and it would be totally unreasonable to expect a participant team member to play that facilitator role and be neutral (just not practical)

9. I’ve had the great pleasure to work with many different teams across many organization types, development processes, and industries. Whenever a team loved Scrum Masters, it was because the Scrum Masters were properly performing their role and getting things done, removing road blocks for the team, facilitating effective meetings and conversations, and so much more.

All of the projects I’ve been on where there was no formal Scrum Master role were teams that had one at one point, but dropped them because they were not effective. They blamed the role instead of the individual.

Find effective Scrum Masters and hold them accountable just as you would any other team member. If they aren’t getting the job done for you, find one that will!

10. When a team is mature enough, this is true that need for a Scrum Master is over.
If the team is self-organizing, cross-functional and respects naturally Scrum ceremonies ; if communication with the PO is smooth, there is no misunderstandings, it means that a Scrum Master would be superfluous.
On top of that, the role of Scrum Master still exists: the difference is that it is endorsed by team members, with no prior assignation, but spontaneously, depending on the context.

11. The need of a SM depends on the tasks that he performs. So whether a SM will be required or not will be determined by the availability of resource to perform that role. So if there are skilled resources who is available to perform those tasks then I think the need for SM is already fulfilled.

12. Although SM role is critical but if thats the case all the times it means your team in not improving. If the team is improving, you need to assign other work to SM (Assign other projects, ask to contribute on technology, design etc). If that is not happening, you should plan to bring new SM.

13. Scrum master is ‘Servant Leader’ in practice. Which means he/she has to adapt to leadership style based on ‘Team’ is at what stage. Whether ‘Forming’, ‘Storming, ‘ Norming’ or ‘Performing’. Once the team reaches ‘Performing’, SM job becomes redundant. And at ‘Adjourning’ the last stage SM is no more needed team to do its function effectively, independent and consistent performance. At this SM would also reach its peak of leadership ‘Pinnacle’.

14. A team can gel despite all kinds of organizational impediments to agility. The SM is not obsolete until those impediments are identified and addressed effectively.

15. For a program with multiple streams and releases, a dedicated SM is more or less a necessity. With obvious(more) focus during the initial stages, the SM involvement can reduce as the team imbibes the mindset that is expected of a proper self organised team. He or she will ideally bring in the culture that sets the team on the progressive path

16.  A dedicated Scrum Master is not needed in a Performing team. However, it is frequently the case that a team degrades over time after the Scrum Master leaves – so unless the team is able continuously keep focus on improving they might at least need regular check-ins from an agile coach (could be an actual agile coach or a leader in the organization or a Scrum Master from another team).

17. I don’t think need of SM can be completely eliminated, whether it is performing team or not as there are lot of things SM take care of such as improvement in processes, removing impediments, taking care of backlog, running sprint etc.

Someone from team should not be SM as this is independent role and it has to be a specialist for the job.

18. A team does not mature takes the time to mature. In a mature team, Scrum Master may not require, so a lot of other things e.g. sprint planning and refinement sessions merging, On demand retro instead of one retro per sprint, time boxing of sprint ( may be kanban), etc.

19. I don’t think the role of SM can be completely eliminated and not at least until the team is mature enough to identify impediments and able take actions to remove them or retrospect themselves. Yes, it would be a good idea to have a team member with willing to serve as SM as well, but that should happen at a later stage only as in SCRUM SM is a separate entity and can be supposed to serve multiple teams at the same time.

20. I think a SM is need at the start of the POD, but as stated above once the team starts moving and has proved they can produce and become self serving then the SM has be become obsolete. Now this can only happen if your product owner and B.A. are in tuned with the POD.

21. Instead of picking SM from outside, you can identify a good fit for this role within team and keep rotating. This would certainly increase your chances of getting better results and at the same time you are helping you team member to play interesting role who aspire to get into management.

DAR – How to find a better option when you have multiple solution for a given problem?
 

“You must choose … but choose wisely”   Your decisions play a critical to make or break your future. The company you choose, the girl or guy you marry, the house you buy, the career option you choose. Isn’t it a great idea to have a tool or intelligent mechanism to make the life easy which would help you to choose the best possible decision based on some real facts rather than some random decision?

DAR

DAR is a process to make key decisions in your organization and even in personal life more objectively and wisely. Just to add more clarity, what do you do when you have multiple solutions for a given problem? How do you decide to pick one that most suited and obviously wise?

Human psychology plays an important role while using this technique. We have a lot of information which we don’t really process rather we just go by Halo effect which is nothing but taking a decision based on what you have in your mind at that moment instead of considering all the inputs

Let’s take some examples

Business Decisions

Should I outsource or not.

Is it a good idea to start an XYZ office in Pune or Mumbai?

Technical Decision – Which technology to choose – C++, Java or .NET

Which technology to choose – C++, Java or .NET

Architecture decisions.

Alright, seems boring. Let me get on to more personal stuff.

Which car do you want to buy?

The DAR – Decision analysis and resolution is an answer for above situations. It is one of the process area defined by CMMI but practically used everywhere. The reason DAR works most times

  • You think about every possible solution and list them out. Hence you consider everything before taking a decision over just thinking about limited core items.
  • You rank individual items based on comparison hence you have more clarity.
  • The template would give you amazing results.
  • You do consider Risk and constraints.

Essentially writing down everything and coming to conclusion. There is no guarantee that your solution would be perfect while you are increasing the chances of getting it right significantly.  It takes almost no time to use this process once you acquainted with it.

Please leverage attached DAR template. I have created it to have the better clarity.

Dar Template

Try few times and trust me you would fall in love with it.

Stand up: Why you should talk about your next actionable?
 

Lots of teams that I work with generally follow the best practices of a Scrum stand up meeting. However, as time goes by team tend to fall into the slippery slope of just reporting what they have accomplished the previous or the current day and completely ignore the next actionable & impediments. This happens more when the team/scrum master is not very strict about the process. In this article, we will see the reasons why this is important and the benefits of the same.

Life without goals

Before we delve deep into practices of Scrum method, we will talk about few general principles how our subconscious works. As per the basic behavioral psychology, there are three parts of the self-concept.

a) Self-Ideal – Goals, aspirations, dreams etc.

b) Self Image – impression about self-based on previous experiences.

c) Self Esteem – Emotional component of how much we like ourselves.

When someone sets goals and achieves them, the self-image corrects and the self-esteem improves. And they start setting bigger goals and continues to go on an upward spiral.

How Psychology relates to Scrum

Whenever a team member talks about “What they will do ” before the next meeting, they are indirectly setting a time-bound goal for themselves. When they come and report the achievement of the same the next day, the self-image and the self-esteem goes up. This will bring more success as the time goes by.

The Sprint is systematically designed methodology using the basic psychology of commit and achieve cycle.

Let’s do an experiment. If you are part of an Agile team, state your goal for the day loudly to your team during the stand-up meeting. You would have that in your back of your mind entire day. At the end the of day, if you accomplish what you stated, you will have an amazing sense of accomplishment.  Otherwise, you feel that you have not done enough. This comes to most members as long as they care about the company and their career. All you have to do is take that seriously and you would find yourself growing much faster than your peers.

I have personally asked this to many people and every time I had the same result. Isn’t it amazing? How simple it is to grow in an Agile team. Isn’t it?

So Next time you are in a stand-up meeting, would you talk about “what you are going to do “?

 

If you like this article, please share and provide comments.