A tracer bullet is not a prototype. Why?
Because,
•A prototype is not deployed in production
•A prototype is not 'working software'.
A tracer bullet is not a POC. Why?
Because
•A POC may not be implementing a feature end to end.
•A POC is not a skeleton of an Epic.
•A POC may not be implementing any functionality
A tracer bullet is not a Sashimi. Why?
Because,
A Tracer bullet is a spike (time boxed) but a sashimi is a
collection of (one or few) user stories that implement a thin version of
a functionality.
Tracer Bullet is a Spike but a Spike may not be a tracer bullet. Why?
Because:
A spike may not deliver deploy-able value in all the cases.
For example, a spike on environment compatibility study may not deliver
any ship-able increment. But the knowledge acquired on this process
would be the outcome of spike.
Sunday, December 14, 2014
Y axis of Burndown chart
I have been interviewing scrum masters. After talking to 25+ candidates, this question still waits to get answered correctly.
What is the difference between release Burndown and sprint Burndown.
I ask this question differently, primarily to identify if the candidate is googling live.
I usually ask - what do you see in the y axis of Release Burndown and what do see in the y axis of Sprint Burndown chart?
Answers for those who are learning now: In Y axis, Sprint burn down has hours todo. Release burndown has story points todo. Should there be a burndown for CXOs, it would have SWAG (todo) of the features in Y axis.
It is always 'Time' ( days, releases or Qts) in X axis.
What is the difference between release Burndown and sprint Burndown.
I ask this question differently, primarily to identify if the candidate is googling live.
I usually ask - what do you see in the y axis of Release Burndown and what do see in the y axis of Sprint Burndown chart?
Answers for those who are learning now: In Y axis, Sprint burn down has hours todo. Release burndown has story points todo. Should there be a burndown for CXOs, it would have SWAG (todo) of the features in Y axis.
It is always 'Time' ( days, releases or Qts) in X axis.
Mischievous cat of an elderly Guru or Cargo cult science
It
is the story of a ‘Gurukul’ (school) that followed traditions
religiously.
This elderly Guru found his pet cat annoying - interfering their daily prayers. So he ordered the pupil’s leader to put that cat on leash, during prayer hours. Guru passed away on a breezy evening. They found his cat, dead under his bed.
Then the pupil’s leader became Guru. On his first prayer, he looked around and ordered his students to go find a cat, as he needed a cat be tied in the third pillar of long corridor that goes to garden; to start his daily prayer.
The moral is, traditions are meaningless when they don’t deliver value.
Some teams don’t talk anything outside those three subjects during scrum.
“What did I do yesterday?”
“What will I do today?”
And “the impediments!”
When I noticed something missing on a scrum and checked the team member if he discussed the release plan for next week; the reply was ‘I will do it on Friday’. What if the deployment POC would be OOO on Friday?
So, there is no need to limit within three heads. Encourage your teams to talk everything to meet the delivery timeline. ‘Three heads’ is just a starting point for collaboration and we should talk as much as possible to deliver the deploy-able increment; ensure that won’t we end up making it a status report.
This elderly Guru found his pet cat annoying - interfering their daily prayers. So he ordered the pupil’s leader to put that cat on leash, during prayer hours. Guru passed away on a breezy evening. They found his cat, dead under his bed.
Then the pupil’s leader became Guru. On his first prayer, he looked around and ordered his students to go find a cat, as he needed a cat be tied in the third pillar of long corridor that goes to garden; to start his daily prayer.
The moral is, traditions are meaningless when they don’t deliver value.
Some teams don’t talk anything outside those three subjects during scrum.
“What did I do yesterday?”
“What will I do today?”
And “the impediments!”
When I noticed something missing on a scrum and checked the team member if he discussed the release plan for next week; the reply was ‘I will do it on Friday’. What if the deployment POC would be OOO on Friday?
So, there is no need to limit within three heads. Encourage your teams to talk everything to meet the delivery timeline. ‘Three heads’ is just a starting point for collaboration and we should talk as much as possible to deliver the deploy-able increment; ensure that won’t we end up making it a status report.
Saturday, May 10, 2014
Agile provides developers..
Freedom to estimate: You estimate and you deliver. No need to work on someone else’s estimate.
Freedom to explain: One of the toughest tasks of a developer is to explain the delay to managers. Many a times, developer wouldn’t have any evidence to show that she/he has tried different options and the task still remains to be a research item. Agile provides means (VersionOne, JIRA) to track what was being done. After spending all the estimated hours, you will still be able to add ‘ToDo’ if really required.
Freedom to schedule: Generally, developers will be taking tasks one after another working closely with Leads till the project would be completed. But, agile lets developers to plan upfront. Developers will be able to plan their personal time accordingly. If a developer likes to take two weeks of vacation, he can own stories appropriately and deliver such that the others work wouldn’t be impacted.
Freedom to Speak: Developer has an opportunity to speak up every day (in case of scrum). If a developer thinks that the sprint zero was not done well then she/he can start a discussion on day one, instead of storing the work on his desktop and losing them in a crash after weeks.
Benefits of listening: Conventionally, the collaboration was a role being played by leads. Agile multiples the chances for successful collaboration as everyone has the freedom / opportunity interact. Developers directly interact with another who has done a task similar to what he would try to start, and achieve it in very less time by collaboration. Earlier leads had to check with other modules and bind people together.
Work on a project- Not a module: When a developer start hearing what others do in a project every day, she/he gets a holistic view and minimizes the integration defects. His knowledge on different modules helps to grow a healthy cross functional group (which actually is a ‘Team’) instead of developers working in silos.
In general, Agile enables people to work as a team, and makes the issues very visible so that teams can work towards a solution. Agile is not a solution for practical issues teams may have; but it helps to identify issues, really visible.
NB : I use scrum and my views above are associated with that
Freedom to explain: One of the toughest tasks of a developer is to explain the delay to managers. Many a times, developer wouldn’t have any evidence to show that she/he has tried different options and the task still remains to be a research item. Agile provides means (VersionOne, JIRA) to track what was being done. After spending all the estimated hours, you will still be able to add ‘ToDo’ if really required.
Freedom to schedule: Generally, developers will be taking tasks one after another working closely with Leads till the project would be completed. But, agile lets developers to plan upfront. Developers will be able to plan their personal time accordingly. If a developer likes to take two weeks of vacation, he can own stories appropriately and deliver such that the others work wouldn’t be impacted.
Freedom to Speak: Developer has an opportunity to speak up every day (in case of scrum). If a developer thinks that the sprint zero was not done well then she/he can start a discussion on day one, instead of storing the work on his desktop and losing them in a crash after weeks.
Benefits of listening: Conventionally, the collaboration was a role being played by leads. Agile multiples the chances for successful collaboration as everyone has the freedom / opportunity interact. Developers directly interact with another who has done a task similar to what he would try to start, and achieve it in very less time by collaboration. Earlier leads had to check with other modules and bind people together.
Work on a project- Not a module: When a developer start hearing what others do in a project every day, she/he gets a holistic view and minimizes the integration defects. His knowledge on different modules helps to grow a healthy cross functional group (which actually is a ‘Team’) instead of developers working in silos.
In general, Agile enables people to work as a team, and makes the issues very visible so that teams can work towards a solution. Agile is not a solution for practical issues teams may have; but it helps to identify issues, really visible.
NB : I use scrum and my views above are associated with that
Monday, April 7, 2014
The 6th Principle.
"Face-to-face conversation is the best form of communication (co-location)"
– That is the sixthof 12 principles upon which the agile manifesto was proclaimed.
We, the Agilists of Eastern Iowa Agile, a meet up group, gather regularly in Cedar Rapids. During the last meeting at Kirkwood College, we had Richard Lawrence of ‘Agile for all’ (http://www.agileforall.com/ ) delivering for us.
It was an interesting workshop with no presentations. The entire gathering took part in opining and realizing the values of agile principle. As an interesting exercise, we were asked to pick most favorite 3 from 12 Agile principles. And we were discussing the pros and cons. But later at the end, we noticed for everyone’s surprise, no one had picked the 7th principle. Then Rick concluded that this should be actually obsolete today and the communication media should have replaced the need to meet face to face. A ground breaking manifesto of 2001 becomes obsolete in 2014.
But, I think a Taskboard full of activities should certainly make a difference in the mid set of teams to bring a healthy competition and would help the team members to understand their contribution in overall delivery, no matter they meet face to face or not. My team is well distributed across the US geography and we ensure that Task board is shared by all of us in scrum, every day.
Because the HR theories of T-groups are still there in books and are found fruitful. So, the truth should be standing tall somewhere between Yes and No. May be…
– That is the sixthof 12 principles upon which the agile manifesto was proclaimed.
We, the Agilists of Eastern Iowa Agile, a meet up group, gather regularly in Cedar Rapids. During the last meeting at Kirkwood College, we had Richard Lawrence of ‘Agile for all’ (http://www.agileforall.com/ ) delivering for us.
It was an interesting workshop with no presentations. The entire gathering took part in opining and realizing the values of agile principle. As an interesting exercise, we were asked to pick most favorite 3 from 12 Agile principles. And we were discussing the pros and cons. But later at the end, we noticed for everyone’s surprise, no one had picked the 7th principle. Then Rick concluded that this should be actually obsolete today and the communication media should have replaced the need to meet face to face. A ground breaking manifesto of 2001 becomes obsolete in 2014.
But, I think a Taskboard full of activities should certainly make a difference in the mid set of teams to bring a healthy competition and would help the team members to understand their contribution in overall delivery, no matter they meet face to face or not. My team is well distributed across the US geography and we ensure that Task board is shared by all of us in scrum, every day.
Because the HR theories of T-groups are still there in books and are found fruitful. So, the truth should be standing tall somewhere between Yes and No. May be…
Velocity – Significance of averaging.
As I was splitting the remaining/partially done stories to the next sprint I wondered what would happen to the story points. Because the task estimates are getting split and carried forward whereas the story point remains the same for both the sprints.
Further, if a sprint is going to accumulate a few heavy stories from previous sprints and get credited in the current sprint then what would happen to the velocity? So,
•It is important to consider the average velocity when you take a shot on SWAG.
•Story points completed in a sprint may not reflect the effectiveness of a sprint.
Further, if a sprint is going to accumulate a few heavy stories from previous sprints and get credited in the current sprint then what would happen to the velocity? So,
•It is important to consider the average velocity when you take a shot on SWAG.
•Story points completed in a sprint may not reflect the effectiveness of a sprint.
Story Points Vs Task Hours
Which one should be appropriate for capacity planning? Story Point or Task Hours. That was an interesting question raised by my client Manager when he was trying to get more resources to the team.
My Answer was ‘Task Hours’.
Story point in case of ‘capacity planning’ and Task hours if you are resource planning. Here is my justification: Story point is an unit that so specific to that team, organically evolved, normalized within the team. Whereas, the Task hours could be universal. I added, the story point unit signifies the ‘Unit of work, that could be ‘DONE’ by our team, using our technology, for our problems, within our time-box in our company during last few sprints’.
Should he been planning for the current team I would have told him ‘story point’. But he was asking about the ‘future’ team, which had not yet taken part in determining the team’s story point units. Rather, he should have asked me ‘Which one should be appropriate for resource planning? Story Point or Task Hours’ I gently hinted that to him.
My Answer was ‘Task Hours’.
Story point in case of ‘capacity planning’ and Task hours if you are resource planning. Here is my justification: Story point is an unit that so specific to that team, organically evolved, normalized within the team. Whereas, the Task hours could be universal. I added, the story point unit signifies the ‘Unit of work, that could be ‘DONE’ by our team, using our technology, for our problems, within our time-box in our company during last few sprints’.
Should he been planning for the current team I would have told him ‘story point’. But he was asking about the ‘future’ team, which had not yet taken part in determining the team’s story point units. Rather, he should have asked me ‘Which one should be appropriate for resource planning? Story Point or Task Hours’ I gently hinted that to him.
Subscribe to:
Posts (Atom)