Agile adoption is increasing with a fast pace in IT and SW industry. Reason for organisations to implementing Agile could be to balance team performance, cut time to market, improve quality and double productivity, as they have heard that its the only process that work these days and adopting agile provide an edge over tradition processes.
Transformation or agile adoption start ideally from the development team and it hardly go beyond that. While the rest of the organisation enjoy a free ride of some or no process at their work, “being agile” journey of organisation which started from development ends there, with the assumption that agile is adopted to its best.
In my experience haven’t seen agile transformation in other departments or layers in organisation then SW Development department, like Marketing, Sales, Support, HR department adopting fully to agile same way as SW development Team.
Doing agile is like using a compass and paper maps, you may get to the destination without getting lost, but not sure thats the destination you are hoping for.
Being agile is like using the GPS turn by turn navigation, it alarm you about next sharp turn ahead, it inform you to change the path of your journey in case of traffic congestion ahead.
And even if you get lost its just re-calculate the route for you. It keep track of your expected arrival time to the destination, keep on monitoring your speed to which you are travelling.
In agile all of its artefacts and activities are interconnected as lego pieces, failing to use any
of it will increase the risk of falling the whole structure on which the while agile foundation rest.
Detail sprint planing, effort estimation, planning poker, knowing team’s velocity, daily scrum are the activities which are interconnected to each other.
Some team have assumption that they are doing agile because they have a Product owner who also happen to be a scrum master, have backlog and run sprint which have duration of 3-4 weeks, another miss conception is “real purpose of agile to have no process overhead and meetings”
Lets have a look at the agile artefacts and lego pieces to know if we are being agile enough or just doing agile for the sake of agile (removing the most obvious activities)
1. Measuring Velocity
What is your team’s velocity ?
Knowing velocity is knowing how much userstory can take up in each sprint, it make sprint and release planning more accurate.
2. Planning Poker
Deck of cards for each member ?
It enable discussion which is veryproductive. In planning poker group of people comes to common consensus, The highest and lowest estimators explain their perspective, which means benefiting from teams collective wisdom.
3. Daily Scrum
Is it daily ?
Concise daily meeting which increase collaboration and support, energise team work. Convey enough information about past day and plan for current day among team member.
4. Sprint planning
How much time you spend ?
Define sprint goal, well prioritised and defined user-stories in backlog, userstories should be explained by PO to team member, team members should provide enough time to estimate the userstory, effort estimation by team members should be respected.
5. Separate PO & SM Roles
Or Person with changing hats ?
One person should not hold two roles, it causes conflicts of interest.
6. Detail Estimation
What is your accuracy ?
Team member should spend enough time during sprint meeting to estimate their work.
7. Sprint Demo
Are the user story demoed by team members ?
Very vital part of sprint is the Sprint Demo, team member should demoed their work.
Measuring what didn’t go well in sprint ?
Reviewing the past sprint , finding what went well and what need improvement, help team to organise better.
9. Burn down chart
How often you are checking, does it reflect reality ?
Check burn down more often as it represent the live status of scrum.
How was your journey towards being agile, share your thoughts
www.yodiz.com All-in-One Agile Management Platform