10 Expert Agile Tips and Techniques

10 Expert Agile Tips and Techniques

This article covers the expert agile tips and techniques for your reference. You can use these valuable insights to create effective, self-organizing teams. These tips are in no particular order, so feel free to skim down the list and read the ones that are most suitable for you.

 

Agile Tip # 1: Discipline

Agile Tips - Discipline

Discipline is the key ingredient in achieving extraordinary results. It brings stability and structure to one’s work or personal life. It takes discipline to attend scrum ceremonies, meet sprint commitments, and continually learn.

“Discipline is the bridge between goals and accomplishment.” - Jim Rohn

 

Agile Tip # 2: Team Collaboration

Agile Tips - Team Collaboration

In Scrum, the entire development team is responsible to ensure that sprint commitments are met. A team member who has completed his assigned tasks should look to assist other team members who need help. The team should practice empathy towards others, learn new skills, and meets their commitments.

 

Agile Tip # 3: Story Point Estimation

Agile Tips - Story Point Estimation

Story points are a relative unit of measure for estimating user stories. A team’s story point estimate should include: 1) the amount of work 2) the complexity of the work 3) any risks or unknowns in doing the work 4) must-have items on your definition of done.

 

Agile Tip # 4: Splitting User Stories

Agile Tips - Splitting User Stories

Split your stories into small stories. Resist the temptation to group items together to avoid the management overhead. Smaller stories flow better through the sprint. Imagine 1,000 marbles working their way down a chute rather than 100 basketballs working their way down the same chute. Smaller stories are easy to estimate and have less variability than large stories.

 

Agile Tip # 5: Define personas

Agile Tips - Define Personas

Define personas for your product and write persona-based user stories. A persona is a fictional character that you create based on your user research to represent different users that might use your product. Understanding the characteristics, experiences, behaviors, and needs of your personas will help you to write valuable user stories.

 

Agile Tip # 6: Maximize the business value

Agile Tips - Maximize Business Value

It is important that you understand the business value associated with each prioritized user story. 

"Your job isn't to build more software faster; it's to maximize the outcome and impact you get from what you choose to build." - Jeff Patton

 

Agile Tip # 7: Focus on One Thing

Agile Tips - Focus on One Thing

Are you multitasking or is it context-switching? Research suggests that productivity can be reduced by as much as 40% by the mental blocks created when people switch tasks. Not only should you work exclusively on what's most important, but you should also look to minimize the number of different things you work on at any given time.

"Extraordinary results are directly determined by how narrow you can make your focus." - Gary Keller

 

Agile Tip # 8: Prioritization

Agile Tips - Prioritization

Product owners should consider both importance and urgency when prioritizing product backlog items for the team. In Scaled Agile Framework (SAFe), WSJF or Weighted Shortest Job First technique is used to sequence jobs and ensure maximum economic benefit. Read more here.

"What is important is seldom urgent, and what is urgent is seldom important."- Eisenhower.

 

Agile Tip # 9: Clean Code

Agile Principle 7 - Working Software

Write a clean and high-quality code to minimize technical debt.

"Anyone can write a code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler, Author, and Programmer

 

Agile Tip # 10: Sprint Retrospectives

Agile Tips - Sprint Retrospective

Sprint Retrospectives provide explicit opportunities to improve the existing process. Retrospectives promote ownership and responsibility with respect to all aspects of the process. 

"If you adopt only one Agile practice, let it be retrospective. Everything else will follow." - Woody Zuill

 

Also, read my agile tips on Medium.

 

Continue reading

Please follow and like us:

What are the Agile Principles?

What are the Agile Principles?

What are Agile Principles?

Let's understand the 12 Agile Principles that set the foundation for being agile. The following principles are based on 'The Agile Manifesto'.

 

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

Customer First

Agile Principle 1 - Satisfy the Customer                                                                                    Photo by rawpixel on Unsplash

What does this Agile principle mean? The phrase “our highest priority” signifies that the entire product team should know their priorities and should work on the highest priority items first. The highest priority for the product team is to “satisfy the customer” such that the product meets the needs of the customer. The phrase “early and continuous delivery of valuable software” implies that the work completed during the iteration must be demonstrated to the customers as soon as it meets the ‘Definition of Done’ to get their early feedback. Moreover, the team must strive to deliver valuable software to the customers at the end of each time-bound iteration.

 

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

