TDD (Test Driven development)
 

There are lots of practices that need to be followed while doing XP as an agile methodology. And one of them is automated testing. However, there is lots of confusion in the tech industry if you want to test the behavior of the system or the subunits/parts of the system. First, lets us understand these terminologies. In this post, we will talk about Test driven development.

TDD (Test Driven development)

TDD or Test Driven development is an approach in which unit tests drive the development of the code. That is, when there is a new feature that needs to be developed, the unit tests corresponding to the feature is developed first before the actual code need to create the feature is coded.

Let’s take an example. Let’s say at a point of sale system, we need to calculate the bill based on the list of products picked by the consumer. Let’s write unit test corresponding to this code. (I have used C# based XUnit as the unit testing framework)

        [Fact(DisplayName = "SimpleBiller Should Calculate Total bill Amount")]
        public void SimpleBillShouldCalculate()
        {
            //Given
            var ProductsList = new List();
            ProductsList.Add(new Product { Name = "test Product1", Price = 5 });
            ProductsList.Add(new Product { Name = "test Product2", Price = 5 });
            var simpleBill = new SimpleBiller();

            //When
            var bill = simpleBill.GenerateBill(ProductsList);

            //then
            Assert.Equal(10, bill.TotalCost);
        }

In the above Unit test, we have 3 parts.

  • Given
  • When
  • Then

Given

This is the known part of the problem. i.e in mathematical terms, it’s part of the problem. In the example, we have initialized the variables and known things corresponding to the products (selected by the consumer) and the Biller object.

When

This is the business action based on which we are writing the code. In this case its GenerateBill action/method.

Then

The purpose of the tests is to ensure that the code/action does it properly as per the plan. In order to do that, we are asserting the assumptions/result of the method we are testing. In our case, we are asserting the total amount that the bill will have to be generated for.

Running the test

There are three stages of running the test.

  • Red – When we run the test now, it will fail as there is no code corresponding to the calculate bill functionality.
  • Green – In order to fix the above test, let’s write the real code corresponding to the above unit test/requirement.
        public Bill GenerateBill(IEnumerable products)
        {
            var bill = new Bill { Products = products };
            foreach (var product in bill.Products)
            {
                bill.TotalCost += product.Price;
            }

            return bill;
        }

Now, when we call GenerateBill method from the test, it will return the Bill with the total amount.

  • Refactor – With the above code written corresponding to the test, we are sure the functionality is correct as per the requirement. But the code is not optimal, as the foreach loop can be reduced to a simple C# LINQ  expression.
        public Bill GenerateBill(IEnumerable products)
        {
            var bill = new Bill { Products = products };
            bill.TotalCost = bill.Products.Sum(x => x.Price);
            return bill;
        }

Conclusion

TDD is a foolproof approach to developing software as per the requirement. The test also provides confidence to the developers on the edge conditions and other possibilities in the code. However, there is an alternative thought that TDD could waste developer time. Do you think, TDD is the right approach to software development? Please provide your comments.

Why do we need tasks? What is the need of Planned, Actual and Remaining hours?
 

I have repeatedly heard from teams that we have done estimation for stories in terms of story points or t-shirt sizes hence now why do we create tasks or if at all if we create tasks why do we add hours to tasks?  Add to that what is the need for specifying actual vs remaining hours every day for each task. The story is good enough to know what is to be done so why look at tasks. The benefits over challenges are much bigger and you can be truly convinced when you attempt it.

The recommendation is to have tasks created for each story.  Typically individual task should not be more than a day. If that’s the case, break it down further. Almost every task can be practically broken down to meet this criteria.  Once tasks are created, each task should be tagged to approx. hours needed for the same.

While creating tasks not just restrict yourselves to functional requirements while focus on following but not limited to

  • Non Functional Requirements (Performance, Security, Scalability, compliance, accessibility, maintainability etc. )
  • Dependency
  • Constraints
  • Acceptance criteria

The best time to create task is pre-grooming which is done few days ago before actual sprint planning/grooming.  It is my personal recommendation to get as many tasks as possible before you go for actual grooming. You can always convince team how you have come up with these tasks.

I am listing some of the core benefits of creating tasks, assign hours to each tasks during planning, smaller tasks and further constantly entering actual hours and hours remaining

  • The tasks add lots of clarity to story. I always advice individuals to create tasks before actual planning meeting. The pre-grooming done in advance in earlier sprint is when tasks should be created. This results in better estimation further result in better planning.
  • It is always simple to do individual smaller tasks over doing entire story. It is undoubtedly faster better and cheaper option.
  • Having tasks for individual story make it very easy to share your story work with other team members.
  • The hour assignment for each tasks helps in predictability of complete the tasks. The risks can be mitigated much earlier or in many cases it can be avoided during planning itself.
  • The actual vs remaining helps to come up with burndown chart which is one of the core artifact of agile teams. You can always have burndown based on # of items closed or velocity burned but that doesn’t give clarity and adds up little or no value.
  • Adds lot of value to individual accountability as it gives clear picture in terms of who is doing what and whether he/she is taking longer or getting it done early. This is one of the main cause many agile members are not inclined to go and add that much of details. The thinking of to become accountable is not a good idea is in reality bad for developers. More than an organization loss, they are killing their careers.
  • Small victories (after completing each tasks) gives motivation to individuals.
  • You are directly or indirectly reducing assumption on stories resulting success chances getting better. “Assumption is mother of all screw ups”. You can’t run away with assumptions while reducing the numbers helps you to do more.
  • The question which you might ask your stakeholders at later stage is typically unearthed well in advance.
  • In majority of cases better sprint success rate by having tasks and further hours (Planned, actual and remaining)
  • The nonfunctional requirements (security, performance, scalability etc) are listed in advance and these are being considered while planning
  • These NFRs, code reviews, testing etc are never missed. Typically POs encourages to list only requirements those have business values while I always recommend to write all the tasks which you are going to do.
  • The dependencies, constraints are identified. Moreover the acceptance criteria is well covered. The tasks suffice the need for missing SRS (Software Requirement Specifications) in agile projects.
  • The productivity is bound to be better in addition to quality. I have personally worked with tons of teams and experience the same.
  • Better bonding within team as things are BETTER organized.
  • You can better calculate matrices like productivity, cycle time, utilization etc.
Does size matter?
 

Estimations in scrum/agile environments often gets tangled in conversations about how big of an effort that is required. The questions that are often asked are “how much of effort?”, “how long/sprints it will take?”, “Is it too complex?”

Scrum provides a model where these questions are easily compressed to a simple thing called story points. Story points is a number denoting the complexity/effort/time taken by the team to solve a problem (story). Story points are often a number of Fibonacci series. (1, 2, 3, 5, 8, 13 …). The scrum team defines what it means by a 1 pointer story. For example one of our teams defined a 1 pointer as “one line of code change”.  Also as the number of unknowns in a story is high, team provide higher story points for the story.

However the size of the story points is not important because

  • Story point size is specific to the team and can not be used to compare teams. A story could be sized differently by different teams based on the understanding of the product, technology and experience.
  • When a management provides a commitment on a given epic/release to the customer, the delivery timeline is often determined by the velocity and not by individual story sizes.
  • Story points are a relative sizing of the stories and not a exact reflection of complexity/effort
  • Bigger story points does not mean higher customer value. A refactoring story or a story of lower business impact could be sized bigger.
  • Story points are time bound. The team could size the story differently depending on their understanding, as their knowledge/understanding changes their story sizes also change. This is one of the reasons some teams re-look at the story sizes during sprint planning although they are sized.

Please let us know your thoughts, using story points? does size matter?

Agile architect
 

In a typical agile environment, as there is no specific design phase, and there are often questions about when the design and architecture happens. There is continuous evolution of architecture and design that happens during the sprint and iterations. Also the conventional roles like Managers and Architects have no room in an agile environment. In this article we will discuss who do we call an Architect in an agile environment and what are their characteristics.

Agile Architect

An agile architect is a developer working and taking the most important technical decisions on the product. This is generally a person who has deep knowledge of the product and the technologies used and have great ownership in taking it to the next level. This definition beats the conventional definitions of a software architect who generally creates artifacts (like class diagram, sequence diagram etc) to be consumed by developers. An agile architect also do these conventional things in order to empower other developers, but also leads & helps the team to solve daily problems faced to implement the technical direction.

Characteristics

  • Be Agile: Agile architects are highly flexible and adaptable to changing requirements and environments and always open to changes.
  • Right tool for the problem : Agile architects often have good knowledge on more than one development language and are always open to newer technologies and solutions. When they are solving an intense problem, they use the right tool to solve that.
  • Emergent Design: Agile architects know that we can not fix the architecture at one go while the requirements keeps changing. So they are always ready to change the architecture and design based on the current business requirements.
  • Always Learning: They know there is always a better way to do thing and are open to do changes to their current tools, techniques and processes.
  • Refactor it in free time: When code does not reach perfection, they are open to achieve the business results and then do code refactoring to fix the flaws.
  • TDD/BDD: Agile architects always follow best practices like TDD/BDD so that the code is always nimble to new architectural changes.
  • Team along: As architecture and design is in the hands of every developer, agile architects always bring the team along and continuously get their inputs and provide technical directions.
  • Respect: There is no ivory tower for an agile architect, they are always part of the team and delivering results. So they respect other team members opinions and ideas and focus on delivering the best results for the product.

In this ever changing business environment, developers are often asked to deliver more and more in less time. Agile architects are a big asset to a team in providing technical, architectural and design guidance to the team.

Self Organizing teams
 

We all hear that Agile teams need to be self-organized. However there is not enough talked about what it means by self-organized. In this article, we will discuss the various qualities of self-organized teams.

  • High levels of personal responsibility

Self-organized team members are highly responsible individuals. They value the importance of their contribution to the overall success of the project. Because of this they do things on time, be available, and develop great relationship with other team members. When things are not happening as required, they take responsibility and do their part to get things done.

  • Put team first Team work
Team work

Being organized also mean being able to see the bigger picture. Self-organized team members always put team before them. Individuals have great respect for a combined democratic team decision than an ego-centric decision.

  • Openly ask and provide help Help me
Help me

Everyone is a learner and beginner before being an expert. So self-organized team help other team members for their short comings and also openly ask for help. They coach their fellow members and give them time to improve. As there are no shaming/blaming any one can ask for help without fear of being criticized.

  • Hold each other accountable
Pointing the finger

Pointing the finger

Self-organized teams are mostly a closed group and they have high levels of emotional security with each other. So they “call spade a spade” openly and bring up crucial topics and iron them out sooner. This not only happens at the same org level but they have no fear to hold a superior accountable.

  • High standards Its a Promise
Its a Promise

They agree upon nothing less than the best. Team members agree on a common set of standards which they continuously improve. They seek advice from industry veterans, architects, managers and anyone who can help improve themselves and the team.

  • NO managers required

They understand the strength and weakness of not only themselves but also other fellow team members. By respectfully and openly talking and holding each other accountable, team gets better at their game. Also self-organizing teams pick and choose who gets into their team. They often interview new individuals and sets very high expectations from the day one. Instead of managers, self-organized teams rather require a coach who will guide them from outside.

  • Highly mature

Maturity not only comes with age, but also with the company of highly mature individuals. Self-reinforcement of high standards and accountability makes them mature and the team members self-esteem is often very high.

  • Enjoy the company

Last but not the least, self-organized team enjoy their time together. They combine specific business meetings at various places where they enjoy the time and at the same time business gets done. They make fun, laugh, and merry together so that life becomes less stressful.

What is the role of a manager in Agile project? Do we need Manager at all?
 

A switch from waterfall to agile project and suddenly you would start seeing whole new world. Is this shift complicated? How can I be successful as manager in agile project? How does it defer from traditional methodology?  And there are many more questions which every manager who starts with agile project or managers already part of agile project come up with.  Most importantly what is my ROLE?  Lets explore

As a manager, when you get into a project you want to manage the day to day deliverables and processes but wait that’s a job of a scrum master, you move on to prioritize the work but that’s again product owner owns. Wow, then you jump on to assign work and get involved in day to day activities but wait again, isn’t your teams are self-organizing?

By heart, I am a software engineer. Can I code? Off course you can if you don’t have any other work and moreover you are expected to become a team member.  Frustrating, well yes and no. If you are quite adamant and not ready to unlearn some of the traditional practices as manager, you would be biggest bottleneck in getting your project successful.  You can’t do many things in agile while you can control everything by keeping some distance while taking complete ownership.

As a manager, I would suggest you to do the following

  • Motivate team – Constantly encourage your team members. Agile focus on every individual and a motivated team member can do wonders. If you are thinking of spoon feeding agile member then either the member has too many challenges or you are not a right manager.
  • Celebrate victories – Find an opportunity to celebrate your victories. Even if that are small as every celebration would enhance your team motivation and bring in lots of energy to system.
  • Focus on business priorities – Constantly focus on your business priorities, contribute in vision, drive vision by ensuring work gets done, keep abreast with business demand. Learn domain and make your team gain expertise over that. Build a model to train new joiners quickly. Encourage collaboration and encourage teams to discuss the business.
  • Be open – This is one of the biggest challenge I see in this industry. You don’t want to hurt anybody and with that you always go with giving positive feedback. Remember the areas of improvement and constructive feedback helps an individual to grow. You are supporting short term growth by killing his/her long term growth as well as organization priorities. You need to constantly strive to build your team and focus on every individual to be successful. More you focus on people, better off your results are. Rate your people as they are. You need to motivate your high performers and bring you low performers to get better. Always remember that you need to get better constantly.
  • Generate Metrics and constantly monitor them – The world is not perfect place. Teams which are doing amazing, may go down. Constantly monitor productivity, prod issues, defect rate and whatever is important in your organization.
  • Trust team and encourage the culture of trusting people – In my experience, if you have an average team, and that team trust each other and ready to support each other, they would end up doing much more and better compare to your star team where you see conflicts. I have seen multiple examples in past where the whole team gel extremely well and the result you see are outstanding. Not just project did the best in those scenarios while the whole team has gotten bigger rewards and great careers.  The dedication to team result in delivering values. This holds true all the times.
  • Invest in resources – Hire best talent. Further send them for trainings, Encourage cross KT culture, plan their travel if their teams are in different country city, constantly keep in touch with them and make them feel that the org does care for them. Many a times in bigger organization individuals are lost while it is primary responsibility of a project manager to ensure they are being taken care of. One of the tool I used heavily is to ask individuals their aspirations and constantly seek opportunities to fulfill them. You may not be able to do it all but creating a path is kind of easy. In fact, many a times I see individual aspirations are so easy that it can be fulfilled in no time and little effort.
  • Process improvements – Let scrum master handles processes while constantly review to see what improvements can be made further. Improving on test coverage, adhering to standard practices, encouraging people to take risks etc. For instance you see all retrospective items are great while after a meeting we don’t do anything about it (Unfortunately most agile team has this challenge). Well, here you can have action items and ask team to assign that. The next retrospective should start with older action items. You can always work with scrum master to get processes better.
  • 1×1 Meetings – This is very powerful tool. As a manager, I would strongly recommend you to keep talking to team members. Appreciate them for their great work. Constantly provide feedback on areas they should get better. Understand their perspective and identify action items for you. Make yourself available for team all the times. I am being often told by managers coming from traditional model that don’t be easily available for your team as you may end up doing more and people won’t value you. I am completely against of that idea. I think you should meet up your team as much as you can.
  • Empowerment – Find right people and empower them to do certain things. Build your next set of leaders. Trust people. If you manage multiple agile teams then build leader within each team and empower them. Practically you shouldn’t be very busy all the times. You should  be available for your team as soon as possible when they need you.
  • Improve system – You should be constantly looking at everything in the system and find opportunities to improve them. Improving productivity, quality, trust, competence, delivery, processes and many more.
  • Seek challenges – The seeking challenges is always better option over embracing challenges. You should be constantly seeking challenges and building the same culture around that.
  • Fun place to work– Create an environment where everyone feels like coming to office. There should be lots of fun. Believe in starting your day with fun and it should be throughout. Don’t have a constraint that I would allow you to have fun when we achieve something. Although you do celebrate every victory but fun is something should be there all the times.

Always remember that things which you can do directly, that’s great while things or tasks which agile doesn’t allow you to do it, get yourself involved indirectly and get them accomplished. At the end of day, your biggest priority is make your team successful. If you can achieve that, rest all fall in place.

Story Points Vs Time
 

The story point is high level estimation based on complexity before the work begins on story while the hour based estimation is just more concrete estimation where effort is represented in hours. The amount of work a team can accomplish during a single sprint is called Velocity. It is calculated at the end of Sprint by adding all the story points which are done-done. 

Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of theSprint by totaling the Points for all fully completed User Stories

Now the question is how does story points relate to time and this is certainly one of the debated topic among sprint teams and I see confusion all around. I heard from individual team members many a times that story point can never be related to time in any way. One cannot say 1 story point equivalent to 2 hours or 5 hours or any other number. The second statement is right while this creates a notion that story point has no relation with time. When you have 3 story points, it could take 3 days or up to 50 days. This doesn’t seem right and this is actually not RIGHT. “Whatever time it takes is fine after-all one is putting on effort” effect is what visible .

The reality is, the story point states EFFORT. The estimation for team member X can be 10 hours for 3 story points while other it could be 20 hours. The moment you say effort, it is size. But the size is relative. Hence it proves the point that it is not exact hours while it’s relative hours. The estimate is for team and they should be able to say what is the biggest size in terms of story points can be picked which would be done in sprint. Moreover if we say, team velocity is 40 story points that means we can complete 40 story points for this team in N week sprint.
If one doesn’t want to relate this to size at all, then I suggest them to stop doing estimation as in that it case it would be just waste of time. Typically a story point suggest min and max time which might be taken to accomplish that story. For instance 3 story point for team P means effort between 3 and 5 days. It could be plus or minus but the point I have is to have some indication with respect to size.

I have seen individuals just change the story point for a given story if they can’t complete the same in stipulated time. I understand the estimation was not done right or probably we might not have done estimation but adding/changing story point or hours post the work is being done is pathetic. It completely wastes the time spent on estimation and further we lose all the value gain with estimation. This practice is primarily meant for inflating numbers to have better reports. This MUST be stopped.

I have been often asked that the team is not able to predict well because they are new or may not be competent enough to find the right story points. How should we handle that as it is important to be predictable as you can’t run the business in vacuum? When your boss or business ask how long it takes to complete the effort, you still have to answer probably by looking at release planning and estimation. This shows another point why we have to relate the effort to hours (Not the exact) and here min and max does the job.

As we are talking about story points, there are many teams who would just add story points to story while for individual tasks they don’t assign hours. The burndown chart in that case is driven by task (Task based or hour based) which is in a way weird because you suddenly see ups and downs. The whole value of one of the most critical artifact in agile is not being materialized. The planned and remaining hours is important in individual tasks.

What happens when you are in the sprint? How to make it more meaningful?
 

There is enough motivation I have to write this article as the whole intention is to answer the questions which I have been asked multiple times pertaining to sprints I dealt with.

Some of which are listed below but not limited to

– How can we ensure sprint success?
– Should we do more or less?
– Why continuous improvement?
– How can I be successful? How can I grow faster?
– How to get better at estimation?
– Am I following the right set of processes?
– Is pairing good and how should we pair?
– Am I being heard? Should I challenge people? What if the team is very senior compare to me?
– The standup happens in the evening because of the offshore and onshore model? How to make it effective?

And the list is endless.

Let’s assume you are already in sprint cycle. One of the important questions is how do you provide an estimate for items which are already prioritized for sprint?  The majority of newbies teams with limited exposure to agile struggle due to unknowns during mid-sprint which was not accounted for. The estimation might have given with many assumptions. The predictability is the biggest concern in most agile teams. One of the easiest ways is to pre-groom stories well in advance.  Typically for two weeks sprint, I encourage the team to spend 10-15% of time daily during the second week of a sprint to get as many details as possible for next sprint stories, create tasks, identify dependencies, quick spikes to find out the feasibility.

The typical myth most people have that we should be adding only tasks having business values while it might be a look good factor for product owner but from a developer standpoint, this is something we should avoid. In addition to functional and non-functional requirements, a team should add testing, documentation, and everything that they would work on as a task. This given better clarity and sharing of work.

When you constantly spend time in grooming next week sprint story, you are very confident how much worth of work you can do it in next sprint when you get on to sprint planning as your estimates are good enough with confidence that what you are going to build. As this practice continues, there is a point which comes approx. in 3 to 4 sprints where the team doesn’t even pick a work which is not clear.

In summary, when a team starts with sprint, during the planning meeting, everyone talks about stories and tasks (Tasking is done). The goal is to add/remove items might not have been considered and provide estimates. The commitment is made with lots of confidence. You can never avoid unknowns while the chances of getting it reduced significantly increases.

Just to prove above point, once I have enforced SRS (Software Requirement Specification) in agile where it must have to be created and approved before planning a day in order for that item to be considered for planning. The team productivity dropped for 30-40% in first two weeks to get settled with new process inception and spending time in creating a document while as the time passed, the team who was not confident in doing 35 story points, hitting close to 60+ story points. All that happens in less than 4 sprints. Worth it!! Isn’t it?

This approach is phenomenal when the team is co-located while teams which are not, it can be slightly modified. For instance, the team at location x can pre-groom few stories and location y does the same with another set of stories.

There is another interesting thing which I have seen in offshore and onshore are sharing the same stories. The challenge is what I work (assuming I am at offshore), I need to hand off to onshore and vice versa. For 6 day worth of story, I and my counterpart need to understand what other person has done. The wastage of time in handoff and further understanding work done by counterpart every day by both ends adds extra hours.

I have seen instances when a story which can be done in 6 days took more than 6 days because of the addition of another person. Sounds funny? Yes, it is. Even if in extremely positive scenarios, it would add 50% extra time. A lot of people think we can avoid dependency and everyone should know everything, while it is funnier that the horizon of learning is limited for an individual if you look at long term. I am not saying that we shouldn’t do that but we need to be wary of taking a right decision. For instance, if there is a production issue or a complicated story which we want more than one person to learn/work or a story must have to be completed in little lesser time. With these kinds of practices, trade-off is understood. Compromising productivity to achieve temporary priority is fine in this case.

When the team is aggressive, they pick more points and to make up that quality is being compromised. Or the team may not be able to do that, which is even worse as it demotivates the team. I always tell my all teams to start with less (less than they think they can really do it). Further, as we progress, keep on taking more and more. The constant improvement is really important.

As discussed earlier, the pre-grooming or creating SRS very much fix this issue.

In order to have your sprint successful below is what I think are very critical

– Trust each other in team
– Give focused hours. Core working hours are really important
– Celebrate every victory
– Appreciate your team members
– Provide feedback openly
– Fail faster

The “I” factor usually becomes a challenge in many sprint teams. I will pick the certain specific piece and create dependency or I am more competent, and I would do my own over working with a team. The moment you see people like this in your team, get that fixed or move those out of the team. They just create a nuisance and spoil team culture. This is just a myth for an individual as it’s very easy to replace anybody in agile. The only worry, I see here is spoiling team culture.

As an individual team member of team, the success of him/her is

Constantly learning, learning faster
Team Success
Fun working

I have seen less competent team while better at supporting and trusting each other ended up doing much better in terms of quality, quantity and achieving business goals compared to high experienced teams with team culture lacking. Agile is all about self-organizing teams which move up in ladder by helping each other to grow. It is so beautiful that everything is visible and individuals with “I” and “We” just do not grow. If you are not able to openly give feedback to your team member because you are scared, you would end up being just mediocre.  I do less because sprint success is important and does it matter if I work just 2 hours a day because I am completed all the work I planned. Sounds familiar?

Another interesting observation what I have from some of the developers is if I don’t contribute it is anyway not visible because I can show I am pairing or stuck on complicated issues or whatever. It’s is a just wonderful myth. The agile gives so much of clarity that everything is visible.

When it comes to releasing software, I would say release as many times as you can. This would force you to think a need of having lots of tests. Again one of the common challenges is, most teams focus well on the unit test while they hardly create integration test. That is bigger killer in long run. A lot of great teams are given 20% to 30% time in a sprint just to refactor code, working on extra tests which are not there or working on nonfunctional requirements. The challenge is if it’s not planned, it doesn’t happen. The human psychology must have to be addressed. If I am given a work on Monday and I am expected to do this by Friday, I would do that on Friday even if I could have done that in 2 days.  In addition to that when you have a task it has to be done.

How great self-organizing team you have, it is always good to add work in sprint board.

The fear is another cause of doing less or not doing RIGHT. Many times teams are afraid that they may not be able to complete the work hence they pick less and even though work gets completed in advance, they keep picking less. The extra time remaining is good for learning new stuff and working on tech debts. 1/2 day or one-day learning is decent for two weeks of sprint while for tech debt and other stuff, planning results better outcome.  When the team trusts each other, they as the team always take credit for success and accountable for failures. It sounds better. Indeed it is. Agile encourage you to fail while with every failure you should learn and avoid repeating that mistake. When you are working on existing complicated product, and while working on the story you see there is an opportunity to fix existing bug or refactor some code, I would say you should do it. Or plan to do it ASAP.

If your team or PO is discouraging you from doing that, talk as a team. Your goal is not just to fix issue what customer reported while you should be constantly striving to make your product better. The priority can be discussed and trade off can be identified while If you don’t do it, it would never happen.

Let’s talk about scope creep. The scope creep is nothing but change of scope or change in requirements

If it’s in middle of sprint, there are only two ways to manage it

– Push it to next sprint
– Remove the same amount of work to pick new work (Do it only when it’s VERY important). Agile completely discourages it but when there is a prod issue or something similar to that sort pops in, you might have to take wise decision)

