Archive for Agile Articles

Cultivating Your Organization’s Future

This article is about individual’s role in creating great culture in organisations. This article was published in Scrum Alliance website.

Please read this article in Scrum Alliance website and provide your comments

Make sure your product backlog is OPTIMISED

This article is about the Product Backlog characteristics. I published this article in Scrum Alliance website. Each letter in the word “OPTIMISED” is explained with different characteristic of the product backlog.

Please reach this article directly in Scrum Alliance website. Kindly leave your comments on this article.

Add toppings (Engineering Practices) to your Ice cream (Scrum) to make it even tastier

I start this post with a metaphor “Your Sprint is like your Ice cream bowl“. You generally put ice cream in the bowl, and also add some toppings on top of it, why? Just to make it tastes “awesome“. I am going to apply this metaphor to the Scrum Teams to make them “High Performance Teams” through adding engineering practices on top of your backlog items delivery in a sprint.

What happens in Scrum? Teams have limited capacity in the sprint. During the sprint planning meeting, they pull items from the product backlog based on the items’ priority, team’s capacity, try to convert them into potentially shippable product increment at the end of the sprint, by following the other Scrum events (Daily Scrum, Sprint Review and Sprint Retrospective). Of course they also perform product backlog refinement activity.

But is this enough? Do all teams able to deliver potentially shippable product increments always? In my opinion, not really. It’s just that you are like a plain ice cream in the bowl, that tastes normal. However, if you want to call yourself as a high performance team (just like toppings added ice cream taste), you have to inculcate some good engineering practices.

Why engineering practices? Engineering Practices make your “Developer and Tester” life easy and happy, trust me! Reason – It helps to keep your design simple, you can keep your code maintainable, anyone can make changes in anyone else’s code without any issues, not only that you can release frequently into production seamlessly.

Okay, where do I start and what practices I need to consider for my teams? My suggestion would be first taste the plain vanilla ice cream for a few sprints and get the taste of it. Then identify what engineering practices will help you to get to the next level. You don’t need to implement all of the practices. Just find what suit your team well and add value. Pick them up during the next sprints. Remember! whatever practices you pick up, don’t try to start all of them at once, you have to be iterative and incremental in this also, after all we are talking about Agile.

Here are some engineering practices that you can try with your teams.

1. Pair Programming:

Pair Programming is one of the wonderful practices that helps your team to write code with high quality. Reason being, one person writes the code (driver) and the other reviews then and there (navigator). This avoids any design, performance, defect related scenarios while the code is getting produced. So this helps to reach “POKA YOKE” (mistake proof) from the beginning. Not only that, your team gets familiar with entire code base if you keep encouraging the pair programming practice with moving people around. Doesn’t it cost me more? Of course yes, but the amount of testing time, code review time, bug fixing time you save is much higher than this cost. So you need to see trade off and make a decision.

2. Test Driven Development (TDD):

TDD helps the teams to create a safety net around their code. If you practice TDD in your teams, they get high level of confidence to make changes as and when there are code changes needed. TDD helps keeping the cost of changes low and also to handle the technical debt. How? The automated tests will help your code as a safety net and whenever you make any change in the code, if any of these tests fail that means your code changes causing the failure so you can immediately fix the code. But make a note, you will never start your code first, rather you write your first test, make it fail, then write code to fix the test, then refactor and then continue with next test. If you write your entire code first, then write corresponding tests, it is not useful and vice versa also not useful. Tests and code must go hand in hand. Also make another important note, when you find a bug at any point of time, add it as a test to the test cases. This helps arresting the repeated defects. Make sure to create your test suite in such a way that they satisfy: Isolated, Automated, Decisive, Repeatable etc principles.

3. Simple Design:

Agile principle #11 says “The best architectures, designs and requirements emerge from self-organized teams“. Yes, it is true, but it depends on how really self-organized you are! Make sure your design and architecture progressively elaborates and keep them simple but scalable using design patterns. Follow YAGNI, DRY etc principles. I suggest to keep your system design visible using lego blocks. This helps your team to come up with optimal solutions when they need to develop new features. During backlog refinement or discussing the design changes during sprint, team can stand around the lego block design table, discuss which layer gets affected for the new features and what should be the best approach to keep it simple. Keep your modules loosely coupled through API/Web service based communication. Challenge complexity and try to simple through architectural and design principles. Less is more!

4. Refactoring:

XP (Extreme Programming) recommends “Mercilessly Refactor”. So you need to encourage your teams to refactor your code often. How often? In fact it should be part of your TDD’s third step (RED, GREEN, REFACTOR).  What happens if I do not refactor? Simple, you may hit road blocks in future and your team’s velocity drastically goes down. You will be fire fighting rather than delivering new features. Who should refactor the code in my team? It’s everyone’s responsibility to refactor their code as and when they write. Any code your team creates, it should have automated tests and should be refactored. This will help to deliver high quality and easily maintainable code.

5. Coding Standards & Code Review:

This is the simplest practice your team can follow immediately. All you need is to agree as a team on what standards you want to follow and corresponding guidelines. Just make a habit of following those standards whenever you write code. At the same time get the code reviewed by someone in the team so that it helps to see if it has any issues, two more pair of eyes is always better. You can use tools such as SONAR for finding the code review, dead code, optimization related issues and this will also save considerable amount of time. Manual review helps to enhance the knowledge on the code to the whole team over a period of time.

6. Feature Toggles:

Feature Toggles (aka: Feature flippers, switches, bits, flags) help you with hiding the partially implemented features when you work in a continuous integration environment. If you are working on 2 weeks sprints cycles and one of your features takes more than 2 weeks to complete and you want to release only after the entire feature is complete, then you can hide the feature related stories using this toggles concept. How does it work? Very simple, it works through configuration files. You create a configuration file with a set of toggles for different features that are pending or you don’t want the end user to see them. Most of these toggles will be used in the user interface layer. While using this practices, you need to make sure to few things that include: Test your code with toggle on and off, maintain these toggles in configuration file and remove the unwanted toggles.

