Agile – Page 5 – Agile Champs

Mar 25 2017

Scrum Ceremonies – Demo/Review or Showcase

The following Scrum ceremonies are to be understood well.

Let’s talk about Demo/Review or Showcase in this article

A showcase, demo, or sprint review represents one and the same thing. A sprint review is an informal meeting that typically takes the form of a demo of the completed features or what is accomplished during the sprint to the product owner (And rest of the team).

This can be done as and when the work is completed over waiting for the last day of the sprint to arrive. This mitigates the risk of incorporating review comments which may result in sprint failure if the demo is done on the last day of the sprint. In case if there are review comments, that should be fixed, and once again demo to be conducted for the story which had review comments.

The whole team should participate. Although the team needs to get the buy-in from PO to change the story to done-done while the feedback from the whole team helps. You can invite other teams, support, or customer as needed.

One of the core objectives of the demo is to review progress against the sprint goal and team commitment. It is an opportunity to get everyone on the same page in terms of what was accomplished, what’s still in progress, and what tradeoffs were made.

Best practices around Demo/Showcase

Prepare, prepare, and prepare – Don’t go to the demo meeting and start talking randomly. Everyone’s time is important including you.
Practice before the demo – Run the workflow or the feature you have built. This ensures everything works.
Give importance to Acceptance Criteria – You can always talk about nonfunctional requirements while the focus should be on acceptance criteria. What value your feature is adding to the product/business.
Follow KISS – Keep it short and simple – Don’t complicate things. Make it crisp, cover all the points written down in the acceptance criteria. Give time to your team and the PO to ask questions.
Showcase Value – Do not focus on technology or the feature you have built works while do talk about business value. Feel the sense of pride or accomplishment in showcasing what you accomplished.
Communication – It’s key to success. Talk to the point. Listen to people (your team). Write down their feedback and comments. A good idea is to record the meeting so that you can always go back and listen to the feedback if any.
Involve right participants/stakeholders – Not just your sprint team or PO but you should be inviting folks representing your product business. Folks on the actual ground adds lots of value to the project/product.
Seek Feedback – Accept the feedback positively. Your goal is your team success, making a product better, and help the organization to get more value. This eventually helps you to grow faster.

Mar 25 2017

Scrum Ceremonies – Planning and Backlog Refinement

The following Scrum ceremonies are to be understood well.

Let’s talk about planning and grooming in this article

The entire sprint team works together and plan for the next sprint goals. The sprint planning meeting is attended by the scrum master, product owner, and rest of the Scrum team. The other teams may be invited on a need basis.

The PO ensures product backlog priority is up to date (At least top-level items) for the team to pick up items from the product backlog. The stories are picked up and prioritized. The PO usually talks about sprint goals and once that is finalized, the stories are being picked up for grooming.

For each story, the product owner writes down the description of the story and acceptance criteria. While grooming it can be further updated by PO and team. The team gets answers for their queries from the PO with respect to functional expectations. In addition to that teamwork together to identify dependencies, constraints, and nonfunctional requirements. The team typically elaborate more on functional requirements as well. The stories are broken down into multiple tasks.

All the groomed stories are then estimated by the team. Each story is tagged with story points or hours. The task usually is tagged with planned hours. The scrum master and team look at the velocity and capacity of the team and commit the amount of work that can be delivered in a sprint.

At the end of this meeting, the scrum team would have two artifacts ready

Sprint Goal
Sprint Backlog

Best Practices

I always suggest the team go with pre-grooming. Typically planning happens a day before or when we are about to start a sprint. Understanding every story the first time, grooming, tasking, and estimating take too much time. Due to time constraints, it is not very effective and done half-heartedly. Moreover, all the questions can’t be answered upfront. This is one of the main causes of sprint failures in most projects as you are not sure of what you are committing. One good idea is to keep looking at upcoming stories and clarify all the doubts with PO or other stakeholders in advance. Spending 30 minutes to an hour by few folks in team 4-5 days in the previous sprint helps to do much better for the next sprint. With this, the planning meeting will have just three goals
1. Explain everyone expectations from stories and get aligned
2. Estimate
3. Once #1 and #2 are done for all the stories, commit sprint.

Note: Many times, the business and competition demand last-minute priority work to be picked when you start the Sprint. This is fine as long as it’s minimal.

PO shouldn’t be telling how much work the team should be picking. The team should take a wise decision by looking at previous sprint capacity. The idea is to have sprint success and continuous improvement.
Always keep a little buffer for planning next sprint items, unknowns in existing sprints, and tech debts
A lot of teams prefer to keep 20% time aside to deal with tech debts. This may be a good idea while I always suggest the team to plan for this 20% during sprint planning and grooming only. What you plan is what can be accomplished.
Don’t be very aggressive as the quality of software in most cases is more important than quantity.
The team member shouldn’t be picking up multiple stories in advance. Each and every member should pick one story and once done they should move to the next one as per the priority order specified in Sprint. The exception of picking up the items within Sprint should be ok as long as the PO is good with that.
Always create a task for stories. Don’t just include tasks that have business values while do consider tasks related to development and testing. For instance testing, code reviews, writing tests, etc. Keep in mind, don’t write too many tasks.
Try to break down the story to as small as possible while if the estimation is going beyond then it’s important to divide that into smaller stories. There are instances where you can’t break down the story to the level where you are not getting business value out of it which is OK at a times but do avoid this situation as much as possible.
In the story where lots of research is involved and there are unknowns that need to be unearthed, prefer to go with Spike.
Trust each other and support each other.
Pair when needed while do not work on the same task in series unless absolutely necessary. I have seen with the offshore-onshore model, the story is being worked on one story offshore, and further, it is handed off to another team member onshore. These cycles keep repeating. The amount of productivity loss that happens in this approach is not worth it.

Important Tip – The scope creep can be managed within Sprint with only two ways

Refuse new work in the middle of Sprint and take up that in the next Sprint.
If it’s absolutely mandatory to pick the work in the middle, you need to take out an equal amount of work from Sprint.

At times, you are done with Sprint in advance, in that case, you can pick more work while it is always a better idea to increase your velocity and focus on tech debts, testing, and quality practices. You can even spend time on learning which is usually way more important than we usually think

Mar 19 2017

Scrum Ceremonies – Retrospectives

The following Scrum ceremonies are to be understood well.

Let’s talk about agile retrospective in this article

No matter how great your team is, there is always scope to improve and get better. The retrospective is a way to accomplish this periodically. The main focus is to look at what is working and what is not? Further, what are the action items we have based on our learning? The core focus of retrospective is continuous improvement which is one of the core philosophies of agile.

The primary agenda of this meeting where every team member is expected to bring their points are

What worked well?
What did not work well?
Action items to improve the process (Mainly action items are the result of what did not work well)

How to do it

Set the stage. Invite the entire team to a meeting (Scrum Master, Product Owner, Team and Customer if possible)
Give 10 minutes for everyone to enter their points towards 3 agenda items stated above. The recommendation is to use a tool (For instance noteapp) and send this to the whole team in advance to enter their points. This would save time for a team in meeting and moreover give enough time to team members to think and state their points.
Start with talking about previous retrospectives action items. Close the items which are accomplished.
Talk about what worked well, appreciate people, and motivate the team to continue utilizing the best practices.
Discuss what did not work well and come with action items
Assign owners to every action item.
Close the retrospective while action items to go to the action item register.

Best Practices

Typically it should happen after every sprint and should last between 30 to 60 minutes.
The whole team should participate.
This can be considered as a “lesson learned” meeting. The notes can go to organizational process assets (Remember “PAL” or “Process Asset Library”).
The owners must be assigned to action items. The next retrospective should start with open items of previous retrospective meetings. I have seen, individual teams have excellent ideas while post retrospective nobody really thinks about it.
One of the recommendations is to have a retrospective of retrospectives to make it better.
Don’t point fingers instead work as a team and support each other.
Do not forget to appreciate your team members.

Mar 19 2017

Scrum Ceremonies – Daily Stand Ups

The following Scrum ceremonies are to be understood well.

Let’s talk about Daily Standups in this article

The standup is nothing but a daily meeting among all scrum members. The agenda of this meeting should be:

1. What did you accomplish since the last meeting

2. What are you planning to work on until the next meeting

3. What issues are blocking your progress (Impediments)

BEST Practices

This is not a status meeting or status to management.
The stand-ups should be strictly time-boxed between 10 minutes to max 15 minutes.
Hold the meeting “Without chairs” if possible. Everyone must stand and speak up.
Plan to do this in the morning. If you have a sprint team outside of your country and a common meeting held only in the evening then plan to meet whoever is available in the morning for 5 minutes for quick sync up with the same agenda. The evening standups are just status or post-mortem which doesn’t serve the purpose of stand-ups.
Everybody in the team reports to three agenda items listed above to the rest of the team.
Prefer to have this meeting at the same place and time every day. Meeting in the morning is very important as it helps set the context for upcoming work.
The quick questions and clarifications can be covered at a time while do remember that the meeting must have to end within 15 minutes. Please understand when I say quick, I am referring to closed-ended quick questions. The rest of everything should go offline or should be addressed with other meetings.
The meeting should not be canceled even some of the members are not present. As a team member, it is extremely important for you to attend the meeting if you are not on leave that day.

Mar 19 2017

Agile Top 10 Interview Questions

Following are the TOP 10 agile interview questions. There is another list of critical questions while these are expected in most interviews. Moreover these are very basic, and every interviewee is expected to excel in his/her responses for these questions.

What is agile roadmap looks like? Explain agile process start to end? How do you start agile project? What is the difference between product roadmap and Release planning?

Refer Agile Roadmap

What is Test Driven Development? How does it differs from traditional method where tests were written before the actual code?
What is continuous integration? How do you achieve that?
What is scope creep and how do you manage that within sprint?
What are the core artifacts of sprint? Elaborate them?
What is the role of Scrum Master, Product Owner and Team Member? Or what are the typical roles in Scrum?

Refer Scrum Roles and Responsibilities

What is Velocity and Story Points? How do you relate story points to hours? Is it right?

Refer Story Points Vs Time

What type of metrics or reports you have in agile? Explain?
Explain Sprint Ceremonies? Planning & Grooming, Stand-up, Demo or Showcase and Retrospective.

Refer

Scrum Ceremonies – Daily Stand Ups

Scrum Ceremonies – Planning and Grooming

Scrum Ceremonies – Retrospectives

Scrum Ceremonies – Demo/Review or Showcase

Explain Agile in 2 minutes? When should you use Agile? Explain the instances when you prefer to go with Waterfall over Agile

Refer Agile in 2 minutes

I would be writing other important questions in addition to questions focused for Managers, Directors, Agile Coaches, Scrum Masters, Team Members and Product Owners in my upcoming blogs.

Mar 17 2017

Agile Appraisal – What to consider

If you are a manager and above in agile work environment and you need to go with appraisal, you might have encountered situations where what to expect from your team members compare to traditional model. The focus is on collaboration, pairing, individual ownership for self and team. The “Working for team” culture over work for “self” make it more difficult. One of the recommendation I have for all the managers or individuals responsible for doing appraisals for agile team is to have a certain percentage allocated to team success in everyone’s goal, and further how the team collaborates and how well they work together. The percentage can differ with experience of an agile team member and expectations what you have from your team.

When it comes to individual performance (obviously there is a percentage attached to this as well which is typically little above than team success), I prefer to look at three factors which covers it all.

1. Competence – Demonstrates strong leadership in one or more areas (e.g., technical, project management, process, etc.). Consistently works to leverage skills for team and larger organization success.

Breadth and depth of knowledge and skills
Problem solving ability
Technical, communication, interpersonal, business skills
Leadership and innovation, applied to people, processes, and projects

2. Contribution – Someone who has a lot of initiative, is a leader across the organization, and has outstanding productivity.

Ability to meet commitments
Overall productivity and volume of output
Early communication of problems and contribution to workarounds that meets business goals
Versatility – willingness and ability to adapt to new tasks
Teamwork – willingness and ability to help others
Leadership skills such as architecture, project management, change management, communication, and mentoring
Ability to motivate others, manage self, and demonstrate initiative.

