A Guide to Practical Agile

A Guide to Practical Agile

Being an ardent fan of Agile, I have tried to list down few best practices from my experience that will help Agile Teams deliver better. 

The purpose of Agile is quite simple and every agile team should remember this.

AGILE should help you to,

  • Plan faster
  • Understand requirements better and quicker
  • Decide faster
  • Deliver faster
  • Welcome and Adopt changes faster
  • Eliminate wastes (time consuming things) that hinder Software development.

So that the delivered software stays relevant to satisfy the current needs.

But often AGILE is misinterpreted as a magic methodology that will help teams to deliver faster.

The core of Agile revolves around the following: The success and failure of agile projects depends on the following.

  • People
  • Collaboration and Communication
  • Processes
  • Individual Ownership
  • Incremental delivery and value addition

Having said above, what scrum teams should follow to make AGILE work better?

  1. Understand AGILE principles and agree a framework that suits your organization:
  • AGILE helps you with various standards and guidelines. But remember those are only guidelines and it may or may not suit your organization.
  • So evaluate and agree on deliverables and processes that will suit your organization (Customization is key). (Ex: Sprint Length, Sprint readiness e.t.c)
  • Keep a constant review process and ensure there is flexibility to accommodate change in process and deliverables.
  • Remember, whatever you are following should help to progress and should not result in a bottle-neck.
  1. Understand AGILE ceremonies and pick those that suits your organization:
  • Most teams gets carried away by the AGILE ceremonies and end-up in consuming more time in preparing for the Agile ceremonies.
  • So ensure whatever you are following as part of these ceremonies should not be a time consuming thing (in other words Waste).
  • Pick those things that will truly add value.
  1. Remember AGILE, teaches you to eliminate wastes and not essentials:
  • AGILE doesn’t alter the basics of software development.
  • The tasks related to basic software development holds good in Agile also.
  • So activities, where time needs to be spent should be given /taken sufficient time. (If planning needs 10 hours, it is 10 hours)
  1. Estimate faster and frequently:
  • AGILE follows relative sizing. It’s about identifying and arranging similar things together. (It helps you to differentiate between lemons and watermelons)
  • By this way you could estimate faster. Because at any given point of time, you know how much is still left in the basket and how much will it take to consume them.
  • But remember even the most carefully planned software estimates go for a toss.
  • So keep re-sizing as and when, you have more details.
  • By this way you could estimate faster and change release scopes / timelines faster and could communicate faster.
  1. Points vs Hours:
  • Remember, Points cannot be converted to hours.
  • Points are used for relative grading.
  • It is for grouping relative items.
  • So either follow points or Hours whichever the team is comfortable. (But don’t get confused by converting one to another)
  1. Remember change is the only constant thing and not velocity:
  • Velocity of a team can change due to various factors.
  • So please don’t follow a constant velocity and don’t try to arbitrarily achieve a constant figure.
  • A higher figure doesn’t mean that a team is delivering better.
  • Even the most matured scrum teams have dip / spike in velocity.
  • Always measure velocity as an average over a period of time.
  1. Visualise the end product:
  • Ensure the vision of the project and the prototype model of the end product are understood by all team members.
  • Have a high level overview of the dots that connect the end product.
  • Collaborate and deliver a simple one pager that articulates the above.
  • Keep periodical sessions to keep this communicated to the whole team.
  • Though the delivery is Incremental, the final product should be in the minds of team members.
  1. Identify risks and un-certainties:
  • Keep track of things where there is no clarity or which might be a potential risk.
  • Keep this updated as and when new threats are identified.
  • Keep this visible, so that the whole team is aware of.
  1. Keep User Stories / Other deliverables simple:
  • Pages and Pages of document will exhaust the reader. So keep documents simple.
  • But simple doesn’t mean less information.
  • Content (Information required) will differ based on the maturity of teams. So post-card sized document may not work for all teams.
  • In case of User Stories it should not be more than 8 story points.
  • Anything more than 8 means, it is not understood fully. So break it.
  1. Document Essentials:
  • The most key thing in AGILE projects is to document only those things that will be valuable. Agile doesn’t mean “No Documentation”.
  • It means document the” key things” that need to be referred by existing teams and future teams.
  • This will ensure, Teams need not wait till a master document is created and reviewed by all parties to start their work.
  • It will also ensure key considerations; assumptions and solutions are briefly documented for future reference.
  1. Use more visual Interpretations to communicate:
  • Use more graphical and visual tools to articulate and document, so that it is easy to understand and review.
  1. Document and Review together:
  • Create documents by collaboration and not in isolation
  • Ensure key people are there while creating and review.
  • Time Box and close review comments together.
  • Updates and Parallel reviews should happen together with the core team.
  • This ensures that documented things are owned by everyone and not a single person.
  1. Don’t hide behind documents and email’s – Rather Collaborate:
  • Collaboration is the key.
  • Don’t keep writing pages of email and email chains to get things done.
  • Call for a meeting or collaborate online to get things done.
  1. Keep Meetings shorter:
  • Human mind cannot stay focused more than 45 minutes.
  • So keep meetings short and crisp.
  • Involve limited / key audience.
  • Keep action owners for every action point and agree on a timeframe to deliver.
  • Also plan only necessary meetings.
  1. Empower Teams:
  • Create self-empowered teams or have a core team that can make decisions on their own.
  • Take decisions faster.
  • Own decisions together.
  1. Expect change, but prioritise change:
  • Agile tends to welcome a lot of changes than traditional waterfall.
  • So be prepared for change, but prioritise change before taking it for delivery.
  • Remember any change will have a direct impact on project timeline.
  • If further change is anticipated better park it.
  1. Practice clean coding:
  • As an author of the code ensure it is easy to understand and can be reviewed easily.
  • Track it against a functionality or User Story and Sprint.
  • This helps to track / change in the future.
  1. Understand Test driven development:
  • Ensure the story is fully understood before you start to code.
  • Practice peer-discussion and collectively identify scenarios.
  • So the whole intent is, the developer knows what all scenarios the code should clear before starting the code.
  1. Maintain a healthy Technical Backlog and encourage audit:
  • Codes written in an Agile environment needs to be reviewed periodically as the dots are unveiled in instalments.
  • So ensure there are adequate tasks planned to review and re-structure technical framework.
  • Also periodically involve third party teams to do an audit to ensure good health.
  1. Use less and essential Tools. Don’t buy everything in the market:
  • Selection of Tools and the number of Tools used in agile environment should be carefully picked.
  • Don’t try every available product in the market.
  • Remember Tools should be a boon and not a pain point.
  1. Do meaningful Retro’ s:
  • Retro meetings are critical to self-analyse and improve.
  • Utilise them properly.
  • Use KPI’s to measure performance and track action items from a Retro.

Last but not least,

Remember, “Small, strongly knitted teams, working in a better and healthy environment” deliver more than large teams.

Enjoy Agile.

Vimal M

Vimal Mohan

Manager Consulting - Aviation and Retail

8 年

Thanks Huzefa

回复
Huzefa Diwanji

Principal Engineer / Architect - Java Distributed Systems | Digital Banking Expert | Open Banking API | Corporate Banking | Dev Ops | CI/CD

8 年

Very well written

Vimal Mohan

Manager Consulting - Aviation and Retail

8 年

Thanks Shini Alex

回复
Shini Alex

Ways of Working- Trusted Advisor??/Coach??

8 年

Well written..very simple... Expecting more such guide... Especially on the art of writing effective user stories... n your contribution on solution deck

要查看或添加评论,请登录

Vimal Mohan的更多文章

社区洞察

其他会员也浏览了