7. Continuous Integration:

Continuous Integration helps you to be able to reach Continuous Delivery and you can make more frequent release of your software. Encourage your teams to integrate their code into a single code base every day multiple times. Why should I care? It saves a lot of time in terms of addressing integration issues. Imaging, your team is developing code in their local laptops/desktops and their code works fine in their machines. When they integrate it after huge amount of code is developed, does it guarantee that all the combined code works fine? Not always. Hence integrating often will help you to get feedback on integration issues so you can save effort and ensure your code is really potentially shippable. Remember: Agile principle #1 says “Our highest priority is to satisfy the customers with early and continuous delivery of valuable software“. Watch the two key words in the above principle: EARLY and CONTINUOUS. Also, principle #7 says: “Working software is the primary measure of progress“. How much code works fine in my local laptop does not matter, how much integrated code (features) work fine in the integrated/production environment is key. So, if you want to achieve these principle and delight your customers, you need to adopt the continuous integration practice.

8. Small Releases:

 I read somewhere, if release is a pain, do it often. So do not be afraid with release of your software into production. In the beginning you may get issues but I am sure the above principles will help you to achieve daily multiple releases as easy as eating a butterscotch ice cream :) Automation of build process, automated sanity and functional test cases etc also will help you to release often painlessly.

So why late, go ahead and add the above toppings to your scrum teams and start enjoying the awesome taste and become high performance teams.

Thank you for your time to read this post…hope you enjoyed reading this. Please provide your feedback and comments on this post…Thank you.

Simple Things You Can Do to Ease Your Agile Journey…Some Dos, Don’t s & Best Practices from my experience

This article is also published in Scrum Alliance Articles section on 1st July 2015.

I have been enjoying the Agile journey over the last six years, which has taken me through a large-scale organizational transformation. During this time I’ve had the opportunity to coach teams, ScrumMasters, product owners, and management. I would like to summarize some do’s, don’ts, and best practices learned during my journey.

I am not going to go into the details of each point here, because I want to keep it simple. If you have queries, suggestions, or corrections on any of the points, please leave a comment for further discussion.

I hope that this article helps you in your own Agile software development journey.

Management

What is the fifth principle of the Agile Manifesto?

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

To uphold this principle, follow these guidelines:

  • Be patient.
  • Create a vision for transformation.
  • Maintain constant communication.
  • Let the teams form on their own; guide them.
  • Don’t compare teams.
  • Don’t micromanage.
  • Encourage innovative thinking.
  • Rely on trends, not just on single occurrences.
  • Apply the Tuckman ladder model for team building.

Product owner best practices

  • Talk about what the work should do, not how.
  • Challenge the team, but don’t bully them.
  • Don’t focus only on short-term delivery.
  • Practice business value-driven thinking.
  • Understand the change, and cascade it.
  • Always be available to the team.
  • Don’t add changes during the sprint.
  • Create quality user stories.
  • Manage stakeholder expectations.
  • Manage the product backlog effectively. Keep it alive.
  • Track progress periodically.
  • Participate in planning, review, and retrospective meetings.
  • Don’t compare teams; that’s detrimental to team-building.
  • Focus communicating on the whole product.
  • Don’t introduce confusion.

Development team best practices

  • Form as a team on your own, although accepting help is usually smart.
  • Create an identity for your team.
  • Choose your ScrumMaster.
  • Ensure that your team is self-organized, cross-functional, and empowered.
  • Pull the tasks for the sprint. Don’t wait for someone to assign the feature items.
  • Respond positively to change.
  • Create your team space.
  • Ensure that your team is co-located.
  • Ensure that all team members have the same understanding of the sprint goal.
  • Encourage face-to-face communication.
  • Evangelize We over I or you.
  • Care about the whole product.
  • Avoid silo-based thinking.
  • Always deliver quality working software.
  • Inspect and adapt regularly.
  • Clear your level impediments. Don’t look for other impediments.
  • Facilitate team-bonding activities.

ScrumMaster best practices

  • You are the change agent.
  • Be courageous when making decisions.
  • Protect your team and clear their impediments expeditiously.
  • Bridge gaps between team roles.
  • Be a true servant leader.
  • Observe the patterns your team exhibits so you can all learn from them.
  • Give feedback, and be receptive to feedback given.
  • Keep constant communication alive with the team.
  • Be your team’s coach.
  • Manage conflicts swiftly and fairly.
  • Don’t own product decisions; work with the team and the product owner.
  • Don’t estimate for your team or give technical solutions.
  • You are not the team’s manager. Don’t assign them tasks.
  • Facilitate all Scrum events and meetings effectively.
  • Be creative; try new approaches to retrospectives and other recurring events.
  • Motivate your team, from the mico level of writing better stories to the macro level of creating the best product possible.

Scrum events best practices

Sprint planning

The sprint goal is the key to the sprint’s success.

  • Ensure that the planning is timeboxed.
  • Enforce the PO’s attendance at the meeting.
  • Encourage collective participation.
  • Estimate story size through story points.
  • Estimate tasks in effort hours (<6 hours).
  • Pull tasks; do not assign them.
  • Ensure that stories meet the Definition of Ready (DoR).
  • Check whether the Definition of Done (DoD) needs adjusting.
  • Update the task board after planning.
Daily Scrum
  • Keep the meeting to 15 minutes or under.
  • Enforce attendance by all team members; only the ScrumMaster’s attendance is optional.
  • Hold the Daily Scrum at the same time and the same place each day.
  • Focus on the three critical questions: What did you do yesterday?What will you do today?, and Are there any impediments in your way?
  • Avoid extended discussions.
  • Start at the scheduled time.
  • Hold the meeting in front of the task board.
  • Track impediments.
  • Ensure that the team speaks only to other team members.
Sprint review
  • Ensure that the review is timeboxed.
  • Enforce the PO’s attendance at the meeting; invite others who are interested.
  • Show only items that satisfy the DoD.
  • Collect feedback on the sprint items.
  • Demo on an integrated environment.
  • Ensure that the PO manages other stakeholders.
  • Discuss the incomplete items and the actions to resolve them.
  • Identify and discuss the probable items for the next sprint.
Sprint retrospective
  • Ensure that the retrospective is timeboxed.
  • Enforce the Scrum team’s attendance at the meeting.
  • Follow the five stages of the sprint retrospective: Set the stage, gather data, generate insights, decide what to do, and close the retrospective.
  • Don’t always follow the same model in every meeting; be creative.
  • Allow everyone to speak.
  • Discuss problems, not people.
  • Don’t play the blame game.
  • Track action items for improvement.

Scaling Scrum best practices

  • Choose a suitable scaling model based on your organization’s needs: Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), or Disciplined Agile Delivery (DAD).
  • Ensure that you satisfy the following conditions:
    • Coaches are trained and experienced.
    • Joint grooming of product backlog exists among Agile teams.
    • Co-located release planning exists (whenever possible).
    • Established release walls exist for promoting cross-team feedback.
    • Joint sprint planning is conducted with other Agile teams.
    • Common sprint schedules exist for all Agile teams.
  • Use release burn-up.
  • Implement a global impediments board.
  • Conduct joint retrospectives.
  • Participate as ambassadors in the Scrum of Scrums.

Engineering best practices

  • Adapt a value-based engineering culture.
  • Don’t force ideas; get the team’s buy-in.
    • Uphold the following principles in the engineering department:
    • Test-driven development
    • Re-factoring to makes sure the code design is simplified
    • Pair programming
    • Collective code ownership
    • Continuous integration
    • Automated fault-slip-through (FST)
    • Single-trunk development
    • Feature toggles
    • Sonar or any other tool integration
    • B2D tools
    • Visible architecture

Key characteristics of information radiators

Don’t use information radiators as a mechanism to criticize or compare.

Effective information radiators have the following key characteristics:

  • Large, easily visible
  • Understandable at a glance
  • Convey same meaning to casual and interested visitors
  • Can be used as the base media for:
    • Team-level, physical task boards
    • Organization-level impediments by using a Kanban board
    • Root cause analysis on critical items
  • Keeps team progress up to date
  • Simple navigation and auto display change
  • Alarm for build failures

Mechanisms for cultivating a Community of Practice (CoP)

A Community of Practice is important for transforming a traditional plan-driven organization into an Agile one.

A Community of Practice is cultivated by doing the following:

  • Sharing knowledge and best practices
  • Providing a forum to get secure cross-functional support in the organization
  • Applying the same practices across the organization
  • Separating ScrumMaster and architecture CoPs
  • Facilitating problem solving
  • Reusing solutions
  • Learning from others’ failures
  • Keeping the CoP self-sustained

Improving communication

Agile communication is open, transparent, and healthy. Successful communication requires that you perform the following activities:

  • Become an active listener.
  • Use fewer electronics.
  • Implement osmotic communication.
  • Avoid blame games.
  • Create a forum for constructive disagreements and not for conflicts.
  • Invest in tools (whiteboards, Blue Jeans or other videoconferencing, etc.).
  • Talk more; write less.
  • For distributed teams, fly in key people for key events.

Ensuring quality

Ensuring quality is the collective responsibility of the Agile team.

  • Uphold the DoR and the DoD.
  • Ensure continuous informal product reviews.
  • Establish coding standards.
  • Encourage simple and just-in-time (JIT) design.
  • Follow engineering practices.
  • Implement automated testing.
  • Write clear user stories and acceptance tests.
  • Conduct frequent code reviews.
  • Ensure continuous integration.
  • Use retrospectives for continuous improvement.
  • Develop a one-click build process.

Tools for tracking and monitoring

Decide which tools to use based on the organizational working model. Tools provide visibility into the team, the project, the program, and the portfolio. They also keep the data up to date. However, the garbage-in/garbage-out philosophy still applies.

  • Use suitable tools, such as VersionOne and JIRA Agile.
  • Use the same tool for all locations.
  • Complete training on tools for all teams.

 

Scrum Teams Can Be Inspired by Mother

You can also find this Article Published at Scrum Alliance website:

https://www.scrumalliance.org/community/articles/2015/january/scrum-teams-should-be-inspired-by-mother

Ever since I started working in Agile, I have been observing my wife’s way of working and how she manages our kids’ dynamic expectations. I keep seeing ways to correlate her methods to Agile. I thought of mapping my observations to some of the Agile principles — as a metaphor. I know that in other households, the various roles may be handled differently and by different people. Based on my observations, however, I’ll put it this way: Why can’t Scrum teams be inspired by a mother? Here are my thoughts.

 

Mother works steadily

In order to prepare the kids for school, she completes activities such as cooking food for them, helping them get their clothes ready, etc. She does these activities almost every day and she has limited time. If on any day she gets delayed in any of these activities, that day kids might be delayed in getting to school.

This highlights Agile Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The Scrum teams should be inspired by mothers to deliver working software at the end of every sprint by continuously managing their work effectively and with the expected quality. For this, they need to work collaboratively, with good planning, having a proper Definition of Done in place. Their objective should be to achieve the sprint goal always by managing unpredictability through collaboration and teamwork.

Mother handles changes well and is proactive

Very often I observe my kids go to the kitchen in the morning while my wife is busy cooking, and they ask for some changes in the menu. Most of the time she will not get upset but will negotiate with them about which changes can fit within the available time frame.

This highlights Agile Principle #2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Similarly, Scrum teams also have to change their mind-set and understand that the product owner has flexibility in managing the scope as per the product vision and ROI of the product. This will increase product success. Of course, they need to remember what the Scrum framework recommends about the changes, and accordingly they need to respond. So the changes have to be discussed with an intention of how they can be adapted without deviating too much from the sprint goal. This is possible through face-to-face conversation with the product owner.

Based on what needs to be prepared for the day’s lunch and snacks for the kids, most of the time I observe my wife preparing things ahead — cutting the vegetables, checking what the kids like/need for lunch, making snacks, purchasing items the day before they are needed. This will make her job easier the next day and the work can be done more smoothly.

So this highlights Agile Principle #4: Business people and developers must work together daily throughout the project.
and
Principle #6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Scrum teams should care and give importance to product backlog grooming so that their sprints will not have turbulence. They also need to work closely with their product owner and give importance to face-to-face conversation instead of emails.

Mother plans and executes effectively

If you observe the way Mother plans and executes her work, it’s amazing. She knows the priorities well, she knows which task takes more time and which tasks take less time, and she allots time to them accordingly. She also identifies the tools that help her complete work with her expected quality and within the given time. Even though she does similar work every day, she does not take it lightly and aims for continuous improvement.

She cares about the work that is required to meet the timeboxed duration by pushing the “unwanted” work back. This can be done by proper prioritization and assessing the need of the work.

This highlights Agile Principle #8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
and
Principle #10: Simplicity — the art of maximizing the amount of work not done — is essential.

Scrum teams also should know which is the highest-value story and which is of lowest value, and accordingly they need to deliver them to make sure working software is delivered at the end of the sprint. They also have to give equal importance to engineering practices such as continuous integration and test-driven development, collective code ownership, refactoring, etc. They always have to strive to deliver rapid value in terms of working software with technical excellence.

Scrum teams also have to understand what is required and what is not, and accordingly they need to push back the things that are not required. They need to know the requirements that deliver the majority of the revenue from the product (80-20 rule, or Pareto principle). This needs constant communication and collaboration among the product owner, team, and the stakeholders.

Mother is innovative

Many times, I observe that my wife creates new recipes by following sources such as YouTube, Google, etc. This makes the kids (stakeholders) happy. Also, she is a continuous learner, even though she has already gathered great experience and expertise in her area of work.

Agile principle #9: Continuous attention to technical excellence and good design enhances agility.
and
Agile principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.

Scrum teams should spare some bandwidth to enhance their cross-functional skills and sharpen their technical caliber on an ongoing basis. It is good to come up with a team-level learning plan by identifying current primary skills and secondary skills the team wants to achieve and planning to mentor each other. The key thing is to make it timeboxed and set a target date, with periodic tracking of progress.

The team can get support from the ScrumMaster to receive external training in case no team member has the required skill to train the others.

Mother takes regular feedback

Even though she does similar kinds of work every day, Mother asks the kids about the food and whether they liked it or not. This helps her improve wherever required. This highlights the Agile principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So it is essential for Scrum teams to have regular retrospective meetings to check where they are good and what needs to be improved so that they can become high-performance teams over a period of time. It should not be just like any other meeting; they have to gather the sprint data, generate insights from the data, and then come up with action items and prioritize those actions for implementation in upcoming sprints.

One thing the ScrumMaster has to follow here is the trends of the retrospective outcomes. Things that are working fine should continue to work fine, and things that are not working well should change so they can start working fine. This will help the Scrum teams become high-performing teams. Maintaining the details of the retrospectives, watching the trend analysis, coming up with suitable solutions, and mentoring the teams in those areas will be the responsibility of the ScrumMaster.

Mother does not get paid

Whatever great work Mother does, she does not get directly paid for it. However, she takes care of the family regardless.

I know this is hard to digest, but I feel that Scrum teams have to focus on their delivery without worrying much about salary hikes, promotions, etc., so that their work will show what they are capable of as a team. Becoming high-performance teams will bring them success in their work lives. 

Hold the ball longer…stronger… together

This is an activity to describe How to manage your code effectively as a TEAM

Timing: This game may take from 20 to 30 minutes

Materials: A multicolor light weight ball, 6 strong sticks or plastic pipes with 21 inches each stick/pipe length, space to walk around while playing

Instructions:

  1. Game brief:

Invite at least 6 volunteers to play this game. We are going to experience various scenarios in this game to demonstrate the need and importance of “collective code ownership” concept.

The volunteers have to come close and hand over them the sticks/pipes. Tell them the ball is their code base. In each scenario they have to make sure to play the scenario without dropping the ball. If balls drops then 1 penalty point. If they complete each scenario without dropping the ball then they get a bonus point. At the end of the game their total score will confirm how they could manage their code.

We need to keep a fixed time period to complete all scenarios mentioned below). This is to make the activity timeboxed.

Team can move to next scenario only after the previous scenario is done successfully without dropping the ball.

Note: If you are playing this game with more than one team then keep a separate scoring board to track the time and final score of each team.

  1. Scenario – 1: Your code increases over a period of time

2.1.         All the participants need to sit on their knees and hold the sticks/pipes with their one hand (left or right does not matter) and try to keep the ball balanced on those sticks. They should not use their other hand at all.

2.2.         Participants have to stand on their feet without dropping the ball.

  1. Scenario – 2: Your code is not static, it changes all the time

3.1.         Ask the participants to walk from their current place to a distance of 5 feet

3.2.         Ask them to make a rotation of their places

Image for 3.2 section

  1. Scenario – 3: One team member develops more stories (more code)

4.1.         One person pushes the ball hard

4.2.         Rest of the members to balance this scenario

  1. Scenario – 4: Change the roles

5.1.         Ask the members to switch their positions (not immediate left or right)

5.2.         They need to keep the ball balanced on the sticks/pipes while they rotate their positions

Image for 5.2 section

  1. Scenario – 5: A very important story came up!

6.1.         Tell the team that the Product Owner has come up with a very important story

6.2.         The story is to rotate the ball in such a way that the color that is on the bottom side should come to the top

6.3.         They should not use the free hands and they need to just rotate the ball using their sticks/pipes

 Image for 6.3 section

  1. Scenario – 6: Couple of members on vacation

7.1.         Ask two team members to drop their sticks and leave the game abruptly

7.2.         Remaining members should be able to manage the ball with remaining sticks/pipes

Learning Points:

The team understands the importance of following concepts:

  • Code should be developed with proper supporting tests
  • Code should be stable even the team is adding new code
  • All the team should have a fair idea on the code base and it should be a collective responsibility and not any more individual owning. Even there is a specialist developers writes some critical parts, there must be a knowledge transfer planned to get everyone up to speed
  • collective code ownership, making the code stable always, quality of the code should be as per expectations
  • Team should be cross functional so that they can manage the code effectively
  • Manage the technical debt time to time and do not go for work-around solutions or short term fixes

Approach For Large Scale Agile Transformation

This article was published in Scrum Alliance website at:

Introduction

I was part of a large-scale Agile transformation recently. It was a great learning experience, and I want to share my experience of the transformation.

Scope

This document covers the information related to a large-scale Agile transformation (hereafter referred as just transformation), based on my personal experience and knowledge. I am trying to collate my experiences and I created this article thinking that it can help as a guide for others.

Definition of a large-scale Agile transformation

Where there are multiple teams working on multiple services/products/projects from various different locations having different policies, culture, time zones, and technologies being used. Most of the time, more than one team shares the same backlog with the same sprint schedule, if those teams are working on the same product.

Groundwork for the transformation

Any organization that would like to shift to Agile has to assess the need of the transformation. The assessment should include the following points:

  • Are there any issues with the current software development approach?
  • Is the current time to market helping the organization achieve the revenue targets?
  • Are the customers of the organization happy with the products?
  • Are the products that are being delivered having expected quality?
  • Are there any gaps between the product management and software development teams?
  • Is there productivity loss due to considerable amount of rework on the delivered products?
  • Is the current feedback loop not working to catch up with market fluctuations?

If the majority of the points above prove to be negative, then it is time to move to Agile transformation. Agile can help solve most of these issues in a positive way due to its simplified frameworks, engineering practices, collaborative way of working among product teams and development teams, small and colocated teams, etc.

Decide on the transformation approach


There are two ways to transform the organization into Agile. They are: Phased and Big Bang implementations. Based on my experience, it will be effective to go with a Phased approach in which we identify the teams that have less pressure on delivery and introduce them to Agile by providing a dedicated two to three days of training. Then we would provide coaching to those teams for a few sprints and get them to a stable level. This process will have to continue till all the teams of the division/organization are transformed. This is an iterative and incremental approach.

Also, you must decide which Agile frameworks (Scrum, XP, DSDM, FDD, etc.) will be suitable for the organization. If there is maintenance work, then Lean and Kanban also can be considered.

The training program will have to include the contents below as well as some class activities/games to explain the concepts in an easy and straightforward way to the participants:

  • Why Agile
  • Agile introduction and fundamentals
  • Agile values and principles
  • Lean and Kanban introduction
  • Respective framework explanation in depth (e.g., Scrum/XP/DSDM, etc.)
  • Agile estimation
  • Agile communications
  • Engineering practices
  • Other related topics

Important: There should be training planned and conducted for the product teams, and this is critical. In Agile, the product owner is the person who is responsible for the product vision, ROI, and success. So if that person doesn’t have a proper understanding of Agile values and principles — concepts such as value-based prioritization, product backlog management, working with delivery teams with a sense of collaboration, release planning — that will impact the entire transformation.

The executive management team also has to undergo some coaching and briefing to set the right expectations about the transformation. This will further help seed the mind-set change within the management team.

Decide on the transformation road map

This can be done based on the number of teams to be transformed, their locations, how much coaching they need (how many sprints), etc. Budget also plays a key role in planning the road map. If you can afford it and the time line is your key constraint, then you can bring experienced external Agile coaches in to complete the transformation within a shorter time frame. Otherwise, you can develop a few internal Agile coaches and create the road map accordingly.

My recommendation is to have at least a few external coaches because they come with previous experience of other organizations’ transformations, challenges, and best practices.

Decide on structural changes and plan for them carefully

Structure plays a critical role in changing the culture. Agile is all about mind-set (culture), so the transformation team has to consider whether there are any structural changes that need to be done as part of the transformation. They need to be in sync with the senior management team in order to manage management expectations, company reputation, employee expectations, etc.

Do not just try to fit the organization’s existing roles into Agile roles. That might not work, and mismatches could impact the entire transformation process.

Decide how to measure transformation progress

This means inspecting and adapting for the transformation process and making necessary changes based on needs. This is also a critical step because if the progress is not as per expectation, organizational strategic objectives could be affecetd. I recommend having a core team within the transformation team (maybe a lead coach and a couple of other coaches) that works together closely to make sure everything is going as per plan, and to respond to changes effectively. This monitoring has to happen periodically after the transformation starts and continue until it is complete.

It is good to have a maturity model in place, against which to measure progress. You could create an Agile Maturity Score Card with a list of areas and corresponding weight for each area, or create different maturity levels and assess the teams against those levels. For example, below is one way to assess the maturity of Agile teams using a maturity level-based assessment.

Level 1 Maturity (SHU)

  • Understand the Agile values and principles from the point of view of value.
  • Conduct all Scrum ceremonies as per the guidelines.
  • Collaborate visibly within the team.
  • Have the product team and development team work toward a common goal (vision).

Level 2 Maturity (HA)

  • The team delivers working software at the end of the sprint.
  • The team follows proper estimation methods and is consistent in terms of understanding.
  • Velocity can be measured.
  • Basic engineering practices are introduced and practiced (pair programming, TDD).

Level 3 Maturity (RI)

  • Velocity is consistent and the team tries to improve its velocity.
  • Feature teams are formed.
  • Advanced engineering practices are implemented.
  • Continuous integration is in place.
  • Teams come up with innovative ideas to improve the delivery.

Please note, it naturally takes some time to move from one level to another. It depends on several factors. Moreover, the time needed to move from one level to another may not be same for all teams. The transformation team has to keep this point in mind and plan the necessary arrangements.

Check the impact at the organizational level for various policies

There will be definitely some changes required in terms of some organization-level policies — for example, the performance appraisal process. Based on the duration of the transformation, the transformation and senior management teams have to work with the HR team to come up with a suitable process for performance appraisals.

My recommendation is to create an appraisal process whereby there will be more importance given to team-based appraisals rather than to individual-based appraisals. However, it could be a combination of the two.

Decide on the required changes to tools

Your organization may be using some tools already as per the existing software development method. Those tools may not be suitable for Agile-based methods, however. So in this case the transformation core team has to identify the suitable tools and plan to present them to the teams. The selection of tools will be dependent on the organization’s size, the number of locations from which the organization operates, etc. If your organization is small, then a simple Excel workbook will be sufficient to manage an Agile project. If your organization is large and has multiple delivery locations, then you might want to try tools such as VersionOne, HP Agile Manager, JIRA Agile, etc.

You may need to plan on a separate training session just for these tools. This training can be provided once teams complete their basic Agile training and complete a few sprints.

Start the transformation

This is the step where the actual transformation gets kicked off. In this phase, the teams that are identified for the transformation will first undergo the two to three days of classroom training, in which coaches will cover the key topics using a slide deck, some classroom activities, and games.

After the training, these teams will be assisted by the coaches for at least four to five sprints. At this point, the teams will start implementing the Agile frameworks for their projects. The coach will closely work with the teams on all the Scrum ceremonies and help them understanding the framework from a value perspective rather than a practice perspective.

During the initial few sprints, I strongly recommend that the teams use a physical task board so that they will see how the stories and tasks are moving and how the team needs to collaborate. Once they are familiar with the framework, they can move to any tool, such as VersionOne.

Keeping visible information radiators is important for the Agile teams during transformation. One idea that can get high transparency of transformation activity is to have a “coaching Kanban board” at a central location in the organization. On this you can display the teams that are pending for training/coaching, teams that are in progress for coaching, teams that have completed coaching and started sprinting on their own. This board has to be managed by the coaching team and must be kept up to date. You can also try the WIP (Work in Process) limits, based on the coaches’ bandwidth available for the in-progress column.

Also, the coaches should practice a daily stand-up at their level in front of the coaching Kanban board, so that they practice what they preach. This will influence the teams in a positive direction to practice the Scrum ceremonies effectively.

Track the progress based on the progress plan

This should be a continuous activity that happens at periodic intervals. The transformation team has to gather required data from the teams and check against the maturity levels or the score card described above. Based on the result, required amendments have to be planned in order to achieve the expected goals for all the teams in the process of transformation.

There may be few challenges you observe during the transformation, and they are discussed in a separate section below.

Make changes as and when required

As part of the tracking of the transformation, you may find some gaps or identify some improvements. Those have to be plugged into their respective areas and you can see how it impacts the ongoing process. Based on this, you might need to extend the transformation time for some teams, or you might need to continue the dedicated coaching for a few more sprints to cover maturity gaps.

Expand the transformation

Once the first set of teams is done with the transformation and achieves the maturity level you expect, you will be able to get a grip on the time needed. This you can consider “transformation velocity.” This will help you come up with required adjustments to your transformation road map and proceed further.

Decide on scaled Agile implementation

Once you complete the transformation at one location, you need to look at choosing a scaling model. There are several scaling approaches already available, but as far as I know, SAFe and LeSS are the two approaches most often chosen by organizations for scaling. Both approaches have pros and cons, so you need to review them thoroughly and decide which approach will work best for your organization.

It’s important to remember that you may have to give a short training to your teams on the scaling model that you have chosen, involving normalized story points, joint Scrum ceremonies, etc., based on the approach that you go with. Hence the teams have to have a good understanding of these topics first.

Also, when you go for a scaled approach, it’s good to have common release schedules so it will be easy to manage the ceremonies and have a better forecast. If for any reason one team falls back, then they can have either a shorter sprint or an extended one in order to catch up with the common release schedule with the other teams.

Possible challenges and corresponding solutions

1. Management buy-in and patience

  • Budget and time required for transformation
  • Fear of loss of productivity during the transformation
  • Possible push for a big-bang approach
  • Expectance of quick maturity, so an expectation of improved delivery from the first sprint
  • Forcing a return to old ways when it takes longer than expected to see results

Solution: Management buy-in is key for any transformation, so setting realistic expectations up front is critical. The transformation core team has to provide coaching and briefing to the management team so that they will have an idea of the expected outcomes and plan accordingly to choose teams for the transformation.

2. Teams might feel the new approach is more pressure-filled.
Solution: Change takes time to become visible. Set expectations for the team early, and make them start with baby steps so that they can see results quickly. Also, initially teams are not cross-functional and they will be in forming and storming stages, so it is good to take a small amount of work so that pressure will be under control.

3. Scrum ceremonies turn into any other general meetings.
Solution: If the ceremonies are not strictly timeboxed, they will become normal meetings. Also, the specific agenda to be circulated for each ceremony, and ensure that people come on time for meetings. Coaches should play an important role initially so that teams understand the value of the meetings and follow the guidelines.

4. Initial sprints may not deliver any working software.
Solution: It is natural that the teams cannot have a proper rhythm initially. So let them choose small and easy stories first that deliver at least some business value, and let them try to deliver those stories. Slowly they can expand the delivery volume while they become cross-functional. The coach must encourage the team to become cross-functional and support them in achieving that.

5. Teams may not want to become cross-functional, as they may feel their primary skill will be impacted negatively.
Solution: This is related to mind-set. A developer does not want to become tester and vice versa. The coach can help them understand the importance of developing secondary skills based on their interests and capabilities, and slowly try to get them there. Let the team try to do pairing up so that slowly it will create interest in developing secondary skills.

6. Documentation may go for a toss with wrong understanding of Agile values and principles.
Solution: One thing that has to be emphasized during the trainings and coaching is that “Agile does not say documentation is waste.” However, it is fine not to follow any template or format to document. So encourage the teams to take pictures from whiteboard discussions and record the important meeting sessions for reference, and use some kind of shared information space such as MOSS, confluence, etc.

7. Quality may be impacted in the hurry of delivering stories.
Solution: Quality and speed do not go hand in hand unless there is good practice and close collaboration. So the product owner, ScrumMaster, and the teams have to work very closely to define the Definition of Ready, Definition of Done, acceptance criteria, informal reviews based on need, etc. These will help achieve the expected quality.

8. Product owners misuse the flexibility of “responding to change.”
Solution: First of all, every change has some cost involved, and some value too. The product owner and team should discuss and then act on changes. Sometimes changes that do not have any value may be requested by the product team, and the teams have a right to ask why that change is required. So product owners have to know the value-based prioritization.

9. Teams get into a compressed Waterfall way of working.
Solution: Some people say that within a sprint we should work in Waterfall. But this is not really true; the coach has to change this thinking and make the teams work inan iterative and incremental model. They need to take the top one or two stories from the sprint backlog and complete them end to end, then move on with the rest of the stories. This will ensure that the team will be able to deliver business value at the end of the sprint.

10. Attrition
Solution: When you make changes to the structure to get a change in culture, it might create some disappointment among employees. Especially for people who worked with an authority earlier, working in a servant-leader role is not now appealing. So it is sometimes not avoidable, but along with management impact analysis, it needs to be done and proper knowledge transfer has to be done by the people who want to move away.

Some best practices

  • Initiate a “community of practices” to share knowledge and best practices.
  • While creating the teams, try to have a team self-forming activity
  • Try a pod structure to change the organizational structure.
  • Keep big, visible information radiators and keep them up to date.
  • Expose impediments through a visible board and try to close them before they impact the sprint goal. Encourage that teams resolve the impediments at the team level, and coach the ScrumMaster to solve the beyond team-level impediments.
  • Define a small set of metrics and take the teams’ buy-in for those metrics. Below are some metrics you can try:
    • Sprint goal success rate: This metric helps Scrum teams realize how continuously they are delivering value to the customer. If this is low, that indicates there is some issue within the process that has to be fixed. Reasons could be taking too much into the sprint, requirements changing during sprints, team skill-set issues, collaboration problems, or other reasons.
    • Velocity: To see the rate at which teams are delivering stories (business value).
    • Sprint burn-down: To show what is remaining in the sprint, it can be effort hours, number of stories, story points, etc.
    • Release burn-up: Helps the product owner come up with a forecast for the remaining product backlog items.
    • Cycle time (if you are using Kanban): Helps you assess the cycle time and, by using continuous improvement tools, you can come up with a plan to improve that cycle time.
    • Escaped defects: This helps the teams see how quality is managed in their delivery. If it is increasing sprint by sprint, that means quality is getting decreased, so you need to plan to improve it.
    • Team happiness index: This is another powerful metric to see how well the teams are motivated. The team’s feelings will have a direct impact on their productivity. Measure this at the end of every sprint.
    • Customer satisfaction: This metric will help you see how happy your customers are with your delivery pace and process. You can measure it through a questionnaire run on a periodic basis.
  • Do not use metrics to compare teams. Also, don’t select metrics that are easy to capture but not useful.
  • A monthly newsletter will help communicate the progress of the transformation.
  • Periodic executive management updates to all employees will also boost the transformation.
  • Try to automate build, deployment, and testing as much as possible, with alerts enabled. This will eliminate a lot of waste and you can achieve mistake-proofing.

- See more at: https://www.scrumalliance.org/community/articles/2014/december/large-scale-agile-transformation-approach#sthash.ggk3KOkD.dpuf Read more

Tips to conduct effective joint product backlog grooming meeting in scaled agile

If you have a plant in your garden, and if you do not take care of it through regular grooming, it grows in all directions and will become unmanageable over a period of time. So you spare sometime to cut the extra grown branches, remove the dead leaves, apply pesticides etc to support the plant’s well growth. Similarly, in Agile software development also we take care of the product in terms of removing the unwanted features, removal of defects, ensuring only valuable features are prioritized for implementation etc. There is a specific event in the Agile product development to conduct these activities. That event is called Product backlog refinement (a.k.a. product backlog grooming) and it is a key event in Agile product development.

The product backlog refinement helps to keep the upcoming backlog items discussed in detail and line them up for the future sprints. So this will improve the rhythm of the scrum team and by the time the scrum team reaches the next sprint planning meeting, the items will have clear information.

Definition of Ready (DOR) is a key artefact that has to be considered in the product backlog grooming. The DOR is a criterion that will ensure the stories groomed in the refinement meeting are “Ready for the next Sprint”.  The product owner and the team will discuss what should be the feasible DOR and agree on the items. Below are some important aspects that can be part of the DOR:

ü  The story should have complete clarity from the “what” aspect

ü  The story should be feasible in one sprint (that means small in size)

ü  The story should be testable (that means acceptance criteria defined)

ü  Any assumptions, constraints, dependencies are identified and addressed

ü  The story should meet INVEST principle

What happens in the product backlog grooming meeting?

  • Discuss the stories to get clarity (only what part but not how part)
  • Split stories if they are large
  • Merge stories if they are too small
  • Discuss acceptance criteria
  • Discuss the assumptions, constraints
  • Identify dependencies
  • Estimate the stories using story points

When you are working as a single Scrum team on one product backlog, it will be pretty much clear and you may not see major issues for the product backlog grooming. However, when you have more than one team working on same product backlog, there will be some common issues observed. If we do not tackle these issues effectively it will become another general meeting without any valuable output.

What are the issues in joint product backlog grooming?

  • Timely starting of the meeting is very rare
  • It takes longer than planned duration
  • Very few stories are groomed and they may not be enough for next sprint
  • Which team needs to groom the backlog item?
  • Should everyone from every team attend the backlog grooming? If so is it not time waste?
  • Who will estimate the size of the backlog item?
  • Who will split the stories into technical tasks?
  • Teams tend to pick up easy stories and leave the hard stories behind
  • More than one team wants to work on same story (when it is technically challenging/interesting)
  • Sometimes no team wants to work on a particular story (may be its not really challenging)