Agile Principle 2 - Welcome Changing Requirements

Agile Principle 2 - Welcome Changing Requirements 🙂 Just Kidding!                                         Photo by rawpixel on Unsplash

This Agile principle focuses on embracing change. The phrase “welcome changing requirements” signifies the importance of accepting revised business priorities. The phrase "even late in development" signifies that changes should be welcomed irrespective of the time and effort the team has already invested to develop a feature. It's hard not to get defensive! But, think from your customer's perspective and understand the business value or the key drivers of the change. 

“Intelligence is the ability to adapt to change.” – Stephen Hawking

 

Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Agile Principle 3 - Deliver Working Software Frequently

Agile Principle 3 - Deliver Frequently 🙂                                                                                   Photo by Pope Moysuh on Unsplash

Let’s understand what this principle means. The phrase, “deliver working software” means that the Agile development team should target to deliver high-quality production-ready work at the end of each iteration. The team should target to deliver working software frequently, preferably, after every couple of weeks. The shorter the delivery timescale, the more incremental development happens with the lesser cost of change.

 

Principle 4: Business people and developers must work together daily throughout the project.

Agile Principle 4 - Collaboration

Agile Principle 4 - Collaboration                                                                                                    Photo by rawpixel on Unsplash

This principle focuses on collaboration between the business and the development team. The phrase “must work together daily” implies that Agile development teams must interact with product sponsors daily throughout the work execution.

“Individual commitment to a group effort – that is what makes a team work, a company work, a society work, a civilization work.” - Vince Lombardi

 

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

Agile Principle 5 - Motivation, Support, and Trust

Agile Principle 5 - Motivation, Support, and Trust                                                                   Photo by Samuel Zeller on Unsplash

What does this principle mean? The phrase, “build around motivated individuals” emphasizes the importance of having motivated people on the team.

“Find people who share your values, and you’ll conquer the world together.” - John Ratzenberger

Give them the environment and support they need” – this phrase means that agile leaders should provide the necessary infrastructure that development teams need to continuously integrate and deploy their changes and should trust the team to deliver valuable software to customers.

 

Principle 6: The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.

Agile Principle 6 - Face-to-Face Conversation

Agile Principle 6 - Face-to-Face Conversation                                                           Photo by Kawtar CHERKAOUI on Unsplash

This principle is all about face-to-face conversation. Agile leaders, product sponsors, and business stakeholders must meet with the development team in-person regularly. Face-to-face conversations boost creativity, credibility, trust, and collaboration as people better understand feelings and reactions via body language and expressions. Face-to-face conversations also promote friendliness and build relationships. Often, face-to-face conversations are constrained by the geographical presence of the development team. Platforms for video conferencing provide the same benefits as that of face-to-face conversations and should be encouraged.

 

Principle 7: Working software is the primary measure of progress.

Agile Principle 7 - Working Software

Agile Principle 7 - Working Software                                                                                       Photo by Markus Spiske on Unsplash

This principle focuses on “working software”. The Agile development team must deliver high-quality work at the end of each iteration that can be released on-demand to end-users or customers of the product. Working software is the primary success measure. Other metrics such as productivity, committed vs actual work, and burndown charts are secondary.

 

Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Agile Principle 8 - Constant Pace

Agile Principle 8 - Constant Pace                                                                                           Photo by Boris Stefanik on Unsplash

The phrase “sustainable development” means that work is developed at a constant pace that can be sustained indefinitely without overburdening a development team.

“It does not matter how slowly you go as long as you do not stop.”  – Confucius

 

Principle 9: Continuous attention to technical excellence and good design enhances agility.

Agile Principle 9 - Technical Excellence

Agile Principle 9 - Technical Excellence                                                                     Photo by Kelly Sikkema on Unsplash

The principle states that agile leaders, developers, and the product team must continuously seek technical excellence and emergent design to enhance agility.

“In an agile project, technical excellence is measured by both capacity to deliver customer value today and create an adaptable product for tomorrow.” - Jim Highsmith

 

Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential.

Agile Principle 10 - Simplicity