3. Value to business – This is very critical. What kind of value you are adding to business. There could be high competence and contribution to build a product while ROI (Return on investment) should never be ignored.

Knowledge and skills as mapped to needs of the business
Extra points here for unique skills we need

Every agile member should ask three questions to himself/herself frequently

Am I learning?
Am I contributing?
Am I making a difference?

The manager should ask the same questions to himself/herself and same for his team. If the answer is no then appropriate development goals must be planned and discussed.

The biggest goals for a manager should be in while managing agile project should be

Sprint success
Continuous Improvement
Constant Learning
Building Self Organizing Teams

Mar 13 2017

Why sprint success is important

In Agile environment, some of the committed stories may not be completed at the end of the iteration. For example, in Scrum, the stories roll to the next sprint. There could be various reasons why some of the stories could not be achieved. Reasons include (not limited to) blockers, inefficiency, improper sync between team members, missing clarity, support from other teams, priority etc. A casual look on this can make someone think this is normal. But sprint success has a huge impact on the long term success of the team and the product.

Fig: Success

Following are the some of the reasons why sprint success is important.

Morale : The team members self esteem actually gets higher when they achieve their goal. This breads confidence and help them to get better a their game, which can lead to more success.

Habit: Success breads happiness and more success. At the same time, failure breads failure. Also success/failure on one aspect of life can cause ripple effect on the rest of the life. We should be focused on success on every aspect of life so that it can bread in to itself.

Fig: Habit Loop

Fine reputation: More than any thing else, team will be very proud when they are able to successfully achieve the sprint goals consistently. Their reputation and respect around the company can actually go up and they will have to live up to that standard.

High standards: Team starts to set higher standard for themselves when they have high reputation. This helps them to get better at questioning, coding, testing, deploying and showcasing etc and improves their living standards in a holistic way.

Team bonding: When the team have a standard to live up to, they come together and get the things done, keeping aside the petty things. The goal becomes bigger than individuals and deliver thing as a team. This leads to higher team bonding and it reinforces their standards, reputation, habit and morale.

These are some of the main reasons why sprint success is important. When we focus on success, more positive things happen to the team and to the product that they work on.

Mar 5 2017

What are Scrum Roles and Responsibilities

The Scrum roles and responsibilities are

Product Owner (PO) – PO is a key stakeholder in an Agile project. He/she is responsible for defining or detailing the vision, understanding organization goals and ensure to align project goals with it. PO has the content authority at a team level.

Defines the features and stories of the product. Responsible for elaborating requirements, clarify doubts, and clearly stating acceptance criteria.
Review and accept/reject the work accomplished by the team.
Responsible for prioritization of the work.
Responsible for release planning.
Owns product backlog and release backlog.
Remove functional impediments and constantly answer product related questions to the team.
Constantly talking to other POs to align product/project changes with business unit/organization goals.
Responsible for the return of investments.
Constantly working with the customer to fulfill their needs and better understand their requirements.

Scrum Master

The Scrum master plays a servant leader to the Scrum team.
Facilitate daily standups.
Setting up retrospectives, pre-grooming, showcase, Scrum of the scrum and other meetings.
Remove impediments or obstacles for all kinds (technical, functional, resource, etc.)
Co-ordinate with POs, teams, Manager, and all the project holders.
Ensure team productivity and closely working with them to ensure quality requirements are enforced.
Ensure the team understands the processes and adhere to them.
Protect the team from external interferences and interruptions.

Team Member

Responsible for actual implementation.
Owns Sprint Backlog while the priority of Sprint backlog should be derived from the product backlog.
The recommended size is between 6 to 10 people. The best practice is to have 7-8 members team.
All the members are expected to be full-time. The exceptions could be DBA or some specialized skill needed on a temporary basis.
Proactively identify ways and opportunities to improve the performance of the team and constantly get better.
Are set of programmers, DBAs, tech writers, technical experts, domain experts, independent testers etc.
Must be self-organizing.
Constantly communicate with the team and ensure to meet sprint goals.
To share all information in daily standups including “work in progress”
To support each other. Most importantly consider sprint goal a priority over individual goals.
Avoid accepting outside or extra work without consent from team.in