So how do we tackle the above issues?

It will be good to have a “common working agreement” in place to resolve the above issues. It is very common for the Scrum Teams having a “working agreement” at their team level when it is a single scrum team working against a single product backlog. When there are more Scrum teams working against same product backlog, it will be useful to have a “common working agreement” across all the teams in addition to the team level working agreement.

What will be part of the “common working agreement”?

ü  Define a commonly feasible time for the meeting and get buy-in from all teams

ü  Define the approach for the teams to choose the stories in the product backlog grooming meeting. Some approaches you can try as below:

  • Round robin
  • Clockwise
  • Anti-clock wise

ü  If for some reason one team cannot pick a story then the next team has to pickup

ü  Define a common baseline story and size it (better to have 2 baseline stories like 2 & 5 or 3 & 8 story points)

Some useful tips to make the joint product backlog grooming effective:

  1. Before the meeting, ensure the scrum masters from the respective teams should check with PO and have the backlog prioritized with stories for the further discussion the meeting
  2. The Scrum masters should ensure the team members are aware of this meeting and they plan to come on time
  3. Definition of Ready is prepared
  4. Initially let all team members along with their Scrum Masters attend the meeting and based on the need you can plan to have representatives from each team on rotation basis. In this case the representatives will go back and update their respective teams
  5. Keep a specific timebox slot for each story grooming. If it is taking longer than that duration someone should act as time keeper and move to next story
  6. All teams should respect the common working agreement
  7. Scrum Masters should observe the behavioural smells from this meeting and coach their respective teams on the areas that need improvement.
  8. Periodically review the DOR and common working agreements to update the suggestions or changes needed to make them effective
  9. Try to apply lean principles like eliminate waste, differ commitment wherever applicable
  10. Encourage open and transparent interactions across the teams in the meeting

Scrum Master – the “Team Spirit” Guardian

I have published this article in Scrum Alliance website, please read it in their website.

 

http://www.scrumalliance.org/community/articles/2014/april/scrummaster

Understand Scrum in a simple metaphor (Medicinal Agility)

I and my colleague Madhavi were discussing in general about Agile and Scrum last week. During the discussion she has suggested that it will be nice if there is a simple explanation about Scrum framework using a common language that makes the concepts easy to anyone. During the discussion we had come up with below explanation.

This article is also published in scrum alliance website:

The Metaphor:

Assume that if some falls sick, he/she visits a doctor for clinical check-up and follow the doctor advice to get well soon. So considering this scenario, we tried to explain the Scrum concepts.

1. Find out which medicine suits your body? [Which framework should I use? Scrum or Kanban?)

Which flavour of Agile is suitable to your team should be analysed first. It is as simple as just like we have various flavours of same drug like paracetamol, Colpol, Crocin for curing fever and not every medicine suits you. So what do we do? We first try with one flavour and experiment with it for some time and if it suits your body, then we continue with it until you are completely recovered.  Else we would try a different flavour.

Exactly similar, is the case with Agile. We do some initial study, start using scrum or Kanban and see how it works for a sprint and then decide whether we want to continue with it or use a different method. Of course if you clearly know you cannot plan at least for one week then you better go with Kanban model, else Scrum.

2. Find out what dosage suits your body? [What is the Sprint Cycle]

Based on various factors like age, weight and intensity of fever, we decide on the dosage of the medicine to be used. Similarly based on factors like how long backlog can be fixed, how often requirements can change etc., the sprint cycle duration needs to be worked out.

If we haphazardly vary the dosage i.e. if we take one dose of medicine today and two doses next day and skip the does in between, the ailment that we are trying to cure becomes worse and the situation goes out of control and our body may develop resistance to that medicine. Similarly, if we try to vary the sprint cycle haphazardly from 1 week, to 2 weeks and back to 2 weeks etc. frequently without having any rhythm, it would be very difficult to see the results and the project would become unpredictable and may end up in a chaos.

You may experiment for a couple of models and fix to one model.

 3. Planning and Execution as per the dosage: (Sprint Planning/Daily Scrum)

After the flavour and dosage of the medicine is decided, doctor (Product Owner) advices the exact medicine names that need to be taken and in what order as per the priority i.e. may be a multi vitamin tablet first followed by an antibiotic etc. We go ahead and take the medicines that is consume them in however way we want, i.e. some take them with water, some may make it a powder and dissolve and drink, sometimes you mix it in food and give to kids. So if you observe the scenario here, the WHAT part is being decided by the doctor and the HOW part is decided by the person taking the tablet. Similarly, in the sprint, WHAT to achieve is decided by the Product Owner and HOW part is decided by the team.

4. Re-check and Feedback on how did the medicine work (Review & Retrospective):

After the completion of the medicine course for the given period, we go to the doctor for re-check up to evaluate how the medicine worked and if the tablets or dosage needs to be changed for the next cycle if needed.

In a similar fashion at the end of the sprint you will give a demo to the Product Owner and the team will conduct a retrospective to inspect and adapt.

5. Daily alarm for the consumption of medicine (Daily Scrum Meeting):

In order to have effectiveness, you take medicine at same time and same dosage every day. For this, you may have some mechanism like mobile alarm to remind you. You might check the progress in your health day by day.

Similarly, in Scrum you will have daily scrum meeting for timeboxed duration (up to 15 minutes) and share everyone’s update and the by-product of this meeting is the status of the work progress.

Conclusion: The scrum framework is very simple common sense which we really practice day in and day out in some or the other way, so maybe we just need to make a good quick short experiment to figure out what suits our nature of the project and execute it the right way and it would really work wonders. However, do remember that it is really hard to master in Scrum unless you have thorough understanding on Scrum Values and follow the framework with a high level of discipline and passion.