One for the Agile gurus
Discussion
My large organisation is introducing 'Agile' in a pretty haphazard manner. It is being driven by IT alone, when any basic Agile course tells you that you need business buy-in, engaged Product Owners in the business etc.
That aside, we are also (again, in my opinion, haphazardly) applying this across the board, from cutting edge apps to 40yr old legacy mainframe systems - my area. Again, a lot of Agile theory says you don't apply it to your monoliths, but we've been told that it has to apply to everything.
The biggest problem I am having is the absolute terrible quality of User Stories; the people tasked with writing them don't really know what they are doing, and as an IT department we have no clear 'Definition of Ready' for taking something into a Sprint. As you can imagine, despite expecting to be on a steep learning curve, it all seems a bit of a disaster before we have even got going.
Which leads me onto my main question: where in the Agile world do you do what is the traditional 'Analysis and Design' for each User Story?
My interpetation is that this is during Sprint Refinement - you look at those vague stories that are approaching the top of the backlog and work out within the team exactly what needs to be done, flesh out the detail, so that you know that by the time you want to to take the Story into the Sprint the programmer should have all the requirements in the Story and all analysis done, in order for them to start productive coding on Day 1 of the Sprint.
What we are getting it a vague set of requirements in a Story, it being thrown into a three week Sprint, and techies like me saying "hang on, this needs several days' analysis before I even know where to start coding". Much frustration all round from people who are used to being given a spec and being told "code this".
Please tell me I'm not going mad? I understand we should be looking at small, iterative changes, but these have got to be scoped out, and this should be done, as far as I understand, during Sprint Refinement. Currently we have zero time devoted to this process.
That aside, we are also (again, in my opinion, haphazardly) applying this across the board, from cutting edge apps to 40yr old legacy mainframe systems - my area. Again, a lot of Agile theory says you don't apply it to your monoliths, but we've been told that it has to apply to everything.
The biggest problem I am having is the absolute terrible quality of User Stories; the people tasked with writing them don't really know what they are doing, and as an IT department we have no clear 'Definition of Ready' for taking something into a Sprint. As you can imagine, despite expecting to be on a steep learning curve, it all seems a bit of a disaster before we have even got going.
Which leads me onto my main question: where in the Agile world do you do what is the traditional 'Analysis and Design' for each User Story?
My interpetation is that this is during Sprint Refinement - you look at those vague stories that are approaching the top of the backlog and work out within the team exactly what needs to be done, flesh out the detail, so that you know that by the time you want to to take the Story into the Sprint the programmer should have all the requirements in the Story and all analysis done, in order for them to start productive coding on Day 1 of the Sprint.
What we are getting it a vague set of requirements in a Story, it being thrown into a three week Sprint, and techies like me saying "hang on, this needs several days' analysis before I even know where to start coding". Much frustration all round from people who are used to being given a spec and being told "code this".
Please tell me I'm not going mad? I understand we should be looking at small, iterative changes, but these have got to be scoped out, and this should be done, as far as I understand, during Sprint Refinement. Currently we have zero time devoted to this process.
You're not going mad, you are absolutely correct.
Nothing can be included in a sprint until the people who are delivering it have committed to delivering it, and the customer (product owner) has committed to having it delivered (i.e. nothing else is more important right now, and once the sprint starts, it won't change).
The delivery team can't commit if they haven't estimated and understood the story, so the sprint is doomed before it starts, because the only thing that drives a sprint to completion is that commitment to deliver.
You can't have one group doing the definition and sprint formation and another group doing the delivery. Commitment is absolutely about the delivery team deciding what they can and will deliver.
Product Planning is needed, where the engineers and the product owners should get together and take the stories from the product backlog into a state of readiness where they can be moved into a sprint. They can't be added to a sprint backlog until they are fully ready. Readiness is more about agreement that they are ready than any particular level of detail or paperwork. Simple things might need no detail. Bigger things might need broken up and discussed to death.
Nothing can be included in a sprint until the people who are delivering it have committed to delivering it, and the customer (product owner) has committed to having it delivered (i.e. nothing else is more important right now, and once the sprint starts, it won't change).
The delivery team can't commit if they haven't estimated and understood the story, so the sprint is doomed before it starts, because the only thing that drives a sprint to completion is that commitment to deliver.
You can't have one group doing the definition and sprint formation and another group doing the delivery. Commitment is absolutely about the delivery team deciding what they can and will deliver.
Product Planning is needed, where the engineers and the product owners should get together and take the stories from the product backlog into a state of readiness where they can be moved into a sprint. They can't be added to a sprint backlog until they are fully ready. Readiness is more about agreement that they are ready than any particular level of detail or paperwork. Simple things might need no detail. Bigger things might need broken up and discussed to death.
This sounds very familiar 
As per usual someone high up has got caught up in the buzz of this is how great Agile is and then convinced the rest of the management that this is the way forward, lets apply it everywhere. And then us poor developers have to deal with the fall-out.
Not saying it's a bad thing if done properly but for certain projects I feel a hybridised approach needs to be taken with a good old Gantt chart to track the bigger picture and break some of the work down into monthly sprints if it fits well. Otherwise you end up with a load of developers doing a lot of disjointed stuff with no clear view of the end goal and it all becomes a shambles. What it has brought though is us migrating to the Atlassian toolset which whilst quite Agile focused is also nice to use.
As per usual someone high up has got caught up in the buzz of this is how great Agile is and then convinced the rest of the management that this is the way forward, lets apply it everywhere. And then us poor developers have to deal with the fall-out.Not saying it's a bad thing if done properly but for certain projects I feel a hybridised approach needs to be taken with a good old Gantt chart to track the bigger picture and break some of the work down into monthly sprints if it fits well. Otherwise you end up with a load of developers doing a lot of disjointed stuff with no clear view of the end goal and it all becomes a shambles. What it has brought though is us migrating to the Atlassian toolset which whilst quite Agile focused is also nice to use.
PurpleTurtle said:
The biggest problem I am having is the absolute terrible quality of User Stories; the people tasked with writing them don't really know what they are doing, and as an IT department we have no clear 'Definition of Ready' for taking something into a Sprint. As you can imagine, despite expecting to be on a steep learning curve, it all seems a bit of a disaster before we have even got going.
The solution to this lies with your developers - they should be rejecting any and all stories during Refinement, sending them back to the PO to re-write or break down into further stories. and your Scrum Master should be enforcing this and protecting the devs doing so.The organisation I work for has tried going the Agile way this year and I've been on two separate one-day courses. Yet I still think prior to this we were working in an 'Agile' way without even realising it. Both course leaders and the other attendees couldn't explain in clear concise terms what Agile actually is
Similar experiences to OP here, it’s actually frustrating as I think it’s down to how people have tried to implement agile/scrum rather than the process itself. The guys here offering actually sensible answers to the issue are exactly right I what they are saying but often in the workplace the politics get in the way.
I know when we as a development team try and get involved in the storyboarding and speccing that those ‘responsible’ for that are not happy. Even though it’s evident that they perhaps do not have as much of an understanding of the things that need to be done as they perhaps should.
So in short OP, no you are not going mad.
I know when we as a development team try and get involved in the storyboarding and speccing that those ‘responsible’ for that are not happy. Even though it’s evident that they perhaps do not have as much of an understanding of the things that need to be done as they perhaps should.
So in short OP, no you are not going mad.
OP, you aren't going mad and I've sat in sprint planning meetings where a badly defined user story has been ushered forwards.
A tactic I and others have used is to play dumb - "I don't understand this one, can someone explain?" if you are lucky, two people start giving their interpretation and quite often, they differ - everyone gets confused, so you let it go for say 5 minutes and then rein it back in - and suggest it gets pulled out and replaced with a user story/task/whatever to clearly define the original user story / success criteria. How exactly you organise this is up to you - some use nested user stories, some like to add a work item/task to the original user story, I've even seen an epic created that rolls up the define, do, verify... as long as everyone is comfortable it doesn't really matter.
If the difference of opinion doesn't happen, you have to probe a bit more, again you can play dumb and ask a few questions to draw the details, which you can ask the scrum master to add to the job.
If this is seen as a bit inflammatory I have pushed this as not a define but a "design" - in other words do we have a rough idea how we're going to achieve it ? blank looks and errms/uhhhs means we don't, so again, pull the story for a "design this thing" replacement on the basis of It may be too big to design and implement in a single sprint. Typically when you get someone thinking about things, more questions fall out which means they start asking questions that ultimately refine the original story and its criteria.
Team involvement is key - "are we all ok on this?" team members will learn to speak up if a mess is about to land in their lap.
If poorly defined stuff still gets through, follow through to the review/retrospective meeting - what evidence is there that the team met the criteria for this item? do we understand how ?
Ultimately its a communication problem, so the more talking you get everyone to do, the better off the team and project will be.
A tactic I and others have used is to play dumb - "I don't understand this one, can someone explain?" if you are lucky, two people start giving their interpretation and quite often, they differ - everyone gets confused, so you let it go for say 5 minutes and then rein it back in - and suggest it gets pulled out and replaced with a user story/task/whatever to clearly define the original user story / success criteria. How exactly you organise this is up to you - some use nested user stories, some like to add a work item/task to the original user story, I've even seen an epic created that rolls up the define, do, verify... as long as everyone is comfortable it doesn't really matter.
If the difference of opinion doesn't happen, you have to probe a bit more, again you can play dumb and ask a few questions to draw the details, which you can ask the scrum master to add to the job.
If this is seen as a bit inflammatory I have pushed this as not a define but a "design" - in other words do we have a rough idea how we're going to achieve it ? blank looks and errms/uhhhs means we don't, so again, pull the story for a "design this thing" replacement on the basis of It may be too big to design and implement in a single sprint. Typically when you get someone thinking about things, more questions fall out which means they start asking questions that ultimately refine the original story and its criteria.
Team involvement is key - "are we all ok on this?" team members will learn to speak up if a mess is about to land in their lap.
If poorly defined stuff still gets through, follow through to the review/retrospective meeting - what evidence is there that the team met the criteria for this item? do we understand how ?
Ultimately its a communication problem, so the more talking you get everyone to do, the better off the team and project will be.
Crafty_ said:
OP, you aren't going mad and I've sat in sprint planning meetings where a badly defined user story has been ushered forwards.
A tactic I and others have used is to play dumb - "I don't understand this one, can someone explain?" if you are lucky, two people start giving their interpretation and quite often, they differ - everyone gets confused, so you let it go for say 5 minutes and then rein it back in - and suggest it gets pulled out and replaced with a user story/task/whatever to clearly define the original user story / success criteria. How exactly you organise this is up to you - some use nested user stories, some like to add a work item/task to the original user story, I've even seen an epic created that rolls up the define, do, verify... as long as everyone is comfortable it doesn't really matter.
If the difference of opinion doesn't happen, you have to probe a bit more, again you can play dumb and ask a few questions to draw the details, which you can ask the scrum master to add to the job.
If this is seen as a bit inflammatory I have pushed this as not a define but a "design" - in other words do we have a rough idea how we're going to achieve it ? blank looks and errms/uhhhs means we don't, so again, pull the story for a "design this thing" replacement on the basis of It may be too big to design and implement in a single sprint. Typically when you get someone thinking about things, more questions fall out which means they start asking questions that ultimately refine the original story and its criteria.
Team involvement is key - "are we all ok on this?" team members will learn to speak up if a mess is about to land in their lap.
If poorly defined stuff still gets through, follow through to the review/retrospective meeting - what evidence is there that the team met the criteria for this item? do we understand how ?
Ultimately its a communication problem, so the more talking you get everyone to do, the better off the team and project will be.
That's a lovely explanation of what involved people are trying to achieve and their desire to commit to the delivery vs what often actually happens.A tactic I and others have used is to play dumb - "I don't understand this one, can someone explain?" if you are lucky, two people start giving their interpretation and quite often, they differ - everyone gets confused, so you let it go for say 5 minutes and then rein it back in - and suggest it gets pulled out and replaced with a user story/task/whatever to clearly define the original user story / success criteria. How exactly you organise this is up to you - some use nested user stories, some like to add a work item/task to the original user story, I've even seen an epic created that rolls up the define, do, verify... as long as everyone is comfortable it doesn't really matter.
If the difference of opinion doesn't happen, you have to probe a bit more, again you can play dumb and ask a few questions to draw the details, which you can ask the scrum master to add to the job.
If this is seen as a bit inflammatory I have pushed this as not a define but a "design" - in other words do we have a rough idea how we're going to achieve it ? blank looks and errms/uhhhs means we don't, so again, pull the story for a "design this thing" replacement on the basis of It may be too big to design and implement in a single sprint. Typically when you get someone thinking about things, more questions fall out which means they start asking questions that ultimately refine the original story and its criteria.
Team involvement is key - "are we all ok on this?" team members will learn to speak up if a mess is about to land in their lap.
If poorly defined stuff still gets through, follow through to the review/retrospective meeting - what evidence is there that the team met the criteria for this item? do we understand how ?
Ultimately its a communication problem, so the more talking you get everyone to do, the better off the team and project will be.
I'm out of these big software projects for a long time now, but way before scrums and sprints were even defined terms I was involved in the development of a sizable software system.
I can vividly remember a whole week of planning and design meetings - we used to call them Use Case analysis - seems they are called 'Story Telling' now. Six of us sat around a big white board listing the customer requirements, end user requirements, the management, the billing, the technicians - and we came up with an architecture that could potentially satisfy all these groups - 'sorry Stake Holders'. We used to take pictures of the white board with digital cameras - no one had a camera in their phone back them.
It was all documented and designed to be flexible - no one really cared about the code at the time it was all about the interfaces between the different business activities - questions like 'can we make that bit of information available over there if we need it later'.
I think we did a pretty good job - a lot of functional operation was covered using RADIUS and SNMP - I wrote the stacks for both those aspects (requirements - even the lads from Cisco were taking an interest in what we were doing) in JAVA. Someone else wrote the database interface to Oracle - and this is where it deteriorated to a point where the the project might fail.
A lot of the code writing was out sourced to India. I don't know what quite went wrong, well I do, but I was dispatched out to Mumbai for a month and it is plainly simply, Indian coders are (probably were now) quite happy to let their code sit waiting for an event to occur blocking everything else the system was trying to do.
They also nod their heads in a direction that seems needless to a westerner
Use case is still a valid technique, its something that people do struggle with, but once everyone starts to understand it life becomes much easier. I didn't mention it because its probably a bit of a leap for the OP and team right now.
Outsourcing can be done, but you need a rigid working practice/structure around requirements, design, test plans (and running them), code quality and so on so that you aren't constantly chasing your tail fixing up stuff that isn't quite right. You cannot give someone a task to do written on the back of a fag packet and expected them to understand all the implications and nuances from that.
A properly defined requirement with some implementation detail, success criteria, test plan etc might just get you somewhere.
Sometimes all that is more work that just doing the thing in the first place - but you now need to track velocity etc to determine that.
Outsourcing can be done, but you need a rigid working practice/structure around requirements, design, test plans (and running them), code quality and so on so that you aren't constantly chasing your tail fixing up stuff that isn't quite right. You cannot give someone a task to do written on the back of a fag packet and expected them to understand all the implications and nuances from that.
A properly defined requirement with some implementation detail, success criteria, test plan etc might just get you somewhere.
Sometimes all that is more work that just doing the thing in the first place - but you now need to track velocity etc to determine that.
Gassing Station | Jobs & Employment Matters | Top of Page | What's New | My Stuff