If it’s outside of sprint

Agile is excellent, it depends on the SOW you have signed. Primarily, you can take something out or you can add another sprint to your total number of sprint or whatever you have agreed on.

I personally don’t allow a team to pick work which comes during the middle of the sprint. It creates lots of confusion. Until and unless it is extremely important, you should not be picking it up. The extreme urgency like prod issue comes from customer etc. Many of the things can be planned by keeping some 10 to 20% of bandwidth to manage these support issues. If there is a huge work which would spoil the sprint, the best thing to do is to start a new sprint.

Another practice which I feel goes pretty well when you have offshore and onshore model, is to have quick sync meeting in morning. Typically standup happens in the evening which is nothing but post-mortem or status meeting who is attending that in evening. It doesn’t have the benefits of stand-up at all hence meeting in morning for such team adds lots of value.

The demo and showcase are very important, and I always prefer a practice of showing it to team and PO as and when it’s available. How great the requirement elicitation is, there are always things which get missed. I have seen teams doing Agile with waterfall model and I call that as “waterfall agile”. Most of the team members work on development for first 70% of days and in the end, the focus is on QA which is ridiculous. Ideally, you should work on development, testing, and showcase. If possible push that code to prod as soon as you can and don’t wait for the whole sprint to get completed. There is an exception to this is when you have bigger products and many customers are using it. This kind of scenarios you should be looking at a number of tests you have and what kind of dependencies to be addressed.

Agile is really very simple hence it doesn’t allow you to do too much tailoring, unlike waterfall method. Every process is simple but it has to be done diligently. You don’t work as individual while you work as a team.