Agile Principle 10 - Simplicity                                                                                                Photo by rawpixel on Unsplash

The developers, product sponsors, and the agile leaders must identify things that do not add value or in other words, must simplify things by maximizing the amount of work not done. 

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is, nothing left to take away.” - Antoine de Saint-Exupery

 

Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

Agile Principle 11 - Self-Organizing Teams

Agile Principle 11 - Self-Organizing Teams                                                                                Photo by rawpixel on Unsplash

This principle is all about self-organizing teams. The product architecture, design, and features emerge from mature self-organizing teams who can freely take decisions and remove temporary blockers on their own. If developers are free to make decisions, they tend to be more accountable, innovative, and collaborative. Such an environment is best suited for emergent design and iterative development. 

“A self-organizing team has authority over its work and the process it uses.” - Mike Cohn

 

Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Principle 12 - Inspect and Adapt

Agile Principle 12 - Inspect and Adapt                                                                                       Photo by Devin Avery on Unsplash

This principle focuses on inspect and adapt. The phrase “at regular intervals” signifies the importance of setting up a regular cadence to inspect and improve. Agile frameworks recommend regular practices such as product demo and retrospectives to continuously improve the process in an iterative way.

“Continuous improvement is better than delayed perfection.” -  Mark Twain

 

Apply these 12 Agile Principles to be agile. Hope this article provided value to you. Please post your valuable feedback in the comments section. Thank you!

To learn more about the Agile Scrum Framework, read my bestselling book, The Basics Of SCRUM. If you like to understand the Lean Kanban method, check out my other book, The Basics Of Kanban.

Please follow and like us:

15 differences between Waterfall and Agile Scrum

15 differences between traditional Waterfall and Agile Scrum approach

Here's a quick comparison of the plan-driven Waterfall methodology and Agile Scrum approach:

 

Core Waterfall Features:

  • Encourages conformance to processes and tools
  • Needs comprehensive documentation
  • Restricts new ideas
  • Promotes a process-centric environment
  • Depends on contract negotiation
  • Conforms to a plan
  • Requires continuous effort to motivate the team members
  • Require a huge rework to accommodate late changes
  • Results in a high cost of change
  • Encourages a detailed project plan
  • Leaves a large possibility of a mismatch between requirements and the final product
  • Is likely to have unhappy customers
  • Supports late customer feedback
  • Requires upfront decisions
  • Does not encourage regular interaction with business sponsors

Core Scrum Features:

  • Encourages people interactions
  • Promotes working software over comprehensive documentation
  • Encourages experimentation and new ideas
  • Promotes a people-centric environment
  • Encourages customer collaboration
  • Embraces change
  • Creates high performing, self-organizing, and motivated teams
  • Adapts late changes with minimal rework
  • Has a low cost of change
  • Is based on just-in-time planning principles
  • Reduces mismatch between initial business requirements and the final product
  • Is likely to produce delighted customers
  • Encourages fast and frequent customer feedback
  • Decisions wait till the last responsible moment (LRM)
  • Promotes high collaboration with the Product Owner

Learn Agile Scrum with my complete handbook, The Basics of SCRUM.

Please follow and like us:

What is Technical Debt?

What Is Technical Debt?

Learn Agile

Ward Cunningham introduced the concept of technical debt in 1992. He defined it as follows:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

 

Cunningham used the ‘Technical Debt’ metaphor to emphasize the benefits and limitations of speedy development. The metaphor was well received by both business and technical people as it resonates with financial debt. Like financial debt, technical debt accumulates interest with late repayment.
In 2004, Joshua Kerievsky describes ‘design debt’ in his article ‘Refactoring to Patterns” and the associated costs. Then again in 2014, Grady Booch compared evolving cities to evolving software and described how lack of refactoring can lead to technical debt. He stated:

“The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So, it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up.”

 

Get the answers to the below questions in my management book, The Basics of SCRUM: A Simple Handbook to the Most Popular Agile Scrum Framework, available exclusively at Amazon.

  • What is a Technical Debt?
  • What are the main causes of Technical Debt?
  • What are the consequences of Technical Debt?
  • How do you manage Technical Debt?
  • What are some of the practical examples of Technical Debt?
  • What are some of the practical techniques to manage Technical Debt?
Please follow and like us: